ingress-nginx 지원 종료
2026년 3월 이후 community ingress-nginx 컨트롤러는 신규 릴리스, 버그 수정, 보안 업데이트가 중단된 상태입니다.
단순한 패치 중단이 아니라 보안 규정 준수와 운영 안정성 문제이므로, 기존 Ingress YAML을 NGINX Gateway Fabric 기반 Gateway API 리소스로 변환하고 migration warning을 먼저 확인하세요.
Kubernetes Ingress API가 사라지는 것은 아니지만, community ingress-nginx 컨트롤러는 2026년 3월 이후 신규 릴리스, 버그 수정, 보안 업데이트가 중단되어 운영 환경에서는 NGINX Gateway Fabric 같은 Gateway API 기반 대안으로의 전환 계획이 필요합니다.
1. 보안 대응 공백: 2026년 3월 이후 발견되는 신규 CVE에 대해 community ingress-nginx의 공식 패치가 제공되지 않습니다. 직접 포크하거나 회피 방법을 찾아야 할 수 있습니다.
2. 버전 호환성 불확실성: Kubernetes 마이너 버전 업그레이드마다 기존 컨트롤러와의 호환성을 직접 검증하고 유지해야 하는 부담이 커집니다.
3. 감사와 컴플라이언스 리스크: 보안 감사나 컴플라이언스 검토에서 지원 종료된 컴포넌트는 운영 리스크 또는 개선 지적으로 분류될 수 있습니다.
gateway api는 Ingress보다 역할 분리와 정책 모델이 명확합니다. GatewayClass, Gateway, HTTPRoute, GRPCRoute로 진입점과 라우팅 책임을 나누고, annotation 중심 설정을 표준 리소스와 정책으로 옮길 수 있습니다.
nginx gateway fabric은 NGINX를 데이터 플레인으로 사용하는 Gateway API 구현체입니다. 이 변환 도구는 기존 NGINX 운영 경험을 유지하면서 nginx gateway fabric migration 초안을 만들고, Gateway, Route, 정책 리소스 중심의 운영 모델을 검토할 수 있게 돕습니다.
첫 화면의 변환기에 기존 Ingress YAML을 붙여 넣으면 Gateway, HTTPRoute, GRPCRoute, TLSRoute, redirect route, ReferenceGrant, NGINX Gateway Fabric 정책 리소스를 생성합니다. ingress nginx gateway api, ingress nginx to gateway api, nginx ingress controller migration 전환 초안을 빠르게 만들고 수동 검토 지점을 분리합니다.
| 변환 영역 | 생성/검토 리소스 | 확인 포인트 |
|---|---|---|
| 진입점 | Gateway, Listener | host, HTTP/HTTPS, TLS secret, GatewayClass 연결 |
| 라우팅 | HTTPRoute, GRPCRoute, TLSRoute | pathType, backendRefs, redirect/rewrite, cross namespace 참조 |
| 운영 정책 | NGF Policy, Filter, Snippets | timeout, body size, rate limit, auth, header, upstream 설정 |
| 검토 결과 | Migration Map | READY, NEEDS_REVIEW, NOT_MIGRATABLE 상태와 운영 영향 |
nginx ingress migration에서 가장 위험한 부분은 annotation 의미가 조용히 사라지는 것입니다. 정규식 rewrite, canary, mTLS, external auth, WAF, snippet, upstream TLS 같은 항목은 자동 YAML만 적용하면 인증·보안·트래픽 분산 동작이 달라질 수 있습니다.
| Annotation | 전환 후 동작 변화 | 검토 우선순위 |
|---|---|---|
nginx.ingress.kubernetes.io/rewrite-target |
HTTPRoute URLRewrite filter로 매핑되지만, 정규식 캡처 그룹은 표준 필드만으로 보존되지 않아 수동 변환이 필요합니다. |
높음 |
nginx.ingress.kubernetes.io/canary-* |
자동 변환하지 않습니다. Gateway API backendRefs.weight와 header match로 수동 canary rollout을 설계하고, cookie 조건은 별도 검증해야 합니다. |
높음 |
nginx.ingress.kubernetes.io/auth-url |
External auth는 NGF ExtensionRef 또는 별도 인증 정책/프록시 설계가 필요합니다. |
높음 |
nginx.ingress.kubernetes.io/ssl-passthrough |
TLSRoute와 passthrough listener로 설계해야 하며, GatewayClass와 listener 설정을 함께 확인해야 합니다. | 중간 |
nginx.ingress.kubernetes.io/proxy-body-size |
NGF ClientSettingsPolicy로 대응할 수 있습니다. |
낮음 |
변환 결과는 바로 운영에 적용하기보다 dev/stage에서 apply, Gateway Programmed 상태, Route Accepted/ResolvedRefs, 실제 HTTP/HTTPS/WebSocket/gRPC 요청까지 확인해야 합니다. gateway api 전환은 리소스 생성보다 동작 검증이 더 중요합니다.
nginx gateway fabric은 Gateway API 구현체로 NGINX Open Source 또는 NGINX Plus 데이터 플레인을 선택해 배포할 수 있습니다. Open Source와 Plus의 기능 차이, 지원 가능한 Policy/Filter, Plus 전용 기능 여부를 버전별 문서와 CRD 기준으로 확인해야 합니다.
생성된 YAML은 apply 성공만으로 충분하지 않습니다. Gateway와 Route condition, NGF controller event, NGINX reload 오류, backend 응답, 인증·mTLS·rate limit·canary 같은 운영 정책이 기존 Ingress와 동일하게 동작하는지 함께 확인해야 합니다.
least_time 계열 로드밸런싱, 추가 Prometheus metrics, live activity dashboard, JWT/OIDC 인증, 상용 지원을 활용할 수 있습니다.가능합니다. Kubernetes Ingress API 자체는 유지되므로 기존 ingress-nginx와 NGINX Gateway Fabric을 같은 클러스터에서 병행 운영하면서 서비스 단위로 전환할 수 있습니다. 다만 컨트롤러와 GatewayClass 구성을 분리하고 트래픽 진입점을 명확히 나눠야 합니다.
동작합니다. NGINX Gateway Fabric은 Kubernetes Gateway API 구현체이므로 EKS, GKE 같은 managed Kubernetes에서도 GatewayClass와 LoadBalancer 서비스 구성을 통해 사용할 수 있습니다. 단, 클라우드별 LB 통합, 노드 포트, 네트워크 정책은 환경에 맞게 확인해야 합니다.
Route 전환 자체는 무중단으로 설계할 수 있습니다. NGINX Gateway Fabric을 먼저 배포하고 DNS 또는 로드밸런서 레벨에서 트래픽을 점진적으로 이동하는 방식이 일반적입니다. 다만 TLS Secret, ReferenceGrant, Route Accepted 상태를 사전에 검증해야 합니다.
NGINX Gateway Fabric 마이그레이션 지원
운영 환경 검토, NGINX Gateway Fabric 전환 설계, annotation 호환성 분석처럼 전문적인 기술지원이 필요하면 NGINX STORE로 연락 주세요.