本記事は 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 仕様のコンポーネントを示しています: 図 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 リソースを実現します。このプロセス全体を通じて、プロビジョニングの進行状況と発生したエラーを反映するためにステータス条件が更新されます。 図 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 ドキュメントを参照してください。

はじめに Kubernetesとは？ コンテナとは？ Kubernetesでできること コンテナの管理 デプロイの自動化 スケーリングの自動化 Kubernetesのアーキテクチャ概要 Pod Podを管理するワークロードリソース Kubernetesの構成 コントロールプレーン ノードコンポーネント 実際に触って理解してみる 環境準備 minikubeでクラスタを起動する Podを起動してみる（nginx） namespaceの違いを確認する namespaceを作成してPodを起動してみる Podの動作を確認する（curl） 片付け まとめ はじめに はじめまして！ 2025年度新入社員の…

はじめに私たちは、社内のプラットフォームにおいて、Cloud NativeなANN（近似最近傍探索）ベクトル検索エンジン「Vald」のマネージドシステムを約4年間にわたり運用・開発してきました。本記事...