Kubernetes Gateway API

 (romaglushko.com)
11P by GN⁺ | ★ favorite | 댓글 5개
  • 2025년 11월 Kubernetes는 전체 클러스터의 40% 이상에서 사용되던 NGINX Ingress Controller의 2026년 3월 deprecation을 발표, 이 결정은 Gateway API를 Ingress API의 후속으로 자리매김하는 전환점이 됨
  • Gateway API는 inbound 트래픽 관리에 필요한 폭넓은 기능을 다루며, Ingress API보다 표현력이 높고 팀 간 관심사 분리를 명확히 함
  • Ingress API의 한계로는 좁은 API 범위, 경직된 확장성, 정책 강제 부재, 모호한 소유권 경계, 안전한 cross-namespace 미지원 등이 있음
  • Gateway API는 GatewayClass, Gateway, Listener, Route 등 분리된 리소스 모델과 ReferenceGrant, Policy attachment 같은 보안·확장 메커니즘을 제공
  • NGINX Ingress Controller의 반복된 CVE는 구조적 결함에서 비롯되며, 장기적으로는 Gateway API로의 마이그레이션이 유일한 근본 해결책임

Ingress의 진화 과정

  • 2014년 초기 Kubernetes에서는 Service 리소스가 애플리케이션을 노출하는 기본 수단
    • ClusterIP는 클러스터 내부 DNS 이름만 제공, 외부 접근 불가
    • NodePort는 모든 노드에 특정 포트를 열어 외부 트래픽 수용, 노드 IP가 공개되면 외부 노출 가능
    • LoadBalancer는 공인 IP를 가진 외부 로드밸런서를 프로비저닝해 트래픽 전달
    • ExternalName은 CNAME 레코드로 외부 서비스의 클러스터 내 별칭 제공
  • 네 가지 중 외부 노출이 직접 가능한 것은 NodePort와 LoadBalancer뿐
    • NodePort는 기초 프리미티브이나 너무 저수준, 노드 간 외부 로드밸런싱과 path 기반 라우팅을 직접 구현해야 함
  • LoadBalancer는 NodePort 위에 L4 로드밸런서(TCP/UDP)를 더해 자동 프로비저닝, Cloud Controller Manager가 담당
    • 단, 다수의 공인 IP·로드밸런서를 관리해야 해 비용 증가, 트래픽 중앙 관리 지점 부재
  • Service마다 별도 로드밸런서 대신, 단일 LoadBalancer Service가 모든 트래픽을 받아 NGINX 같은 reverse proxy Deployment로 전달하고 경로·호스트명 기준으로 라우팅하는 구조가 Ingress API와 Ingress Controller의 출발점

Ingress Controller

  • 2015년 Kubernetes 팀이 외부 HTTP(S) 트래픽을 내부 Service로 라우팅하는 규칙 정의 수단으로 Ingress API 도입

  • Ingress API는 IngressClass와 Ingress 두 리소스로 구성, 공통 인터페이스만 정의하고 실제 동작은 Ingress Controller 설치 필요

  • IngressClass

    • 어떤 컨트롤러가 특정 Ingress 리소스 집합을 처리할지 지정하는 cluster-wide 리소스
    • 동일 클러스터에서 여러 Ingress Controller를 병행 운영 가능하게 함, 각 컨트롤러는 자신의 IngressClass로 선택된 리소스만 감시
    • 컨트롤러는 IngressClass를 읽고 사용하기 위한 ClusterRole 권한 필요

  • Ingress 리소스

    • Ingress는 Ingress API의 주요 리소스로 여러 요소를 결합
      • path 기반(exact/prefix) 및 host 기반 매칭 규칙으로 내부 Service 라우팅 정의
      • 인바운드 트래픽의 TLS 설정 정의
    • 리소스 생성 시 Ingress Controller가 이를 감지해 자체 설정을 갱신하고 라우팅 규칙 적용

  • Ingress API의 문제점

    • 실제 운영 환경에서 다음 문제 발생: 매우 제한된 API 범위, 경직된 확장성, 정책 강제 부재, 모호한 소유권 경계, 안전한 cross-namespace 미지원

  • 매우 제한된 API 범위

    • Ingress API는 단순(simple)하다기보다 빈약(simplistic), 인그레스 트래픽 설정에 필요한 최소한만 다룸
    • NGINX에서 흔히 원하는 다음 기능을 직접 지원하지 않음
      • request timeout, CORS, max body size 제한, sticky cookie 세션, canary 트래픽 분할, rate limiting, header·query·cookie 기반 라우팅, header 수정
    • 이로 인해 custom annotation이 추가 설정 전달의 표준 방식이 됨, Traefik 등 일부 컨트롤러는 자체 CRD 사용
    • 여러 Ingress Controller를 동시 사용 시 통합 설정 방식 부재로 컨트롤러마다 annotation이 달라 이식성 저하
    • Ingress는 HTTP(S) 라우팅만 다루며 gRPC(L7)·TCP·UDP(L4)는 구현체마다 custom annotation으로 처리

  • 경직된 확장성

    • custom annotation은 문자열 key-value 쌍에 불과해 복잡한 설정을 문자열로 직렬화해야 하므로 표현력 부족

  • 정책 강제 부재

    • 애플리케이션 팀이 Ingress 리소스에 임의의 annotation을 추가 가능, 예를 들어 플랫폼 팀이 전체 라우트에 기대하는 rate limiting을 비활성화할 수도 있음
    • Ingress API 자체에 전역 동작 강제 메커니즘이 없어 Kyverno나 OPA Gatekeeper 같은 외부 정책 엔진에 의존

  • 모호한 소유권 경계

    • Ingress 리소스가 여러 설정을 혼재
      • 라우팅 규칙은 보통 애플리케이션 팀 소유
      • hostname·port 설정은 DNS·로드밸런서·네트워킹을 관리하는 플랫폼 팀 소유
      • TLS 설정은 인증서 프로비저닝을 담당하는 플랫폼 팀 소유
      • custom annotation은 양 팀 중 어느 쪽이든 소유 가능
    • umbrella Helm chart로 배포된 복잡한 시스템에서 Ingress는 보통 애플리케이션 subchart에 위치하나 플랫폼 팀도 일부를 갱신·강제해야 함
    • 단일 책임 원칙 관점에서 Ingress는 변경 사유가 둘 이상이므로 더 집중된 리소스로 분리하는 것이 바람직함

  • 안전한 cross-namespace 미지원

    • Ingress 리소스는 자신의 namespace 외부의 Service나 TLS secret을 참조 불가, rules[].backend.service에 namespace 지정 필드조차 없음
    • 우회책으로 동일 namespace에 ExternalName Service를 만들어 대상 Service의 클러스터 내 DNS 이름을 가리킬 수 있음
    • 단, 이 방식은 바로 confused deputy attack에 해당하는 문제 내포

