피드로 돌아가기
Dev.toInfrastructure
원문 읽기
Ingress-NGINX EOL, 실패 시나리오 기반의 4가지 전환 경로
Ingress-NGINX Deprecation: What to Do Next (Four Paths, Four Failure Modes)
AI 요약
Context
kubernetes/ingress-nginx 저장소의 Read-only 전환으로 인한 패치 및 CVE 수정 중단. L7 데이터 경로 내 EOL 소프트웨어 사용으로 인한 보안 취약점 및 컴플라이언스 위반 위험 발생. 단순 도구 교체를 넘어선 아키텍처 결정의 필요성 증대.
Technical Solution
- 기존 Ingress 리소스의 Annotation 개수를 파악하여 마이그레이션 난이도 및 범위 측정
- 상용 벤더 제품이나 포크 버전으로 전환하여 기존 Annotation 호환성을 유지하고 패치 지원 확보
- Traefik, Kong 등 타 Ingress Controller로 교체하여 리소스 명세 유지 및 전환 속도 최적화
- Kubernetes-native 표준인 Gateway API를 도입하여 플랫폼 팀과 애플리케이션 팀 간의 역할 및 리소스 분리
- Service Mesh나 Cloud-native LB를 도입하여 Ingress 계층을 완전히 제거하고 네트워크 제어 구조 단순화
- 각 경로의 실패 지점(Vendor 종속성, Annotation 동작 차이, 도구 성숙도, 운영 복잡도)을 분석하여 선택
Key Takeaway
마이그레이션 도구의 마케팅 성능이 아닌 실제 운영 환경에서의 실패 시나리오를 정의하고 관리 가능한 리스크를 선택하는 설계 원칙.
실천 포인트
마이그레이션 전 Ingress 리소스당 Annotation 개수를 전수 조사하여 5개 초과 시 복잡도 높은 경로로 분류하고 검증 계획 수립할 것