Amazon Web Services ブログ

AWS Load Balancer Controller が Kubernetes Gateway API サポートの一般提供を開始

本記事は 2026 年 3 月 6 日に公開された “AWS Load Balancer Controller adds general availability support for Kubernetes Gateway API” を翻訳したものです。

AWS は最近、Amazon Web Services (AWS) Load Balancer Controller による Kubernetes Gateway API サポートの一般提供を発表しました。これまで、AWS Load Balancer Controller は Kubernetes Ingress と Service リソースの要件を満たすため、それぞれ Application Load Balancer (ALB) と Network Load Balancer (NLB) をプロビジョニングしていました。この新機能により、標準の Kubernetes Gateway API を使用してAWSロードバランシング機能を定義できるようになりました。この投稿では、AWS Load Balancer Controller の Kubernetes Gateway API サポートをご紹介します。Gateway API 統合の構成ベストプラクティス、機能、ユースケースを共有し、AWS 上での Kubernetes デプロイメントのモダナイゼーションと合理化を支援します。

前提条件

Kubernetes API、コントローラー、Deployments、Services、カスタムリソースなどのリソースタイプを含む Kubernetes の概念に精通していることを前提としています。また、Amazon Elastic Kubernetes Service (Amazon EKS) と AWS ロードバランシングサービスについての基本的な理解も必要です。これらの概念を復習する必要がある場合は、Kubernetes ドキュメントと Amazon EKS ユーザーガイドから始めることをお勧めします。

Gateway API 概要

Gateway API は、Kubernetes クラスターで L4 (TCP/UDP) および L7 (HTTP/gRPC) トラフィックルーティングを管理するための次世代フレームワークです。従来の Ingress API よりも柔軟で表現力豊かなロール指向のアプローチを提供し、Ingress における以前の制限に対処しています。流入トラフィック (north-south トラフィック) やサービス間接続 (east-west トラフィック) を含む、幅広いトラフィック管理ニーズに対応する標準化された、ポータブルで拡張可能な仕様を提供します。

Ingress API は長年にわたって Kubernetes ユーザーによく貢献してきましたが、Gateway API が対処するいくつかの制限があります。Ingress は高度な機能に対してベンダー固有のアノテーションに依存しており、異なる実装間での構成の移植性を低下させています。さらに、ロールベースのリソース管理のネイティブサポートが不足しており、これはクラスター運用者とアプリケーション開発者が同じ構成面を共有することを意味します。Gateway API は、インフラストラクチャプロバイダー (GatewayClass)、クラスター運用者 (Gateway)、アプリケーション開発者 (Routes) に対して異なるリソースを持つロール指向設計を導入しています。この分離により、より良い組織ポリシーとセキュリティ境界が可能になります。さらに、Gateway API は、クロス名前空間ルーティング、重み付きトラフィック分割、ヘッダーベースルーティング、L4 と L7 の両方のプロトコルに対するネイティブサポートを提供します。これらの機能は以前は複雑な回避策が必要であったか、Ingress だけでは不可能でした。これらの改善により、Gateway API はより表現力豊かで拡張可能であり、現代のクラウドアーキテクチャに適したものになります。