Gateway API

  • Gateway API는 Ingress API의 차세대 버전으로 다음을 통해 한계 해소
    • 인바운드 트래픽 관리에 필요한 훨씬 넓은 기능을 다루며 표현력 강화
    • 일반적인 리소스 소유 패턴을 반영해 팀 간 관심사 분리 명확화
    • policies라는 정의된 확장 메커니즘과 유연한 cross-namespace 객체 참조 포함

GatewayClass

  • IngressClass와 유사하게 특정 Gateway 컨트롤러 배포가 소유하는 Gateway 집합을 정의, IngressClass와 사실상 같은 의미·구조
  • 추가 구현체별 Gateway 설정을 담은 custom resource 참조 가능
    • Gateway proxy 노출 방식, 부트스트랩·실행 기본 설정, 배포 롤아웃·스케일 방식, 기타 컨트롤러별 옵션 포함

Gateway

  • Gateway 리소스는 동적으로 프로비저닝되는 edge gateway를 나타내며, 인바운드 트래픽을 받아 적절한 백엔드 서비스로 라우팅하는 인프라 추상화

    • Ingress 설계의 Ingress Controller가 이 역할을 했으므로 정적으로 프로비저닝된 Gateway 인스턴스로 볼 수 있음

  • 각 Gateway는 GatewayClass를 참조해 어떤 컨트롤러가 프로비저닝·관리할지 지정, 가장 중요한 구성 요소는 listener 목록

  • Listeners

    • Gateway가 인바운드 트래픽을 수용하는 방식을 정의, 각 listener는 port·protocol·hostname 조합으로 기술되는 별개의 진입점
    • TLS termination 설정 가능, Ingress 세계에서는 이 정보가 Ingress 리소스 안에 존재했음
    • Route가 Gateway에 attach될 수 있는 가장 세분화된 단위

  • ListenerSet

    • listener는 진입점 설정을 중앙화하기에 좋으나 수백 개가 필요한 경우에는 부적합
    • 주된 사례는 단일 wildcard TLS 인증서 대신 서비스별 hostname·TLS 설정을 가진 HTTPS listener, 마이크로서비스 수만큼 listener 발생 가능
    • 단일 Gateway로 모델링 시 두 문제 발생
      • Gateway는 최대 64개 listener만 지원
      • 다수 팀이 listener·TLS를 관리하면 Gateway가 조정 병목이 됨
    • 이를 분산·멀티테넌트화하기 위해 ListenerSet 리소스 사용

  • 허용된 Listener와 Route

    • Gateway와 Route 개념 분리 후, 어떤 테넌트가 어떤 listener에 Route를 attach할지 통제하는 새 문제 발생
    • listener는 공유 인프라이며 용도가 상이, 예를 들어 데이터베이스로의 passthrough 채널인 tls-passthrough-db listener에는 HTTPRoute를 붙이는 것이 부적절하고 db 외 namespace에서 Route를 붙이는 것도 부적절
    • Route가 자율 관리 방식으로 추가되므로 오설정 방지를 위해 allowedRoutes 메커니즘 사용
    • allowedRoutes는 Gateway·ListenerSet과 특정 namespace·route 타입의 Route 간 신뢰 관계 수립

