Application Gateway for Containers (ALB)

用語について: ALB

本ドキュメントおよび公式ドキュメントで言及される ALB は、Application Gateway for Containers の管理コンポーネントである ALB Controller (Application Load Balancer Controller) やそのカスタムリソースを指します。 Azureのレイヤー4ロードバランサーサービスである Azure Load Balancer とは異なりますのでご注意ください。

Application Gateway for Containersは、Azure Kubernetes Service (AKS) などのKubernetesクラスターで実行されるワークロード向けに設計された、新しいアプリケーション（レイヤー7）ロードバランシングおよび動的トラフィック管理ソリューションです。

これは、従来のApplication Gateway Ingress Controller (AGIC) の進化形であり、Kubernetes Gateway APIをサポートしています。

概要

Application Gateway for Containersは、以下の3つの主要コンポーネントで構成されています。

1. Application Gateway for Containers リソース: Azure上の管理プレーンリソース。
2. フロントエンド: トラフィックを受け付けるエントリポイント。
3. 関連付け (Association): ゲートウェイとバックエンド（VNet/Subnet）の接続定義。

アーキテクチャとしては、AKSクラスターのデータプレーンの外部に位置し、ALBコントローラー（Application Load Balancer Controller）によって管理されます。

Kubernetes Gateway API

Application Gateway for Containersは、Kubernetesの新しい標準であるGateway APIを実装しています。Gateway APIは、Ingress APIの後継として設計され、より表現力豊かで拡張性の高いトラフィックルーティングを提供します。

主要なリソースモデル

Gateway APIは、役割分担（ロール指向）を意識したリソースモデルを採用しています。

• GatewayClass: インフラストラクチャプロバイダーが定義。共通の設定を持つゲートウェイのテンプレート。
• Gateway: クラスターオペレーターが定義。トラフィックを処理するロードバランサーのインスタンス。
• HTTPRoute: アプリケーション開発者が定義。HTTPリクエストをバックエンドサービスにルーティングするルール。

これにより、インフラ管理者とアプリ開発者がそれぞれの責任範囲で設定を管理できるようになります。

主な機能とメリット

Application Gateway for Containersは、以下のような高度な機能を提供します。

• トラフィック分割 / 重み付けラウンドロビン: カナリアリリースやブルー/グリーンデプロイメントに有用。
• 高度なルーティング: ホスト名、パス、ヘッダー、クエリ文字列、メソッド、ポートに基づくルーティング。
• ヘッダーの書き換え: リクエスト/レスポンスヘッダーの変更。
• 相互認証 (mTLS): フロントエンドおよびバックエンドへのmTLSサポート。
• 自動スケーリング: トラフィック量に応じた自動スケール。
• ゾーン冗長性: 可用性ゾーンをサポートし、高い耐障害性を実現。

デプロイ戦略

Application Gateway for Containersには、主に2つのデプロイ戦略があります。

1. ALB コントローラーによる管理

Kubernetesクラスター内にALBコントローラーをデプロイし、Kubernetesのカスタムリソース（Gateway APIまたはIngress API）の変更を検知して、Azureリソース（Application Gateway for Containersなど）のライフサイクルを自動的に管理します。

2. Bring Your Own (BYO) デプロイ

Azureリソース（Application Gateway for Containers、フロントエンド、関連付け）をTerraformやAzure CLIなどで事前にプロビジョニングし、Kubernetes側の設定からそれらを参照する方式です。インフラ管理とアプリデプロイを完全に分離したい場合に適しています。

複数のフロントエンドアプリケーションがある場合のベストプラクティス

AKSクラスターで複数のフロントエンドアプリケーションをホストする場合、1つのApplication Gateway for Containersを共有することが推奨されます。

推奨構成: 単一Gatewayの共有

Application Gateway for Containersは、マルチサイトホスティングをネイティブサポートしており、1つのGatewayリソースで複数のアプリケーションを効率的にホストできます。

メリット:

• コスト削減: 複数のApplication Gateway for Containersインスタンスを作成する必要がなく、Azureリソースのコストを最小化できます。
• 管理の簡素化: インフラストラクチャの管理ポイントが減り、統一的な設定とモニタリングが可能になります。
• リソース効率: Gatewayリソースの自動スケーリング機能を効率的に活用でき、トラフィック量に応じた最適なリソース配分が実現します。
• 高度なルーティング: 単一のエントリポイントで、ホスト名、パス、ヘッダーに基づいた柔軟なルーティングが可能です。

