2026年5月6日に公開または更新された Azure Kubernetes Service の公式情報で、AKS Automatic でも Application Gateway for Containers を AKS Add-on 経由で利用できるようになりました。これまで AKS Automatic クラスターでは Application Gateway for Containers をプロビジョニングできない制限がありましたが、今回の Public Preview により、AKS Automatic の運用モデルに合わせてマネージドな Ingress／L7ロードバランサーを構成しやすくなります。(Microsoft Azure)
結論から言うと、AKS Automatic を使っている管理者や開発者は、Application Gateway for Containers を「本番へすぐ入れる機能」としてではなく、非本番環境で Gateway API、Ingress、ネットワーク、ID、DNS/TLS、既存Ingressコントローラーからの移行性を検証する候補として扱うのが現実的です。Azure Updates の「In preview」は非本番での利用・テスト向けの位置付けであり、AKS のプレビュー機能も SLA や保証の扱いに注意が必要です。(Microsoft Azure)
Application Gateway for Containers managed add-on + AKS Automaticで変わったこと
今回の変更の中心は、AKS Automatic クラスターで Application Gateway for Containers を AKS Add-on として有効化できるようになった点です。Application Gateway for Containers 自体や AKS Add-on は以前から発表されていましたが、AKS Automatic では利用できない制限がありました。今回の Public Preview は、そのギャップを埋める更新です。(Microsoft Azure)
| 観点 | これまで | 今回の更新後 |
|---|---|---|
| AKS Automatic での利用 | Application Gateway for Containers をプロビジョニングできない制限があった | AKS Add-on を有効化することで利用可能 |
| 運用モデル | AKS Automatic の簡素化された運用体験と組み合わせにくかった | AKS Automatic のマネージド体験の一部として扱いやすくなる |
| 管理対象 | 支援インフラの手動準備・管理が課題になりやすかった | Add-on により、関連インフラの管理負担を下げられる |
| アプリ配信 | 既存の Ingress 構成や別のコントローラーに依存しやすかった | Gateway API／Ingress API ベースの Azure ネイティブな L7 配信を検討しやすい |
特に大きいのは、AKS Automatic の思想と合うことです。AKS Automatic は、クラスター構成や運用を自動化し、推奨構成を組み込むマネージド Kubernetes 体験です。今回の更新により、アプリケーションの入口となるロードバランサーについても、より Azure 側に管理を寄せた構成を取りやすくなります。(Microsoft Learn)
Application Gateway for Containersとは何か
Application Gateway for Containers は、Kubernetes クラスター上のワークロード向けに提供される L7ロードバランシング／アプリケーション配信サービスです。HTTP/HTTPS のルーティング、Ingress API、Gateway API、TLS、gRPC、WebSocket、WAF、トラフィック分割などに対応し、従来の Application Gateway Ingress Controller（AGIC）の発展形として位置付けられています。(Microsoft Learn)
ざっくり言えば、次のような役割を担います。
| 役割 | 内容 |
|---|---|
| 外部公開 | インターネットや外部クライアントから AKS 上のアプリへトラフィックを流す |
| L7ルーティング | Host、Path、Header、Query、Method などを条件にバックエンドへ振り分ける |
| TLS処理 | SSL終端、End-to-End SSL、mTLS などの構成を検討できる |
| Gateway API対応 | Kubernetes の Gateway API を使ったアプリケーション配信設計に移行しやすい |
| セキュリティ | WAF などを使い、アプリに到達する前の防御層を作れる |
Application Gateway for Containers は AKS クラスターの外側にデータプレーンを持ち、クラスター内で動作する ALB Controller が Kubernetes の Ingress、Gateway、ApplicationLoadBalancer などのリソースを監視して Azure 側の構成へ反映します。既存の Azure Application Gateway と同じものではなく、専用の ARM API と制御モデルを持つ点に注意が必要です。(Microsoft Learn)
AKS managed add-onを使うメリット
Application Gateway for Containers AKS managed add-on を使うと、ALB Controller を Helm で手動導入するのではなく、AKS の Add-on として管理できます。Microsoft Learn では、マネージド更新、マネージドIDの自動作成、専用サブネットの自動構成、フェデレーション資格情報やロール割り当ての簡素化がメリットとして整理されています。(Microsoft Learn)
| メリット | 実務での効果 |
|---|---|
| Helm チャート更新の負担軽減 | コントローラー更新作業を AKS 管理に寄せられる |
| ID構成の自動化 | applicationloadbalancer-<cluster-name> というマネージドIDと必要な権限が構成される |
| サブネット構成の簡素化 | AKS 管理の仮想ネットワークでは aks-appgateway サブネットが自動作成される |
| Gateway APIとの統合 | AKS の Gateway API Add-on と合わせて使える |
| AKS Automatic対応 | AKS Automatic では Add-on デプロイが必要になる |
AKS Automatic を使う場合、ALB Controller の Helm デプロイはサポートされず、Application Gateway for Containers ALB Controller AKS Add-on を使う必要があります。カスタム名前空間や独自IDなどを細かく制御したい場合は、AKS Automatic ではなく AKS Standard と Helm デプロイを含めて設計を見直すべきです。(Microsoft Learn)
影響範囲：管理者と開発者が見るべきポイント
今回の更新は、単に「新しいロードバランサーが使える」という話ではありません。AKS Automatic の運用、ネットワーク、ID、アプリ配信設計に関わるため、管理者と開発者で確認観点が異なります。
| 対象者 | 確認すべきこと | 理由 |
|---|---|---|
| AKS管理者 | 対応リージョン、ネットワーク方式、プレビュー機能登録、Workload Identity | Add-on を有効化しても、前提条件を満たさないと Application Gateway for Containers のプロビジョニングに失敗する |
| ネットワーク管理者 | Azure CNI／Azure CNI Overlay、サブネット、VNet、NVA、Firewall 経路 | Kubenet や別VNet構成など、サポート外・制約ありの構成がある |
| セキュリティ管理者 | マネージドID、RBAC、WAF、TLS、証明書管理 | Add-on が作成するIDや権限、入口での防御設計を確認する必要がある |
| 開発者 | Ingress、Gateway、HTTPRoute、Service、ヘルスチェック | 既存マニフェストがそのまま使えるか、ルーティングやTLSの挙動が変わらないか検証が必要 |
| SRE／運用担当 | ログ、メトリック、DNS切り替え、ロールバック | 切り替え時の障害検知と戻し手順を事前に作る必要がある |
Application Gateway for Containers の Add-on を有効化するには、対応リージョン、Azure CNI または Azure CNI Overlay、Workload Identity、有効な AKS Kubernetes バージョンなどの要件を満たす必要があります。また、Add-on を有効化できても、Application Gateway for Containers が対応していないリージョンではリソース作成が失敗する可能性があります。(Microsoft Learn)
有効化前に確認すべきチェックリスト
AKS Automatic で Application Gateway for Containers を試す前に、次の項目を確認してください。
| 確認項目 | 判断基準 | 見落とすと起きること |
|---|---|---|
| リージョン | AKS Automatic と Application Gateway for Containers の両方に対応しているか | Add-on は有効化できても、Application Gateway for Containers リソース作成で失敗する |
| ネットワーク方式 | Azure CNI または Azure CNI Overlay か | Kubenet では Application Gateway for Containers を利用できない |
| Workload Identity | OIDC issuer と Workload Identity が有効か | ALB Controller の認証・権限連携で問題が出る |
| Gateway API Add-on | --enable-gateway-api を有効化するか | Application Gateway for Containers Add-on では Gateway API Add-on が必要 |
| プレビュー機能 | 必要な Feature Flag を登録済みか | CLI 実行時やプロビジョニング時に失敗する |
| サブネット | CNI Overlay では Application Gateway for Containers サブネットが /24 か | アップグレード時に停止や再作成が必要になる可能性がある |
| IDとRBAC | Add-on が作成するマネージドIDと権限を許容できるか | セキュリティポリシーや監査で差し戻しになる |
| DNS/TLS | 既存ドメイン、証明書、CNAME、TTL を整理したか | 切り替え時に名前解決や証明書不一致で障害になる |
日本リージョンでの検証を考えている場合は、特にリージョン確認が重要です。AKS Automatic の公開リージョン一覧には Japan East／Japan West が含まれますが、Application Gateway for Containers の対応リージョン一覧は別で、記事執筆時点の Microsoft Learn の一覧では Japan East／Japan West が掲載されていません。リージョン一覧は変わる可能性があるため、検証前に必ず最新の公式ドキュメントで確認してください。(Microsoft Learn)
展開の基本手順
ここでは、AKS Automatic クラスターで Application Gateway for Containers AKS Add-on を検証する流れを、実務向けに整理します。プレビュー機能のため、実行前に Azure CLI と拡張機能、サブスクリプション、対象リージョンの状態を確認してください。
プレビュー機能とプロバイダーを確認する
Application Gateway for Containers Add-on のクイックスタートでは、必要なリソースプロバイダーとプレビュー機能登録が前提として示されています。代表的な Feature Flag は次の2つです。(Microsoft Learn)
az feature register --namespace "Microsoft.ContainerService" --name "ManagedGatewayAPIPreview"
az feature register --namespace "Microsoft.ContainerService" --name "ApplicationLoadBalancerPreview"リソースプロバイダーについても、次の名前空間が登録済みか確認します。
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.Network
az provider register --namespace Microsoft.NetworkFunction
az provider register --namespace Microsoft.ServiceNetworkingFeature Flag の登録はすぐに反映されないことがあります。検証環境を作る前に、az feature show などで登録状態を確認してから進めると、途中で原因不明の失敗に見えるトラブルを避けやすくなります。
AKS Automaticクラスターを用意する
AKS Automatic は、Azure CLI では --sku automatic を指定して作成します。Microsoft Learn のクイックスタートでも、AKS Automatic クラスター作成に az aks create --sku automatic を使う例が示されています。(Microsoft Learn)
az aks create \
--resource-group <resource-group> \
--name <aks-automatic-cluster> \
--sku automatic既存の AKS Automatic クラスターを使う場合は、対象リージョン、ネットワーク、Workload Identity、ポリシー、権限を先に棚卸ししてください。AKS Automatic では node resource group lockdown が事前構成されるため、MC_ リソースグループを手動変更する前提の運用は避けるべきです。(Microsoft Learn)
Gateway APIとApplication Load Balancer Add-onを有効化する
既存クラスターでは、次のように Gateway API と Application Gateway for Containers Add-on を有効化します。公式クイックスタートでも、既存クラスターに対して --enable-gateway-api と --enable-application-load-balancer を指定する手順が示されています。(Microsoft Learn)
az aks update \
--resource-group <resource-group> \
--name <aks-cluster> \
--enable-gateway-api \
--enable-application-load-balancerこの時点で確認したいのは、単にコマンドが成功したかではありません。GatewayClass、ALB Controller、関連CRD、マネージドID、サブネット、ロール割り当てまで確認してください。
kubectl get gatewayclass
kubectl get crd | grep -E "gateway|alb"Add-on 統合では、applicationloadbalancer-<cluster-name> というIDが作成され、MC リソースグループに対して Network Contributor、AppGw for Containers Configuration Manager、Reader などのロールが割り当てられます。また、名前空間やIDを変更することはサポートされていません。(Microsoft Learn)
ネットワーク設計で注意すべき点
Application Gateway for Containers は Azure CNI と Azure CNI Overlay に対応しますが、Kubenet はサポートされません。Kubenet を使っている既存 AKS クラスターでは、先に CNI Overlay などへ移行し、その後で Application Gateway for Containers を導入する流れになります。(Microsoft Learn)
| 注意点 | 内容 |
|---|---|
| Kubenet非対応 | Kubenet クラスターには Application Gateway for Containers を導入できない |
| 同一VNet要件 | Application Gateway for Containers と AKS を別VNetに分ける構成は現在サポートされない |
| CNI Overlayのサブネット | Application Gateway for Containers サブネットは /24 が必要 |
| VNet Peering | Application Gateway for Containers と AKS ノードを VNet Peering 越しに分ける構成はサポートされない |
| NVA／Azure Firewall | CNI Overlay では NVA が Overlay ネットワークへのプロキシトラフィックにアクセスできない |
特に CNI Overlay へアップグレードする場合、Application Gateway for Containers サブネットが /24 でないと停止につながり、サブネット再作成が必要になる可能性があります。ネットワーク変更はメンテナンス時間帯に実施し、DNS切り替えやロールバック手順も事前に用意してください。(Microsoft Learn)
既存環境からの移行で考えるべきこと
Application Gateway for Containers を AKS Automatic で使えるようになったからといって、既存の Ingress 構成をすぐ置き換える必要はありません。まずは現在の入口構成を棚卸しし、どの課題を解決したいのかを明確にするべきです。
| 現在の構成 | 移行判断のポイント |
|---|---|
| Application Gateway Ingress Controller | Application Gateway for Containers は AGIC の発展形だが、制御モデルやAPIが異なるため、単純な置換と考えない |
| Managed NGINX／Application Routing | Gateway API への移行方針と、必要な機能差を確認する |
| OSS NGINX Ingress | 上流プロジェクトのメンテナンス終了やAKSでのサポート方針を踏まえ、長期運用の代替候補を検討する |
| 自前のIngressコントローラー | カスタム設定、Lua、独自アノテーション、外部認証などが Application Gateway for Containers で代替できるか検証する |
| Azure Front Door + AKS | Front Door と Application Gateway for Containers の役割分担を整理し、二重TLSやWAFポリシーを見直す |
AKS では、Ingress NGINX プロジェクトのメンテナンス終了予定に合わせて Gateway API を長期的な標準として位置付ける動きがあります。Microsoft のドキュメントでも、OSS NGINX ユーザーの移行先候補として Application Gateway for Containers が挙げられています。(Microsoft Learn)
移行時は、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 |
|---|---|
| 現状棚卸し | IngressClass、Host、Path、TLS Secret、証明書、WAF、ヘルスチェック、DNS、外部認証を一覧化する |
| 非本番検証 | 1つのアプリだけを対象に、Gateway API または Ingress API で動作確認する |
| 並行稼働 | 既存IngressとApplication Gateway for Containersを別ホスト名で並行稼働させる |
| 負荷・障害試験 | ルーティング、TLS、WebSocket、gRPC、スケール、バックエンド切断時の挙動を確認する |
| DNS切り替え | TTLを短くし、CNAMEやホスト名の切り替え手順を文書化する |
| ロールバック | 旧Ingressへ戻す条件、DNS復旧、証明書、監視アラートを事前に決める |
開発者が見るべきマニフェスト上のポイント
開発者側では、Application Gateway for Containers が使えるかどうかだけでなく、既存の Kubernetes マニフェストがどこまで再利用できるかを確認する必要があります。
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| IngressClass | azure-alb-external など、利用するクラスが想定通りか |
| GatewayClass | Gateway API を使う場合、正しい GatewayClass を参照しているか |
| Host／Path | 既存の Host ベース、Path ベースルーティングを再現できるか |
| TLS | Secret、証明書更新、TLS終端、End-to-End SSL の要件を満たせるか |
| Backend Protocol | HTTP、HTTPS、gRPC、WebSocket などのアプリ要件に合うか |
| Health Probe | アプリのヘルスチェックURL、タイムアウト、失敗時の挙動が適切か |
| Header | x-forwarded-for など、アプリ側で参照しているヘッダーに影響がないか |
Application Gateway for Containers は、Gateway API と Ingress API の両方をサポートします。将来的な設計を見据えるなら、単に既存 Ingress を移すだけでなく、Gateway API の HTTPRoute を使って「プラットフォーム担当が Gateway を管理し、アプリ担当が Route を管理する」ような責任分担も検討できます。(Microsoft Learn)
採用しやすいケースと待ったほうがよいケース
今回の Public Preview は魅力的ですが、すべてのAKS環境にすぐ適用すべきものではありません。次の基準で判断すると現実的です。
| 判断 | 向いているケース |
|---|---|
| 試すべき | AKS Automatic を検証中、または新規サービスで Gateway API ベースの入口設計を検討している |
| 試すべき | Ingressコントローラーの運用負荷を下げ、AzureネイティブなL7ロードバランサーへ寄せたい |
| 試すべき | WAF、TLS、gRPC、WebSocket、トラフィック分割などを AKS の外側で整理したい |
| 慎重に検討 | 本番の高トラフィックサービスで、既存Ingressの独自設定が多い |
| 慎重に検討 | 日本リージョン固定など、対応リージョンに制約がある |
| 慎重に検討 | Kubenet、別VNet、NVA経由など、ネットワーク制約に抵触する可能性がある |
| 待つべき | プレビュー機能を本番に入れられない社内ポリシーがある |
| 待つべき | Helm版ALB Controllerのような細かいカスタマイズが必須で、AKS Automaticを前提にしている |
独自性のある見方をするなら、今回の更新は「AKS Automatic の入口機能が増えた」というより、AKS Automatic を本格的なアプリケーション基盤として評価するための不足ピースが1つ埋まったと捉えるとよいでしょう。ノード、監視、ポリシーだけでなく、外部公開とL7ルーティングまでマネージドな選択肢に寄せられるため、プラットフォームチームが標準構成を作りやすくなります。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 原因 | 回避策 |
|---|---|---|
| Add-on は有効化できたがリソース作成に失敗する | Application Gateway for Containers 非対応リージョンを使っている | AKS Automatic と Application Gateway for Containers の両方のリージョンを確認する |
| HelmでALB Controllerを入れようとする | AKS Automatic では Helm デプロイがサポートされない | AKS Automatic では AKS Add-on を使う |
| 既存のKubenetクラスターで試す | Kubenet がサポート外 | CNI Overlay などへ移行してから導入する |
| DNS切り替え後に証明書エラーが出る | Host名、TLS Secret、CNAME、証明書SANの不一致 | 事前に検証用ホスト名でTLS疎通を確認する |
| Gateway APIのリソースが競合する | 既存のGateway API CRDや別コントローラーがある | GatewayClass と管理対象リソースを整理してから導入する |
| セキュリティレビューで差し戻される | Add-on が作成するIDやロールを事前説明していない | マネージドID、RBAC、MCリソースグループの変更範囲を文書化する |
| 無効化で別機能に影響する | Gateway API Add-onも無効化する可能性がある | 依存しているGateway APIリソースを棚卸ししてから無効化する |
検証後に Add-on を無効化する場合は、公式クイックスタートで示されているように --disable-gateway-api と --disable-application-load-balancer を指定できます。ただし、Gateway API を他の用途でも使っている場合は、無効化前に依存関係を必ず確認してください。(Microsoft Learn)
az aks update \
--resource-group <resource-group> \
--name <aks-cluster> \
--disable-gateway-api \
--disable-application-load-balancerよくある疑問
本番環境で使ってよいですか？
Public Preview のため、まずは非本番環境で検証するのが前提です。Azure Updates の In preview は非本番の利用・テスト向けとして説明されており、AKS のプレビュー機能も SLA や限定保証の対象外となる扱いに注意が必要です。(Microsoft Azure)
AKS Standardでも関係ありますか？
関係あります。Application Gateway for Containers AKS Add-on 自体は、新規または既存の AKS クラスターに対して有効化できます。今回の更新で特に変わったのは、これまで制限があった AKS Automatic でも利用できるようになった点です。(Microsoft Learn)
AKS AutomaticでHelm版ALB Controllerは使えますか？
使えません。Microsoft Learn のFAQでは、AKS Automatic で ALB Controller をプロビジョニングする場合は Application Gateway for Containers ALB Controller AKS Add-on を使い、Helm デプロイはサポートされないと説明されています。(Microsoft Learn)
Gateway APIに移行しないと使えませんか？
必ずしも Gateway API だけではありません。Application Gateway for Containers は Ingress API と Gateway API の両方をサポートします。ただし、AKS全体では Gateway API を長期的なIngress／L7トラフィック管理の標準として見る流れがあるため、新規設計では Gateway API を前提に検証する価値があります。(Microsoft Learn)
まず何から始めるべきですか？
最初にやるべきことは、既存環境への適用ではなく、対応リージョンの非本番 AKS Automatic クラスターで1つのアプリを通す検証です。次に、IngressまたはGateway APIのマニフェスト、TLS、DNS、監視、ロールバックを確認し、既存Ingressコントローラーから移行する価値があるかを判断してください。
まず非本番で「1アプリ・1ルート」を検証する
今回の Application Gateway for Containers managed add-on + AKS Automatic の Public Preview は、AKS Automatic を使うチームにとって重要な更新です。AKS Automatic の簡素化された運用モデルの中で、AzureネイティブなL7ロードバランサー、Gateway API、Ingress API、WAF、TLS、トラフィック制御を検討しやすくなります。
ただし、プレビュー機能であること、対応リージョンがAKS Automaticと完全には一致しないこと、Kubenetや別VNet構成などのネットワーク制約があること、Helm版ALB ControllerがAKS Automaticでサポートされないことは、導入前に必ず確認すべきです。
管理者はリージョン、ネットワーク、ID、RBAC、サブネットを確認し、開発者はIngress／Gateway API、TLS、Host／Pathルーティング、ヘルスチェックを確認してください。最初の一歩としては、本番移行ではなく、非本番で1つのアプリを Application Gateway for Containers 経由で公開し、DNS切り替え前後の挙動まで検証するのが最も安全です。
コメント