この記事では、Application Gateway for Containers のコンポーネントに関する詳細と要件について説明します。 Application Gateway for Containers が受信要求を受け入れ、バックエンド ターゲットにルーティングする方法について説明します。 Application Gateway for Containers の概要全般については、「Application Gateway for Containers とは」を参照してください。
コア コンポーネント
- Application Gateway for Containers のリソースは、コントロール プレーンをデプロイする Azure の親リソースです。
- コントロール プレーンは、顧客の意図に基づいてプロキシ構成を調整します。
- Application Gateway for Containers には、関連付けとフロントエンドという 2 つの子リソースがあります。
- 子リソースは、コンテナーの親 Application Gateway にのみ属し、他の Application Gateway for Containers リソースと共有することはできません。
Application Gateway for Containers のフロントエンド
- Application Gateway for Containers のフロントエンド リソースは、Application Gateway for Containers 親リソースにとっての Azure 子リソースになります。
- Application Gateway for Containers フロントエンドは、特定の Application Gateway for Containers に対してクライアント トラフィックが使用するエントリ ポイントを定義します。
- フロントエンドを複数の Application Gateway for Containers に関連付けることはできません。
- 各フロントエンドが提供する一意の FQDN を使用して、CNAME レコードを作成できます。
- プライベート IP アドレスは現在サポートされていません。
- 1 つの Application Gateway for Containers で複数のフロントエンドをサポートできます。
Application Gateway for Containers の関連付け
- Application Gateway for Containers の関連付けリソースは、Application Gateway for Containers の親リソースにとっての Azure 子リソースになります。
- Application Gateway for Containers の関連付けでは、仮想ネットワークへの接続ポイントを定義します。 関連付けは、委任された Azure サブネットへの関連付けリソースの 1 対 1 のマッピングです。
- Application Gateway for Containers は、複数の関連付けを可能にするように設計されています。
- 現時点では、現在の関連付けの数は 1 に制限されています。
- 関連付けの作成時に、基になるデータ プレーンがプロビジョニングされ、定義された仮想ネットワークのサブネット内のサブネットに接続されます。
- 各関連付けで、プロビジョニング時にサブネットで少なくとも 256 個のアドレスが使用されることを想定しておく必要があります。
- デプロイごとに、最小 /24 サブネット マスクが必要です（サブネットにリソースが事前にプロビジョニングされていない場合）。
- 同じサブネットを共有する複数の Application Gateway for Containers リソースをデプロイする場合は、必要なアドレスを n×256 として計算します。 ここで、n は Application Gateway for Containers リソースの数と等しくなります。 これは、それぞれが 1 つの関連付けが含まれていることを前提としています。
- すべての Application Gateway for Containers の関連付けリソースは、Application Gateway for Containers 親リソースと同じリージョンである必要があります。
- デプロイごとに、最小 /24 サブネット マスクが必要です（サブネットにリソースが事前にプロビジョニングされていない場合）。
関連付けサブネット上のネットワーク セキュリティ グループ
2026 年 4 月 23 日以降に作成された関連付けの場合、Application Gateway for Containers の関連付けサブネットでは、受信規則と送信規則の両方を含むネットワーク セキュリティ グループ (NSG) が完全にサポートされます。
"すべて拒否" ルールはサポートされていますが、明示的な許可例外がない場合は、次の方法でトラフィックに影響を与える可能性があります。
- 許可規則が追加されていない限り、すべての受信規則を拒否すると、ポート 80 と 443 のトラフィックがブロックされ、フロントエンドへのアクセスが妨げられます。
- すべての受信 規則を拒否すると、NSG に対して既定で作成される AzureLoadBalancer サービス タグがブロックされます。 ゲートウェイの円滑な運用を確保するには、 AzureLoadBalancer タグが許可されていることを確認する必要があります。
- すべての送信を拒否する 規則は、ヘルス プローブを含め、Application Gateway for Containers から AKS クラスターへのトラフィックをブロックします。 ポッドの IP 範囲への送信アクセスを許可してください。
注
関連付けサブネットの NSG 規則に加えて、AKS サブネットに適用された NSG に対するすべての送信 規則を拒否すると、Application Gateway for Containers ALB コントローラーからのトラフィックをブロックできます。 ALB コントローラーが負荷分散の意図を適切に調整できるようにするには、 これらのエンドポイントへの送信トラフィックが許可されていることを確認します。
2026 年 4 月 23 日より前に作成された関連付けの場合は、受信 NSG 規則を構成できます。ただし、定義されている規則に関係なく、ポート 80 と 443 のトラフィックは常に許可されます。
関連付けサブネット上のユーザー定義ルート
Application Gateway for Containers のルート テーブル ルールとの関連付けサブネットをきめ細かく制御できます。 これは、Aplication Gateway for Containers と AKS クラスターの間で仮想ネットワーク アプライアンスを使用する場合に便利です。
Warning
ルート テーブルの構成が正しくないと、Application Gateway for Containers で非対称ルーティングが発生する可能性があります。 仮想アプライアンス経由ではなく、インターネットイングレスがインターネットに返されることを確認します。
ここでは、フロントエンドに接続するパブリック (インターネット) で受信したトラフィックがインターネットに返されるようにするためにサポートされるシナリオをいくつか示します。
シナリオ 1: UDR で Application Gateway サブネットへの Border Gateway Protocol (BGP) ルート伝達を無効にする
既定のゲートウェイ ルート (0.0.0.0/0) が、Application Gateway for Containers 仮想ネットワークに関連付けられている ExpressRoute または VPN ゲートウェイを介してアドバタイズされる場合があります。 この動作により、クライアントがインターネットに戻るトラフィックが中断されます。 このようなシナリオでは、UDR を使用して BGP ルートの伝達を無効にすることができます。
BGP ルートの伝達を無効にするには以下の手順を行います。
- Azure でルート テーブル リソースを作成します。
- 仮想ネットワーク ゲートウェイのルート伝達パラメーターを無効にします。
- ルート テーブルを適切なサブネットに関連付けます。
このシナリオで UDR を有効にすると、既存のセットアップが中断されないはずです。
シナリオ 2: UDR で 0.0.0.0/0 をインターネットに送信する
0.0.0.0/0 トラフィックをインターネットに直接送信する UDR を作成できます。
Application Gateway for Containers の ALB コントローラー
- Application Gateway for Containers の ALB コントローラーは、カスタム リソースとリソース構成 (イングレス、ゲートウェイ、ApplicationLoadBalancer など) の両方を監視することで Application Gateway for Containers の構成とデプロイを調整する Kubernetes のデプロイです。 ARM と Application Gateway for Containers の両方の構成 API を使用して、Application Gateway for Containers Azure デプロイに構成を伝達します。
- Helm を使用して ALB コントローラーをデプロイまたはインストールします。
- ALB コントローラーは、2 つの実行中のポッドで構成されます。
- alb-controller ポッドは、Application Gateway for Containers の負荷分散構成に対する顧客の意図を調整します。
- alb-controller-bootstrap ポッドは CRD を管理します。
Application Gateway for Containers のセキュリティ ポリシー
- Application Gateway for Containers セキュリティ ポリシーでは、ALB コントローラーが使用する WAF などのセキュリティ構成を定義します。
- 1 つの Application Gateway for Containers リソースで、複数のセキュリティ ポリシーを参照できます。
- 現時点では、提供されるセキュリティ ポリシーの種類は、Web アプリケーション ファイアウォール機能の
wafのみです。 -
wafセキュリティ ポリシーは、セキュリティ ポリシー リソースと Web アプリケーション ファイアウォール ポリシーの間の 1 対 1 のマッピングです。- 定義された Application Gateway for Containers リソースの任意の数のセキュリティ ポリシーで参照できる Web アプリケーション ファイアウォール ポリシーは 1 つだけです。
Application Gateway for Containers AKS マネージド アドオン
Application Gateway for Containers 用 AKS アドオンは、AKS による ALB コントローラー用のマネージド デプロイ エクスペリエンスを提供するため、Helm チャートを手動でデプロイする必要がなくなります。
Helm ベースのデプロイでマネージド アドオンを使用する利点の一部は次のとおりです。
- マネージド更新プログラム: Helm チャートを手動で更新する必要はありません。更新プログラムは AKS によって管理されます。
-
自動化された ID 管理: アドオンは、必要なアクセス許可を持つマネージド ID (
applicationloadbalancer-<cluster-name>) を自動的に作成して構成します。 -
簡略化されたサブネット構成: 専用サブネット (
aks-appgateway) は、正しい委任を使用して自動的にプロビジョニングされます。 - 構成の複雑さの軽減: フェデレーション資格情報またはロールの割り当てを手動で設定する必要はありません。
- AKS 自動サポート: AKS 自動クラスターを使用する場合は、アドオンのデプロイが必要です。
Azure/一般的な概念
プライベート IP アドレス
- プライベート IP アドレスは、Azure Resource Manager リソースとして明示的に定義されません。 プライベート IP アドレスとは、特定の仮想ネットワークのサブネット内の特定のホスト アドレスを指します。
サブネットの委任
- Microsoft.ServiceNetworking/trafficControllers は Application Gateway for Containers で採用されている名前空間であり、仮想ネットワークのサブネットに委任できます。
- 委任する場合、Application Gateway for Containers リソースはプロビジョニングされません。また、Application Gateway for Containers の関連付けリソースへの排他的なマッピングもありません。
- 任意の数のサブネットに、Application Gateway for Containers と同じまたは異なるサブネット委任を含めることができます。 定義した後は、サービスの実装によって明示的に定義されていない限り、他のリソースをサブネットにプロビジョニングすることはできません。
ユーザー割り当てマネージド ID
- Azure リソース用マネージド ID を使用すると、コードで資格情報を管理する必要がなくなります。
- Application Gateway for Containers を変更するには、Azure Load Balancer コントローラーごとにユーザー割り当てマネージド ID が必要です。
- AppGw for Containers Configuration Manager は、ALB コントローラーが Application Gateway for Containers リソースにアクセスして構成できるようにする組み込みの RBAC ロールです。
注
AppGw for Containers Configuration Manager ロールには、所有者ロールと共同作成者ロールにはないデータ アクションのアクセス許可があります。 ALB コントローラーが Application Gateway for Containers サービスに変更を加える問題を防ぐために、適切なアクセス許可を委任することが重要です。
Application Gateway for Containers で要求を受け入れる方法
各 Application Gateway for Containers フロントエンドは、Azure によって管理される、生成された完全修飾ドメイン名を提供します。 FQDN as-is を使用することも、CNAME レコードでマスクすることもできます。
クライアントが Application Gateway for Containers に要求を送信する前に、クライアントはフロントエンドの FQDN を指す CNAME を解決するか、クライアントは DNS サーバーを使用して Application Gateway for Containers によって提供される FQDN を直接解決します。
DNS リゾルバーは、DNS レコードを IP アドレスに変換します。
クライアントが要求を開始すると、指定された DNS 名がホスト ヘッダーとして、定義されたフロントエンド上の Application Gateway for Containers に渡されます。
ルーティング規則のセットは、定義されたバックエンド ターゲットに対してそのホスト名の要求を開始する方法を評価します。
Application Gateway for Containers で要求をルーティングする方法
HTTP/2 要求
Application Gateway for Containers では、クライアントとフロントエンド間の通信に HTTP/2 プロトコルと HTTP/1.1 プロトコルの両方がサポートされています。 HTTP/2 設定は常に有効になっており、変更することはできません。 クライアントが Application Gateway for Containers のフロントエンドとの通信に HTTP/1.1 を使用する場合は、それに応じて引き続きネゴシエートできます。
Application Gateway for Containers とバックエンド ターゲット間の通信は、HTTP/2 を使用する gRPC を除き、常に HTTP/1.1 経由で行われます。
要求への変更
Application Gateway for Containers では、バックエンド ターゲットへの要求を開始する前に、すべての要求に 3 つの追加ヘッダーが挿入されます。
- x-forwarded-for
- x-forwarded-proto
- x-request-id
x-forwarded-for は、元のリクエスターのクライアント IP アドレスです。 要求がプロキシを経由する場合、ヘッダー値は受信したアドレスをコンマ区切りで追加します。 例: 1.2.3.4,5.6.7.8;ここで、1.2.3.4 は Application Gateway for Containers の前にあるプロキシへのクライアント IP アドレス、5.6.7.8 は Application Gateway for Containers へのトラフィックを転送するプロキシのアドレスです。
x-forwarded-proto は、Application Gateway for Containers がクライアントから受信するプロトコルを返します。 値は HTTP または HTTPS のいずれかです。
x-request-id は、Application Gateway for Containers がクライアント要求ごとに生成し、転送された要求でバックエンド ターゲットに提示する一意の GUID です。 GUID は、ダッシュで区切られた 32 文字の英数字で構成されます (例: aaaa0000-bb11-2222-33cc-444444dddddd)。 この guid を使用して、Application Gateway for Containers が受信し、アクセス ログで定義されているバックエンド ターゲットに対して開始する要求を関連付けることができます。
要求のタイムアウト
Application Gateway for Containers は、クライアント、Application Gateway for Containers、バックエンドの間で要求を開始および維持する際に、次のタイムアウトを適用します。
| タイムアウト | 期間 | 説明 |
|---|---|---|
| 要求タイムアウト | 60 秒 | Application Gateway for Containers がバックエンド ターゲットの応答を待機する時間。 |
| HTTP アイドル タイムアウト | 5 分 | HTTP 接続を閉じる前のアイドル タイムアウト。 |
| ストリーム アイドル タイムアウト | 5 分 | HTTP 接続によって伝達される個々のストリームを閉じる前のアイドル タイムアウト。 |
| アップストリーム接続タイムアウト | 5 秒 | バックエンド ターゲットへの接続を確立する時間。 |
注
要求タイムアウトでは、データがアクティブにストリーミングされているか、要求がアイドル状態であるかに関係なく、定義された時間内に要求が完了するように厳密に強制されます。 たとえば、大きなファイルのダウンロードを提供していて、サイズや転送速度が遅いために転送に60秒を超える時間がかかると予想される場合は、リクエストのタイムアウト値を増やすか、0に設定することを検討してください。
要求タイムアウトが複数の場所で構成されている場合、Application Gateway for Containers は次の優先順位を適用します。
-
timeouts.requestで定義されているゲートウェイ API の HTTPRoute タイムアウト (timeouts.backendRequestとHTTPRouteRule) をお勧めします。 -
RoutePolicyタイムアウト (routeTimeout) は、ゲートウェイ API HTTPRoute タイムアウトが定義されていない場合に使用されます。 - 既定のタイムアウト値は、ゲートウェイ API の HTTPRoute タイムアウトも
RoutePolicyタイムアウトも定義されていない場合に使用されます。
Connectivity
Application Gateway for Containers を正常に操作するには、次の接続要件が必要です。
ALB コントローラーの送信接続
| エンドポイント | 港 / ポート | Purpose |
|---|---|---|
| management.azure.com | TCP 443 | Azure の ARM API |
| login.microsoftonline.com | TCP 443 | Entra AD 認証 |
| *.oic.prod-aks.azure.com | TCP 443 | AKS OIDC 発行者 (ワークロードアイデンティティ) |
| *.alb.azure.com | TCP 443 | 構成エンドポイント |
| mcr.microsoft.com | TCP 443 | Helm デプロイ用のコンテナー イメージ |
| DNS の解決 | UDP 53 | 既定の AKS デプロイでは、ALB コントローラーはクラスター内の coreDNS/kube-dns に対してクエリを実行します |
ALB コントローラーの内部からの接続
注
これらの受信ポートは ClusterIP Service 経由で公開され、インターネットに直接公開されません。 これらはトラブルシューティング/診断に役立つよう公開されており、必要に応じてネットワーク ポリシーでブロックされる可能性があります。
| 港 / ポート | 名前 | Purpose |
|---|---|---|
| TCP 8000 | バックエンドの状態 | バックエンド正常性エンドポイント (/backendHealth) |
| TCP 8001 | メトリクス | Prometheus メトリクス エンドポイント (/metrics) |
フロントエンド接続
Application Gateway for Containers の各フロントエンドは、 *.fzXX.alb.azure.com形式です。XX は数字 0 から 99 です。 フロントエンドは、ポート 443 と 80 でのみリッスンできます。