Ingress NGINX에서 AKS Istio Gateway API로의 전환

Kubernetes에서 외부 또는 내부 사용자 트래픽을 애플리케이션으로 전달할 때, 가장 익숙한 방식은 오랫동안 Ingress와 Ingress Controller였다. 나 역시 기존 환경에서는 ingress-nginx를 사용해 여러 서비스의 진입점을 운영하고 있었다.

하지만 최근에는 단순히 “익숙하다”는 이유만으로 Ingress 구조를 계속 유지하기에는 고민할 지점이 많아졌다. Kubernetes 공식 문서에서도 Ingress는 기능 동결 상태로 안내되고 있고, 더 유연한 구조인 Gateway API 사용이 권장되고 있다. 여기에 더해 커뮤니티 ingress-nginx 프로젝트도 2026년 3월 retire 예정으로 발표되면서, 기존 구조를 계속 가져가는 것에 대한 운영 리스크도 분명해졌다.

이번 작업의 목적은 단순히 리소스 종류를 Ingress에서 Gateway로 바꾸는 것이 아니었다. 핵심은 기존 ingress-nginx 기반 진입 구조를 AKS의 Istio add-on 기반 Gateway API 구조로 전환할 수 있는 기반을 먼저 만들고, 기존 서비스에는 영향 없이 점진적으로 옮길 수 있는 길을 여는 것이었다. AKS는 Istio service mesh add-on을 제공하고, 해당 구조에서는 Gateway API 기반 ingress 구성이 가능하다. 또한 Gateway가 생성한 LoadBalancer Service는 Azure Load Balancer와 연결되기 때문에, 결과적으로 Azure 네트워크 위에서 새로운 진입점을 운영할 수 있다.

 

이번 전환을 더 이상 미룰 수 없었던 이유

가장 직접적인 이유는 ingress-nginx retire 발표였다. retire 이후에는 보안 패치나 버그 수정이 더 이상 제공되지 않기 때문에, 기존 배포가 당장 깨지지는 않더라도 장기 운영 관점에서는 더 이상 안정적인 선택지라고 보기 어렵다.

또한 Kubernetes도 이미 Ingress보다 Gateway API를 더 확장 가능한 방향으로 제시하고 있다. 따라서 이번 전환은 단순한 실험이 아니라, Kubernetes 생태계의 흐름과 운영 안정성을 고려했을 때 자연스럽게 검토해야 하는 다음 단계라고 판단했다.

 

왜 Gateway API로 바꾸려 했는가

핵심 이유는 두 가지였다.

• Ingress보다 역할 분리가 명확하다
• 기존 진입점과 분리된 새 진입점으로 안전하게 점진 전환할 수 있다

Gateway API에서는 역할이 이렇게 나뉜다.

• GatewayClass: 어떤 컨트롤러를 사용할지 정의
• Gateway: 실제 진입점 정의
• HTTPRoute: 서비스별 라우팅 정의

즉 기존처럼 Ingress 하나에 모든 규칙을 몰아넣는 방식이 아니라,
진입점과 라우팅 규칙을 나눠서 관리할 수 있다.

 

기존 구조

기존에는 하나의 ingress-nginx가 여러 도메인과 여러 경로를 한 번에 처리했다.

이 구조는 처음에는 단순하고 편하다.
하지만 서비스가 늘어나면 하나의 ingress controller에 너무 많은 역할이 몰리게 된다.
또한 timeout, websocket, redirect 같은 세부 설정이 annotation 위주로 쌓이면서 관리가 점점 복잡해진다.

 

목표 아키텍처

이번 작업의 목표는 기존 ingress-nginx를 한 번에 제거하는 것이 아니었다. 오히려 그 반대였다. 기존 ingress-nginx는 유지하고, 별도의 Gateway API 진입점을 먼저 만든 뒤, 새로운 진입점으로 HTTPRoute를 하나씩 붙이며 천천히 마이그레이션하는 구조를 만들고 싶었다.

이 접근이 중요한 이유는 다운타임 리스크를 낮출 수 있기 때문이다. Gateway API는 구현체에 따라 동적으로 인프라를 프로비저닝할 수 있고, AKS + Istio add-on 환경에서는 Gateway 생성 시 gateway deployment/service가 자동 생성될 수 있다. 즉 기존 ingress는 그대로 두고, 새로운 Gateway 진입점에 대해서만 개별 호스트/경로를 검증한 뒤 DNS를 전환하면 된다.

 

기존 ingress-nginx는 그대로 두고,
새 Gateway는 별도 Internal LoadBalancer IP로 생성됐다.

• 기존 ingress-nginx: 10.X.X.X
• 신규 Istio Gateway: 10.X.X.X

이렇게 되면 운영 트래픽을 건드리지 않고 새 진입점에서 먼저 테스트할 수 있다.

 

실제 구성 방식

이번 구조는 Azure CNI 자체 기능으로 Gateway를 만든 것은 아니다.
정확히는 AKS 위에서 Istio add-on이 Gateway를 생성하고, 그 결과 만들어진 LoadBalancer Service를 Azure가 Internal Load Balancer로 연결해주는 방식이다. AKS의 internal LoadBalancer Service는 Azure Internal Load Balancer로 연결된다.

 

즉 이 구조는 Azure CNI 기반 AKS 위에서 Istio add-on을 통해 Gateway를 운영하는 형태라고 보는 게 가장 정확하다.

 

내가 적용한 핵심 포인트

이번 작업에서 중요한 포인트는 아래였다.

1) Gateway를 먼저 생성

기존 ingress를 지우지 않고, 새 Gateway를 먼저 만들었다.

2) 새 IP를 먼저 확보

Gateway가 PROGRAMMED=True 상태가 되면서 새로운 내부 IP가 생겼다.

3) HTTPRoute를 하나씩 옮길 수 있는 기반 마련

이제부터는 argocd, grafana, prometheus, chatx 순서로 HTTPRoute를 점진적으로 붙이면 된다.

 

즉 이번 작업은 “한 번에 전체 교체”가 아니라, 별도 진입점을 먼저 확보한 뒤 단계적으로 이전할 수 있는 구조를 만든 것에 의미가 있다.

 

 

이번 작업은 단순히 Ingress YAML을 Gateway YAML로 바꾸는 수준의 변경이 아니었다.
더 이상 확장되지 않는 Ingress 중심 구조에서 벗어나, 역할 분리가 명확하고 점진 전환이 가능한 Gateway API 구조로 넘어가기 위한 첫 단계였다.

무엇보다 의미 있었던 점은, 기존 ingress-nginx와 완전히 분리된 새로운 internal entrypoint를 확보했다는 것이다. 덕분에 운영 서비스에 영향을 주지 않고 Route를 하나씩 옮겨가며 검증할 수 있는 기반이 마련됐다.

즉 이번 작업의 의미는 “전환 완료”가 아니라,
안전하게 마이그레이션할 수 있는 새로운 진입점을 확보했다는 것에 있다.