Envoy Gateway で実現する開発者主導の Gateway 管理¶

インフラ開発者とアプリケーション開発者の責任分担を明確にするため、Kubernetes の Gateway API はロール指向設計を採用しています。Gateway API の実装のうち、AWS や GKE のコントローラーがクラウドプロバイダー固有のリソースに依存するのに対し、Envoy Gateway はクラウドに依存しない実装です。Envoy と Envoy Gateway の基本概念を整理したうえで、クラウドへの依存の違いによって、アプリケーション開発者自身が Gateway を管理できる可能性がどう変わるかを説明します。

Envoy の基本概念¶

Envoy は、マイクロサービスアーキテクチャにおける通信を管理し、可観測性を確保するためのミドルウェアです。主に次の機能を提供します。

リクエストのトレーシング
高度な負荷分散
認証・認可

開発者は Envoy を主に次の 2 つのパターンで利用します。

Side Car パターン - 各サービスの横に配置
Gateway パターン - エントリーポイントとして配置

Envoy Gateway の概要¶

Envoy Gateway は、Kubernetes の Gateway API 仕様に対応した、Envoy Proxy を管理するためのコントロールプレーンです。Gateway API のリソースを読み取り、実際の通信を処理する Envoy Proxy へ設定を渡します。この役割分担は公式ドキュメントの構成図でも確認できます。

主な機能¶

Envoy Gateway は次の機能を提供します。

トラフィック管理
- 高度なリクエストルーティング
- 負荷分散
- リトライ機構とタイムアウト制御
セキュリティ
- 多様な認証方式（API Key、Basic 認証、OIDC、JWT）
- TLS 通信の管理
メトリクス
- 詳細なリクエストトラッキング
- モニタリング

備考: Envoy Gateway は頻繁にアップデートされています。最新の機能については公式ドキュメントを参照してください。

Gateway API の概念¶

Kubernetes のリソースタイプの 1 つである Gateway API は、外部からのリクエストを受け付けるためのインターフェースを定義します。

Ingress との違い¶

機能	Gateway API	Ingress
プロトコルサポート	L4-L7（TCP/UDP/HTTP など）	主に L7（HTTP/HTTPS）
ロール指向	✅	❌
カスタマイズ性	高い	限定的

Gateway のロールベースアーキテクチャ¶

Gateway API のロール指向設計により、インフラ開発者とアプリケーション開発者が管理するリソースを明確に分離できます。インフラ開発者がGatewayClassとGatewayを用意し、アプリケーション開発者がリクエストの振り分け先をHTTPRouteで定義する、という分担です。

リソースとロールの関係図¶

Gateway API の各リソースをどのロールが担当するかを、次の図に示します。

Gateway API リソースモデル

Gateway API の公式ドキュメントによると、図の 3 つのロールと担当するリソースの対応は次のとおりです。

インフラ提供者（Infrastructure Provider）: GatewayClass
クラスタ運用者（Cluster Operator）: Gateway
アプリケーション開発者（Application Developer）: HTTPRoute

インフラ提供者とクラスタ運用者を、本記事ではまとめてインフラ開発者と呼びます。

リソースの定義例¶

インフラ開発者がGatewayClassとGatewayを、アプリケーション開発者がHTTPRouteを管理し、HTTPRouteのbackendRefsでリクエストの振り分け先となる Service を指定します。Envoy Gateway を使う場合の定義例は次のとおりです。

gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: envoy-gateway
  listeners:
    - name: http
      protocol: HTTP
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: example-gateway
  hostnames:
    - "example.com"
  rules:
    - backendRefs:
        - name: example-service
          port: 8080

クラウド実装との比較¶

AWS と GKE の Gateway コントローラーは、いずれもクラウド事業者固有のリソースに依存します。

AWS Gateway コントローラー¶

AWS の実装であるAWS Gateway API Controllerは、Gateway リソースを VPC Lattice に関連付けます。次の図のとおり、Gatewayが VPC Lattice のサービスネットワーク、HTTPRouteが VPC Lattice のサービス、Kubernetes の Service がターゲットグループにそれぞれ対応しています。

AWS Gateway Controller

GKE Gateway コントローラー¶

Google Cloud の実装は、Gateway リソースを Google Cloud ロードバランサーに関連付けます。GKE のドキュメントによると、Gatewayリソースに定義した構成を実装するロードバランサーを GKE が作成します。

GKE Gateway Controller

クラウドプロバイダーでのロール分担の必要性¶

AWS や GKE の実装で Gateway リソースを作成・管理すると、VPC Lattice やロードバランサーなどのクラウド固有のリソースが自動生成されます。クラウドの IAM 権限管理やネットワーク構成も必要になるため、クラウドインフラストラクチャに精通したインフラ開発者のロールが不可欠です。インフラ開発者が管理する項目は次のとおりです。

クラウドリソースのプロビジョニングと構成管理
IAM ポリシーとセキュリティグループの設定
ネットワークトポロジーと VPC 設定
コスト最適化

Envoy Gateway の特徴的なポジション¶

クラウドプロバイダーの実装と Envoy Gateway の主な違いは次のとおりです。

AWS/GKE: Gateway 作成時にクラウド固有のリソース（VPC Lattice、Google Cloud ロードバランサー）が自動生成される
Envoy Gateway: Gateway の設定を Kubernetes リソースで管理し、外部公開の方式は別に選ぶ

開発チームへの影響¶

Envoy Gateway 自体はクラウド固有のリソースに依存しないため、Gateway の設定をクラスタ内で管理できます。ただし、Envoy Proxy の Service をクラウドの LoadBalancer として外部公開する場合は、そのリソースや権限の管理も必要です。そのため、アプリケーション開発者自身が Gateway リソースを管理できる可能性があります。開発者自身で管理できれば DevOps の効率化と開発サイクルの短縮が期待でき、インフラチームへの依存度が低減して開発者の自律性も高まります。

Service の公開方法の違いは、Envoy Gateway のシステム設計でも説明されています。

まとめ¶

クラウドプロバイダーに依存せず Gateway API のロール指向設計を実現できるのが、Envoy Gateway の特徴です。管理対象が少ないぶん、アプリケーション開発者自身が Gateway を扱える場面が広がり、DevOps の効率化と開発サイクルの短縮も期待できます。インフラ開発者への依存をどこまで減らせるかは、Gateway の実装に加えて、外部公開の方式やチームの権限分担によっても変わります。