Routes

  • listener는 트래픽을 받지만 이후 처리 방법은 모르며, 이를 Route 리소스가 담당, Gateway API 유연성의 핵심

  • 여러 프로토콜을 다루는 다섯 가지 Route 리소스 존재

    • HTTPRoute: 강화·확장된 HTTP 트래픽 라우팅
    • GRPCRoute: gRPC 인지 라우팅
    • TLSRoute: TLS SNI 기반 라우팅
    • TCPRoute·UDPRoute: listener 포트의 TCP/UDP 트래픽을 백엔드로 직접 전달

  • 모든 Route 리소스(통칭 xRoutes)는 유사한 envelope 구조

    • parentRefs는 Route를 수용하는 부모 리소스(주로 Gateway, ListenerSet, service mesh의 Service 등)에 대한 typed object reference, 옵션 sectionName·port로 특정 listener 지정 가능
    • rules는 프로토콜별 라우팅 규칙·필터·설정 포함, 각 rule은 matches, 선택적 filters, 선택적 backendRefs로 구성, 필터가 요청을 완전히 처리하면 backendRefs 생략 가능
    • 프로토콜이 허용하면 hostnames 필드로 Route 수준 host 기반 라우팅 가능

  • HTTPRoute

    • L7 수준 HTTP(S) 트래픽 라우팅 규칙 정의

    • Traffic Matching

      • Ingress 유사 path·host 기반 라우팅, header·query·method 기반 매칭 규칙 지원
      • 예: 내부 클라이언트만을 위한 canary 릴리스를 header 기반 매칭으로 테스트 deployment에 라우팅 가능
      • 데이터 플레인은 가장 구체적인 규칙을 적용하므로 규칙 정의 순서는 무관

    • URL Rewrites

      • filter를 사용해 백엔드 도달 전 요청 URL 일부 rewrite 가능

    • Header Modifications

      • request·response 헤더를 추가·제거·수정하는 HeaderModifier 필터 제공
      • Cross-Origin Resource Sharing 설정용 전용 CORS 필터 제공, 개념상 응답 헤더 수정의 특수 사례지만 별도 필터 타입으로 노출

    • Redirects

      • 백엔드 전달 대신 클라이언트에 redirect 응답 반환 가능, 3xx path 기반 redirect 및 HTTP→HTTPS redirect 지원

    • Traffic Control

      • weight로 백엔드 서비스 간 트래픽 분할 가능, blue-green 배포·A/B 테스트 등에 유용
      • traffic mirroring은 프로덕션 트래픽 사본을 추가 백엔드로 보내며 RequestMirror 필터로 설정, 원 요청은 기본 백엔드로 진행
      • mirroring은 리팩토링·마이그레이션 시 구·신 버전 결과를 비교하는 tap-and-compare testing의 핵심 구성 요소

    • Sticky Sessions

      • session persistence 지원, cookie·header를 세션 마커로 설정해 동일 클라이언트 요청을 동일 백엔드 인스턴스로 일관 라우팅

    • External Authentication

      • gRPC 또는 HTTP 기반 실험적 external authentication 필터 지원, Gateway가 백엔드 전달 전 외부 인증 서비스로 요청 헤더 전송, 요청 본문은 명시적 활성화 시 전송
      • gRPC의 경우 외부 인증 서비스는 Envoy의 ext_authz protobuf API 구현 필요
      • HTTP의 경우 인증 성공 시 200 반환, 그 외 상태는 인증 실패로 처리

    • Retries & Timeouts

      • 특정 라우트에 retry 설정 가능, BackendTrafficPolicy는 retry storm 방지를 위한 전역 retry budget 제공

  • GRPCRoute

    • gRPC는 HTTP/2 기반이라 HTTPRoute로도 처리 가능하나 별도 리소스로 모델링하는 이유 존재
      • URL rewrite처럼 gRPC에 무의미한 옵션 분리로 각 리소스가 프로토콜에 맞게 독립 발전
      • gRPC 응답은 HTTP 200을 반환하면서도 grpc-status·grpc-message 헤더로 애플리케이션 오류 표현, 올바른 retry·메트릭에 중요
      • 고수준 gRPC 용어로 규칙 정의 시 사용자 경험 향상
    • HTTPRoute의 path matcher가 method matcher로 대체, 내부적으로는 path를 매칭하나 service·method 형태로 노출
    • request·response 헤더 처리는 가능하나 gRPC payload를 디코드하지 않아 특정 protobuf 필드 기반 라우팅 불가
    • traffic mirroring·weighted load balancing, header 수정 등 HTTPRoute 필터의 일부 지원

  • TCPRoute와 UDPRoute

    • listener 포트에 도달한 트래픽을 백엔드 서비스로 단순 전달, 현재 matcher·filter 미지원
    • 두 타입 모두 다중 백엔드 간 weighted load balancing 지원

  • TLSRoute

    • TLS handshake 중 제공되는 SNI 기반으로 TLS 암호화 트래픽을 백엔드로 라우팅
    • 주로 TLS passthrough에 사용, Gateway가 SNI를 확인해 백엔드 선택 후 TLS 종료 없이 암호화 연결 전달, 백엔드가 TLS 종료 담당
    • Envoy Gateway나 kgateway 같은 일부 구현체는 edge에서 TLS termination도 지원하나 이는 확장 기능
    • Route에 hostname 명시 필요, SNI 값과 매칭되며 Gateway listener의 hostname과 교집합 필요, matcher·filter는 미지원하나 weighted load balancing 지원

  • Route Filter Extensions

    • HTTPRoute와 GRPCRoute는 extensionRef 필터로 custom 필터·요청/응답 처리 확장 메커니즘 포함, typed object reference로 다른 리소스를 가리킴
    • 예: Envoy Gateway는 백엔드 서비스 없이 직접 응답을 반환하는 HTTPRouteFilter CRD 제공

  • Backend Targets

    • 기본적으로 표준 Service(가장 일반적)와 멀티클러스터용 ServiceImport를 백엔드 타깃으로 지원
    • typed object reference로 지정되므로 구현체별 custom resource로 확장 가능
    • 예: Envoy Gateway는 FQDN·IP·UNIX 소켓 등 외부 upstream을 가리키는 custom Backend 리소스 지원

  • ReferenceGrant

    • Gateway API는 cross-namespace 참조를 표준 설계의 1급 개념으로 다루나 보안 위험 존재
    • confused deputy attack 사례: 공격자가 한 namespace를 장악하면 Ingress·Service·EndpointSlice 생성 권한으로 보호된 서비스 접근 유출 가능
      • 새 Ingress가 손상된 namespace의 신규 Service를 가리킴
      • 해당 Service는 selectorless라 어떤 deployment와도 매칭되지 않아 수동으로 EndpointSlice 제공 가능
      • 공격자가 다른 namespace의 보호된 백엔드 pod IP를 포함하도록 EndpointSlice 위조, 포트 정렬로 보호 API에 두 번째 진입로 생성
      • ExternalName Service로도 동일 결과 도달 가능
    • 이를 완화하기 위해 ReferenceGrant 리소스 도입, 한 namespace가 자신의 리소스를 참조하도록 허용할 namespace를 정의하는 양방향 신뢰 메커니즘
    • Gateway Controller는 백엔드 타깃·TLS secret으로의 cross-namespace 참조 시 ReferenceGrant를 고려, confused deputy attack을 어렵게 만듦
    • 단, ReferenceGrant는 참조의 정당성만 보장하며 트래픽 전달 후 동작은 관여하지 않음, NetworkPolicies로 보호 API 포트 접근 차단 보완 가능

