ingress-nginx가 EOL인데 뭘로 갈아타야 하는가

ingress-nginx 커뮤니티 컨트롤러가 2026년 3월 EOL을 맞았다. Kubernetes 클러스터의 약 50%가 사용 중인 컨트롤러의 퇴장 — 무엇으로 갈아타야 하고, 언제 움직여야 하는가.

Kubernetes에서 외부 트래픽을 내부 서비스로 연결하는 일은 대부분 Ingress 리소스가 담당해왔다. 그리고 그 뒤에서 가장 많이 쓰인 컨트롤러가 ingress-nginx다. Kubernetes 1.35에서도 Ingress API 자체는 여전히 동작하고, HAProxy나 Traefik 같은 다른 Ingress 컨트롤러도 정상 운영 중이다. ingress-nginx의 EOL이 곧 Ingress의 끝은 아니다.

다만 이 EOL은 전환을 검토해야 하는 유일한 이유도 아니다. Ingress API 자체의 구조적 한계 — annotation 의존, 역할 분리 부재, HTTP 전용 — 는 HAProxy든 Traefik이든 모든 Ingress 컨트롤러에 공통으로 적용된다. Gateway API는 이 구조적 한계에 대한 Kubernetes SIG-Network의 공식 대안이다. 이 글에서는 Ingress의 한계를 짚은 뒤, Gateway API가 무엇을 다르게 하는지 살펴보고, 구현체별 비교와 환경에 따른 전환 판단 기준을 제시한다.

Ingress의 구조적 한계

Ingress가 단순히 “오래되었기 때문에” 교체되는 것은 아니다. 스펙 자체에 근본적인 제약이 있고, 많은 조직이 이를 구현체별 CRD, RBAC 정책, IngressClass 분리 등으로 보완해왔다. 이 보완책들은 표준이 아니라 조직 패턴에 의존하는 것이었고, 컨트롤러를 교체하면 함께 무너진다.

Annotation 의존 — Ingress 스펙이 제공하는 기능이 제한적이어서, 실질적인 설정은 대부분 annotation으로 처리한다. nginx.ingress.kubernetes.io/rewrite-target, proxy-body-size 같은 annotation은 NGINX 전용이다. 컨트롤러를 교체하는 순간, 이 annotation을 전부 새 구현체의 문법으로 번역해야 한다. “포터빌리티”라는 Kubernetes의 핵심 가치가 Ingress 레벨에서는 작동하지 않는 셈이다.

역할 분리의 스펙 부재 — 하나의 Ingress 리소스에 인프라 설정(TLS, 포트)과 앱 라우팅이 혼재한다. IngressClass와 RBAC을 조합하면 부분적으로 분리할 수 있지만, 스펙 차원에서 역할 분리를 지원하지 않아 구현체와 조직 패턴에 의존할 수밖에 없다.

HTTP 전용 — TCP, UDP, gRPC 라우팅은 Ingress 스펙에 없다. 별도 CRD나 ConfigMap 우회가 필요하고, 이것 역시 구현체마다 다르다.

정리하면, Ingress의 문제는 “기능이 부족하다”보다 “부족한 기능을 비표준 방식으로 채운다”에 가깝다.

Gateway API가 다른 점

Gateway API는 이러한 한계를 “역할 기반 리소스 분리”로 해결한다. Ingress에서 조직 패턴으로 보완하던 역할 분리를 스펙의 일급 개념으로 승격시킨 것이다.

GatewayClass     ← 인프라 제공자가 정의 (Envoy, NGINX 등)
  └─ Gateway     ← 플랫폼 팀이 관리 (리스너, TLS, 접근 정책)
       └─ HTTPRoute / GRPCRoute / TCPRoute  ← 앱 팀이 관리 (라우팅)
           └─ ReferenceGrant  ← 크로스 네임스페이스 참조 허용

멀티테넌트 환경에서 플랫폼 팀이 Gateway를 소유하고, 앱 팀이 독립적으로 HTTPRoute를 관리할 수 있다. 다만 이 다중 리소스 모델(GatewayClass, Gateway, Route, ReferenceGrant)은 Ingress의 단일 리소스 대비 초기 학습 곡선과 YAML 관리 복잡도가 존재한다. 역할 분리라는 설계적 이점이 이 초기 비용을 정당화하는지는 조직 규모와 멀티테넌시 요구에 따라 다르다.

