2026年6月16日に更新された公式情報の要点は、AKSのApplication RoutingアドオンにおけるGateway API運用の明確化です。具体的には、Envoyアクセスログが標準で有効になることと、externalTrafficPolicy: Localを使う場合のAzure Load Balancerヘルスプローブ設定が追記されました。
今回の更新で新たな強制切り替えや料金改定が発表されたわけではありません。ただし、従来のIngress NGINXベースのApplication Routingは、Microsoftによる重要なセキュリティパッチの提供が2026年11月までとなっています。利用中の管理者は、今回の更新内容を確認しながらKubernetes Gateway APIへの移行を進める必要があります。(Microsoft Learn)
2026年6月16日に更新された主な内容
公式ドキュメントの変更履歴を見ると、2026年6月16日の更新は、次の2点を中心とした運用情報の追加です。
| 変更点 | 管理者への影響 | 必要な対応 |
|---|---|---|
| Envoyアクセスログの仕様を追記 | Gatewayが処理したHTTPリクエストを標準出力で確認できる | ログ収集方法、保存期間、監視コストを確認する |
externalTrafficPolicy: Local利用時の注意を追記 | 既定のヘルスプローブ用アノテーションを残すと設定が不整合になる可能性がある | 指定された3つのアノテーションをConfigMapで解除する |
Application RoutingのGateway API実装自体は、2026年5月にプレビュー表記やプレビュー用機能フラグが削除され、一般提供向けのドキュメントへ更新されています。したがって、6月16日の変更は新機能の公開というより、一般提供後に必要となる監視・ネットワーク設定の補足と捉えるのが適切です。(GitHub)
AKSのApplication Routing with Gateway APIとは
AKSのApplication Routingアドオンでは、Kubernetes Gateway APIを使ってクラスター外部からのHTTP・HTTPSトラフィックを管理できます。
有効化すると、AKSが軽量なIstioコントロールプレーンをデプロイします。ただし、通常のIstioサービスメッシュとは異なり、対象はapprouting-istioというGatewayClassに属するGateway APIリソースだけです。
アプリケーションPodへのサイドカー注入、Istio独自のVirtualServiceやDestinationRule、サービス間mTLSなどは提供されません。つまり、Istioを利用したIngress専用のマネージド実装と考えると分かりやすいでしょう。(Microsoft Learn)
Ingress NGINXとの違い
| 項目 | 従来のApplication Routing | Gateway API実装 |
|---|---|---|
| Kubernetes API | Ingress | Gateway、HTTPRoute |
| クラス名 | webapprouting.kubernetes.azure.com | approuting-istio |
| データプレーン | ingress-nginx | Istio／Envoy |
| Azure DNS連携 | 組み込み対応 | 現時点では未対応 |
| Key Vault証明書連携 | 組み込み対応 | Secrets Store CSI Driverで構成 |
| サービスメッシュ機能 | なし | なし |
| 長期的な位置付け | 2026年11月までに移行が必要 | AKSにおける後継候補 |
Gateway APIでは、インフラ担当者がGatewayを管理し、アプリケーション担当者がHTTPRouteを管理するといった役割分担がしやすくなります。一方、Ingressのアノテーションをそのまま移せるわけではないため、既存マニフェストの変換と動作確認が必要です。(Microsoft Learn)
誰に影響する変更なのか
Application RoutingでIngress NGINXを利用している管理者
最も影響が大きい利用者です。
Ingress NGINXのアップストリーム保守は2026年3月に終了しています。AKSのApplication Routingで管理されるNGINXについては、Microsoftが2026年11月まで重要なセキュリティパッチを提供しますが、それ以降も使い続ける前提にはできません。(Microsoft Learn)
すでにGateway API実装を利用している管理者
アクセスログを独自に有効化しようとしていた場合は、設定を見直してください。Envoyアクセスログは既定で有効です。
また、クライアントIPの保持などを目的にexternalTrafficPolicy: Localを設定している場合は、Azure Load Balancerのヘルスプローブ用アノテーションを確認する必要があります。
Istioサービスメッシュアドオンの利用者
Application RoutingのGateway API実装と、AKSのIstioサービスメッシュアドオンは同時に有効化できません。
Istioサービスメッシュを無効化しただけでは、IstioのCRDやistioというGatewayClassが残ります。これらが残っているとApplication Routing側のIstioコントロールプレーンが起動できません。CRDを削除すると、関連するVirtualServiceやDestinationRuleも削除されるため、事前の棚卸しとバックアップが必要です。(Microsoft Learn)
一般ユーザー
正常に移行できれば、WebサイトやAPIを利用する一般ユーザーに操作変更はありません。
ただし、DNS切り替えやルーティング設定に不備があると、接続エラー、証明書エラー、404、502、503などが発生します。利用者への影響を避けるには、旧経路と新経路を並行稼働させてから切り替えることが重要です。
Gateway API実装の設定手順
前提条件を確認する
Azure CLIはバージョン2.86.0以上が必要です。
az --version古い場合はアップグレードします。
az upgradeまた、Application Routingでは自己管理のGateway API CRDはサポートされません。AKSのManaged Gateway API Installationを利用する必要があります。
既存クラスターにExperimentalチャネルのGateway API CRDがある場合は、そのまま有効化できません。Standardチャネルへの整理と、AKS・Gateway APIバンドル間のバージョン互換性を確認してください。(Microsoft Learn)
既存クラスターで有効化する
環境変数を設定します。
export RG=<resource-group-name>
export CLUSTER=<cluster-name>最初にManaged Gateway API CRDを有効化します。
az aks update \
--resource-group $RG \
--name $CLUSTER \
--enable-gateway-api続いてApplication RoutingのGateway API実装を有効化します。
az aks update \
--resource-group $RG \
--name $CLUSTER \
--enable-app-routing-istioこの操作だけで既存のIngressがGatewayやHTTPRouteへ自動変換されるわけではありません。既存のIngress NGINXは引き続きトラフィックを処理できるため、移行期間中は両方を並行稼働できます。(Microsoft Learn)
有効化できたか確認する
Istioコントロールプレーンの起動を確認します。
kubectl -n aks-istio-system rollout status deploy/istiod --timeout=5mGatewayClassを確認します。
kubectl get gatewayclass approuting-istioManaged Gateway API CRDも確認します。
kubectl get crds | grep gateway.networking.k8s.io作成済みのGatewayとHTTPRouteは次のコマンドで確認できます。
kubectl get gateway,httproute -AEnvoyアクセスログは標準で有効
2026年6月16日の更新では、管理対象のGatewayプロキシPodでEnvoyアクセスログが標準有効になっていることが明記されました。
ログには、HTTPメソッド、パス、レスポンスコード、転送先サービス、リクエストサイズ、レスポンスサイズなどが記録されます。追加設定を行わなくても、次のコマンドで確認できます。
kubectl logs \
-n <gateway-namespace> \
deployment/<gateway-name>-approuting-istio障害調査では、GatewayやHTTPRouteの状態だけでなく、Envoyログに記録されたレスポンスコードと転送先を確認すると、ルーティング設定とバックエンド障害を切り分けやすくなります。(GitHub)
ログ形式は変更できない
Application RoutingのGateway API実装では、IstioのTelemetry APIを使った次の変更はサポートされません。
- ログ形式の変更
- ログ出力範囲の変更
- ログプロバイダーの変更
- 独自テレメトリー設定の適用
ログの詳細なカスタマイズが必要な場合は、Application Routingではなく、Istioサービスメッシュアドオン上のGateway APIを検討する必要があります。(Microsoft Learn)
externalTrafficPolicyをLocalにするときの注意点
Application Routingは、既定のexternalTrafficPolicy: Clusterに合わせて、Azure Load Balancerのヘルスプローブを設定するアノテーションをGatewayのServiceへ追加します。
externalTrafficPolicyをLocalへ変更する場合は、公式ドキュメントで指定された次の3つのアノテーションを解除しなければなりません。
service: |
spec:
externalTrafficPolicy: Local
metadata:
annotations:
service.beta.kubernetes.io/port_80_health-probe_port:
service.beta.kubernetes.io/port_80_health-probe_protocol:
service.beta.kubernetes.io/port_80_health-probe_request-path:設定はGatewayClassレベルのConfigMap、または個別Gateway用のConfigMapで行います。
単にexternalTrafficPolicyだけをLocalへ変更し、Cluster向けのヘルスプローブ設定を残さないようにしてください。変更後は、Azure Load Balancerのバックエンド正常性と、各ノードへのトラフィック到達を確認します。(GitHub)
Ingress NGINXからGateway APIへ移行する手順
現在のIngressと接続元を棚卸しする
Application RoutingのIngressを一覧表示します。
kubectl get ingress -A \
-o jsonpath='{range .items[?(@.spec.ingressClassName=="webapprouting.kubernetes.azure.com")]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'Ingressだけでなく、次の設定も洗い出します。
- DNSのAレコード
- Azure Front Doorのオリジン
- Traffic Managerのエンドポイント
- ファイアウォールの許可IP
- 外部監視サービスの接続先
- TLS証明書と対象ホスト名
- WebSocket、gRPC、長時間接続の利用有無
DNSのTTLを先に短くする
切り替え前にDNSレコードのTTLを60秒、またはDNS事業者が許可する最小値へ変更します。
以前のTTLが1時間だった場合は、変更後に少なくとも1時間待ってから切り替えます。この待機を省略すると、キャッシュ済みのDNSリゾルバーが旧Ingress NGINXへアクセスし続けます。(Microsoft Learn)
IngressをGatewayとHTTPRouteへ変換する
基本的な役割は次のように置き換わります。
| 既存リソース | 移行先 |
|---|---|
| Ingress controller | GatewayClassとGateway |
| Ingressのhost・pathルール | HTTPRoute |
| IngressのTLS設定 | GatewayのHTTPSリスナー |
| NGINX固有アノテーション | Gateway APIのフィルターやConfigMap |
Ingressのアノテーションは、機械的に置換できないものがあります。リダイレクト、URL書き換え、ヘッダー操作、認証、タイムアウト、リクエストサイズ制限を利用している場合は、項目ごとに変換結果を確認してください。
HTTPSを先に構成する
Gateway API実装では、Application RoutingによるAzure DNS連携とKey Vault証明書の組み込み設定は、現時点でサポートされていません。
HTTPSを利用する場合は、Azure Key Vault Provider for Secrets Store CSI Driverで証明書をKubernetes Secretへ同期し、GatewayのcertificateRefsから参照します。DNSを切り替える前に、証明書チェーン、有効期限、SAN、ホスト名の一致を確認してください。(Microsoft Learn)
新旧の経路を並行してテストする
旧Ingress NGINXと新しいGateway API実装には、それぞれ異なるAzure Load BalancerのフロントエンドIPが割り当てられます。
DNS変更前は、curl --resolveを使って新しいIPへ直接アクセスできます。
curl --resolve "example.com:443:<new-gateway-ip>" \
https://example.com/HTTP 200だけで判断せず、次の動作も確認します。
- すべてのホスト名とパス
- POSTやファイルアップロード
- ログインと認証リダイレクト
- Cookieとセッション維持
- WebSocketとgRPC
- 長時間レスポンス
- TLS証明書チェーン
- 数分以上の連続負荷
- 5xxエラーと遅延の変化
DNSと上流サービスを切り替える
検証後、DNSのAレコードを新しいGateway IPへ変更します。
Azure Front Door、Traffic Manager、外部ファイアウォールなどに旧IPを直接登録している場合は、それらも同時に変更します。
旧Ingress NGINXのIPを新しいGatewayへそのまま付け替える方式は推奨されません。AKS管理のパブリックIPは、所有するServiceが削除されると、静的指定であっても削除される可能性があるためです。(Microsoft Learn)
安定後にNGINXを削除する
アクセスが新しいGatewayへ完全に移ったことを確認してから、既定のNGINXコントローラーの管理を停止します。
az aks approuting update \
--resource-group $RG \
--name $CLUSTER \
--nginx None残っているNginxIngressControllerリソースを削除します。
kubectl delete \
nginxingresscontrollers.approuting.kubernetes.azure.com \
--all切り替え直後にNGINXを削除しないことが重要です。旧経路を残している間は、DNSを元に戻すだけでロールバックできます。
自動更新で確認すべきこと
Application RoutingのIstioコントロールプレーンは、AKSのKubernetesバージョンに対応するIstioバージョンへ更新されます。
パッチ更新とマイナー更新はいずれもインプレースです。AKSクラスターを更新した場合だけでなく、対応リージョンに新しいIstioバージョンが展開された場合も、自動更新が行われることがあります。更新中にトラフィックが一時的に影響を受ける可能性は否定できません。(Microsoft Learn)
障害を抑えるため、各Gatewayには最小2レプリカのHPAと、最小可用数1のPodDisruptionBudgetが設定されます。istiodのHPAは、既定で最小2、最大5、CPU使用率80％です。最小レプリカ数を2未満には設定できません。
本番環境では、次を運用手順に含めてください。
- AKSリリースノートとリージョン展開状況の確認
- 更新前後のGateway・HTTPRouteステータス比較
- 5xx、レイテンシ、Pod再起動数の監視
- ノードの空きCPU・メモリ確認
- ステージング環境での回帰テスト
- 更新時間帯に合わせた監視体制の確保
料金は何が増えるのか
2026年6月16日の公式更新には、Application Routing Gateway API固有の料金改定は記載されていません。
ただし、機能を有効化しても実行リソースが無料になるわけではありません。次のコストを確認する必要があります。
| コスト項目 | 増える可能性がある理由 |
|---|---|
| AKSノード | istiodとGatewayプロキシPodがCPU・メモリを消費する |
| Azure Load Balancer | GatewayのServiceに負荷分散ルールとフロントエンドIPが作成される |
| パブリックIP | 外部公開するGatewayでIPアドレスが必要になる |
| データ転送 | Load Balancerのデータ処理とAzure外への送信が発生する |
| Azure Key Vault | TLS証明書や秘密情報の取得操作が発生する |
| Azure Monitor／Log Analytics | Envoyの標準出力ログを収集すると、取り込み量と保持期間に応じた料金が発生する |
特に移行期間中は、Ingress NGINXとGateway APIが別々のフロントエンドIPで並行稼働します。Load Balancerルール、パブリックIP、Podリソースが一時的に重複する点を予算へ含めてください。(Microsoft Learn)
Envoyログが標準出力へ出るだけでは、必ずしもLog Analytics料金が発生するわけではありません。Azure Monitorなどでログ収集を有効化した場合に、取り込み量や保持期間がコストへ影響します。TLSでKey Vaultを利用する場合は、シークレットや証明書の操作回数も確認します。(Microsoft Azure)
導入前に確認したい制約
次の要件がある場合は、Application RoutingのGateway API実装が適しているか再検討してください。
| 要件 | 判断 |
|---|---|
| Ingress専用のマネージドGateway APIが必要 | 適している |
| サービス間mTLSやサイドカーが必要 | Istioサービスメッシュアドオンを検討 |
| IstioのVirtualServiceを使いたい | Application Routingでは非対応 |
| Istio Telemetry APIでログを変更したい | Application Routingでは非対応 |
| Gateway APIでEgressを管理したい | 非対応 |
TLSRouteでSNIパススルーしたい | 現時点では非対応 |
| Azure DNSとKey Vaultを自動連携したい | 現時点では組み込み非対応 |
| 独自の監視・セキュリティ用サイドカーを注入したい | 正式サポート外 |
また、aks-istio-system名前空間へ独自に作成したistio-gateway-class-defaults ConfigMapがある場合は、Managed Gateway APIを有効化する前に削除が必要です。AKS管理のConfigMapと競合し、リソース調整が正常に行われない可能性があります。(Microsoft Learn)
2026年11月までに移行計画を具体化する
Ingress NGINXを利用している場合、2026年11月を単なる調査期限にしないことが重要です。実務上は、次の順序で前倒しするのが安全です。
- 現在のIngress、アノテーション、DNS、証明書を棚卸しする
- 検証環境でGatewayとHTTPRouteへ変換する
- Envoyアクセスログと監視コストを確認する
- HTTPS、認証、WebSocket、gRPCをテストする
- 本番で新旧データプレーンを並行稼働する
- DNSで段階的に切り替える
- 十分な監視期間を確保してからNGINXを削除する
すでにGateway APIを使っている場合は、まずアクセスログの収集設定とexternalTrafficPolicyを確認してください。Ingress NGINXを使っている場合は、移行対象の一覧作成と検証用Gatewayの構築が次に取るべき行動です。
コメント