次の方法で共有

Application Gateway for Containers のコンポーネント

  • [アーティクル]

この記事では、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 for Containers の専用であり、その他の 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 に関連付けることはできません。
    • 各フロントエンドは、顧客の CNAME レコードによって参照できる一意の FQDN を提供します。
    • プライベート 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 個プロビジョニングされ、各 Application Gateway for Containers に 1 つの関連付けが含まれていて、同じサブネットを共有することを意図している場合、使用可能な必須アドレスは n * 256 です。
    • すべての Application Gateway for Containers の関連付けリソースは、Application Gateway for Containers 親リソースと同じリージョンである必要があります。

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 デプロイに構成を伝達します。
  • ALB コントローラーが Helm 経由でデプロイまたはインストールされます。
  • ALB コントローラーは、2 つの実行中のポッドで構成されます。
    • alb-controller ポッドは、Application Gateway for Containers の負荷分散構成に対する顧客の意図を調整する役割を担います。
    • alb-controller-bootstrap ポッドは CRD の管理を担当します。

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 ロールです。

Note

AppGw for Containers Configuration Manager ロールには、所有者ロールと共同作成者ロールにはないデータ アクションのアクセス許可があります。 ALB コントローラーが Application Gateway for Containers サービスに変更を加える問題を防ぐために、適切なアクセス許可を委任することが重要です。

Application Gateway for Containers で要求を受け入れる方法

各 Application Gateway for Containers フロントエンドは、Azure によって管理される生成済み完全修飾ドメイン名を提供します。 FQDN をそのまま使用することも、CNAME レコードで FQDN をマスクすることもできます。

クライアントが 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 プロトコルが完全にサポートされています。 Application Gateway for Containers からバックエンド ターゲットへの通信には、HTTP/1.1 プロトコルが使用されます。 HTTP/2 設定は常に有効になっており、変更することはできません。 クライアントが Application Gateway for Containers のフロントエンドとの通信に HTTP/1.1 を使用することを希望する場合は、それに応じてネゴシエートを継続できます。

要求への変更

Application Gateway for Containers は、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 は、アプリケーション ゲートウェイによってクライアント要求ごとに生成され、バックエンド ターゲットに転送される要求で示される一意の GUID です。 GUID は、ダッシュで区切られた 32 文字の英数字で構成されます (例: aaaa0000-bb11-2222-33cc-444444dddddd)。 この GUID を使用して、Application Gateway for Containers によって受信され、バックエンド プール メンバーに対して開始された要求を、アクセス ログの定義に従って関連付けることができます。

要求のタイムアウト

要求が開始され、クライアント、Application Gateway for Containers、バックエンドの間で維持されている間は、Application Gateway for Containers により次のタイムアウトが適用されます。

タイムアウト Duration 説明
Request Timeout 60 秒 Application Gateway for Containers がバックエンド ターゲットの応答を待機する時間。
HTTP アイドル タイムアウト 5 分 HTTP 接続を閉じるまでのアイドル タイムアウト。
ストリーム アイドル タイムアウト 5 分 HTTP 接続によって実行されている、個々のストリームを閉じるまでのアイドル タイムアウト。
アップストリーム接続タイムアウト 5 秒 バックエンド ターゲットに対し接続を確立するための時間。