Ingress NGINX 지원 종료
지원 종료된 Ingress NGINX 컨트롤러를 계속 운영하면 신규 CVE와 Kubernetes 업그레이드 리스크를 운영 팀이 직접 떠안게 됩니다.
community Ingress NGINX 컨트롤러는 2026년 3월 이후 신규 릴리스, 버그 수정, 보안 업데이트가 중단됩니다(EOL, End-of-Life). Kubernetes Ingress API 자체가 사라지는 것은 아니지만, 운영 환경에서는 NGINX Gateway Fabric 같은 Gateway API 기반 대안으로의 전환 계획이 필요합니다.
기존 Ingress NGINX YAML을 입력해 보세요. 이 도구는 NGINX Gateway Fabric 기반 Gateway API 리소스(HTTPRoute 등)로 변환한 결과를 제공하고, 전환 전에 확인해야 할 migration warning과 annotation 호환성 지점을 표시합니다.
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 운영 경험을 유지하면서 초기 변환 결과를 만들고, Gateway, Route, 정책 리소스 중심의 운영 모델을 검토할 수 있게 돕습니다.
첫 화면의 변환기에 기존 Ingress NGINX manifest와 annotation을 붙여 넣으면 Gateway, HTTPRoute, GRPCRoute, TLSRoute, redirect route, ReferenceGrant, NGINX Gateway Fabric 정책 리소스를 생성합니다.
기존 Ingress NGINX 환경을 Gateway API로 전환하기 위한 변환 결과를 빠르게 만들고, HTTPRoute 변환과 annotation 호환성처럼 수동으로 검토해야 할 지점을 명확히 분리합니다.
| 구분 | 생성/검토 리소스 | 확인 포인트 |
|---|---|---|
| Gateway | Gateway | GatewayClass, host, HTTP/HTTPS protocol, TLS secret 연결 |
| routing | 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 상태와 운영 영향 |
Ingress NGINX 마이그레이션에서 가장 위험한 부분은 annotation의 운영 의미가 변환 과정에서 빠지거나 다르게 적용되는 것입니다.
정규식 rewrite, canary, mTLS, external auth, snippet, upstream TLS 같은 항목은 자동 생성된 YAML만 적용하면 인증·보안·트래픽 분산 동작이 기존 Ingress와 달라질 수 있습니다.
| 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로 대응할 수 있습니다. |
낮음 |
Security Policy
WAF/ModSecurity annotation은 기존에 사용하던 Open Source WAF나 ModSecurity 구성을 그대로 승계하는 변환 대상이 아닙니다. 운영 팀은 NGINX Gateway Fabric 전환 시 F5 WAF for NGINX policy bundle, WAFPolicy, 보안 로그 profile, 탐지/차단 모드를 별도 보안 정책으로 설계해야 합니다.
NGINX Gateway Fabric Release Notes
v2.6.3은 2.6.x의 Gateway API 기능을 유지하면서 NGINX, NGINX Agent, F5 WAF for NGINX 조합과 ListenerSet 관련 버그를 업데이트한 패치 릴리스입니다. 실제 Ingress 입력과 관련된 항목만 Migration Map에 표시합니다.
| 릴리스 항목 | 마이그레이션 영향 | 도구 변환 |
|---|---|---|
| v2.6.3 패치 업데이트 | NGINX OSS 1.31.1, NGINX Plus R37.0, NGINX Agent v3.10.3, F5 WAF for NGINX 5.13.1 조합으로 갱신됐고 Agent mTLS CA 갱신, ListenerSet attachment/service port, policy TargetConflict 관련 수정이 포함됐습니다. | 기본 선택 버전을 v2.6.3으로 올리고, 생성 manifest ref와 Migration Map의 버전 안내를 v2.6.3 기준으로 표시합니다. |
ListenerSet |
Application team이 Gateway 본체를 수정하지 않고 listener, hostname, certificate를 위임 관리할 수 있습니다. | Ingress가 여러 host를 사용할 때만 Migration Map에 표시하고, 다중 TLS secret 검토는 FrontendTLS / 다중 인증서 항목에서 분리해 안내합니다. |
ProxySettingsPolicy.spec.timeout |
proxy-connect-timeout, proxy-read-timeout, proxy-send-timeout을 정책 필드로 표현할 수 있습니다. |
v2.6.x 선택 시 ProxySettingsPolicy로 생성하고, v2.5.x 이하는 SnippetsFilter fallback을 사용합니다. |
| FrontendTLS / 다중 인증서 | Gateway listener에서 client certificate validation과 여러 certificateRefs를 지원합니다. |
auth-tls annotation 또는 여러 TLS secret이 있을 때 CA, ReferenceGrant, SNI/hostname 범위 확인을 수동 설계로 표시합니다. |
F5 WAF for NGINX / WAFPolicy |
외부에서 컴파일된 WAF policy bundle을 WAFPolicy로 Gateway, HTTPRoute, GRPCRoute에 연결할 수 있습니다. |
기존 WAF/ModSecurity annotation을 라우팅 리소스로 자동 변환하지 않습니다. Open Source WAF 설정을 그대로 옮기는 대신 F5 WAF for NGINX 정책과 bundle 배포를 별도 보안 검토 항목으로 표시합니다. |
변환 결과는 바로 운영 환경에 적용하기보다 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을 같은 클러스터에서 병행 운영하면서 서비스 단위로 전환할 수 있습니다. 다만 Ingress NGINX 지원 종료라는 표현은 community Ingress NGINX 컨트롤러 지원 종료를 뜻하므로, 컨트롤러와 GatewayClass 구성을 분리하고 트래픽 진입점을 명확히 나눠야 합니다.
가능합니다. NGINX Gateway Fabric은 Kubernetes Gateway API 구현체이므로 EKS, GKE 같은 managed Kubernetes에서도 GatewayClass와 LoadBalancer 서비스 구성을 통해 사용할 수 있습니다. 단, 클라우드별 LB 통합, 노드 포트, 네트워크 정책은 환경에 맞게 확인해야 합니다.
아닙니다. HTTPRoute 변환은 라우팅 초안일 뿐입니다. NGINX Gateway Fabric을 먼저 배포하고 DNS 또는 로드밸런서 레벨에서 트래픽을 점진적으로 이동하는 방식이 일반적이며, Ingress NGINX migration 과정에서는 TLS Secret, ReferenceGrant, Route Accepted 상태를 사전에 검증해야 합니다.
NGINX Gateway Fabric 마이그레이션 지원
운영 환경 검토, NGINX Gateway Fabric 전환 설계, annotation 호환성 분석처럼 전문적인 기술지원이 필요하면 NGINX STORE로 연락 주세요.