Ingress NGINX 은퇴, Gateway API로 안전하게 전환하세요!

본문에 따르면 쿠버네티스(Kubernetes)에서 Ingress API는 기존 서비스 네트워킹(Service Networking)을 담당했지만, 더 높은 표현력과 확장성을 위해 Gateway API가 차세대 표준으로 제시되었다. Ingress API는 Deprecated될 계획이 없으며, 두 API는 공존한다. Gateway API는 역할 기반 설계(Role-based Design)를 통해 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자가 각자의 책임 범위 내에서 리소스를 독립적으로 관리할 수 있도록 지원한다. 이는 기존 Ingress API의 단일 리소스 구조와 비교했을 때, 유연한 관리(Flexible Management)를 가능하게 한다.

글에서는 NGINX Gateway Fabric, Envoy Gateway, Istio Gateway, Cilium Gateway, Kong Gateway, Traefik Gateway, kgateway 등 7가지 Gateway API 구현체를 선정하여 PoC(Proof of Concept) 테스트를 진행했다. 각 구현체는 CNCF(Cloud Native Computing Foundation) 생태계와의 연관성, 커뮤니티 활성도, 프로덕션 환경에서의 검증 여부를 기준으로 선정되었다. 총 17개의 테스트 시나리오를 통해 기능 완성도를 평가했으며, Rate Limiting, TLS 종료, 트래픽 관리 등 다양한 기능을 검증했다. 테스트 결과, NGINX, Envoy, Istio, Cilium 4개 Gateway는 프로덕션 환경에 적합한 것으로 평가되었다.

NGINX Gateway Fabric은 NGINX의 안정성과 풍부한 문서, 대규모 커뮤니티를 기반으로 한다. 이미 NGINX를 사용 중인 조직에게는 기존 운영 경험을 활용할 수 있다는 장점이 있다. 하지만, Rate Limiting을 구현하려면 SnippetsFilter를 통해 로우 레벨의 NGINX 설정을 직접 주입해야 하므로, Envoy 기반 구현체에 비해 동적 설정 변경의 유연성이 떨어진다. 테스트 결과, 17개 시나리오 중 Rate Limiting을 제외한 모든 테스트를 통과했다. NGINX 환경에서 Gateway API로의 자연스러운 전환을 원하는 팀에 적합하다.

Envoy Gateway는 선언적 CRD(Custom Resource Definition)를 통한 Rate Limiting 네이티브 지원이 가장 큰 강점이다. BackendTrafficPolicy CRD 하나로 초당·분당 요청 제한을 직관적으로 설정할 수 있다. xDS 프로토콜 기반의 동적 설정, 풍부한 필터 체인, 뛰어난 관측성 역시 장점이다. 하지만 NGINX에 비해 상대적으로 역사가 짧아 커뮤니티가 성장 중이며, Envoy 자체의 복잡성으로 인해 학습 곡선이 존재한다. 새로운 프로젝트에서 Gateway API를 도입한다면, 가장 먼저 고려해볼 만한 선택지이다.

본문에서는 Ingress NGINX 은퇴 일정(2026년 3월)에 맞춰 마이그레이션을 위한 단계별 준비 사항을 제시한다. 먼저 현재 클러스터에서 Ingress NGINX 사용 현황을 파악하고, 특히 Annotation 사용 여부를 확인하여 마이그레이션 복잡도를 가늠해야 한다. Gateway API에 대한 학습과 함께 PoC 환경을 구축하여 구현체를 직접 다뤄보는 것이 중요하다. Dev 또는 Stage 환경에서 Ingress와 Gateway를 병행 운영하며 차이를 비교하고, 점진적으로 트래픽을 전환하는 시나리오를 검증해야 한다. 마지막으로, 팀의 기술 스택, 운영 경험, 요구사항에 따라 적합한 구현체를 선택하고, 문서화 및 표준화 작업을 병행해야 한다.