Policies

  • Policy attachment는 원본 리소스를 수정하지 않고 하나 이상의 Gateway API 컴포넌트에 계층적으로 동작·효과를 적용하는 강력한 확장 패턴
  • 인증이 대표 사례
    • Gateway(또는 ListenerSet) 전체에 인증을 적용하면 현재·미래의 모든 attach된 Route에 계층적으로 영향, 동시에 공개 라우트 같은 Route 수준 예외 가능
    • 인증은 Gateway·Route와 무관한 팀이 통제할 수 있어 해당 리소스를 직접 수정하지 않도록 설계
    • OAuth 2·OIDC 등 표준이 있어도 인증 설정은 구현체 의존성이 높아 모든 구현체에 통하는 추상화는 어려움
  • 예: Envoy Gateway의 SecurityPolicy 리소스로 JWT 토큰 검증 설정, Policy는 Ingress 시대의 annotation 기반 설정을 대체하는 현대적·표현력 있는 방식
  • 기본 제공 Policy는 둘뿐
    • BackendTLSPolicy: Gateway가 upstream 백엔드에 TLS로 연결하도록 지시
    • BackendTrafficPolicy: 특정 백엔드의 retry budget 지정, 전역 retry 허용량을 초과하면 503 반환, circuit breaker처럼 작동해 retry storm 방지