이 글의 비교는 v1.2 기준이다. 이후 v1.3(2025.06)에서 CORS 필터, Retry Budget, Gateway Merging이 추가되었고, v1.5에서 TLSRoute가 Standard 채널로 승격되는 등 스펙은 빠르게 발전 중이다.

앞서 짚은 Ingress의 한계가 Gateway API에서 어떻게 달라지는지 비교하면 다음과 같다.

몇 가지 눈에 띄는 차이를 짚으면:

트래픽 분할이 네이티브다 — Ingress에서는 annotation으로 처리하던 카나리 배포가, Gateway API에서는 HTTPRoute의 weight 필드로 표준화되었다. annotation 없이 backendRef에 weight만 지정하면 된다.

크로스 네임스페이스 참조 — ReferenceGrant로 다른 네임스페이스의 서비스를 명시적으로 허용한다. Ingress에서는 같은 네임스페이스 내 서비스만 참조 가능했다.

다중 프로토콜 — HTTP, gRPC, TCP, UDP 라우팅을 각각 전용 Route 리소스로 다룬다. v1.2 기준 HTTPRoute와 GRPCRoute는 GA, TCPRoute와 UDPRoute는 Experimental 상태다. TLSRoute는 이후 v1.5에서 Standard 채널로 승격되었다.

타임아웃 — v1.2에서 Standard 채널로 승격된 HTTPRoute 필드로, annotation이 아닌 타입 안전한 스펙으로 요청/백엔드 타임아웃을 설정한다.

재시도 — v1.2에서 Experimental 채널로 도입되었다. 재시도 횟수, 백오프, 재시도 대상 상태 코드를 HTTPRoute에서 설정할 수 있지만, 아직 실험적 단계이므로 프로덕션 적용 시 주의가 필요하다.

Gateway API 구현체 비교

Gateway API는 스펙이고, 실제 트래픽을 처리하는 것은 구현체다. kube-proxy IPVS 교체 사례처럼, “무엇으로 바꾸느냐”가 “바꾸느냐 마느냐”보다 중요한 결정이다.

성능 벤치마크 (참고용)

아래 수치는 단순 HTTP 응답 기준의 커뮤니티 벤치마크이며, 워크로드 특성(L7 필터 사용 여부, TLS, gRPC), 리소스 스펙, 튜닝 상태에 따라 크게 달라진다. 실환경에서는 반드시 자체 측정이 필요하다.

Envoy 기반 구현체는 xDS API로 무중단 설정 갱신이 가능한 반면, NGINX Gateway Fabric은 설정 변경마다 worker 프로세스를 재생성한다. 설정 변경이 빈번한 환경(카나리 배포, 오토스케일링)에서 이 차이는 더 벌어진다. 다만 QPS 수치만으로 구현체를 판단하면 안 된다 — NGINX는 정교한 튜닝, 상용 모듈(NGINX Plus), 기존 운영 노하우라는 생태계 강점이 있고, Envoy도 필터를 많이 사용하면 처리량이 감소한다.

구현체별 포지셔닝

• Kgateway — Solo.io가 CNCF에 기증한 Sandbox 프로젝트(kgateway-dev/kgateway). Envoy 기반으로 벤치마크 성능이 최상위권이며, Solo.io의 상용 제품(Gloo)과 코어를 공유한다
• Envoy Gateway — Kubernetes SIG 거버넌스 하의 공식 구현체. 서비스 메시 없이 Gateway API만 필요한 환경에서 가장 표준적인 선택이다. Gateway API 적합성 점수가 가장 높다. 다만 xDS 기반 동적 설정은 NGINX 대비 운영 학습 곡선이 있다
• Istio — Gateway → sidecar mTLS까지 일원화된다. 서비스 메시를 이미 운영 중이라면 자연스러운 선택이지만, Gateway API만 필요한 환경에는 컨트롤 플레인과 CRD 복잡도가 과하다
• NGINX Gateway Fabric — NGINX 에코시스템을 유지하면서 Gateway API로 전환할 수 있다. 기존 NGINX 설정 노하우가 많은 조직에 유리하다. 동적 설정 성능은 열위이지만, 보안 모듈과 상용 서포트가 강점이다
• Cilium — eBPF 기반 CNI와 Gateway를 통합한다. 이미 Cilium을 CNI로 사용 중이라면 별도 프록시 없이 Gateway API를 활성화할 수 있다
• Traefik — 자동 설정, Let’s Encrypt 내장으로 개발/테스트 환경에서 빠르게 시작할 수 있다. 프로덕션에서도 사용되지만, 대규모 환경에서는 Envoy 기반 대비 생태계가 작다

