Ingress NGINX 은퇴: 알아두어야 할 사항

1 개요[ | ]

Ingress NGINX 은퇴: 알아두어야 할 사항

Kubernetes SIG Network와 Security Response Committee(SRC)는 생태계의 안정성과 보안을 우선하기 위해 Ingress NGINX의 은퇴(retirement)를 발표합니다. 2026년 3월까지는 최선의 노력을 기반으로 한 유지보수가 계속되지만, 그 이후에는 더 이상의 릴리스, 버그 수정, 보안 취약점 패치가 제공되지 않습니다. 기존 Ingress NGINX 배포는 계속 동작하며, 설치 아티팩트도 그대로 제공됩니다.

저희는 다양한 대안으로의 마이그레이션을 권장합니다. 현대적 대체재인 Gateway API로의 이전을 고려해 주세요. Ingress를 계속 사용해야 한다면, Kubernetes 문서에서 제공하는 여러 대체 Ingress 컨트롤러 목록을 참조할 수 있습니다. Ingress NGINX의 역사, 현재 상태, 그리고 앞으로의 계획에 대해 더 알고 싶다면 계속 읽어 주세요.

2 Ingress NGINX에 대해[ | ]

Ingress는 Kubernetes에서 워크로드로 향하는 네트워크 트래픽을 전달하기 위한, 사용자 친화적인 초기 방식이었습니다. (Gateway API는 동일한 목표를 달성하기 위한 새로운 방식입니다.) Ingress가 클러스터에서 동작하려면 반드시 Ingress 컨트롤러가 필요합니다. 이를 위해 다양한 선택지가 존재하며, 일부는 특정 클라우드 제공업체에 종속적이고, 일부는 범용적으로 사용됩니다.

Ingress NGINX는 Kubernetes 프로젝트 역사 초기에 Ingress API의 예시 구현으로 개발된 컨트롤러입니다. 특정 클라우드에 종속되지 않으면서도 놀라울 만큼 유연하고 기능이 풍부해 매우 인기를 끌었습니다. 그 이후로도 다양한 Ingress 컨트롤러가 커뮤니티 그룹과 벤더에 의해 새롭게 만들어졌지만, Ingress NGINX는 여전히 가장 널리 배포되는 컨트롤러 중 하나였으며, 수많은 호스티드 Kubernetes 플랫폼과 독립적인 사용자들의 클러스터에서 사용되었습니다.

3 역사와 도전 과제[ | ]

Ingress NGINX의 광범위한 기능과 유연성은 곧 유지보수의 어려움으로 이어졌습니다. 또한 클라우드 네이티브 소프트웨어에 대한 기대치가 변화하면서, 예전에는 유용했던 기능들이 지금에 와서는 심각한 보안 문제로 간주되는 경우도 생겼습니다. 대표적으로 "스니핏(snippets)" 어노테이션을 통한 임의의 NGINX 설정 삽입 기능은 과거에는 강점이었지만 지금은 해결하기 어려운 기술 부채가 되었습니다.

사용자들에게 인기가 있는 프로젝트임에도, Ingress NGINX는 항상 유지관리 인력이 매우 부족했습니다. 수년 동안 1~2명이 본업 외 시간(퇴근 이후, 주말 등)을 들여 유지보수를 담당해 왔습니다. 작년, Ingress NGINX 유지관리자들은 Ingress NGINX를 종료하고 Gateway API 커뮤니티와 함께 새 컨트롤러(InGate)를 개발하겠다고 계획을 발표했습니다. 그러나 이 발표에도 추가적인 기여자 확보에 실패, InGate 역시 충분한 성숙 단계로 발전하지 못했고 결국 함께 종료됩니다.

4 현재 상태와 향후 계획[ | ]

현재 Ingress NGINX는 최선의 수준(best-effort)으로만 유지보수되고 있습니다. SIG Network와 Security Response Committee는 Ingress NGINX를 지속 가능하게 유지하기 위한 추가 지원을 찾기 위해 노력해왔지만 더 이상 가능한 방법이 없는 상황입니다. 사용자 안전을 우선시하기 위해, 우리는 이 프로젝트를 중단(retire)해야 합니다.

2026년 3월, Ingress NGINX의 유지보수는 중단되고 프로젝트는 공식적으로 종료됩니다. 이 시점 이후에는 새로운 릴리스, 버그 수정, 보안 취약점 패치 등의 업데이트가 더 이상 제공되지 않습니다. GitHub 리포지토리는 읽기 전용(read-only) 으로 전환되고 참고용으로만 남겨집니다.

기존에 배포된 Ingress NGINX는 즉시 중단되거나 고장 나지는 않습니다. Helm 차트나 컨테이너 이미지 등 기존 프로젝트 산출물 역시 계속해서 사용할 수 있습니다.

대부분의 경우, 클러스터 관리자 권한으로 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 명령어를 실행하여 Ingress NGINX를 사용 중인지 확인할 수 있습니다.

Ingress NGINX 프로젝트를 만들어 유지해 온 모든 기여자들에게 깊은 감사를 표합니다. 이 컨트롤러는 전 세계 데이터센터와 홈랩에서 수십억 건의 요청을 처리해 왔습니다. Kubernetes가 지금의 위치에 오르기까지 Ingress NGINX의 역할은 매우 컸으며, 우리는 오랜 기간 이어진 놀라운 헌신에 감사드립니다.

SIG Network와 Security Response Committee는 모든 Ingress NGINX 사용자에게 즉시 Gateway API 또는 다른 Ingress 컨트롤러로의 마이그레이션을 시작할 것을 권장합니다. Kubernetes 문서에는 여러 대안이 정리되어 있습니다: Gateway API, Ingress. 또한, 협력 중인 벤더에서 제공하는 다른 옵션도 있을 수 있습니다.

5 같이 보기[ | ]

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}