쿠버네티스 Ingress NGINX 지원 종료 임박, Gateway API 이전 준비

2026년 3월, 쿠버네티스에서 가장 널리 사용되던 Ingress NGINX의 지원이 공식 종료됨에 따라 Gateway API로의 이전은 더 이상 미룰 수 없는 과제가 되었습니다. 특히 Ingress NGINX의 설정 주입 방식에서 비롯된 IngressNightmare(CVE-2025-1974, CVSS 9.8) 같은 심각한 보안 취약점은 원격 코드 실행(RCE) 가능성을 내포하여 클러스터 전체의 보안을 위협합니다. 이러한 구조적 위험성과 지원 종료라는 현실적인 제약은 안전하고 현대적인 트래픽 라우팅 표준으로의 전환을 더욱 가속화하고 있습니다.

이번 재측정은 작년의 통과율 기반 채점 방식이 가진 구조적 한계(미지원 기능 미반영, 기능 가중치 불균형, A/F 등급의 모호성)를 극복하기 위해 Gateway API의 공식 적합성 모델을 따랐습니다. Core(필수 기능 7개)와 Extended(선택 기능 13개)로 나누어 평가하고, 구현체 고유 기능은 별도 매트릭스로 비교했습니다. 이 방식은 각 구현체가 표준을 얼마나 충실히 따르는지, 그리고 어떤 추가 기능을 제공하는지에 대한 더욱 세밀하고 객관적인 정보를 제공합니다.

작년과 달리 Kong, Traefik 등 주요 구현체들이 Core 테스트를 통과한 이유는 제품 자체의 변화보다는 측정 환경과 방식의 개선에 있습니다. Gateway API 표준 성숙(v1.2 → v1.4), 권장 설치 방식(KIC Unmanaged → KGO Managed) 적용, 그리고 기능별 라우트 분리 적용 등 정교해진 측정 절차가 작년의 오진단을 바로잡았습니다. 이는 기술 검증 시 측정 방법론의 중요성을 다시 한번 강조합니다.

Gateway API v1.4 기준, 7개 구현체 모두 Core 기능을 통과했지만 Extended 기능 지원 범위는 구현체별로 차이를 보였습니다. Envoy Gateway와 Istio는 13개 Extended 기능을 모두 지원하며 가장 폭넓은 기능을 제공합니다. 반면 Kong은 6개로 가장 적은 기능을 지원했습니다. timeout, 응답 헤더 수정, 요청 미러링 등 운영 환경에서 자주 사용되는 기능의 지원 여부는 구현체 선택 시 중요한 고려 사항입니다.

Ingress NGINX에서 Gateway API로 마이그레이션 시, **설정 스니펫(configuration-snippet, server-snippet) 대체 불가, mTLS 클라이언트 인증(auth-tls-*)의 표준 부재, 세션 어피니티(Session Affinity)의 구현체별 상이한 설정**은 반드시 확인해야 할 주요 제약 사항입니다. 특히 임의 NGINX 지시문 주입 방식은 IngressNightmare 취약점의 원인이었으므로, 표준 기능으로의 전환이 필수적입니다.

단일 파드 삭제 후 트래픽 복구 시간 측정 결과, Istio와 kgateway는 무중단(Zero Downtime) 복구를 달성했습니다. NGINX Gateway Fabric, Envoy Gateway, Traefik은 약 13초, Kong은 약 34초가 소요되었습니다. 이는 고가용성(High Availability) 환경에서의 페일오버(Failover)와는 다르지만, 단일 노드 엣지 환경 등에서는 사용자 경험에 직접적인 영향을 미칠 수 있는 지표입니다.