Kubernetes 공식 블로그에서 Ingress NGINX Retirement를 발표했습니다 
수년간 “사실상 표준(De facto standard)”이었던 Ingress NGINX가 2026년 3월까지만 best-effort 유지보수 후, 이후에는 릴리스·버그픽스·보안 업데이트가 중단되는 것으로 확정됐습니다. Ingress NGINX Retirement: What You Need to Know | Kubernetes
Ingress NGINX는 수많은 조직에서 쿠버네티스 클러스터의 단일 진입점 역할을 해왔기 때문에, 이번 결정은 생태계 전반·아키텍처·운영 방식·플랫폼 설계에 꽤 큰 파장을 줄 것 같습니다.
아래는 최근 벤더·CSP 동향 + 우리가 실제로 고민해야 할 포인트를 정리해 본 것이고, Bro 분들은 각자 조직/프로젝트 상황에서 어떻게 대응할지 같이 이야기해보면 좋겠네요 
공식 발표 및 기본 레퍼런스
Kubernetes 공식 블로그 (Ingress NGINX Retirement)
Ingress NGINX GitHub
Reddit DevOps 토론 스레드
Kubernetes X 공식 포스트
Gateway API 구현체 목록(공식)
Gateway API 소개(공식 문서)
전체 흐름 요약
-
Ingress NGINX는 2026년 3월 이후 공식적으로 아카이브 예정
-
현재는 보안 이슈 중심의 최소 유지보수만 제공
-
Kubernetes는 Gateway API를 차세대 표준 네트워크 API로 지정
-
Helm 차트, 플랫폼, 서비스 메쉬, LB 구성 등 생태계 전반에 영향 확대 중
최근 벤더·CSP에서 나타나는 실제 변화들
GKE (Google)
- GKE Gateway Controller GA
- Gateway API 기반의 L7 Load Balancer 제공
- Multi-Cluster Gateway까지 GA로 지원
- 사실상 GKE는 Ingress보다 Gateway API를 먼저 업데이트하는 구조로 이동 중
AWS (EKS)
- AWS Gateway API Controller (for Amazon VPC Lattice)
- Gateway/HTTPRoute 적용 → VPC Lattice 리소스 자동 생성
- 서비스 간 통신/라우팅을 Gateway API 기반으로 재정의
- 기존 “AWS ALB Ingress Controller”의 후속·대체 움직임이 보임
- (업데이트) AWS LB Controller에서 Gateway API 지원시작 했으나 “Using the LBC and Gateway API together is not suggested for production workloads (yet!)”
Azure (AKS)
- Application Gateway for Containers (AGFC)
- Gateway API 및 Kubernetes용 L7 LB 제공
- 기존 AGIC(애플리케이션 게이트웨이 Ingress Controller)의 진화 버전
- 향후 AKS의 기본 Gateway가 될 가능성이 높음
세 CSP 모두 Gateway API를 “주요 진입점 구조”로 전환 하는 중.
오픈소스·상용 컨트롤러 트렌드
Envoy 기반
- Contour , Envoy Gateway , Istio Gateway
- Gateway API 리소스(Gateway, HTTPRoute) 완성도 높음
- Istio는 Mesh Gateway + 동서(E/W) 트래픽 제어(GAMMA)까지 통합
NGINX 기반
- NGINX Gateway Fabric
- NGINX의 Gateway API 중심 신규 프로젝트
- Ingress NGINX 퇴역 이후 공식적으로 이쪽이 메인 계보
API Gateway / Proxy 계열
- Kong , Traefik , Apache APISIX
- Gateway API 적극 통합 중
- 특히 Traefik은 Gateway API v1.4까지 빠르게 지원 확대
서비스 메쉬 연계형
- Consul API Gateway , Linkerd Gateway
- Mesh-North/South 트래픽을 Gateway API 기준으로 정리하는 방향
아키텍처/운영 측면 고려 사항
1) 기술적 호환성 체크
- Gateway API 지원 범위는 구현체마다 다름
- HTTPRoute는 대부분 안정 지원
- GRPCRoute, TCPRoute, TLSRoute 등은 편차 큼
- 컨트롤러별로 API 버전(v1 / v1beta1) 지원 여부 확인 필요
2) TLS·보안·운영 구조 재정비
- TLS Termination 구조 변경 가능
- LB 계층 변화로 X-Forwarded-For, Access Log, 모니터링 지표 도 영향
- 기존 NGINX 기반 로깅/알람 룰 수정 필요
3) 팀 구조 및 RBAC 변화
- Gateway API는 기본적으로 Role 기반 모델(Persona 기반)
- Infra 팀 → Gateway/GatewayClass
- App 팀 → HTTPRoute
- 결국 RBAC/권한/운영 프로세스를 재설계해야 함
4) GitOps·Helm 전환 전략
- 대부분의 OSS Helm Chart는 아직 Ingress 중심
- 단기적으로는
- Ingress + HTTPRoute 템플릿 병행
- 조직 표준 Gateway 스펙 정의
- Dual Controller로 점진적 전환
전환 전략 (Recommended Patterns)
옵션 A) 인그레스 유지하면서 컨트롤러만 교체
- HAProxy Ingress / Kong Ingress 등으로 단기 대체
- 장점: Manifest 변경 최소화
- 단점: 결국 Gateway API로 한 번 더 옮겨야 함
옵션 B) 신규 서비스부터 Gateway API 적용
- 기존 서비스는 Ingress 유지
- 신규 리소스는 Gateway/HTTPRoute로 시작
- 중기적으로 점진적 전환하기 좋음
옵션 C) 서비스/네임스페이스 단위 전환
- Dual Stack 운영(Ingress + Gateway API 병행)
- Canary 방식으로 테스트 → Gateway 비율을 점진적으로 증가
옵션 D) 메쉬 기반으로 재설계
- Istio/Consul/Linkerd 사용 중인 경우
- Gateway API는 자연스럽게 Mesh Gateway와 통합됨
- Mesh + Gateway API 조합이 장기적으로 안정적
Bro 분들과 나누고 싶은 토론 주제
1. 여러분 조직은 Ingress NGINX를 언제까지 운영할 계획인가요?
(설마 완전히 지원되지 않는 그 순간까지..?)
2. Gateway API 전환 시 가장 먼저 다뤄야 할 영역은 어디라고 보시나요?
- Helm Chart?
- LB/TLS 구조?
- RBAC?