実装パターン

パターン1: ホスト名ベースのルーティング（複数ドメイン）

異なるドメインで複数のフロントエンドアプリケーションを提供する場合、1つのGatewayリソースに複数のHTTPRouteを定義します。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: wildcard-tls-secret
---
# アプリケーション1のルート
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app1-route
  namespace: app1-namespace
spec:
  parentRefs:
  - name: shared-gateway
    namespace: gateway-infra
  hostnames:
  - "app1.contoso.com"
  rules:
  - backendRefs:
    - name: app1-service
      port: 80
---
# アプリケーション2のルート
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app2-route
  namespace: app2-namespace
spec:
  parentRefs:
  - name: shared-gateway
    namespace: gateway-infra
  hostnames:
  - "app2.contoso.com"
  rules:
  - backendRefs:
    - name: app2-service
      port: 80

パターン2: パスベースのルーティング（単一ドメイン）

同一ドメインで複数のアプリケーションを提供する場合、パスプレフィックスでルーティングを分離します。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: multi-app-route
  namespace: gateway-infra
spec:
  parentRefs:
  - name: shared-gateway
  hostnames:
  - "portal.contoso.com"
  rules:
  # /admin/* へのリクエストは管理アプリへ
  - matches:
    - path:
        type: PathPrefix
        value: /admin
    backendRefs:
    - name: admin-app-service
      port: 80
      namespace: admin-namespace
  # /api/* へのリクエストはAPIサービスへ
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80
      namespace: api-namespace
  # その他のリクエストはフロントエンドアプリへ
  - backendRefs:
    - name: frontend-service
      port: 80
      namespace: frontend-namespace

Namespace分離とセキュリティ

Gateway APIは、クロスNamespace参照 (Cross-Namespace Reference) をサポートしています。これにより、以下のような分離構成が可能です。

• Gatewayリソース: インフラチーム管理用のNamespace（例: gateway-infra）に配置
• HTTPRouteリソース: 各アプリケーションチームのNamespace（例: app1-namespace, app2-namespace）に配置

ReferenceGrantによるアクセス制御: クロスNamespace参照を許可する際は、ReferenceGrantリソースで明示的に権限を付与します。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-routes
  namespace: gateway-infra
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: app1-namespace
  to:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: shared-gateway

個別Gatewayを作成すべきケース

以下の場合は、複数のApplication Gateway for Containersインスタンスを作成することを検討してください。

1. 完全な環境分離が必要な場合

   • 本番環境と開発環境を完全に分離したい
   • コンプライアンスやセキュリティ要件で、異なるVNetやサブネットへの完全な分離が必要

2. 異なるSLA要件がある場合

   • 一部のアプリケーションで専用のスケーリング設定や高可用性構成が必要
   • ミッションクリティカルなアプリケーションと開発用アプリケーションを完全に分離したい

3. 独立したコスト管理が必要な場合

   • 各プロジェクトやテナント毎に、Azureリソースのコストを明確に分離して追跡したい

4. 異なる地理的リージョンに配置する場合

   • 異なるAzureリージョンにアプリケーションを配置する必要がある

まとめ

構成	推奨シナリオ	メリット	デメリット
単一Gateway共有	同一クラスター内の複数アプリ、マイクロサービスアーキテクチャ	コスト削減、管理の簡素化、リソース効率	一部のアプリの障害が他に影響する可能性
複数Gateway分離	環境分離（本番/開発）、完全な独立性が必要	完全な分離、独立したSLA、コスト追跡	コスト増加、管理の複雑化

ベストプラクティス: 特別な要件がない限り、1つのApplication Gateway for Containersを共有し、HTTPRouteで論理的にルーティングを分離する構成を採用することが推奨されます。

AGIC (Ingress Controller) との違い

従来のAGICと比較して、Application Gateway for Containersは以下の点で優れています。

• パフォーマンス: 更新の反映がほぼリアルタイムに行われます。
• 機能性: Gateway APIのサポートにより、より複雑なルーティングが可能になりました。
• 分離性: データプレーンがAKSクラスターから分離されているため、クラスターのリソースに影響を与えにくい構造になっています。

Nginx Ingress Controller との比較

