Ingress NGINX의 공식 은퇴

서두

Kubernetes SIG Network와 Security Response Committee(SRC)는 2025년 11월, Kubernetes 생태계에서 가장 널리 사용되어 온 Ingress 컨트롤러인 Ingress NGINX의 공식 은퇴(retirement)를 발표했다.

마지막 유지보수는 2026년 3월까지만 최종 유지보수(best-effort maintenance)가 지속되며, 이후에는 보안 패치·버그 수정·기능 업데이트가 단 한 건도 제공되지 않는다.

아래도 나오지만, 빚처럼 쌓여있는 유지보수 문제를 두 명 남짓한 개발자로 감당하기에는 더 이상 역부족인듯 하다.
클라우드 생태계의 변화야 늘 있던것이지만 그걸 맞춰 따라가려면 그만한 개발 인력이 필요한데 ingress nginx에 인력을 투입하기엔 이미 gatewayAPI가 있으니 말이다.

공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다.이는 정확한 정보가 아닐 수 있음을 알려드립니다.

 

---

참고 링크

광고 클릭은 큰 힘이 됩니다!

Ingress NGINX Retirement: What You Need to Know

728x90

---

Ingress NGINX 지원 중단 

Ingress NGINX는 Kubernetes의 대표적인 Ingress 컨트롤러로 수많은 SaaS·클라우드 벤더 환경에 기본값처럼 사용되어 왔다.
그러나 Kubernetes SIG Network & SRC는 생태계 보안 확보를 위해 Ingress NGINX를 은퇴시키기로 결정했다. 핵심 발표 내용은 다음과 같다.

---

지금까지의 사용 방식

“Ingress NGINX는 Kubernetes 초창기부터 사실상 표준 Ingress 컨트롤러였다.”

트래픽 관리의 출발점

초기의 Kubernetes 사용자에게 Ingress는 가장 쉬운 HTTP 라우팅 방식이었다. 특정 도메인을 어떤 서비스로 연결하는지 매니페스트 한 장으로 관리할 수 있어서 DevOps 운영에 이점을 가져왔다. Ingress를 실질적으로 작동시키는 핵심 컴포넌트가 Ingress Controller이며, Ingress NGINX는 이 중 가장 범용적이며 강력한 컨트롤러였다.

주요 이점

• 벤더 중립성
• 강력한 NGINX 기능 기반
• 높은 확장성
• 별도 비용 없음
• CNCF/Kubernetes 커뮤니티 주도 개발

---

역사적·기술적 문제

“과거의 유연성이 지금의 기술 부채(technical debt)로 돌아왔다.”

변화 그리고 인력난

• 지나치게 광범위한 기능 범위
  예시 구현으로 출발했으나 많은 기능이 붙으며 유지 난이도 폭증.
• 변경된 클라우드 네이티브 보안 기준
  유연성보다 "안전한 기본값"이 요구되면서 구조적 한계가 드러남.
• 단 두 명 남짓한 개발자 유지 체계
  막대한 사용자 기반에 비해 유지보수 인력이 너무 적어 지속 불가능한 상태.
• 대체 프로젝트(InGate)도 실패
  GatewayAPI 기반의 후속 컨트롤러 InGate도 기여자 부족으로 중단.

---

대체 방안

“Gateway API는 Ingress의 공식적인 후속 아키텍처다.”
Gateway APIIngress보다 안전하고 모듈화된 차세대 네트워크 모델. 이미 GA이며 다양한 구현체가 존재한다.

 

---

중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.