AKS Ingress Patternsを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
非HTTPのTCP/UDP workloadはKubernetes LoadBalancer ServiceによるLayer 4 exposureが基本候補。HTTP/HTTPS/gRPC等はLayer 7 ingress/Gatewayを使う。 Microsoftのcurrent guidanceはHTTP-like trafficにmanaged ingress optionsを提示し、Application Gateway for Containersをrecommended optionの一つとしている。
Kubernetes Gateway APIはIngress APIのsuccessor/evolutionとしてrole-orientedなresource modelを提供し、AKSもlong-term ingress standardへ移行している。 AKS AutomaticではAKS 1.36以降の新規clusterでapplication routing add-onのKubernetes Gateway APIが既定となるため、新規設計ではGateway APIをbaselineとして扱う。
upstream Ingress NGINX projectは2026年3月にmaintenance終了。AKS application routing add-onのNGINX Ingress resourcesにはMicrosoftが2026年11月までcritical security patch supportを提供する。 2026年9月時点ではmanaged NGINXを新規long-term architectureの終着点にせず、Gateway API implementationやApplication Gateway for Containers等へのmigration pathを持つ。
Ingress controllerが正常でもService/EndpointSlice/pod readiness/NetworkPolicy/backend TLSが壊れていればapplicationは到達しない。L7→Service→Podまで通しで検証する。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Client endpoint | DNS/IP + protocol | L4かL7かを最初に決める。 |
| Listener/Gateway | TLS/SNI/host/path | shared ingressのplatform boundary。 |
| Service | ClusterIP/LoadBalancer等 | Kubernetes service abstractionとexternal Azure resourceを区別。 |
| Pod backend | EndpointSlice-selected workload | route成功とapplication readinessを別に確認。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| Protocol | HTTP-likeかarbitrary TCP/UDPか | HTTP-like→L7/Gateway、非HTTP→L4 Serviceを基準。 |
| Gateway API | role split/portable route modelが必要か | 新規L7はGateway API capable optionを優先。 |
| Azure-managed L7 | cluster外data plane/WAF/Azure integrationが必要か | Application Gateway for Containersを評価。 |
| Mesh | mTLS/service meshを既に採用するか | Istio ingress等をmesh architectureと一体で評価。 |
| Legacy NGINX | 既存application routing NGINXがあるか | 2026-11 support horizonをmigration deadlineとして計画。 |
実装・移行の順序
- protocol/port/host/path/TLS/client source requirementsをtraffic matrixへ。
- 候補をL4 / managed Gateway API / AGfC / meshに絞り、legacy NGINXはmigration sourceとして扱う。
- 1つのrepresentative appでfrontend→Service→Podまでend-to-end pathを作る。
- TLS certificate rotation、backend health、route status、negative host/pathを試験する。
- private ingressの場合はDNS/VNet/NSG routeをpublic testと分けて確認する。
- migrationはparallel ingress + low TTL/controlled cutoverで実施し、old endpointをrollback期間保持する。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| Frontend | DNS→IP、TLS cert/SNI、listener protocolを確認。 |
| Route | Gateway/Ingress statusとhost/path ruleを確認。 |
| Backend | Service selector、EndpointSlice、pod readinessを確認。 |
| Security | NetworkPolicy/NSG/WAF等のdecision pointを特定。 |
変更前に確認する
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,httproute -A
kubectl get ingress -A
kubectl get svc,endpointslices -A
kubectl get pods -A -o wideCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| frontend IPへ届くが404 | host/path route mismatch | Host/SNIとroute rule/statusを確認。 |
| 502/503 | Service endpoint/readiness/backend TLS | frontendよりbackend chainを優先確認。 |
| NGINX継続可否が不明 | support horizon見落とし | AKS managed NGINXは2026-11までのcritical patch supportを前提にmigration計画。 |
| TCP workloadをL7へ押し込む | protocol mismatch | LoadBalancer Service等L4 optionへ戻す。 |