重要: Nginx Ingress Controller のリタイアについて

Kubernetesコミュニティは、Ingress NGINX プロジェクトをリタイアすることを発表しました。 2026年3月をもってメンテナンスが終了し、以降はセキュリティ更新も提供されません。 そのため、新規プロジェクトでの採用は推奨されません。Gateway APIへの移行が強く推奨されています。 詳細: Ingress NGINX Retirement: What You Need to Know

OSSのNginx Ingress Controllerと比較した場合の主な違いは以下の通りです。

特徴	Application Gateway for Containers (ALB)	Nginx Ingress Controller (非推奨)
タイプ	Azureマネージドサービス (PaaS)	クラスター内ソフトウェア (In-cluster)
データプレーン	AKSクラスターの外部で動作	AKSクラスターの内部 (Pod) で動作
リソース消費	Azure側のリソースを使用 (クラスター負荷なし)	クラスターのCPU/メモリを消費
スケーリング	トラフィックに応じてAzureが自動スケール	HPA (Horizontal Pod Autoscaler) の設定が必要
機能拡張	Gateway API標準、Azure機能との統合	豊富なコミュニティプラグイン、Luaスクリプト
コスト	ALBの利用料金が発生	コンピュートリソース (VM) の料金に含まれる

ALBを選択すべきシナリオ:

• クラスターのリソースをアプリケーション処理に集中させたい場合（SSL終端などの負荷をオフロード）。
• AzureのマネージドサービスとしてのSLAやサポートが必要な場合。
• Gateway APIの高度なルーティング機能をネイティブに利用したい場合。
• 将来的なサポートとセキュリティを確保したい場合（Nginx Ingress Controllerのリタイアに伴い、ALBなどの代替手段が必須となります）。

Nginxを選択すべきシナリオ:

• （非推奨） 既存の資産があり、移行までの期間のみ維持が必要な場合。
• 特定のNginxモジュールや高度なカスタマイズが必要な場合（ただし、セキュリティリスクを許容できる場合に限る）。

マニフェストの比較

Nginx Ingress ControllerではIngressリソースを使用しますが、Application Gateway for Containers (Gateway API) ではGatewayとHTTPRouteリソースを使用します。

Nginx Ingress Controller (Ingress API):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - example.com
    secretName: my-tls-secret
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Application Gateway for Containers (Gateway API):

Gateway APIでは、ゲートウェイ定義とルーティング定義が分離されています。

# Gateway: ロードバランサーの定義
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: alb-gateway
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: my-tls-secret
---
# HTTPRoute: ルーティングルールの定義
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: alb-route
spec:
  parentRefs:
  - name: alb-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-service
      port: 80

TLS証明書の取り扱い

機能	Application Gateway for Containers (ALB)	Nginx Ingress Controller
保存場所	Kubernetes Secret または Azure Key Vault	Kubernetes Secret
管理方法	Azure Key Vault連携による一元管理が可能	cert-manager等によるクラスター内管理が一般的
設定箇所	Gateway リソースの listeners	Ingress リソースの tls
自動更新	対応 (Key Vault + CSI Driver連携)	対応 (cert-manager連携)

Nginx Ingress Controller: Kubernetes Secret (kubernetes.io/tls) を作成し、Ingressリソースで参照します。cert-managerと連携してLet's Encrypt証明書を自動発行する構成が一般的です。

Application Gateway for Containers: Kubernetes Secretを参照することも可能ですが、Azure Key Vault に保存された証明書を直接参照することが推奨されます。これにより、証明書のライフサイクル管理をAzure基盤側にオフロードし、セキュリティを向上させることができます。

Azure App Service Certificate の自動更新について: Azure App Service Certificate で購入・管理している証明書は、Azure Key Vault に格納されます。 Application Gateway for Containers でこれを利用する場合、Azure Key Vault Provider for Secrets Store CSI Driver を使用して Kubernetes Secret に同期することで、証明書の自動更新に対応できます。 CSI Driver の rotationPollInterval を設定することで、Key Vault 側で更新された証明書が自動的にクラスター内の Secret に反映され、ALB コントローラーがそれを検知してロードバランサーの設定を更新します。

参考リンク

• Application Gateway for Containers の概要 - Azure
• Gateway API - Kubernetes
• Application Gateway for Containers での SSL オフロード