기존 Ingress 리소스를 일괄 변환해야 한다면 ingress2gateway v1.0이 출발점이 된다. 30개 이상의 annotation 자동 변환을 지원하며, 변환 결과의 수동 검토는 여전히 필요하지만 초기 버전 대비 커버리지가 크게 개선되었다.

전환 판단 기준: 어떤 환경에서 어떻게 움직일 것인가

전환에는 두 가지 축이 있다. “컨트롤러를 바꿔야 하는가”와 “리소스 타입을 바꿔야 하는가”는 별개의 질문이다.

컨트롤러 전환

• ingress-nginx를 쓰고 있는가? → EOL이므로 컨트롤러 교체 필수. CVE 패치가 중단된 컨트롤러를 프로덕션에 두는 것은 보안 리스크다
• 다른 Ingress 컨트롤러를 쓰고 있는가? (HAProxy, Traefik 등) → 컨트롤러를 교체할 필요가 없다. 이 컨트롤러들은 정상 운영 중이며, 대부분 Gateway API도 이미 지원한다

리소스 전환

컨트롤러와 무관하게, Ingress 리소스 자체의 annotation 의존 문제는 HAProxy든 Traefik이든 동일하다. HAProxy가 Gateway API를 GA로 지원한다는 것은, 컨트롤러는 그대로 두고 Ingress 리소스를 HTTPRoute/Gateway로 점진적으로 전환할 수 있다는 뜻이다. 이렇게 하면 HAProxy 전용 annotation이 Gateway API 표준 필드로 대체되어, 나중에 구현체를 교체해도 리소스를 다시 작성할 필요가 없다.

대부분의 환경은 여기서 “컨트롤러 교체 + 리소스 전환”(ingress-nginx) 또는 “컨트롤러 유지 + 리소스 점진 전환”(HAProxy, Traefik) 중 하나로 결정이 끝난다.

구현체 선택

시급성이 판단되면, 다음 질문으로 구현체를 좁힌다.

• 팀의 역량과 운영 목표: 네트워크/서비스 메시 경험이 충분한가? SLO/SLI 목표는 무엇인가? 관리형 서비스(GCP ASM, AWS App Mesh 등)를 이미 사용 중인가?
• 서비스 메시가 필요한가? → 이미 운영 중이고 사이드카/정책/텔레메트리를 적극 활용 중이라면 Istio가 자연스럽다. 하지만 “도입 예정”이라는 모호한 계획만으로 Istio를 선택하면, 실제로는 Gateway만 쓰고 메시 기능은 비활성화된 채 복잡도만 떠안는 경우가 흔하다. Gateway 역할만 필요하다면 Envoy Gateway나 Cilium Gateway로 충분하다
• 메시 없이 표준 게이트웨이만 필요한가? → Envoy Gateway. SIG 거버넌스, 높은 적합성, 활발한 커뮤니티
• 클라우드 매니지드 서비스를 쓰고 있는가? → GKE, EKS 등에서 매니지드 Gateway를 제공한다면, 자가 호스팅 전환보다 매니지드 유지가 운영 비용 면에서 유리할 수 있다

정리

이 글에서 가져갈 수 있는 판단 기준은 세 가지다.

• 컨트롤러 교체와 리소스 전환은 별개의 질문이다 — ingress-nginx는 컨트롤러 교체가 시급하다. HAProxy나 Traefik은 컨트롤러를 유지하면서, Ingress 리소스를 Gateway API 리소스로 점진 전환하는 것만으로도 annotation 종속에서 벗어날 수 있다
• 구현체 선택은 환경과 팀 역량으로 갈린다 — 메시가 이미 있으면 Istio, 표준 게이트웨이만 필요하면 Envoy Gateway. 다만 QPS 수치나 “메시 도입 예정”같은 단일 축이 아니라, 팀의 운영 역량과 실제 요구사항을 기준으로 판단해야 한다
• Ingress → Gateway API는 기술 전환이 아니라 역할 모델 전환이다 — annotation 기반의 단일 리소스에서, 역할별로 분리된 리소스 모델로 바뀐다. 이것은 단순히 YAML을 바꾸는 것이 아니라, 플랫폼 팀과 앱 팀의 책임 경계를 재정의하는 작업이다