[Kubernetes] 🌐 Ingress에서 Gateway API로: HTTPProxy vs HTTPRoute 비교

쿠버네티스에서 앱 트래픽을 라우팅하는 방법은 Ingress로 시작해 벤더별 CRD를 거쳐 표준 Gateway API(HTTPRoute·GRPCRoute)로 수렴하고 있습니다. 이 글에서는 그 진화의 흐름과 함께, 설정(API)과 엔진(Envoy)이 다른 층이라는 핵심 구분, 그리고 Contour 전용 HTTPProxy vs 표준 HTTPRoute의 차이를 실무 관점에서 정리합니다.

이 시리즈는 쿠버네티스 gRPC 삽질에서 출발해 HTTP/2·TLS·로드밸런서·Gateway API·인증서까지 풀어가는 기록입니다. 이번 5편은 Ingress → Gateway API 편입니다. 앞선 3편(L4 vs L7), 4편(트래픽 구조)을 먼저 보면 좋습니다.

🧩 먼저: API(설정)와 엔진(Envoy)은 다른 층이다 #

Ingress·HTTPProxy·Gateway API는 “설정(API)“이고, Envoy·nginx는 그 설정을 실행하는 “엔진"입니다. 이걸 안 나누면 “Gateway → Envoy → HTTPRoute” 식으로 머릿속에서 다 섞입니다. 두 층을 분리합시다.

• API 층 (내가 쓰는 설정): Ingress, HTTPProxy, Gateway API(Gateway + HTTPRoute + GRPCRoute). “이렇게 라우팅해라"라고 적는 문서입니다.
• 데이터 플레인 엔진 (실제로 트래픽을 처리하는 것): Envoy(또는 nginx). 내가 적은 설정대로 진짜 패킷을 나르는 프록시입니다.

💡 Envoy는 API가 아니라 엔진입니다. Contour도, Istio도, Envoy Gateway도 전부 그 밑에서 Envoy를 엔진으로 씁니다. 그러니 “Gateway API라는 설정을 Envoy라는 엔진이 실행한다"가 올바른 그림입니다. Envoy를 HTTPRoute와 같은 줄에 두면 안 됩니다.

🧬 진화의 흐름 #

쿠버네티스 라우팅 API는 3세대를 거쳐 진화했습니다.

1세대: Ingress (원조, 빌트인) #

Ingress API는 쿠버네티스 1.19(2020)에서 GA가 된 기능으로, 오랫동안 HTTP 서비스를 노출하는 표준이었습니다. 하지만 너무 단순해서 컨트롤러마다 부족한 기능을 애너테이션으로 메우기 시작했고, 설정이 파편화되고 이식성이 떨어졌습니다.

2세대: 벤더별 CRD #

벤더들이 각자 풍부한 CRD를 만들어 한계를 메웠습니다 — Contour의 HTTPProxy, Istio의 VirtualService, Traefik의 IngressRoute처럼요. 기능은 좋았지만 전부 벤더 락인이었습니다.

3세대: Gateway API (표준) #

그 교훈을 모아 커뮤니티가 표준으로 수렴한 게 Gateway API입니다. GatewayClass·Gateway·HTTPRoute·GRPCRoute 같은 타입화된 리소스로, 벤더 중립적이고 이식성이 높습니다.

⚔️ HTTPProxy vs HTTPRoute #

HTTPProxy는 Contour 전용 CRD이고, HTTPRoute는 표준 Gateway API의 일부입니다. 둘 다 L7 라우팅을 하지만 출신이 다릅니다.

한 줄로: “한 벤더 전용이지만 성숙(HTTPProxy)” vs “표준이라 이식성 높음(HTTPRoute)”.

gRPC 라우팅을 표준으로 작성하면 다음과 같습니다.

 1# GRPCRoute (Gateway API 표준)
 2apiVersion: gateway.networking.k8s.io/v1
 3kind: GRPCRoute
 4metadata:
 5  name: my-grpc-route
 6spec:
 7  parentRefs:
 8    - name: my-gateway       # 플랫폼팀이 만든 Gateway 참조
 9  rules:
10    - matches:
11        - method:
12            service: helloworld.Greeter   # gRPC 서비스명으로 매칭
13      backendRefs:
14        - name: my-grpc-svc
15          port: 8080

🤝 역할 분리 — Gateway API의 핵심 장점 #

Gateway API는 플랫폼팀(인프라)과 앱팀(라우팅)의 책임을 공식적으로 나눕니다.

즉 플랫폼팀이 인프라(Gateway)를, 앱팀이 라우트를 따로 소유하는 구조입니다. 이 “관심사의 분리(separation of concerns)“가 핵심 이점입니다. (다음 6편에서 TLS 인증서를 이 구조로 중앙화하는 걸 다룹니다.)

🕸️ 왜 Istio 문서랑 비슷하게 느껴질까 #

