Ingress NGINX 지원 종료 대응 | Gateway API YAML 자동 변환

컨트롤러 지원 종료가 비즈니스에 미치는 3가지 리스크

1. 보안 대응 공백: 지원 종료 이후 발견되는 신규 CVE에 대해 community Ingress NGINX의 공식 패치가 제공되지 않습니다. 운영 팀은 직접 포크하거나 회피 방법을 검증해야 할 수 있습니다.

2. 버전 호환성 불확실성: Kubernetes 마이너 버전 업그레이드마다 운영 팀이 기존 컨트롤러와의 호환성을 직접 검증하고 유지해야 하는 부담이 커집니다.

3. 감사와 컴플라이언스 리스크: 보안 감사나 컴플라이언스 검토에서 지원 종료된 컴포넌트는 운영 리스크로 분류될 수 있습니다.

왜 표준 Gateway API 기반의 NGINX Gateway Fabric으로 전환해야 하나요?

Gateway API는 Ingress보다 역할 분리와 정책 모델이 명확합니다.

GatewayClass, Gateway, HTTPRoute, GRPCRoute로 진입점과 라우팅 책임을 나누고, annotation 중심 설정을 표준 리소스와 정책으로 옮길 수 있습니다.

복잡한 설정을 한 번에, NGINX Gateway Fabric 변환 도구 활용법

NGINX Gateway Fabric은 NGINX를 데이터 플레인으로 사용하는 Gateway API 구현체입니다.

이 변환 도구는 기존 NGINX 운영 경험을 유지하면서 초기 변환 결과를 만들고, Gateway, Route, 정책 리소스 중심의 운영 모델을 검토할 수 있게 돕습니다.

Ingress NGINX 구성을 NGINX Gateway Fabric / Gateway API 리소스로 자동 변환