AWS のフルマネージドアプリケーションネットワーキングサービスである Amazon VPC Lattice は、Amazon VPC Lattice Gateway API Controller を通じて Kubernetes Gateway API のサポートを既に提供しています。これは、VPC とアカウント内の EKS クラスター間でサービス間接続を可能にする別のコントローラーです。AWS Load Balancer コントローラーも Gateway API 仕様をサポートすることで、ALB と NLB による流入 (north-south）トラフィック管理と、east-west サービスメッシュ機能に VPC Lattice を使用する柔軟性の両方について包括的なカバレッジを得ることができます。そして、これらはすべて同じ標準化された Gateway API リソースを使用して実現されます。

Gateway API コンポーネント

Gateway API は、Kubernetes クラスターへのトラフィックの流入と通過の方法を定義するために連携する 3 つのコアリソースを導入します。これらのコンポーネントとそれらが AWS インフラストラクチャにどのようにマッピングされるかを理解することで効果的なトラフィック管理戦略を設計できます。図 1 は Gateway API 仕様のコンポーネントを示しています:

Gateway API コントローラーコンポーネント

図 1 : Gateway API コントローラーコンポーネント [出典]

GatewayClass

GatewayClass は、共通の構成と動作を持つ Gateway を作成するためのテンプレートを定義します。プラットフォームチームは GatewayClass を使用して組織ポリシーとインフラストラクチャテンプレートを確立します。例えば、GatewayClass はどのコントローラーが Gateway を管理するか (AWS Load Balancer Controller など) と、どのタイプのロードバランサーをプロビジョニングするか (ALB または NLB) を指定します。

以下は、ALB をプロビジョニングする GatewayClass の例です:

apiVersion: gateway.networking.k8s.io/v1 
kind: GatewayClass 
metadata: 
  name: aws-alb 
spec: 
    controllerName: gateway.k8s.aws/alb

Gateway

Gateway はロードバランサーをインスタンス化し、トラフィックがクラスターにどのように入るかを定義します。クラスター運用者は、リスナー (プロトコルとポートの組み合わせ)、ホスト名、TLS 設定を指定するように Gateway を構成します。Gateway を作成すると、AWS Load Balancer Controller は指定されたリスナーで対応する AWS ロードバランサーをプロビジョニングします。

以下は、HTTP と HTTPS リスナーを持つ ALB を作成する Gateway の例です:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: aws-alb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  - name: https
    protocol: HTTPS
    port: 443
    hostname: example.com

Routes

Routes は、リスナーをバックエンド Kubernetes サービスにマッピングするルーティングルールを定義します。アプリケーション開発者は、パス、ヘッダー、ホスト名などのリクエスト属性に基づいてトラフィックがサービスにどのように分散されるかを制御するために Routes (HTTPRoute、GRPCRoute、TCPRoute、UDPRoute、TLSRoute) を作成します。

以下は、Gateway の HTTP リスナーから Kubernetes サービスにトラフィックをルーティングする HTTPRoute の例です:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
    sectionName: http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    backendRefs:
    - name: my-service
      port: 8080

AWS Load Balancer Controller は Kubernetes Gateway API オブジェクトの調整をサポートしています。以下を満たします:

  • TCPRoute や UDPRoute などの L4 ルートを AWS NLB で
  • HTTPRoute や GRPCRoute などの L7 ルートを AWS ALB で

動作の仕組み

AWS Load Balancer Controller が Gateway API リソースを AWS インフラストラクチャにどのように変換するかを理解することで、より信頼性の高いアプリケーションを設計し、問題をより迅速にトラブルシューティングできます。コントローラーの調整モデルにより、Kubernetes の定義が AWS ロードバランサーと同期された状態を保ち、継続的な検証とリアルタイムステータスフィードバックを提供します。
高レベルでは、以下のステップが調整ループの動作を示しています:

  • API 監視: Gateway API リソースの作成、変更、削除について、Kubernetes API が継続的に監視されます。
  • キューイング: コントローラーは特定されたリソースを処理のための内部キューに追加します。
  • 処理: 内部キューの各アイテムに対して:
    • コントローラーは関連する GatewayClass をチェックして、ユーザーが AWS ロードバランサーを要求しているかどうかを確認します。
    • yes の場合、対応する Gateway リソースの Gateway API 定義が、NLB/ALB、リスナー、リスナールール、ターゲットグループ、またはアドオンなどの AWS リソースにマッピングされます。
    • これらのマッピングされたリソースは、AWS の実際の状態と比較されます。差分があると、コントローラーは AWS の状態を Gateway オブジェクトによって設定された望ましい状態と一致させます。
  • ステータス更新: 調整後、AWS Load Balancer Controller は対応する Gateway および Route リソースのステータスフィールドを更新します。これにより、ALB の DNS 名や Amazon Resource Name (ARN) などのプロビジョニングされた AWS リソース、およびデバッグを支援するエラー詳細について、リアルタイムフィードバックが提供されます。例えば、HTTPRoute を作成すると、ステータスフィールドにはルートが受け入れられたかどうか、それが接続されている Gateway、およびプロビジョニング時にトラフィックルーティングに使用する ALB の DNS 名がすぐに表示されます。無効な証明書 ARN などの構成エラーがある場合、ステータスフィールドは実用的なエラーメッセージを提供します。

図 2 は、この調整フローを詳細に示しています。コントローラーは Gateway API リソースに対するウォッチを確立し、内部キューを通じて変更を処理し、望ましい状態の中間表現を構築し、対応する AWS リソースを実現します。このプロセス全体を通じて、プロビジョニングの進行状況と発生したエラーを反映するためにステータス条件が更新されます。

Gateway API コントローラー調整フロー

図 2 : Gateway API コントローラー調整フロー

この宣言的アプローチは、望ましいロードバランシング構成を一度定義すると、コントローラーが AWS がその意図と一致することを継続的に保証することを意味します。これにより、ドリフトと構成変更が自動的に処理されます。

主要機能

このセクションでは、Load Balancer Controller Gateway API サポートの主要機能について説明します:

強化されたカスタマイズ

AWS Load Balancer Controller は、適切に定義された Kubernetes Custom Resource Definitions (CRD) を採用し、アノテーションベースの構成を廃止します。この変更により、検証や IDE サポートが不足しているアノテーション文字列に複雑なデータ構造を埋め込むという制限に対処します。例えば:

Before (アノテーションベースアプローチ):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    alb.ingress.kubernetes.io/target-group-attributes: |
      deregistration_delay.timeout_seconds=30,
      stickiness.enabled=true,
      stickiness.type=lb_cookie

After (CRDベースアプローチ):

apiVersion: gateway.k8s.aws/v1beta1
kind: TargetGroupConfiguration
metadata:
  name: my-app-tg-config
  namespace: my-app
spec:
  targetReference:
    name: my-service
  defaultConfiguration:
    targetGroupAttributes:
      - key: deregistration_delay.timeout_seconds
        value: "30"
      - key: stickiness.enabled
        value: "true"
      - key: stickiness.type
        value: lb_cookie
    healthCheckConfig:
      healthyThresholdCount: 5
      healthCheckInterval: 30
      healthCheckPath: /health
      healthCheckPort: "8080"
      healthCheckProtocol: HTTP
      healthCheckTimeout: 5
      unhealthyThresholdCount: 2

AWS Load Balancer Controller は Gateway API カスタマイズのために 3 つの CRD を導入しています：

  • TargetGroupConfiguration: サービスレベルでヘルスチェック、登録解除遅延、スティッキネス設定を含むターゲットグループプロパティを構成
  • LoadBalancerConfiguration: Gateway または GatewayClass レベルでサブネット配置、セキュリティグループ、アクセスログなどのリスナーおよびロードバランサープロパティを定義
  • ListenerRuleConfiguration: Amazon Cognito または OIDC プロバイダーを通じた認証を含む AWS 固有のルーティング動作で HTTPRoute および GRPCRoute リソースを拡張

これらの CRD は、スキーマ検証、タイプセーフティ、GitOps ワークフローとのネイティブ統合を提供します。構成エラーは実行時ではなく適用時に表面化し、運用オーバーヘッドを削減し、インフラストラクチャの信頼性を向上させます。

Cross-Namespace トラフィックルーティング

Gateway API は、Cross-Namespace ルーティングを通じてインフラストラクチャ運用者とアプリケーション開発者の間の関心の分離を可能にします。プラットフォームチームは共有 Gateway リソースをプロビジョニングし、アプリケーションチームはクラスターレベルの権限を必要とせずに独自の Rout を管理します。

このモデルでは、プラットフォームチームがアクセス制御された専用の名前空間に Gateway をデプロイします。別々の名前空間のアプリケーションチームは、共有 Gateway を参照する Route リソースを作成します。コントローラーは、これらの分散された定義に基づいてトラフィックをルーティングするようにロードバランサーを自動的に構成します。

このアーキテクチャは、Kubernetes API レベルで RBAC 境界を強制します。アプリケーションチームは、サブネット配置やセキュリティグループ割り当てなどのインフラストラクチャレベルの構成にアクセスすることなく、サービスのルーティングロジックを管理します。

自動 TLS 証明書検出

AWS Load Balancer Controller は、L4 と L7 の両方のプロトコルについて、Ingress API から Gateway API リスナーへの証明書検出を拡張します。Gateway リスナーまたは Route ホスト名でホスト名が指定されると、コントローラーは AWS Certificate Manager (ACM) にクエリを実行して、ホスト名マッチングに基づいて一致する証明書を見つけて添付します。

コントローラーは証明書の更新について ACM を監視し、ロードバランサー構成に変更を自動的に適用します。これにより、手動での証明書 ARN 管理が不要になり、複数の環境間での証明書ローテーションの運用複雑性が軽減されます。

これらの機能により運用オーバーヘッドを削減し、関心の分離を改善した本格的な AWS 上の Kubernetes ネットワーキングが可能になります。型安全な CRD、Cross-Namespace ルーティング、自動証明書管理の組み合わせにより、チームはインフラストラクチャ構成ではなくアプリケーション配信に集中できます。

始め方

初回ユーザーの場合は、インストールガイドに従ってください。このガイドでは、必要な AWS Identity and Access Management (IAM) 権限を設定し、AWS Load Balancer Controller を Kubernetes クラスターにデプロイします。

AWS Load Balancer Controller で Gateway API サポートを有効にするには、まず前提条件が満たされていることを確認してください。その後、Gateway API サポートを有効にするには、こちらで説明されているように機能フラグを有効にする必要があります。

構成例

この例では、AWS Load Balancer Controller Gateway API 統合の 3 つの主要機能を実証します : HTTP ルーティング、自動証明書検出を使用した HTTPS ルーティング、ListenerRuleConfiguration を使用したカスタムルーティングルール。デプロイメント手順と検証コマンドを含む完全なウォークスルーについては、AWS Load Balancer Controller Gateway API の例を参照してください。
この例では、以下のアーキテクチャでALBをプロビジョニングします：

  • ポート 80 の HTTP リスナーが blue デプロイメントにルーティング
  • ポート 443 の HTTPS リスナーが自動証明書検出により orange デプロイメントにルーティング
  • HTTP リスナー上の /alb-response パスに対して固定レスポンスを返すカスタムルーティングルール

構成概要

構成には以下が含まれます:

  • AWS Load Balancer Controller を実装として定義する GatewayClass:
# alb-gatewayclass.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: aws-alb-gateway-class
spec:
  controllerName: gateway.k8s.aws/alb
  • HTTP および HTTPS リスナーを持つ Gateway:
# my-alb-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-alb-gateway
  namespace: example-ns
spec:
  gatewayClassName: aws-alb-gateway-class
  infrastructure:
    parametersRef:
      kind: LoadBalancerConfiguration
      name: lbconfig-gateway
      group: gateway.k8s.aws
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      hostname: "sample.com"
      protocol: HTTPS
      port: 443
      allowedRoutes:
        namespaces:
          from: Same
  • スキームまたはその他のゲートウェイ構成パラメータ用の LoadBalancerConfiguration:
# lb-config-gateway.yaml
apiVersion: gateway.k8s.aws/v1beta1
kind: LoadBalancerConfiguration
metadata:
  name: lbconfig-gateway
  namespace: example-ns
spec:
  loadBalancerName: "my-example-gateway-alb"
  scheme: internet-facing
  • カスタムルーティング動作用の ListenerRuleConfiguration:
# listener-rule-config-blue.yaml
apiVersion: gateway.k8s.aws/v1beta1
kind: ListenerRuleConfiguration
metadata:
  name: blue-lrc-config
  namespace: example-ns
spec:
  actions:
    - type: "fixed-response"
      fixedResponseConfig:
        statusCode: 404
        contentType: "text/plain"
        messageBody: "customized text"
  • リスナーをバックエンドサービスにマッピングする HTTPRoutes:
# httproute-blue.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-route-blue
  namespace: example-ns
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: my-alb-gateway
      sectionName: http
  rules:
    - matches:
        - path:
            value: "/alb-response"
      filters:
        - type: ExtensionRef
          extensionRef:
            group: "gateway.k8s.aws"
            kind: "ListenerRuleConfiguration"
            name: "blue-lrc-config"
    - backendRefs:
        - name: service-blue
          port: 80
# httproute-orange.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-route-orange
  namespace: example-ns
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: my-alb-gateway
      sectionName: https
  rules:
    - backendRefs:
        - name: service-orange
          port: 80

デプロイとテスト

この例をデプロイするには、バックエンドの DeploymentsとServices が必要です。以下のリソースを作成してください:

# deployment-orange.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-orange
  namespace: example-ns
spec:
  selector:
    matchLabels:
      app: orange-app
  replicas: 1
  template:
    metadata:
      labels:
        app: orange-app
    spec:
      containers:
        - image: k8s.gcr.io/e2e-test-images/echoserver:2.5
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080
---
# deployment-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-blue
  namespace: example-ns
spec:
  selector:
    matchLabels:
      app: blue-app
  replicas: 1
  template:
    metadata:
      labels:
        app: blue-app
    spec:
      containers:
        - image: k8s.gcr.io/e2e-test-images/echoserver:2.5
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080
---
# service-orange.yaml
apiVersion: v1
kind: Service
metadata:
  name: service-orange
  namespace: example-ns
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector:
    app: orange-app
---
# service-blue.yaml
apiVersion: v1
kind: Service
metadata:
  name: service-blue
  namespace: example-ns
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: ClusterIP
  selector:
    app: blue-app

Gateway がプロビジョニングされるまで待機します:

kubectl wait --for=condition=Programmed gateway/my-alb-gateway -n example-ns

デプロイメントの検証

blue デプロイメントへの HTTP ルーティングをテストします:


# ALB ホスト名を取得
ALB_HOSTNAME=$(kubectl get gateway my-alb-gateway \
    -n example-ns \
    -o jsonpath='{.status.addresses[0].value}')

# HTTP エンドポイントをテスト
curl http://$ALB_HOSTNAME

orange デプロイメントへの証明書検出を使用した HTTPS ルーティングをテストします:

curl -k https://$ALB_HOSTNAME -H "Host: sample.com"

カスタムルーティングルールをテストします:

curl http://$ALB_HOSTNAME/alb-response

NLB 構成、Cross-Namespace ルーティング、高度なカスタマイゼーションシナリオを含むその他の例については、AWS Load Balancer Controller ドキュメントを参照してください。

考慮事項

  • GatewayClass によるポリシー強制: プラットフォームチームは、サブネット配置、セキュリティグループ割り当て、アクセスログを制御する LoadBalancerConfiguration 設定を持つ GatewayClass リソースを定義します。アプリケーションチームは、インフラストラクチャ変更権限なしに承認された GatewayClass オプションから選択します。これにより、 Kubernetes RBAC を通じて内部ワークロードをインターネット向けロードバランサーから分離するなどの組織ポリシーが強制されます。
  • 標準ベースの移植性: Gateway、GatewayClass、Route リソースは Kubernetes Gateway API 仕様に従います。コアルーティングロジックは実装間で一貫性を保ちます。AWS 固有の CRD (LoadBalancerConfiguration、TargetGroupConfiguration、ListenerRuleConfiguration) はオプションのままで、コアルーティング定義から分離されています。これにより、必要に応じてAWS固有の機能を持つポータブルなアプリケーション構成が可能になります。
  • 運用可視性: コントローラーは、リアルタイムプロビジョニング進行状況、リソース識別子 (ロードバランサー ARN と DNS 名)、エラーメッセージで Gateway API ステータスフィールドを更新します。これにより、トラブルシューティング時間が短縮され、リソース状態を確認するための直接的な AWS API クエリが不要になります。
  • AWS サービス統合: この実装は、自動証明書検出のための ACM、アプリケーション保護のための AWS WAF、DDoS 保護のためのAWS Shield Advancedと統合されます。ターゲットグループ構成、ヘルスチェック、アクセスログはAmazon S3 および Amazon CloudWatch と統合されます。
  • GitOps 互換性: スキーマ検証を持つ型安全な CRDは、デプロイ前検証中に構成エラーを表面化します。Infrastructure as Code (IaC) ツールである Flux、ArgoCD、Kubernetes 用 AWS Cloud Development Kit (AWS CDK) は、自動ドリフト検出を伴う宣言的インフラストラクチャ管理のための Gateway API サポートを提供します。

まとめ

AWS Load Balancer Controller の Gateway API サポートは、AWS 上での Kubernetes トラフィック管理に対する標準ベースのアプローチを提供します。Gateway API 仕様を採用することで、Kubernetes 環境間での移植性を維持しながら、ロール指向のリソース管理、Cross-Namespace ルーティング機能、型安全な CRD による拡張されたカスタマイゼーションを得ることができます。プラットフォームチームが Ingress ベースの構成から移行する場合でも、新しい Kubernetes デプロイメントを構築する場合でも、Gateway API 統合によってアプリケーションチームにセルフサービスルーティング機能を提供しながら組織ポリシーを強制することができます。この実装は、証明書管理、セキュリティ、可観測性のためのネイティブ AWS 統合と組み合わせることで運用ワークフローを合理化し、構成の複雑性を軽減します。AWS Load Balancer Controller デプロイメントで Gateway API サポートを有効にして、今すぐ始めましょう。詳細な構成例とベストプラクティスについては、AWS Load Balancer Controller ドキュメントを参照してください。