AKS에서 Kubernetes Gateway API를 Azure Application Gateway를 통해 노출
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, markdown formatting, code blocks, and URLs exactly as they are.
소개
멀티 테넌트 AKS 클러스터에서 Azure Application Gateway를 통해 Kubernetes Gateway API를 노출해야 했습니다. 초기 통합은 실패했으며, 헬스 프로브가 비정상 상태이고 백엔드도 비정상으로 표시되었으며 트래픽이 흐르지 않았습니다. 이 문서에서는 작동하는 솔루션을 문서화하고 동일한 문제에 직면한 팀을 위한 레퍼런스 아키텍처를 제공합니다. 전체 솔루션은 GitHub에서 확인할 수 있습니다.
개념 증명 개요
POC는 AKS에서 Kubernetes Gateway API를 설정하고 이를 Azure Application Gateway를 통해 다중 테넌트 환경에서 노출하는 방법을 보여줍니다. 두 개의 샘플 애플리케이션(app1 및 app2)이 클러스터에 배포되며, 각각은 자체 HTTPRoute를 통해 노출되고 공통 Istio Gateway 리소스를 공유합니다.
샘플 애플리케이션
| Component | Description |
|---|---|
sample-app-1 | 경로 /app1에서 **“Hello from App 1”**을 반환하는 Nginx pod |
sample-app-2 | 경로 /app2에서 **“Hello from App 2”**을 반환하는 Nginx pod |
health-responder | /healthz에서 Application Gateway 건강 프로브를 위한 전용 pod |
| Istio Gateway | K8s Gateway API를 구현하는 공유 Gateway 리소스 |
| HTTPRoutes | 애플리케이션 네임스페이스 내 경로별 라우팅 규칙 |
각 애플리케이션은 자체 네임스페이스에 HTTPRoute를 가지고 있으며, 이는 애플리케이션 팀이 공통 게이트웨이 인프라를 사용하면서 라우트를 직접 관리하는 셀프‑서비스 라우팅 모델을 보여줍니다.
Note: POC는 Azure 통합 과제에 집중하기 위해 시나리오를 단순화했습니다.
app1과app2는 두 개의 별도 테넌트에서 실행되는 애플리케이션을 시뮬레이션합니다. 향후 게시물에서는 Capsule과 Gateway API를 활용한 쿠버네티스 멀티‑테넌시에 대해 다룰 예정입니다.
아키텍처 구성 요소
| Component | Purpose |
|---|---|
| Azure Application Gateway | WAF와 TLS 종료를 포함한 공개 진입점 |
| Internal Load Balancer | Application Gateway를 AKS 클러스터에 연결 |
| Istio Gateway | Kubernetes Gateway API 구현 |
| HTTPRoutes | 테넌트를 위한 네임스페이스별 라우팅 규칙 |
| Istio Ambient Mesh | 사이드카 없이 서비스 간 mTLS |
구현 과제 및 해결책
문제 1: 헬스 프로브 실패
문제 – Azure Application Gateway 헬스 프로브가 404를 반환했는데, 이는 Istio의 Envoy 프록시가 프로브 경로에 일치하는 HTTPRoute가 없었기 때문입니다.
해결책 – 헬스 프로브 경로와 일치하고 health-responder 포드로 전달하는 명시적인 HTTPRoute를 생성합니다.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: health-route
namespace: gateway-health
spec:
parentRefs:
- name: shared-gateway
namespace: istio-ingress
rules:
- matches:
- path:
type: PathPrefix
value: /healthz
backendRefs:
- name: health-responder
port: 8080문제 2: Azure DSR을 위한 ExternalTrafficPolicy
문제 – Azure 내부 로드 밸런서는 Direct Server Return(DSR) 모드로 동작합니다. 기본 externalTrafficPolicy: Cluster 설정에서는 kube‑proxy가 노드 간 트래픽을 전달할 때 SNAT을 수행하여 DSR에 필요한 비대칭 라우팅이 깨지고 연결 타임아웃이 발생합니다.
해결책 – 게이트웨이 서비스에 externalTrafficPolicy: Local을 적용하도록 패치하여, 트래픽이 요청을 받은 노드의 파드로만 라우팅되도록 하고 DSR 흐름을 유지합니다.
kubectl patch svc -n \
-p '{"spec":{"externalTrafficPolicy":"Local"}}'