Application Gateway for Containersを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
Application Gateway for ContainersはKubernetes workload向けmanaged Layer 7 load balancing / ingress serviceで、Azureがcluster外のunderlying data planeを運用する。 HTTP、HTTPS、gRPCに加えcurrent offeringではAI inference trafficにも対応する。protocol/feature要件はcurrent support matrixで確認する。
ALB ControllerはKubernetesのGateway API / Ingress API configurationをApplication Gateway for Containersのload balancing rulesへ変換する。 platform teamはshared ingress infrastructureを提供し、application teamはKubernetes-native route resourceでtraffic intentを定義する責任分界が取りやすい。
Gateway APIはGatewayClass/Gateway/HTTPRoute等でinfrastructure ownerとroute ownerを分離しやすく、長期的なAKS ingress designの中心になっている。 ingress成功だけでなくbackend endpoint health、TLS/SNI/host/path、source identity、NetworkPolicy、private backend reachabilityをpacket pathで確認する。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Frontend | client-facing IP/FQDN/TLS identity | DNS/certificate/host/SNIと紐付ける。 |
| Gateway/Route | Kubernetes-native intent | platform-owned Gatewayとapp-owned Routeの権限分界を定義。 |
| Service | stable backend abstraction | selector/port/EndpointSliceがactual backendを決める。 |
| Pod endpoint | actual application destination | readiness/NetworkPolicy/backend TLSをend-to-endで確認。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| API model | Ingress APIかGateway APIか | 新規設計はGateway APIを優先しrole-oriented ownershipを活用。 |
| Exposure | public/private ingressか | frontend/network association/DNS/certificateをenvironmentごとに分離。 |
| TLS | termination/re-encryption/backend TLS requirement | certificate ownership/rotationとhostname validationを設計。 |
| Shared platform | 複数namespace/teamで共有するか | Gateway ownershipとHTTPRoute attachment policyを定義。 |
| Migration | AGIC/NGINX等から移行するか | parallel endpoint + DNS cutoverでrollback可能にする。 |
実装・移行の順序
- client→host/path→Gateway/Ingress→Service→Podのdesired routeを表にする。
- ALB Controller identity/RBACとAzure resource ownershipをplatform boundaryとして確定する。
- non-prod routeを1本作り、status conditionとAzure data plane反映を確認する。
- TLS、host/path matching、backend health、negative routeを検証する。
- NetworkPolicy/NSG/UDRがAGfC data planeからbackendへの通信を阻害しないことを確認する。
- production移行はDNS weight/TTLまたはparallel hostnameでstageし、旧ingressを即時rollback可能に保つ。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| Kubernetes status | Gateway/HTTPRoute/IngressのAccepted/Programmed/ResolvedRefs等statusを確認。 |
| Controller | ALB Controller healthとevent/logを確認。 |
| Azure data plane | frontend/listener/routing/backend healthをAzure側で照合。 |
| End-to-end | 外部clientから実host/path/TLSでrequestしbackend responseを検証。 |
変更前に確認する
Control state
AKS networkProfile、Kubernetes object、Azure associationをread-onlyで採取し、desired configurationを固定する。
Data plane
同じ5-tupleで実通信し、forward path・return path・source translation・policy decisionを証明する。
Observability
DNS/TCP/flow/drop/backend health等、障害点に対応するsignalを同一時刻で収集する。
Negative test
allowだけでなく、禁止すべき通信が明示的に失敗することもsecurity acceptanceへ含める。
kubectl get gatewayclass,gateway -A
kubectl get httproute -A
kubectl get ingress,svc,endpointslices -A
kubectl get pods -A -o wideCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| Routeが反映されない | Gateway/HTTPRoute status/attachment/ALB Controller | status conditionを先に読み、Azure resourceだけを眺めない。 |
| 502/503 | backend Service/Endpoint/health/TLS | Service→EndpointSlice→pod readiness→backend TLSを確認。 |
| 一部host/pathだけ404 | matching priority/hostname/path | client Host/SNIとHTTPRoute ruleを比較。 |
| migrationで切戻せない | 旧ingress即削除/DNS TTL未設計 | parallel runとexplicit rollback endpointを維持。 |