📝 Ingress-NGINX Retirement 핵심 논점 - Gateway API 메인테이너 관점

[cloudbro-radar]

오는 3월 예정된 **Ingress-NGINX의 은퇴(Retirement)**를 앞두고, Gateway API 메인테이너인 Rob Scott가 커뮤니티의 우려와 오해를 4가지 핵심 포인트로 정리한 내용에 대해서 핵심만 요약한 정보를 공유드립니다.

1. 주요 요약 정보 - Gateway API 메인테이너 입장

1. Gateway API는 불안정하다?!?!

   • Fact: Gateway API는 이미 2년 넘게 GA(General Availability) 상태다.
   • Detail: 실험적(Experimental) 기능은 Feature Gate로 숨겨져 있어 안전하며, 오히려 Ingress 컨트롤러들보다 Gateway 구현체(Envoy Gateway 등)의 개발이 훨씬 활발하다.

2. 다른 Ingress Controller로 가는 게 더 쉽지 않나?!?!

   • Fact: ingress-nginx를 쓰던 사람들은 이미 수많은 **Annotation(주석)**에 락인(Lock-in)되어 있다.
   • Detail: 다른 Ingress 컨트롤러(Traefik, HAProxy 등)로 가려면 어차피 그쪽 전용 Annotation으로 다 바꿔야 한다. 그럴 바엔 표준화된 포터빌리티를 제공하는 Gateway API로 가는 게 낫다.

3. Gateway API에 없는 기능이 있다?!?!

   • Fact: Core API에 없더라도 각 구현체(Implementation)의 Extension으로 대부분 해결 가능하다.
   • Detail: GKE Gateway, Envoy Gateway 등은 이미 강력한 Custom Policy를 가지고 있다.

4. 마이그레이션이 너무 힘들다?!?!

   • Solution: ingress2gateway라는 툴을 통해 ingress-nginx의 설정을 Gateway API 리소스로 자동 변환하는 기능을 강력하게 지원 중이다.

2. Community Q&A (주요 질문 및 답변)

커뮤니티 댓글에서 나온 핵심 질문들과 그에 대한 답변을 정리했다.

• Q: Gateway API는 너무 복잡해. (IngressClass, Ingress vs GatewayClass, Gateway, HTTPRoute)
  • A: 인정한다. 하지만 HTTPRoute가 기존 Ingress의 진정한 대체재다. Gateway 리소스가 중간에 추가됨으로써 로드밸런서와 라우팅 규칙을 분리할 수 있어, 하나의 라우팅 규칙(HTTPRoute)을 내부/외부 게이트웨이에 동시에 붙이는 등 훨씬 유연한 구성이 가능하다.
• Q: 그럼 Ingress API는 이제 죽은 건가?
  • A: **“Frozen API”**다. 없어지진 않겠지만(Kubernetes 2.0 전까진 유지), 새로운 기능 추가는 없다. 모든 혁신(CORS, Timeouts 등)은 Gateway API에서만 일어난다.
• Q: Gateway API로 가려면 CNI(Calico, Flannel 등)도 바꿔야 하나?
  • A: 아니오. (Cilium Gateway 같은 특수 케이스 제외). Gateway API 구현체는 대부분 CNI와 독립적으로 작동한다. 예를 들어 Istio나 Envoy Gateway는 CNI 교체 없이 도입 가능하다.
• Q: 마이그레이션 전략은?
  • A: 한 번에 다 바꿀 필요 없다. 기존 Ingress와 새로운 Gateway API를 동시에(Side-by-side) 운영하며 점진적으로 트래픽을 옮겨라.

결론: Ingress-Nginx는 전설이었지만, 이제 보내줄 때가 됐다. Gateway API is the new standard.

[출처] Reddit - The heart of the internet

[jerry (이제응)]

@hyungwook.yu 님! 참고요!