Istio의 자체 CRD(VirtualService·Gateway·DestinationRule)가 Gateway API 설계에 큰 영향을 줬기 때문입니다. Istio는 Envoy 기반 서비스 메시이고, 지금은 Istio도 Gateway API를 지원합니다. 그래서 “어디서 본 것 같다"는 감이 정확합니다.

단, 결이 하나 다릅니다.

• Gateway API / Ingress = north-south 트래픽 (외부 ↔ 클러스터)
• 서비스 메시 = east-west 트래픽 (서비스 ↔ 서비스)

둘은 경쟁이 아니라 보완 관계입니다.

📅 2026년 현재 상태 #

빠르게 변하는 영역이라 작성 시점(2026년 6월) 기준이며, 최신 공식 문서 확인을 권장합니다.

• Gateway API: 2023년 10월 v1.0 GA에 도달했고, 2026년 들어 v1.5까지 릴리스되며 여러 기능이 Standard(Stable)로 승격된 성숙·프로덕션 레디 상태입니다. SIG Network의 공식 권고는 Gateway API로의 이전입니다.
• Ingress는 사라지지 않습니다. Ingress API 자체는 폐기·제거 계획이 없고, 다만 더 이상 적극 개발되지 않는 “feature-frozen” 상태입니다.
• ⚠️ 주의 — ingress-nginx 은퇴: 가장 널리 쓰이던 커뮤니티 ingress-nginx 컨트롤러는 2026년 3월 retired 되었습니다. 저장소는 kubernetes-retired로 옮겨져 read-only가 되었고, 더 이상 릴리스·버그픽스·CVE 패치가 없습니다. 기존 배포는 계속 동작하지만 신규 보안 취약점은 패치되지 않으므로 마이그레이션이 권장됩니다. (이는 커뮤니티 프로젝트 얘기이며, F5/NGINX의 상용 컨트롤러는 별개입니다.) 이전을 돕는 공식 도구 ingress2gateway도 제공됩니다.
• 표준이라 구현체가 여럿입니다. 완전 적합 구현으로 Envoy Gateway·Istio·NGINX Gateway Fabric·Traefik·Cilium·kgateway 등이 있고, Contour·AWS LB Controller·GKE Gateway·Kong 등은 부분 적합입니다.

🎯 실무 권장 #

신규로 시작한다면 Gateway API가 자연스럽고, 잘 돌아가는 Ingress 설정이 있다면 구체적인 한계에 부딪힐 때 옮기면 됩니다. 1편에서 HTTPProxy를 썼더라도 당장 바꿀 필요는 없지만, 신규 설계·멀티 벤더·이식성이 중요하면 HTTPRoute/GRPCRoute 방향이 미래지향적입니다. 다만 ingress-nginx를 쓰고 있다면 은퇴(EOL)로 인해 이전이 사실상 필수입니다.

📝 한 줄 요약 #

• Ingress(원조, 애너테이션 한계) → 벤더 CRD(HTTPProxy 등) → 표준 Gateway API(HTTPRoute·GRPCRoute)로 진화 중입니다.
• HTTPProxy는 Contour 전용, HTTPRoute는 표준이라 이식성이 높습니다.
• API(설정)와 Envoy(엔진)는 다른 층입니다.

❓ 자주 묻는 질문 #

Q. HTTPProxy와 HTTPRoute 중 무엇을 써야 하나요? #

이식성·표준·멀티 벤더가 중요하면 HTTPRoute(Gateway API)를 권장합니다. 이미 Contour와 HTTPProxy로 잘 돌아가고 있다면 당장 바꿀 필요는 없지만, 신규 설계는 표준 방향이 미래지향적입니다.

Q. Ingress는 이제 안 쓰나요? #

Ingress API 자체는 제거 계획이 없는 feature-frozen 상태로 계속 동작합니다. 다만 커뮤니티 ingress-nginx 컨트롤러가 2026년 3월 은퇴해 CVE 패치가 중단되었으므로, 해당 컨트롤러 사용자는 마이그레이션이 필요합니다.

Q. Gateway API와 서비스 메시(Istio)는 무엇이 다른가요? #

Gateway API는 north-south(외부↔클러스터) 트래픽을, 서비스 메시는 east-west(서비스↔서비스) 트래픽을 주로 다룹니다. 경쟁이 아니라 보완 관계이며, Istio는 Gateway API도 지원합니다.

Q. Envoy와 Gateway API의 관계는? #

Envoy는 트래픽을 실제로 처리하는 데이터 플레인 “엔진"이고, Gateway API는 “이렇게 라우팅하라"를 적는 설정(API)입니다. Contour·Istio·Envoy Gateway 등이 Gateway API 설정을 받아 Envoy 엔진으로 실행합니다.

📚 참고 #

• Gateway API v1.0: GA Release (Kubernetes Blog)
• Gateway API v1.5: Moving features to Stable (Kubernetes Blog)
• Ingress NGINX Retirement: What You Need to Know (Kubernetes Blog)
• Gateway API 공식 문서 - Implementations
• ingress2gateway - 마이그레이션 도구
• 관련 글: 트래픽 구조 (4편) · L4 vs L7 (3편)