Ingress NGINX 은퇴 앞둔 상황, 어떻게 준비할까
갑작스럽게 찾아온 변화
최근 Kubernetes 커뮤니티에서 꽤 큰 발표가 있었습니다. 오랫동안 많은 클러스터에서 기본 게이트웨이 역할을 해온 Ingress NGINX가 2026년 3월에 공식 지원을 종료한다는 소식이었거든요.
사실 이런 일이 언젠가는 일어날 거라는 예상은 있었습니다. 보안 이슈가 계속 터져나오고, 유지보수하는 사람들도 점점 줄어들고 있었으니까요. 하지만 막상 공식적으로 발표되고 나니 적잖은 충격이었습니다.
왜 은퇴하게 됐을까
Ingress NGINX의 가장 큰 문제는 너무 유연했다는 점이었습니다. 임의의 NGINX 설정을 주입할 수 있는 기능이 처음엔 강점이었지만, 시간이 지나면서 치명적인 보안 취약점이 되었어요.
특히 다양한 보안 이슈들이 계속 발견되면서, 소수의 유지보수자들이 이를 따라잡기 어려워졌습니다. Kubernetes SIG 네트워크팀에서도 더 이상 안전하게 유지할 수 없다고 판단했고요.
주요 문제점들:
- 지속적인 보안 취약점 발생
- 제한된 유지보수 인력
- 레거시 아키텍처로 인한 기술 부채
- Kubernetes 업데이트 속도를 따라가지 못하는 상황
대안들을 살펴보자
그렇다면 어떤 선택지가 있을까요? 여러 대안들을 체계적으로 평가해봤습니다.
Gateway API (Contour/Envoy)
미래 지향적인 선택이라고 할 수 있습니다. Kubernetes의 차세대 표준으로 자리잡고 있어서 장기적으로 가장 안전한 선택지예요.
- 표준 스펙에 따른 안정성
- 강력한 커뮤니티 지원
- 최신 기능들 적극 지원
- 다소 높은 러닝 커브
Traefik Proxy
사용 편의성 면에서는 단연 최고입니다. 설정이 직관적이고, 자동 서비스 디스커버리가 잘 되어 있어요.
- 간단한 설정과 관리
- 우수한 문서화
- 활발한 커뮤니티
- Let's Encrypt 자동 연동
Kong Ingress Controller
API 게이트웨이 기능이 필요하다면 Kong이 좋은 선택입니다. 플러그인 생태계가 풍부해서 확장성이 뛰어나거든요.
HAProxy Ingress
성능을 최우선으로 한다면 HAProxy를 고려해볼 만합니다. 오랜 시간 검증된 안정성과 뛰어난 성능을 자랑하죠.
선택 기준은 무엇일까
어떤 대안을 선택할지는 여러 요소를 종합적으로 고려해야 합니다.
보안 측면
| 항목 | 중요도 | 평가 포인트 |
|---|---|---|
| 취약점 이력 | 높음 | CVE 기록, CVSS 점수 |
| 대응 속도 | 높음 | 패치 릴리즈 속도 |
| 보안 기능 | 중간 | mTLS, OIDC 지원 여부 |
운영 복잡성
- 설치와 설정의 난이도
- 기존 팀의 학습 곡선
- CI/CD 파이프라인 통합 복잡도
- 문제 해결 도구의 품질
성능과 확장성
실제 워크로드와 비슷한 환경에서 테스트해보는 게 가장 확실합니다. RPS 용량, 지연시간, 리소스 사용량을 꼼꼼히 측정해봐야 해요.
마이그레이션 어떻게 할까
실제 마이그레이션은 단계적으로 진행하는 게 안전합니다.
1단계: 현황 파악
먼저 현재 사용 중인 Ingress 리소스들을 모두 정리해야 합니다.
# 모든 Ingress 리소스 조회
kubectl get ingress --all-namespaces
# 특정 어노테이션 사용 현황 확인
kubectl get ingress -o yaml | grep -A 5 -B 5 "nginx.ingress"
2단계: 대상 솔루션 검증
스테이징 환경에서 충분히 테스트해봐야 합니다. 특히 기존에 사용하던 어노테이션들이 새로운 솔루션에서도 지원되는지 확인이 필요해요.
3단계: 점진적 롤아웃
블루-그린 배포나 카나리 배포 방식을 활용하면 리스크를 최소화할 수 있습니다.
- 새로운 Ingress 컨트롤러 설치
- 일부 서비스만 새 컨트롤러로 라우팅
- 모니터링하면서 점진적으로 확대
- 모든 트래픽 이전 후 구 컨트롤러 제거
4단계: 모니터링과 검증
메트릭, 로그, 알림 설정이 제대로 동작하는지 확인해야 합니다. 특히 Prometheus 메트릭 형식이 바뀔 수 있으니 대시보드도 함께 업데이트해야 해요.
언제까지 준비해야 할까
2026년 3월이 데드라인이지만, 여유를 두고 2025년 말까지는 마이그레이션을 완료하는 게 좋을 것 같습니다.
특히 대규모 클러스터라면 더 일찍 시작해야 하고요. 팀 내 교육이나 새로운 도구에 대한 적응 시간도 충분히 확보해야 합니다.
추천 시나리오
제 경험으로는 이런 선택이 합리적일 것 같습니다.
- 장기적 안정성 우선: Gateway API (Contour)
- 빠른 마이그레이션 필요: Traefik
- 고성능 요구사항: HAProxy
- API 게이트웨이 기능: Kong
- 서비스 메시 환경: Istio Gateway
마치며
기술 생태계에서 이런 변화는 자연스러운 일이지만, 막상 당면하면 부담스럽긴 합니다. 하지만 이번 기회에 더 현대적이고 안전한 솔루션으로 업그레이드할 수 있다고 생각하면, 나쁘지만은 않은 것 같아요.