Ownership

  • 클러스터 내 Gateway API 리소스는 보통 두 팀이 소유
    • Platform team은 GatewayClass·Gateway·ListenerSet과 LoadBalancer·TLS 설정을 정의, 일부 또는 전체 Gateway에 적용되는 전역 Policy 관리 가능
    • Application/Service team은 주로 자신의 Route 리소스에 집중, 필요 시 Route 수준 Policy 적용
  • 유연성이 높아 Route를 플랫폼 팀이 한 namespace에 모아 소유하는 등 다양한 소유 모델 구성 가능

Typical Architecture

  • Gateway API는 구현 아키텍처를 크게 가정하지 않으나 흔한 방식은 control plane과 data plane 분리
  • Gateway Controller는 control plane 역할의 Kubernetes operator로 Gateway API 리소스·CRD를 감시해 원하는 data plane 설정을 종합, 리소스 읽기·수정을 위한 확장 권한 필요
  • Gateway data plane은 설정에 따라 트래픽을 처리하는 proxy, 흔히 Envoy Proxy·NGINX·Traefik 등 사용, 구현체에 따라 Gateway별 proxy 프로비저닝 또는 공유
  • control/data plane 분리는 NGINX Ingress Controller에서 발견된 근본적 보안 결함 회피에 유리한 설계 선택

Ingress 마이그레이션

  • NGINX Ingress Controller deprecation 대응 옵션은 네 가지, 침습도가 낮은 순서로 검토

  • Do Nothing

    • 최선은 아니나 일부 경우 가능, homelab에서는 동기가 적을 수 있음

    • 엔터프라이즈에서는 유지·패치된 소프트웨어 운영을 기대하는 규제·보안·컴플라이언스 프레임워크 때문에 용인하기 어려움

      • ISO 27001: 취약점 관리·패치·EOL 추적 기대
      • SOC 2 Type II: 취약점 스캔·패치 관리·교정 SLA 기대
      • HIPAA Security Rule: 레거시·미패치 소프트웨어를 위험 분석에 포함 필요
      • PCI DSS v4.0.1: 미지원 컴포넌트 식별·교정 계획 요구, 심각 취약점 처리 기한 규정
      • FedRAMP: 미지원 소프트웨어를 유지되는 대안으로 교체 기대, 심각도별 교정 기한 존재

    • 대부분 프레임워크에서 EOL 소프트웨어는 신규 취약점 공개 시 실질적 문제가 됨

    • CVE 분석

      • 지난 5년간 NGINX Ingress Controller CVE 현황
        • 전체 20건의 취약점
        • 2021년 secret 유출 관련 High 4건
        • 2022년 컨트롤러 credential 유출 관련 High 1건
        • 2023~2024년 High 3건
        • 2025년 6건, Critical 1건(IngressNightmare)과 NGINX 설정 주입 관련 High 4건 포함
        • 2026년 6건, NGINX 설정 주입 관련 High 3건 포함
      • 2021~2022년 CVE는 주로 annotation 내 미정제 사용자 제공 NGINX 설정 문제, 설정 주입·정보 노출·secret 유출 야기, Kubernetes가 validation 추가
      • 2023~2024년 CVE는 주로 그 annotation validation 우회
      • IngressNightmare(CVE-2025-1974) 는 상황 악화, 기존에는 Ingress 리소스 생성·수정 권한이 필요했으나 admission controller에 네트워크 접근만 있으면 설정 주입 유사 버그로 ingress-nginx 컨트롤러 맥락에서 원격 코드 실행 가능, 이후 컨트롤러가 접근 가능한 Secret 유출 가능
      • 2026년 배치도 annotation·path·comment를 통한 설정 주입 패턴 지속
      • 이 취약점들은 설계의 동일 약점을 반복적으로 노림
        • 컨트롤러가 매우 유연해 광범위한 NGINX 기능을 노출, 완벽한 validation이 어려워 설정 주입이 반복 발생
        • 컨트롤러가 control plane과 data plane을 같은 pod에서 실행하고 파일시스템을 공유해 사고 시 영향 범위 확대
        • 컨트롤러가 클러스터 전역 Secret에 접근하는 경우가 많아 설정 주입 성공이 클러스터 전역 secret 유출로 이어질 수 있음
      • 구조적 문제로 향후 추가 CVE 예상, 마이그레이션 계획 없이 원본 컨트롤러에 머무르는 것은 위험한 선택

  • NGINX Controller Fork 사용

    • 가장 단순한 경로는 유지되는 fork로 전환
      • Chainguard의 fork는 빌드된 이미지를 제공하지 않는 것으로 보이며 이는 판매 대상의 일부
    • 신규 CVE 노출 위험을 줄이고 큰 변경 없이 시스템 유지 가능하나 단기 해결책
    • Chainguard는 장기 프로젝트로 컨트롤러를 계속 개발하려는 것이 아니라 사용자에게 마이그레이션 시간을 벌어주기 위한 best-effort CVE 교정 제공

  • 다른 Ingress Controller 사용

    • Ingress 리소스 자체는 deprecated가 아니므로 유지되는 다른 Ingress Controller로 전환도 유효, 대표적으로 HAProxy·Istio·Traefik
    • 시스템 전반의 annotation 마이그레이션 필요, NGINX 특화 기능 의존도에 따라 난이도 상이
    • 향후 더 많은 프로젝트가 Gateway API로 이동하며 Ingress 비중은 줄겠으나 당분간 Ingress도 충분히 무방

  • Gateway API로 마이그레이션

    • 유일한 장기 옵션은 Ingress API에서 Gateway API로의 이전
      • Gateway API CRD·구현체 설치
      • GatewayClass·Gateway·필요 시 Policy 리소스 설정
      • 기존 Ingress 리소스를 Route로 마이그레이션
    • Kubernetes 팀이 만든 ingress2gateway CLI가 best-effort 자동 변환 제공, custom annotation은 이후 직접 재확인 필요
    • timeout, file upload 한도, body size 한도 등을 정확히 마이그레이션해야 하며 누락·오매핑 시 애플리케이션 가정을 조용히 깨뜨릴 수 있음
    • Ingress Controller의 LoadBalancer에서 새 Gateway proxy의 LoadBalancer로의 트래픽 전환을 신중히 계획해야 하며 big-bang일 필요는 없음
      • Ingress Controller를 공개 진입점으로 임시 유지하며 일부 트래픽만 Gateway API data plane으로 보내 실트래픽 테스트 후 점진 전환 가능

