3줄 요약 (TL;DR)
중요 공지: Kubernetes 생태계에서 널리 사용되던 kubernetes/ingress-nginx 프로젝트의 지원이 종료됩니다.
1.
언제?: 2026년 3월부로 보안 패치를 포함한 모든 지원이 중단됩니다.
2.
왜?: 유지보수 인력 부족, Snippet 기능의 보안 취약점, 차세대 프로젝트(InGate) 개발 중단이 주요 원인입니다.
3.
해결책: 단기적으로는 다른 Ingress 컨트롤러(NGINX Inc., Kong, Istio 등)로 전환하거나, 장기적으로는 차세대 표준인 Gateway API로 마이그레이션해야 합니다.
타임라인: 알아야 할 주요 시점
시점 | 상태 | 상세 내용 |
2024. 11 | 계획 발표 | KubeCon NA에서 InGate 프로젝트 발표 및 Ingress NGINX의 단계적 종료 계획 공유 |
2025. 11 | 공식 발표 | InGate 개발 중단 및 Ingress NGINX 완전 종료 공식 발표 |
2026. 03 | 지원 종료 | Best-effort 유지보수 종료. 이후 보안 패치, 버그 수정, 릴리스 전면 중단 |
참고 사항:•
2026년 3월 이후에도 기존 배포된 Ingress NGINX는 계속 작동합니다.
•
Helm 차트와 컨테이너 이미지는 참조 형식으로 계속 제공됩니다.
•
단, 새로운 보안 취약점이 발견되어도 패치가 제공되지 않으므로 프로덕션 환경에서는 마이그레이션이 필요합니다.
왜 종료되는가? (The Why)
Kubernetes 클러스터에서 가장 많이 사용되는 Ingress 컨트롤러 중 하나가 왜 종료되는 것일까요?
1. 지속 불가능한 유지보수 구조
•
Ingress NGINX는 수 년 간 단 1~2명의 메인테이너가 개인 시간(퇴근 후, 주말)에 관리해왔습니다.
•
프로젝트의 인기에도 불구하고 추가 지원 메인테이너를 확보하는 데 실패했습니다.
•
전형적인 오픈소스 '지속가능성' 문제를 보여주는 사례입니다.
2. 기술 부채: Snippet 기능의 보안 문제
•
NGINX 설정을 직접 주입할 수 있는 'Snippet' annotation은 높은 유연성을 제공했지만, 임의의 설정 주입이 가능한 보안 취약점이 되었습니다.
•
현대적인 클라우드 네이티브 보안 요구사항을 충족하기 어려운 구조였습니다.
3. 대체 프로젝트(InGate) 개발 실패
•
2024년 KubeCon NA에서 Gateway API 기반 대체 프로젝트 'InGate'를 발표했습니다.
•
그러나 InGate 개발이 충분히 진행되지 못하고 중단되었습니다.
•
결과적으로 점진적 전환 대신 프로젝트 완전 종료가 결정되었습니다.
Ingress API의 한계와 Gateway API의 등장
이번 사태는 단순한 도구의 종료가 아니라, Ingress API 표준의 구조적 한계를 보여줍니다.
Legacy: Ingress API의 'Annotation 의존성'
Ingress 표준은 기본적인 HTTP 라우팅만 지원합니다. 실무에 필요한 고급 기능들(리다이렉트, 인증, Rate Limit, 카나리 배포 등)은 표준에 포함되지 않아 벤더별 Annotation에 의존해야 했습니다.
# Ingress의 현실: 표준보다 벤더 특화 annotation이 더 많은 구조
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: legacy-ingress
annotations:
# 컨트롤러를 변경하면 이 annotation들을 모두 다시 작성해야 합니다
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app
port:
number: 80
YAML
복사
주요 문제점:
•
컨트롤러 변경 시 annotation을 전부 재작성해야 함
•
벤더 락인(Lock-in) 발생
•
표준화 부족으로 인한 일관성 저하
Next Gen: Gateway API의 '역할 기반 표준화'
Gateway API는 조직의 역할을 모델링하여 인프라 관리자와 애플리케이션 개발자의 책임을 분리했습니다.
주요 구성 요소:
•
GatewayClass: 인프라 제공자가 정의 (어떤 로드밸런서를 사용할 것인가?)
•
Gateway: 클러스터 운영자가 정의 (어떤 포트와 프로토콜을 열 것인가?)
•
HTTPRoute: 애플리케이션 개발자가 정의 (트래픽을 어떻게 라우팅할 것인가?)
# Gateway API: 역할 분리와 표준화된 트래픽 분할
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: canary-route
spec:
parentRefs:
- name: my-gateway
rules:
- backendRefs:
- name: app-v1
weight: 90 # 표준 필드로 가중치 제어
- name: app-v2
weight: 10
YAML
복사
Gateway API의 장점:
•
고급 기능(가중치 기반 라우팅, 헤더 매칭 등)이 표준 API로 제공
•
역할 기반 접근 제어(RBAC)가 자연스럽게 통합
•
HTTP, gRPC, TCP, UDP 등 다양한 프로토콜 지원
•
벤더 중립적 표준
대응 전략: 무엇을 선택할 것인가?
조직의 상황에 따라 두 가지 전략 중 하나를 선택할 수 있습니다.
Strategy A: 다른 Ingress 컨트롤러로 전환 (단기 대응)
Gateway API 도입이 부담스럽다면, Ingress API를 유지하면서 유지보수가 활발한 다른 컨트롤러로 전환합니다.
주요 컨트롤러 소개:
대안 | 특징 | 적합한 경우 |
NGINX Inc. Ingress | F5 NGINX가 관리하는 별도 프로젝트. 상용 지원 가능 | 기존 NGINX 설정을 유지하면서 엔터프라이즈 지원이 필요한 경우 |
Kong Ingress | API Gateway 기능(인증, Rate Limit, 플러그인)이 강력함 | Ingress를 API Gateway처럼 사용하는 경우 |
Istio Ingress | Envoy 기반. 서비스 메시와 긴밀한 통합 | mTLS, 상세한 트래픽 관리가 필요한 경우 |
Traefik | 자동 서비스 디스커버리, Let's Encrypt 통합 | 동적 환경에서 간편한 설정을 원하는 경우 |
마이그레이션 고려사항:
•
기존 Ingress 리소스 중 annotation에 크게 의존하는 부분 파악
•
새 컨트롤러의 annotation 문법으로 변환 필요
•
테스트 환경에서 충분한 검증 후 단계적 전환
Strategy B: Gateway API로 완전 전환 (장기 전략)
SIG Network가 권장하는 미래 지향적 접근입니다. Ingress의 구조적 한계를 벗어나 Kubernetes의 네트워킹 표준으로 이동합니다.
Gateway API 도입의 이점:
1.
표준화된 고급 기능: 카나리 배포, 헤더 기반 라우팅, 미러링 등이 표준 API로 제공
2.
역할 기반 분리: 인프라, 운영, 개발 팀 간 책임과 권한을 명확히 분리
3.
프로토콜 통합: HTTP, gRPC, TCP, UDP를 일관된 API로 관리
4.
벤더 중립성: 컨트롤러 교체 시에도 설정 변경 최소화
주요 Gateway API 구현체:
•
Istio Gateway Controller
•
Cilium Gateway API
•
Envoy Gateway
•
Kong Gateway
•
Traefik
•
등등
결론 및 Action Items
Kubernetes 생태계는 끊임없이 진화합니다. Ingress NGINX의 종료는 아쉽지만, 더 성숙하고 표준화된 Gateway API 시대로 나아가는 자연스러운 과정입니다.
지금 해야 할 일:1.
현황 파악: 클러스터에서 Ingress NGINX 사용 여부 확인
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Bash
복사
2.
의존성 분석: Snippet, custom annotation 등 마이그레이션 시 주의가 필요한 설정 파악
3.
전략 수립:
•
단기: 다른 Ingress 컨트롤러로 전환 (Strategy A)
•
장기: Gateway API로 마이그레이션 (Strategy B)
4.
일정 계획: 2026년 3월 이전까지 마이그레이션 완료를 목표로 로드맵 수립
5.
테스트 환경 구축: 프로덕션 전환 전 충분한 검증 수행
참고 자료
•
InGate 프로젝트 저장소 (개발 중단)
본 글은 Kubernetes SIG Network와 Security Response Committee의 공식 발표를 기반으로 작성했습니다.
이현승 프로
오픈소스사업부 오픈소스클라우드그룹
클라우드 및 오픈소스 SW 관련 연구 개발 프로젝트를 수행하였으며,
현재 OSS 기술 서비스 및 아키텍처를 담당하고 있습니다.