Ingress NGINX 종료 이후를 준비하는 관점 Gateway API 전환, 어떻게 접근해야 할까?
쿠버네티스 환경에서 외부 트래픽을 서비스로 연결하는 방식으로 Ingress는 오랫동안 사실상의 표준 역할을 해왔습니다.
그중에서도 NGINX 기반 Ingress Controller는 전 세계적으로 가장 널리 사용된 구현체였습니다.
실제로 F5 NGINX가 공개한 자료에 따르면,
오픈소스 Ingress-NGINX(ingress-nginx) 는 한때 약 40% 수준의 시장 점유율,
누적 1,000만 회 이상의 다운로드를 기록한 대표적인 Ingress 솔루션으로 언급되어 왔습니다.
그러나 이 사실상의 표준이 이제 명확한 전환 시점을 맞이하고 있습니다.
⚡Ingress-NGINX 은퇴(EOL), 무엇이 달라지는가?
2025년 11월, Kubernetes SIG Network 는
커뮤니티 Ingress-NGINX(ingress-nginx) 프로젝트의 은퇴(retirement) 를 공식 발표했습니다.
발표 내용의 핵심은 다음과 같습니다.
2026년 3월까지: best-effort 수준의 유지보수 제공 2026년 3월 이후: 신규 릴리스 중단, 버그 수정 중단, 보안 패치 중단 |
|---|
즉, 쿠버네티스 커뮤니티가 유지해오던 Ingress-NGINX 프로젝트가 종료된다는 의미입니다.
여기서 반드시 짚고 넘어가야 할 점이 있습니다.
⚡Ingress-NGINX 종료 = NGINX 종료는 아니다
현장에서 가장 자주 발생하는 오해는 다음과 같습니다.Ingress-NGINX가 끝난다 = NGINX 자체가 끝난다 이는 사실이 아닙니다.
종료되는 것은 커뮤니티 Ingress-NGINX(ingress-nginx) 프로젝트이지
NGINX 웹서버나 리버스 프록시 자체가 종료되는 것이 아닙니다.
NGINX 기반의 다른 컨트롤러·게이트웨이 역시 동시에 종료되는 것이 아닙니다.
실제로 F5 NGINX는 Ingress-NGINX 은퇴 이후의 대안으로 Gateway API 기반 컨트롤러 전략을 명확히 제시하고 있습니다.
즉, 지금의 변화는 NGINX의 종말이 아니라 Ingress라는 모델 자체의 세대 교체에 가깝습니다.
⚡Ingress 이후의 표준: Gateway API란 무엇인가?
현재 쿠버네티스 커뮤니티가 공식적으로 제시하는 대안은 Gateway API입니다.
Kubernetes 공식 문서에서는 Gateway API를 다음과 같이 설명합니다.
Role-oriented: 역할 기반 분리 (Gateway / Route / Policy)
Expressive: 더 풍부한 트래픽 표현력
Extensible: 확장 가능한 표준 모델
기존 Ingress에서는 annotation으로 우회 구현해야 했던 기능들
예를 들어 가중치 기반 트래픽 분기, 헤더 기반 라우팅, 세밀한 정책 제어를
표준 리소스 모델로 공식 수용한 것이 Gateway API의 핵심 변화입니다.
⚡Gateway API 전환의 현실적인 고민
어떤 구현체를 선택할 것인가?
Gateway API로의 전환을 논할 때, 실제 운영 리스크를 좌우하는 질문은 이것입니다.
어떤 Gateway API 구현체(Controller)를 선택할 것인가?
Kubernetes Gateway API 프로젝트는
구현체별 Conformance(표준 적합성) 와 GA(운영 성숙도) 상태를 공개하고 있습니다.
그중 다음 세 구현체는 Conformant + GA로 분류되어, 운영 환경에서 선택 가능한 상태로 평가받고 있습니다.
Envoy Gateway
NGINX Gateway Fabric
Traefik Proxy
또한 NHN Cloud 의 NKS(Kubernetes Service) 환경에서도
이들 구현체는 특정 CNI 전환을 요구하지 않고,
일반적인 Kubernetes CNI 구조에서 동작 가능해 환경 충돌 가능성이 낮은 편입니다.
이제 각 구현체를 운영 현실 관점에서 살펴보겠습니다.
1️⃣ Envoy Gateway 표준 기반으로 기술을 리딩하려는 조직에 유리한 선택
Envoy Gateway는 CNCF 생태계에서 발전해 온 Envoy Proxy 기반 Gateway API 구현체입니다.
공개 자료 기준으로 2024년 3월 GA에 도달했으며,
Gateway API Conformance 및 GA 기준을 모두 충족합니다.
대형 조직이 Envoy Gateway를 검토할 때 주로 보는 강점은 다음과 같습니다.
표준 중심성 : Gateway API 모델에 충실하며, 향후 기능 확장 시 커뮤니티 흐름과의 정합성이 높음
고급 트래픽 제어 : HTTPRoute 기반 매칭·정책 모델로 Ingress의 annotation 의존을 제거
관찰성(Observability) 친화성 : Envoy 생태계의 메트릭·로깅·트레이싱 패턴이 널리 표준화됨
반면, 리소스 사용량이 상대적으로 높고
Envoy 기반 운영 경험이 부족한 조직에서는
초기 학습 비용과 운영 체계 정착에 시간이 필요하다는 점이 고려 요소입니다.
2️⃣ NGINX Gateway Fabric NGINX 친숙함과 전담 유지보수를 동시에 고려한 선택지
NGINX Gateway Fabric 역시
Gateway API 구현체 목록에서 Conformant + GA로 분류됩니다.
운영 관점에서 NGINX Gateway Fabric의 의미는 다음과 같습니다.
기존 NGINX 운영 자산의 연속성 : NGINX에 익숙한 조직일수록 전환 시 심리적·운영적 마찰이 낮음
전담 조직(F5)의 유지보수 기대 : 커뮤니티 기반이지만 명확한 주도 조직이 존재
표준 기반 전환 : 데이터 처리 방식은 유지하면서, 관리 모델만 Gateway API로 전환 가능
다만, 특정 기업 주도의 로드맵이라는 점에서 유료 지원의 장점과 벤더 종속 가능성이 공존합니다.
3️⃣ Traefik Proxy 경량·온프레미스·k3s 환경에서 여전히 의미 있는 선택
Traefik Proxy 역시 Gateway API 기준에서
Conformant + GA 상태를 충족합니다.
Traefik은 전통적으로 다음과 같은 환경에서 선호도가 높습니다.
온프레미스 소규모 클러스터, k3s 기반 경량 Kubernetes 환경
실무적으로 Traefik이 선택되는 이유는 다음과 같습니다.
운영 난이도 측면의 장점 : 구성 단순성, 빠른 설정 변경
Gateway API로의 자연스러운 수용 : 표준 기반 전환 흐름에 참여 가능
다만, 대규모 트래픽 환경에서의 검증 사례가 상대적으로 제한적이며
고급 트래픽 제어 시 설정 복잡도가 증가할 수 있다는 점은 고려가 필요합니다.
⚡환경·조직 특성에 따라 갈리는 선택 경향
아래 전망은 Gateway API Conformance 현황, 공식 공지, 프로젝트 성숙도 신호를 기반으로 한 운영 관점의 관측입니다.
1) 글로벌 서비스 또는 대형 클러스터
→ 표준 중심 전략을 선호하며 Envoy Gateway를 통해 기술 리딩을 시도할 가능성이 큼
2) 공공·금융·보수적 운영 환경
→ 전담 조직의 유지보수 기대가 있는 NGINX Gateway Fabric을 우선 채택할 가능성
3) 기존 NGINX 경험을 최대한 유지하려는 클러스터
→ 전환 부담을 최소화하기 위해 NGINX Gateway Fabric 선택 가능성 높음
4) 온프레미스·k3s·경량 운영 환경
→ 단순성과 경량성을 중시하며 Traefik 선택 유지 가능성 존재
Ingress-NGINX의 은퇴는
단순한 컨트롤러 교체 이슈가 아니라,
쿠버네티스 트래픽 관리 모델이 한 단계 진화하는 전환점입니다.
지금 시점에서 중요한 것은
무엇이 끝났는가보다, 우리 조직은 어떤 운영 성숙도와 표준 전략을 지향하는가를 기준으로
Gateway API 전환 전략을 설계하는 것입니다.
이 변화는 피할 수 없지만, 준비된 조직에게는 표준화·확장성·운영 일관성을 강화할 기회가 될 수 있습니다.
📍출처