어떤 Gateway를 선택할 것인가

  • 마이그레이션 결정 후 첫 큰 질문은 어떤 Gateway API 구현체를 쓸 것인가

  • 본 글의 generic API Gateway 사례 정의: 완전히 통제하는 환경에 배포되는 public North-South 트래픽용 확장 가능 게이트웨이로, 일반적 인증 패턴과 유연한 rate limiting을 기본 제공

  • API Gateway 외에 LLM Gateway·Agent Gateway도 존재하나 본 절은 고전적 API Gateway에 집중

  • Gateway API Conformance

    • Kubernetes 팀이 구현체의 핵심 프로토콜 처리 정확성을 검증하는 표준 conformance 테스트 마련, 주로 기능적 동작에 초점, 신뢰성·성능·확장성·운영 복잡성 등 비기능적 측면은 미포함
    • conformant 구현체를 선호해야 하며, 공식 사이트에 결과가 없으면 메인테이너에게 conformance 보고서 요청 권장

  • Public Benchmarks

    • 공식 테스트 외에 신뢰성·성능을 다루는 공개 벤치마크 존재, Istio 기여자이자 Solo.io 직원인 John Howard가 주요 구현체 벤치마크 제작, Solo.io는 kgateway의 모회사
    • Route attachment·전파·스케일·일반 트래픽 처리 성능 등 유용한 테스트 케이스 포함, 본인 경험 기반이라 특정 사례에 치우칠 수 있으나 평가의 한 관점으로 활용

  • OSS vs Proprietary

    • 오늘날 강력한 프로덕션급 OSS Gateway API 구현체가 많아 평가 시 진지하게 고려, 다수 조직에 OSS가 기본 출발점
    • OAuth2·OIDC처럼 과거 상용 구매를 정당화하던 기능이 commodity화, OSS 컨트롤러도 기본 제공
    • OSS는 커밋 전에 직접 품질 평가가 가능하나 상용은 벤더를 일찍 신뢰해야 함

  • Recommendations

    • data plane 기준 그룹화

      • Envoy Proxy 기반: Envoy Gateway, Istio, Cilium, kgateway 등
      • NGINX 기반: NGINX Gateway Fabric, Kong
      • 기타 proxy: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Envoy Proxy 팀이 개발한 Envoy Proxy 기반 오픈소스 Gateway API 컨트롤러, Envoy 기능을 Gateway API에 최대한 직접 매핑해 Istio보다 제품 특화 추상화가 적어 이해 용이
      • Ingress API는 미지원, Envoy AI Gateway로 LLM·MCP gateway·Inference Pools 기능 확장 가능
      • 가볍고 배포·운영이 간단하며 API Gateway(North-South)에 집중, 지원 기능
        • external authentication·JWT 검증·JWT claim 기반 authorization·OIDC·IP allowlisting·static API key 인증·credential injection 등 보안 패턴
        • 전역·라우트 수준 설정, shadow mode, request cost 설정 등을 갖춘 유연한 global rate limit policy
        • connection·bandwidth·file size 제한, availability zone 인지 라우팅, ServiceImport 기반 기본 멀티클러스터, Brotli·gzip·zstd 응답 압축, direct response·response override
      • 확장성도 높음: 요청·응답·xDS 설정 수정용 gRPC 서비스 작성 가능, Lua 또는 WASM 컴파일 가능 언어(Go·Rust)로 플러그인 작성 가능
      • FQDN·IP 외부 리소스, sidecar용 UNIX 소켓을 가리키는 custom Backend 리소스 포함
      • 현재 일부 스킵 테스트로 partially conformant로 등재되나 기능상 거의 모든 항목 충족, KEDA·KNative 등 CNCF 프로젝트와 통합
      • 풍부한 기능의 API Gateway만 필요하다면 좋은 선택지

    • Istio

      • Envoy Proxy 기반 service mesh이자 CNCF Graduated 프로젝트, Gateway API 테스트에 conformant로 등재
      • Ingress Controller·Gateway API 컨트롤러·service mesh를 포함하는 패키지, agentgateway 연동으로 LLM·MCP·A2A gateway 기능 제공 가능
      • Admiral 등으로 고급 멀티클러스터 지원, 넓은 배포 프로필·큰 커뮤니티·O'Reilly 서적 등 풍부한 자료, mTLS 기반 pod-to-pod 암호화로 정부·FedRAMP 환경에 유용
      • 단점으로 sidecar 모드에서 자원 소모가 크고 자체 개념이 많아 학습 곡선이 가파름
      • ambient mode로 경량 setup 제공하나 고급 L7 사례에서는 sidecar만큼 기능적이지 않을 수 있음, 더 강한 정책·L7 제어가 필요하면 Envoy Gateway를 ingress gateway·waypoint proxy로 병용 고려
      • service mesh가 먼저고 Gateway API가 부차적일 때 최선, API gateway만 필요하면 다소 부족하게 느껴질 수 있음

    • kgateway

      • Gloo 프로젝트 기반 오픈소스 CNCF Sandbox 게이트웨이, data plane으로 Envoy Proxy와 agentgateway(AI gateway 기능) 지원, 외부에서 관리되는 자체 data plane 인스턴스 사용 가능
      • 완벽한 Gateway API conformance로 거의 유일하게 모든 항목 충족
      • Envoy data plane에서 JWT 검증·OAuth2/OIDC·external authentication·IP 접근 제어, Envoy global rate limiting, ext_proc 기반 요청·응답 처리 노출, 단 Lua·WASM 플러그인이나 raw xDS 직접 수정은 노출하지 않는 것으로 보임
      • MiniJinja 템플릿 기반 강력한 transformation 엔진으로 TrafficPolicy 리소스에서 header·response body·status 변환을 선언적으로 정의
      • Istio와 edge proxy로 통합 가능하나 자체 service mesh 역할은 아님, 하나의 Route가 다른 Route로 트래픽 처리를 위임하는 계층적 Route 지원, AWS Lambda를 직접 호출하는 custom AwsLambda CRD 보유
      • 벤더의 넓은 배포 주장에도 독립적 피드백이 많지 않아 공개 커뮤니티 관점에서는 아직 성장 중인 프로젝트로 보임

    • Traefik

      • Go로 작성된 인기 오픈소스 reverse proxy, Ingress API와 Gateway API 모두 지원, 우수한 문서·정돈된 코드베이스·간단한 설정·쉬운 배포로 특히 homelab 커뮤니티에서 인기
      • 핵심 Gateway API 기능과 일부 추가 기능 지원하나 ListenerSet·Gateway API를 통한 traffic mirroring은 아직 미지원(custom TraefikService 백엔드로는 mirroring 가능)
      • 확장 모델은 middleware 기반, ExtensionRef 필터로 Route를 Middleware CRD에 연결, 내장 middleware로 ForwardAuth(외부 인증 위임, Envoy ext_authz 유사), IP allowlisting·CORS, connection 제한·retry·circuit breaker, 압축·custom error page 등 제공
      • Plugin middleware로 custom YAEGI·WASM 플러그인 연결 가능(주로 요청·응답 수정), JWT 검증·OIDC·OAuth2 Client Credentials는 유료 플러그인으로만 제공
      • Middleware CRD로 기본 분산 rate limiting 지원(IP·host·header 버킷)하나 설정이 유연하지 않고 policy attachment가 아닌 ExtensionRef로 붙어 전역 적용 후 라우트 수준 override 같은 계층화가 어려움
      • 명확한 control/data plane 분리가 없어 아키텍처가 NGINX Ingress에 가까움, 동일 pod가 리소스 감시·트래픽 처리, Gateway별 proxy를 동적 프로비저닝하지 않고 단일 deployment가 감시 namespace의 모든 Gateway 관리, 단일 장애점·격리 저하로 대규모에서 복원력 문제 가능
      • 선택 시 예상 트래픽으로 load test 권장, 특히 Traefik의 성능 불만을 들은 바 있어 더 주의 필요

    • NGINX Gateway Fabric

      • NGINX 기반 F5의 공식 Gateway API 구현체(NGF), 견고한 conformance를 가지며 최근 버전에서 Gateway API 1.5, 표준 HTTPRoute 필터를 통한 CORS·request/response header 수정 지원 추가
      • JWT·OIDC 인증, cookie 기반 session persistence, NGINX reload 없는 upstream 갱신 등 일부 기능은 여전히 NGINX Plus에 종속, 이는 흔한 API Gateway 요구사항
      • custom SnippetsPolicy·SnippetsFilter로 생성 config의 여러 수준에 custom NGINX 설정 주입 가능, 기존 NGINX Ingress의 방대한 custom 설정을 재작성하지 않고 마이그레이션 용이화
      • custom RateLimitPolicy로 rate limiting 지원하나 local rate limiting이라 상태가 NGINX data plane에 존재, 다중 NGF 복제본 운영 시 인스턴스 수에 따라 실효 한도가 달라져 엄격한 사용자 단위 제한이 어려움
      • NGINX 자체 확장 escape hatch로 경량 JavaScript·Lua 스크립팅, 외부 인증 위임용 auth_request(Envoy ext_authz·Traefik ForwardAuth 유사), custom C 모듈 제공, 단 ext_proc 방식의 외부 서비스 기반 요청/응답 수정은 미지원
      • NGF 2.0에서 아키텍처를 개편해 control/data plane 분리와 다중 Gateway 리소스 지원, 이전에는 아키텍처가 큰 우려였음

    • Cilium Service Mesh

      • 다수 클러스터가 CNI로 Cilium 사용, eBPF 기반 sidecar-less service mesh에 Envoy Proxy 기반 Gateway API 구현 포함, 구성 요소를 줄이고 기술 스택을 슬림화 가능
      • 다만 주로 Gateway API conformance에 초점, Gateway API 외 유용한 Envoy 기능이 1급 설정으로 노출되지 않음, 예로 Envoy 확장·플러그인, IP allowlisting, JWT 검증·claim 기반 authorization·OIDC의 1급 지원 부재
      • Cilium의 현재 Gateway API 기능으로 충분하다고 확신하지 않는 한 Envoy Gateway·kgateway·Istio 등 더 풍부한 옵션보다 범용 API Gateway로 권장하지 않음

    • Kong

      • NGINX 기반의 인기 API Gateway, Kong Operator가 Ingress·Gateway API 모두 지원
      • 주된 우려는 OSS 전략, 신규 오픈소스 Gateway 버전의 prebuilt Docker 이미지 발행을 중단한 것으로 보이며 OSS 이미지가 3.10 릴리스 라인 무렵 멈춰 직접 빌드·패치·강화·유지가 필요할 수 있음
      • 이 조치가 enterprise 고객 이탈 감소와 관련됐다는 공개 추측 존재, 확정 사실로 볼 수는 없으나 OSS 방향이 덜 예측 가능하게 느껴짐
      • 따라서 enterprise 라이선스를 구매하거나 OSS 패키징·유지를 스스로 떠안을 준비가 되지 않는 한 권장하지 않음

