Ingress NGINX 지원 종료

Ingress NGINX 지원 종료, NGINX Gateway Fabric으로 완성하는 표준 전환

지원 종료된 Ingress NGINX 컨트롤러를 계속 운영하면 신규 CVE와 Kubernetes 업그레이드 리스크를 운영 팀이 직접 떠안게 됩니다.

community Ingress NGINX 컨트롤러의 저장소는 2026년 3월 24일 archive되어 read-only 상태가 되었고, 신규 릴리스, 버그 수정, 보안 업데이트가 이미 종료되었습니다(EOL, End-of-Life). Kubernetes Ingress API 자체가 사라지는 것은 아니지만, 운영 환경에서는 NGINX Gateway Fabric 같은 Gateway API 기반 대안으로의 전환 계획이 필요합니다.

기존 Ingress NGINX YAML을 입력해 보세요. 이 도구는 NGINX Gateway Fabric 기반 Gateway API 리소스(HTTPRoute 등)로 변환한 결과를 제공하고, 전환 전에 확인해야 할 migration warning과 annotation 호환성 지점을 표시합니다.

INGRESS (원본)
GATEWAY API (변환)

컨트롤러 지원 종료가 비즈니스에 미치는 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.7.0 릴리스 노트

v2.7.0은 Gateway API 1.6.1을 지원하는 주요 릴리스입니다. 라우팅, 인증, WAF, NginxProxy와 Kubernetes 호환성 범위가 확장됐으며, 실제 Ingress 입력과 관련된 항목만 Migration Map에 표시합니다.

릴리스 항목 마이그레이션 영향 도구 변환
v2.7.0 핵심 버전 조합 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으로 올리고, 생성되는 Gateway API 리소스와 Migration Map의 버전 안내를 v2.7.0 기준으로 표시합니다.
라우팅 리소스 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 claim validation이 확장됐습니다. OIDC 인증 필드 검증 강화(CVE-2026-66362 수정)도 포함합니다. 기존 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.7.0 기준 NGINX OSS 1.31.4 조합입니다.
  • 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 변형을 사용할 수 있습니다.
  • 비용과 운영 단순성이 중요하고 인증, 관측성, 상용 지원을 별도 계층에서 처리할 수 있다면 OSS가 현실적입니다.

NGINX Plus Gateway Fabric

  • 데이터 플레인은 NGINX Plus를 사용하며, v2.7.0 기준 NGINX Plus R37.1 조합입니다.
  • Pod scale up/down처럼 upstream endpoint가 바뀌는 경우 NGINX Plus API로 동적으로 반영해 reload 빈도와 영향을 줄일 수 있습니다.
  • 추가 Prometheus metrics, live activity dashboard, JWT/OIDC 인증, NGINX Plus API와 상용 지원을 활용할 수 있습니다. random two least_time 같은 Plus 전용 변형도 사용할 수 있습니다.
  • 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 전환 상담하기
복사 완료!