첫 화면의 변환기에 기존 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` 상태와 운영 영향

기존 Annotation 호환성 분석 및 운영 영향도 검토

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는 라우팅 변환과 분리해 검토하세요

WAF/ModSecurity annotation은 기존에 사용하던 Open Source WAF나 ModSecurity 구성을 그대로 승계하는 변환 대상이 아닙니다. 운영 팀은 NGINX Gateway Fabric 전환 시 F5 WAF for NGINX policy bundle, WAFPolicy, 보안 로그 profile, 탐지/차단 모드를 별도 보안 정책으로 설계해야 합니다.

NGINX Gateway Fabric Release Notes

NGINX Gateway Fabric 2.8.0 릴리스 노트

v2.8.0은 Gateway API 1.6.3을 지원하며 IP 접근 정책과 OSS cookie session persistence 지원을 추가했습니다. 실제 입력에 적용되는 변환과 experimental/deprecated 항목의 검토 지점을 구분해 표시합니다.

릴리스 항목	마이그레이션 영향	도구 변환
v2.8.0 핵심 버전 조합	Gateway API 1.6.3, Gateway API Inference Extension 1.6.2, Kubernetes 1.32+, NGINX OSS 1.31.7, NGINX Plus R37.2, NGINX Agent v3.12.2, F5 WAF for NGINX 5.16.0, Helm chart 2.8.0, Operator image 1.6.0 조합입니다.	기본 선택과 변환 프로필을 v2.8.0으로 설정합니다. 생성되는 Gateway API GA 리소스는 `gateway.networking.k8s.io/v1`을 사용합니다.
AccessPolicy와 IP 접근 제어	`gateway.nginx.org/v1alpha1`의 `AccessPolicy`로 Gateway, HTTPRoute, GRPCRoute에 IPv4/IPv6 주소와 CIDR allow/deny 규칙을 적용할 수 있습니다. deny 규칙은 allow보다 먼저 평가됩니다.	v2.8.0 선택 시 `whitelist-source-range`와 `denylist-source-range`를 route-level `AccessPolicy`로 생성합니다. 프록시/LB 뒤에서는 NGF가 관측하는 client IP를 확인하고 필요하면 `NginxProxy.spec.rewriteClientIP`를 구성하세요. 적용 후 AccessPolicy `Accepted`와 Route `AccessPolicyAffected` 상태를 확인해야 합니다.
Cookie session persistence	NGINX OSS와 NGINX Plus 모두 cookie session persistence를 지원합니다. HTTPRoute/GRPCRoute의 `sessionPersistence`는 experimental이며 deprecated 상태로, 향후 Backend 리소스 기반 API로 대체될 예정입니다.	Ingress affinity/cookie 설정은 자동 생성하지 않고 Migration Map에 검토 항목을 표시합니다. 적용하려면 experimental Gateway API CRD와 NGF experimental flag가 필요하며, secret/쿠키 속성과 향후 API 전환을 확인해야 합니다.
AuthenticationFilter 업그레이드	legacy `nginx.org/htpasswd` Secret type 지원을 제거했습니다. Basic Auth에는 `Opaque` Secret과 `auth` key를 사용해야 합니다.	Ingress 입력만으로 참조 Secret의 type/data는 확인할 수 없습니다. Basic Auth 변환 시 secret 형식을 Migration Map에 검토 경고로 표시합니다.
Plus 및 운영 기능	Active/passive health checks는 NGINX Plus 전용이고 Plus upstream zone 기본 크기는 2MB입니다. NginxProxy access log file/syslog destination, Helm ServiceMonitor와 data plane PodDisruptionBudget 설정도 추가됐습니다. InferencePool EndpointPicker의 BackendTLSPolicy 검증 지원이 추가됐지만, policy가 없으면 TLS 연결의 server certificate 검증은 수행되지 않습니다.	Ingress annotation과 직접 대응하지 않는 기능은 임의로 생성하지 않습니다. health checks, access log destination, telemetry/PDB, EPP TLS는 NGF 2.8.0 리소스와 설치값으로 별도 설계하세요.
v2.7.2 패치 업데이트	Gateway API 1.6.1, Gateway API Inference Extension 1.6.0, Kubernetes 1.32+, NGINX OSS 1.31.6, NGINX Plus R37.1(패키지 37.1.1.2), NGINX Agent v3.12.0, F5 WAF for NGINX 5.15.0 조합입니다. Helm chart 2.7.2, Operator image 1.5.2입니다.	v2.7.2 선택 시 해당 릴리스의 manifest와 Migration Map 버전 안내를 표시합니다.
v2.7.1 패치 업데이트	Gateway API 1.6.1, Gateway API Inference Extension 1.6.0, Kubernetes 1.32+, NGINX OSS 1.31.6, NGINX Plus R37.1, Agent v3.12.0, F5 WAF for NGINX 5.15.0 조합입니다. Helm chart 2.7.1과 Operator image 1.5.1을 사용하며, Service patch 렌더링과 여러 Gateway에서의 WAF bundle 탐색, WAF/Telemetry 활성화 후 데이터 플레인 복구 등을 수정했습니다.	v2.7.1 선택 시 해당 NGF 릴리스 참조를 사용합니다. 지원 기능 분류는 v2.7.0과 같습니다.
v2.7.0 최초 2.7 계열 버전 조합	Gateway API 1.6.1, Kubernetes 1.32+, NGINX OSS 1.31.4, NGINX Plus R37.1, NGINX Agent v3.11.4, F5 WAF for NGINX 5.15.0, Helm chart 2.7.0, Operator 1.5.0 조합입니다.	v2.7.0 선택 시 해당 릴리스의 manifest와 Migration Map 버전 안내를 표시합니다.
라우팅 리소스	`TCPRoute`와 `UDPRoute`는 Gateway API 1.6.1에서 Standard 채널의 v1으로 승격되었습니다. NGINX Gateway Fabric 2.7.0은 `TLSRoute` Terminate 모드와 upstream HTTP/2를 구현합니다.	이 도구는 Ingress 입력 범위에 맞춰 `Gateway`, `HTTPRoute`, `GRPCRoute`를 생성하고, `ssl-passthrough` 입력이 있으면 `TLSRoute`도 생성합니다. TCP/UDP 입력은 별도 리소스로 수동 설계해야 합니다.
External Authentication	HTTPRoute용 Gateway API `HTTPExternalAuthFilter`를 지원하고, JWT/OIDC `AuthenticationFilter`에 claim validation을 추가했습니다.	기존 Ingress NGINX `auth-url`의 응답·redirect·cache 의미는 자동 재설계하지 않고 Migration Map에서 수동 인증 설계로 표시합니다.
NGINX OSS 로드밸런싱	`least_time header`, `least_time last_byte`와 각 `inflight` 변형(총 4개 변형)을 NGINX Open Source에서도 사용할 수 있습니다. `random two least_time` 변형은 NGINX Plus 전용입니다.	v2.7.0 선택 시 OSS 지원 4개 변형과 NGINX Plus 전용 random two 변형을 Migration Map에서 구분합니다.
F5 WAF for NGINX / Policy Lifecycle Manager	`WAFPolicy` bundle source로 F5 Policy Lifecycle Manager를 사용할 수 있고, WAF telemetry를 NGINX Instance Manager로 보낼 수 있습니다.	기존 WAF/ModSecurity annotation은 라우팅 리소스로 자동 변환하지 않습니다. F5 WAF for NGINX policy bundle과 `WAFPolicy`를 별도 보안 정책으로 검토합니다.
`NginxProxy` / `ClientSettingsPolicy` 확장	HTTP response compression과 worker 설정은 `NginxProxy`에, `client_body_buffer_size`는 `ClientSettingsPolicy.spec.body.bufferSize`에 해당하며, Service ClusterIP 사용은 `NginxProxy`와 `UpstreamSettingsPolicy`에서 지원됩니다.	Ingress annotation의 자동 변환 범위를 넘는 `NginxProxy` 및 `ClientSettingsPolicy` 확장 설정은 임의로 생성하지 않고, 해당 입력이 있을 때 수동 검토로 분리합니다.
`ListenerSet`와 FrontendTLS	기존 2.6 계열의 ListenerSet, Gateway listener client certificate validation, 다중 `certificateRefs` 지원을 계속 제공합니다.	Ingress가 여러 host 또는 TLS secret을 사용할 때만 관련 검토 항목을 Migration Map에 표시합니다.

Gateway API 전환 전 확인할 항목

변환 결과는 바로 운영 환경에 적용하기보다 dev/stage 환경에서 apply, Gateway Programmed 상태, Route Accepted/ResolvedRefs, 실제 HTTP/HTTPS/WebSocket/gRPC 요청까지 확인해야 합니다. Gateway API 전환은 리소스 생성보다 동작 검증이 더 중요합니다.

NGINX Gateway Fabric OSS vs Plus: 비즈니스 요구에 최적화된 선택

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와 동일하게 동작하는지 함께 확인해야 합니다.

NGINX Gateway Fabric Open Source

표준 Gateway API 기반 라우팅, TLS, HTTPRoute/GRPCRoute, 기본 정책 구성이 필요한 환경에서 충분한 선택지입니다.
데이터 플레인은 NGINX Open Source를 사용하며, v2.8.0 기준 NGINX OSS 1.31.7 조합입니다.
endpoint 변경이 잦은 워크로드나 빈번한 Pod scale 환경에서는 graceful reload 빈도와 요청 지연 영향을 stage에서 측정해야 합니다.
round_robin, least_conn, ip_hash, hash, random, Random with Two Choices(Least Connections)와 v2.7.0부터 OSS에서도 지원되는 least_time header/last_byte 및 inflight 변형을 사용할 수 있습니다.
Cookie session persistence도 OSS에서 지원하지만, 관련 Gateway API 필드는 experimental/deprecated이며 이 도구는 자동 생성하지 않습니다.
비용과 운영 단순성이 중요하고 인증, 관측성, 상용 지원을 별도 계층에서 처리할 수 있다면 OSS가 현실적입니다.

NGINX Plus Gateway Fabric

데이터 플레인은 NGINX Plus를 사용하며, v2.8.0 기준 NGINX Plus R37.2 조합입니다.
Pod scale up/down처럼 upstream endpoint가 바뀌는 경우 NGINX Plus API로 동적으로 반영해 reload 빈도와 영향을 줄일 수 있습니다.
추가 Prometheus metrics, live activity dashboard, JWT/OIDC 인증, Active/Passive health checks, NGINX Plus API와 상용 지원을 활용할 수 있습니다. random two least_time와 2MB upstream zone 기본값도 포함됩니다.
SLO 99.9% 이상을 목표로 하는 프로덕션, 대규모 트래픽, 엔터프라이즈 지원이 필요한 환경에서는 Plus 기능 세트와 라이선스 비용을 함께 검토하세요.

FAQ: Ingress NGINX 지원 종료 대응 중 기존 Ingress 리소스를 삭제하지 않고 병행 운영할 수 있나요?

가능합니다. Kubernetes Ingress API 자체는 유지되므로 기존 Ingress NGINX와 NGINX Gateway Fabric을 같은 클러스터에서 병행 운영하면서 서비스 단위로 전환할 수 있습니다. 다만 Ingress NGINX 지원 종료라는 표현은 community Ingress NGINX 컨트롤러 지원 종료를 뜻하므로, 컨트롤러와 GatewayClass 구성을 분리하고 트래픽 진입점을 명확히 나눠야 합니다.

FAQ: Ingress NGINX Gateway API 변환은 EKS, GKE 같은 매니지드 환경에서도 가능한가요?

가능합니다. NGINX Gateway Fabric은 Kubernetes Gateway API 구현체이므로 EKS, GKE 같은 managed Kubernetes에서도 GatewayClass와 LoadBalancer 서비스 구성을 통해 사용할 수 있습니다. 단, 클라우드별 LB 통합, 노드 포트, 네트워크 정책은 환경에 맞게 확인해야 합니다.

FAQ: HTTPRoute 변환만 하면 쿠버네티스 Ingress 마이그레이션이 끝나나요?

아닙니다. HTTPRoute 변환은 라우팅 초안일 뿐이며, 정책·TLS·검증까지 완료해야 쿠버네티스 Ingress 마이그레이션이 끝납니다. Ingress NGINX migration 과정에서는 TLS Secret, ReferenceGrant, Route Accepted 상태와 실제 동작을 함께 검증해야 합니다.

NGINX Gateway Fabric 마이그레이션 지원

운영 환경에 맞춘 Gateway API 전환 전문가 지원

운영 환경 검토, NGINX Gateway Fabric 전환 설계, annotation 호환성 분석처럼 전문적인 기술지원이 필요하면 NGINX STORE로 연락 주세요.

NGINX Gateway Fabric 전환 상담하기