1. 공식 발표 및 EOL 정의
2025년 11월 11일, Kubernetes 프로젝트는 Ingress NGINX 컨트롤러가 2026년 3월부로 EOL(End of Life) 단계에 진입한다고 공식 발표하였다. 해당 내용은 Kubernetes 공식 블로그를 통해 명시되었다.
공식 발표 본문:
https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
향후 릴리스 및 유지보수는 아래와 같이 변경된다.
- 신규 기능 업데이트 중단
- 보안 패치 중단
- 문제 발생 시 버그 수정 불가
- 장기적으로 운영 리스크 증가
Ingress NGINX는 오랜 기간 업계 표준으로 활용되었지만, Kubernetes 네트워킹 구조 변화와 프로젝트 유지 역량 한계로 인해 공식 은퇴가 결정되었다.
2. 왜 Ingress NGINX가 EOL 되었는가
2.1 유지보수 구조의 한계
Ingress NGINX는 수많은 기능을 제공하는 동시에 설정 복잡도와 기술 부채가 증가해 왔다. 커뮤니티 차원의 장기적 유지보수가 더 이상 현실적이지 않다고 판단되었다.
공식 블로그에서도 다음과 같은 언급이 포함되어 있다.
- 제한된 Contributor 인력
- 코드 베이스 복잡성 증가
- Feature 유지 비용 상승
공식 발표 본문:
https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
2.2 보안 및 안정성 문제
Ingress NGINX는 annotation 기반 설정과 Custom Snippet 사용 방식으로 인해 보안 취약성 관리가 어렵고 통일된 보안 정책 적용이 제한적이었다. 향후 Kubernetes 보안 정책 기준과도 어긋날 가능성이 있다.
2.3 기술 구조의 한계
Ingress 구조는 다음 기능 부족이 지속적으로 지적되었다.
- Multi-Cluster
- Multi-Tenant
- Multi Listener
- 표준화된 L7 트래픽 제어
이러한 이유로 Ingress API 자체를 대체할 Gateway API가 차세대 표준으로 제시되었다.
3. Kubernetes 공식 권고: Gateway API
Ingress API 기반 Controller 대신 Gateway API 전환이 권장된다. Gateway API는 Ingress API의 구조적 단점을 개선한 Kubernetes Networking 표준이다.
공식 가이드:
https://kubernetes.io/docs/concepts/services-networking/gateway/
Gateway API 핵심 특징
- RBAC 기반의 역할 분리 가능
- Listener, Gateway, Route 구성
- Controller 교체 가능 (Vendor-neutral)
- 확장성과 유연성 향상
Ingress가 단일 리소스로 Network Entry를 정의하던 방식에서 벗어나, Gateway API는 구성 요소를 분리하여 보다 정교한 제어 능력을 제공한다.
4. 현재 사용 중이라면 확인해야 할 사항
4.1 Ingress NGINX 확인 명령
kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx
4.2 전환 전략
- 기존 Ingress 리소스 분석
- Annotation 기반 설정 기능 정리
- Gateway API로 단계적 전환 테스트
- Ingress Controller 제거 전 Blue-Green 방식 권장
5. 결론 및 대응 방향
Ingress NGINX EOL은 단순한 Controller 종료가 아닌 Kubernetes Networking 표준 전환이라는 의미를 가진다.
지금 시점에서 해야 할 최우선 대응은 다음과 같다.
- Kubernetes 클러스터 구성 자산 분석
- Gateway API 기반 전환 계획 수립
- 테스트 환경에서 마이그레이션 검증
- 신규 Deployment는 Gateway API 기반으로 설계
이전 방식이 계속 동작할 수도 있지만, 이후 발생할 보안, 유지보수, 기능 확장 문제를 고려하면 더 이상 Ingress NGINX 기반 운영은 장기적으로 권장되지 않는다.
Best Practice
- 마이그레이션은 단계적으로 수행
- Deprecated 기능 사용 자제
- Gateway API 기반 Controller 선택 (AKS 기반이라면 AGfC 또는 AGIC 검토 가능)
다음 글 예고
다음 글에서는 Azure Kubernetes Service(AKS) 환경에서 다음 내용을 설명한다.
- Azure에서 제공하는 AGIC(Application Gateway Ingress Controller) 구성 방법
- Azure가 공식적으로 권장하는 Gateway API 기반 방식인 AGfC(Application Gateway for Containers) 구성 방법
- 두 방식의 차이와 선택 기준
- 실무 환경에서의 마이그레이션 전략
해당 글에서는 Azure 환경에서의 구체적인 구성 절차, 명령어, YAML, Portal 구성 방법을 포함해 단계별로 설명한다.