Kubernetes Ingress NGINX 종료 안내와 대처 전략

핵심 요약
Kubernetes의 대표적인 Ingress 컨트롤러였던 Ingress NGINX가 2026년 3월을 끝으로 유지보수가 중단됩니다. 기존 클러스터는 계속 동작하지만, 이후에는 보안 패치와 버그 수정이 없으므로 Gateway API나 다른 Ingress 컨트롤러로의 이전을 서둘러 준비해야 합니다.
Ingress NGINX 종료 결정의 핵심
Kubernetes SIG Network와 Security Response Committee는 생태계의 보안과 안정성을 위해 Ingress NGINX를 공식적으로 종료하기로 결정했습니다.
현재는 "최대한의 선에서" 유지보수가 이루어지고 있지만, 2026년 3월 이후에는 새로운 릴리스, 버그 수정, 보안 취약점 패치가 일절 제공되지 않습니다.
중요한 점은, 기존에 배포된 Ingress NGINX는 그대로 동작하고, 관련 Helm 차트와 컨테이너 이미지도 계속 접근 가능하다는 것입니다.
하지만 보안 취약점이 발견되더라도 더 이상 고쳐지지 않으므로, 장기적으로는 사용을 지속하는 것이 큰 위험 요인이 됩니다.
Ingress와 Gateway API의 역할 이해
Ingress는 Kubernetes에서 외부 트래픽을 클러스터 안의 서비스로 라우팅하기 위해 도입된 초기의 "사용자 친화적인" 진입점 API입니다.
다만 Ingress는 표현력이 제한적이고, 다양한 L4/L7 네트워크 요구사항을 모두 안정적으로 담기에는 구조적인 한계가 있었습니다.
Gateway API는 이러한 한계를 보완하기 위해 설계된 차세대 API로, 역할 기반 리소스 분리(예: Gateway, HTTPRoute), 멀티 테넌시, 더 풍부한 라우팅 제어 등 현대적인 네트워크 요구사항을 더 잘 반영합니다.
Ingress NGINX 종료는 단순히 한 프로젝트의 종료가 아니라, Kubernetes 네트워크 진입 방식이 Ingress 중심에서 Gateway API 중심으로 넘어가는 흐름의 일부로 볼 수 있습니다.
Ingress NGINX가 특별했던 이유
Ingress NGINX는 Kubernetes 초창기에 "Ingress API의 예제 구현"으로 등장했지만, 곧 사실상의 표준처럼 널리 쓰이게 되었습니다.
특정 클라우드에 종속되지 않고 어디서나 쓸 수 있었고, NGINX의 풍부한 기능을 거의 그대로 활용할 수 있어 유연성이 매우 높았습니다.
그래서 여러 매니지드 Kubernetes 서비스, 온프레미스 클러스터, 개인 홈랩까지 수많은 환경에서 기본 선택지처럼 사용되었습니다.
결과적으로, 전 세계 데이터센터와 사용자 클러스터에서 매 순간 수많은 HTTP/HTTPS 요청을 처리하는 핵심 구성 요소가 되었습니다.
유지보수 어려움과 기술적 부채
Ingress NGINX의 강점이었던 "너무 많은 기능과 유연성"은 시간이 지나면서 유지보수 난이도를 크게 높였습니다.
예를 들어, 애노테이션으로 임의의 NGINX 설정을 주입할 수 있는 기능은 과거에는 '강력한 커스텀 기능'이었지만, 오늘날 기준으로는 심각한 보안 리스크가 될 수 있습니다.
보안 요구사항이 강화되고, 클라우드 네이티브 환경의 모범사례가 발전하면서, 옛날에 추가된 옵션들이 점점 "손대기 어려운 기술적 부채"로 변해갔습니다.
여기에 더해, 실제 개발과 유지보수를 담당하는 핵심 기여자가 항상 매우 적었고, 대부분 본업 외의 시간에 프로젝트를 유지해 왔다는 점도 큰 부담이었습니다.
InGate 시도와 실패가 의미하는 것
Ingress NGINX 유지보수자들은 문제를 인지하고, Gateway API와 연계한 새로운 컨트롤러(InGate)를 만들려는 계획을 발표했습니다.
이 계획은 "기존 부담이 큰 코드베이스를 붙잡고 있는 대신, 새로운 아키텍처로 재출발하자"는 방향성이었습니다.
그러나 이 프로젝트에 충분한 커뮤니티 참여와 리소스가 모이지 못했고, 결국 InGate 역시 성숙한 대체재로 성장하지 못한 채 종료 수순을 밟게 되었습니다.
이는 대형 오픈소스 프로젝트라도, 유지보수 인력이 충분히 확보되지 않으면 영구적으로 지속될 수 없다는 현실을 보여줍니다.
현재 상태: 무엇이 유지되고 무엇이 멈추는가
오늘 시점에서 Ingress NGINX는 여전히 "가능한 범위 내에서" 관리되고 있으며, 치명적인 문제에 대해 일정 부분 대응이 이루어지고 있습니다.
하지만 2026년 3월이 지나면 다음과 같은 변화가 일어납니다.
첫째, GitHub 리포지터리는 읽기 전용으로 전환되고, 프로젝트는 'retired' 상태로 이동합니다.
둘째, 신규 릴리스, 기능 추가, 버그 수정, 보안 패치는 더 이상 제공되지 않습니다.
셋째, 기존 이미지와 Helm 차트 등 배포에 필요한 아티팩트는 계속 접근 가능하지만, 내용은 고정된 상태로 남게 됩니다.
즉, "지금 당장 멈추지는 않지만, 시간이 지날수록 위험이 커지는 정지된 자산"이 됩니다.
내 클러스터가 Ingress NGINX를 쓰는지 확인하는 방법
먼저, 자신이 Ingress NGINX를 사용 중인지 확인하는 것이 중요합니다.
클러스터 관리자 권한이 있다면, 다음 명령어로 비교적 쉽게 확인할 수 있습니다.
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx이 명령어로 하나 이상의 파드가 조회된다면, 해당 클러스터에는 Ingress NGINX가 배포되어 있는 것입니다.
매니지드 Kubernetes를 사용하는 경우, 클라우드 콘솔의 애드온 목록이나 로드밸런서/Ingress 설정 화면에서 Ingress NGINX 사용 여부를 확인하는 것도 좋습니다.
어떤 방향으로 마이그레이션해야 할까?
기본 권장 방향은 Gateway API 기반의 솔루션으로 이전하는 것입니다.
Gateway API는 Kubernetes 공식 생태계에서 장기적으로 밀고 있는 네트워크 진입 모델이며, 다양한 구현체(컨트롤러)들이 활발히 개발되고 있습니다.
이미 Ingress 리소스를 많이 사용하고 있다면, 우선 소규모 환경(스테이징/테스트 클러스터)에서 Gateway API 리소스(예: Gateway, HTTPRoute)로 하나씩 옮겨보며 동작을 검증하는 접근이 안전합니다.
만약 당장 Gateway API 도입이 어려운 환경이라면, Kubernetes 문서에 나열된 다른 Ingress 컨트롤러 옵션(예: 특정 클라우드 전용 컨트롤러, 다른 벤더 제품)을 검토할 수 있습니다.
또한, 현재 사용 중인 클라우드나 벤더가 제공하는 공식 로드밸런서/Ingress 솔루션이 있는지 확인하면, 운영과 지원 측면에서 이점이 있을 수 있습니다.
마이그레이션 시 고려해야 할 실무 포인트
현재 Ingress NGINX에서 활용 중인 기능 목록을 먼저 정리하는 것이 좋습니다.
예를 들어, TLS 설정 방식, 리다이렉트 규칙, Path 기반 라우팅, 헤더 조작, 애노테이션 기반의 고급 설정 등을 목록화합니다.
이후, 선택한 대체 솔루션(Gateway API 구현체나 다른 Ingress 컨트롤러)이 각각의 기능을 어떻게 제공하는지 매핑해 보며 대체 방안을 찾습니다.
가능하다면, "완전 동등한 기능 복제"보다는, 현재의 보안·운영 기준에 맞게 설정을 단순화하고 불필요한 유연성(특히 임의 설정 주입)을 줄이는 방향을 택하는 것이 바람직합니다.
마지막으로, 점진적 롤아웃 전략(예: 일부 도메인, 일부 서비스부터 순차적으로 이전)을 사용해 리스크를 낮추는 것이 좋습니다.
인사이트
Ingress NGINX 종료는 단순한 서비스 종료가 아니라, Kubernetes 네트워킹이 한 세대를 넘어가는 신호라고 볼 수 있습니다.
과거에는 "어떤 기능이든 넣을 수 있는 유연성"이 강점이었다면, 이제는 "표준화, 보안, 유지보수 가능성"이 더 중요해졌습니다.
실무적으로는 다음을 빠르게 실행하는 것이 좋습니다.
내 클러스터에서 Ingress NGINX 사용 여부 확인
Gateway API 또는 다른 Ingress 컨트롤러 후보 선정
테스트 환경에서 소규모 마이그레이션 시범 적용
기능 매핑 및 설정 정리 후, 점진적 전환 로드맵 수립

지금부터 차근차근 이전을 준비하면, 나중에 급하게 갈아탈 필요 없이 안정적으로 다음 세대 네트워크 구조로 넘어갈 수 있습니다.
출처 및 참고:
https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/