Summary

  • Kubernetes 인그레스 패턴의 진화를 초기부터 Gateway API 시대까지 추적하고, Gateway API 프로토콜 자체를 심층적으로 다룸
  • GAMMA(Gateway API 아이디어를 service mesh로 확장)와 Inference Extension(Kubernetes 추론 워크로드 정의·최적화)은 의도적으로 범위에서 제외, 별도 심층 논의가 필요한 주제
  • 사용 가능한 Gateway API 구현체와 선택 기준을 함께 검토

함께 보면 좋은 글 β

calmlake79   [-]

실제로 사용해 보면 실망을 금치 못함.
작년에 이걸 적용해서 업데이트 해보려다가 실제로는 클라우드 벤더들이 구현을 아예 안한게 아니고, API 자체에서 지원을 안한다는것을 뒤늦게 알게되서 결국 전부 다시 롤백함.
아직 로드밸런서와의 연계라던가, 혹은 기타 세세한 정책들이 전부 문서상에만 존재함.
구현이 다 되면 그때 다시 써볼듯.

답변달기
comnwav   [-]

envoy gateway를 구현체로하여 프로덕션에서 훌륭하게 사용중입니다

답변달기
click   [-]

작년에 NGF 써보려고 했는데 Authorization 헤더 기반 인증을 만들 방법이 없어서 envoy로 갔었던 기억이 있네요
envoy보다는 nginx를 선호해서 gateway api 전체 지원되면 다음엔 NGF를 써볼까 싶어요

답변달기
hmmhmmhm   [-]

Envoy 가 더 뜨겠군요

답변달기