Envoy Gateway の概要

目的と Envoy Proxy との関係

Envoy Gateway は、Envoy Proxy のためのオープンソースの制御プレーンおよび管理レイヤであり、特に Kubernetes Ingress 用の API ゲートウェイとして Envoy をより使いやすくするために設計されています。基本的には、Envoy Gateway はコアとなる Envoy Proxy（データプレーン）をラップする形で動作し、Envoy のコア、xDS API、またはその動作を変更することはありません。
Envoy Proxy 自体は、高性能な L4/L7 プロキシであり、その柔軟性の高さが魅力ですが、直接設定するには低レベルで複雑な部分があります。Envoy Gateway はそのギャップを埋めるべく、より高水準な API と自動化を提供します。そのミッションは 「Envoy を大衆に届ける」 ことにあり、簡略化されたデプロイモデルと統一された API を通して、ユーザーが Envoy のパワーを深い専門知識なしに利用できるようにしています。
Envoy を単体で使用する場合、設定の手動管理やカスタムの制御プレーンの運用が必要になりますが、Envoy Gateway は Kubernetes の CRD を用いたアウトオブザボックスの構成を提供し、Envoy インスタンスの起動や更新を自動で処理します。これにより、チームは Envoy の力を簡単に活用できる、ターンキーな Ingress コントローラーとして機能します。

主要な機能と能力

Envoy Gateway は API ゲートウェイユースケースを満たすために、豊富な機能を備えています。

• Kubernetes ネイティブな構成
  Envoy Gateway は Kubernetes の Gateway API と統合しており、ルーティング、トラフィックポリシー、セキュリティの設定を行います。ユーザーは Gateway や Route リソースを宣言的に定義し、Envoy Gateway がそれらを Envoy の設定へと変換します。本プロジェクトは、Envoy 固有の拡張を含みつつ Gateway API を正規のインターフェイスとして採用しており、ベンダー固有の注釈や API を避け、業界標準のロール指向 API を用いてゲートウェイの設定管理を行います。

• 「バッテリー同梱」の体験
  インストール後すぐに利用可能なデプロイメントを提供します。Envoy Gateway は Envoy プロキシ（データプレーン）のライフサイクルを自動管理し、Kubernetes 内での Deployment や Service のプロビジョニング、設定、さらには TLS 用の cert management（Let’s Encrypt など）との統合も行います。これにより、本番環境レベルの Envoy ベースのゲートウェイを最小限の労力で立ち上げることが可能となり、質の高いドキュメントやクイックスタートガイドも用意されています。

• 高いパフォーマンスとスケーラビリティ
  データプレーンは Envoy 上に構築されているため、Envoy の効率的な C++ エンジンの恩恵を受け、非常に高い負荷（毎秒数百万リクエスト）を低レイテンシで処理できます。また、Envoy の HTTP/2 や gRPC、コネクションプーリング、非同期 I/O などの高度な L7 機能をサポートし、数千のサービスや大量のトラフィックにもスムーズにスケールします。制御プレーンとプロキシは分離されているため、制御プレーンに負荷をかけることなく、Envoy インスタンス（Pod）を水平スケールできます。

• 豊富なトラフィック管理機能
  Envoy Gateway はホスト名、パス、ヘッダー、正規表現マッチなどの複雑なルーティングルール、トラフィックスプリッティング、直接応答やリダイレクトなど、標準の Gateway API に準じた幅広いトラフィック管理ポリシーを提供します。さらに、カスタムポリシーの CRD を通して、より高度な機能（詳細は後述の技術的詳細参照）を実現しています。ロードバランシングアルゴリズム（例：ラウンドロビン、リーストリクエスト、リングハッシュを用いた一貫性のあるハッシュ）、サーキットブレイキング（接続数、同時リクエスト、リトライの上限）やバックエンド毎のタイムアウト設定が、複雑な Envoy 設定を必要とする部分を Kubernetes リソースで簡単に管理できるようになっています。

• セキュリティ
  TLS 終端（Termination）や TLS パススルー、さらに着信接続に対して mTLS を有効にするなど、セキュリティ機能がファーストクラスでサポートされています。例えば、Envoy Gateway 1.1 では段階的な mTLS のロールアウトが可能になり、ダウンタイムなしでクライアント証明書の要求を進めることができます。また、JWT 検証、OAuth/OIDC、API キー、外部認証サービスとの統合のための認証ポリシー API（SecurityPolicy）を提供しています。ロールベースのアクセス管理、IP アクセス制御リスト、CORS ポリシーなどにより、サービスへのアクセスを厳格に制御できます。

• レート制限とクォータ
  サービスを過負荷や悪用から保護するためのレート制限機能が利用可能です。Envoy Gateway は、ローカルレート制限（各インスタンス単位でのスロットリング）とグローバルレート制限（すべての Envoy インスタンス間での調整）を、Envoy のグローバルレートリミットサービスを用いてサポートします。これにより、ユーザーレベルの API クォータや DDoS 対策を、ゲートウェイ群全体で一貫して実施できます（詳細は技術セクションを参照）。これらのポリシーも、低レベルの Envoy 設定ではなく Kubernetes の CRD を通じて設定されます。

• 可観測性
  Envoy 上に構築されているため、豊富なメトリクスとログを出力します。Envoy Gateway は監視システムとの統合を容易にし、リクエストレート、レイテンシ、成功／エラー件数などの詳細なメトリクスおよびトラフィック用のアクセスログを提供します。最近のバージョンでは、Grafana ダッシュボードやトレーシング（Zipkin/Jaeger）のサポート、ルートにメタデータを付与してトレースレポートに反映させる機能などが追加され、運用者がトラフィックフローの可視化や問題の迅速なトラブルシュートを行えるようになっています。

• 拡張性
  主要な設計目標のひとつとして、コアをフォークや再実装することなく機能拡張できる点が挙げられます。Envoy Gateway は、カスタムフィルターやポリシー（例：Web アプリケーションファイアウォールフィルター、カスタム認証ロジックなど）のプラグインをサポートする仕組みを持っています。拡張フレームワークと API を通じて、外部フィルター（Wasm モジュールや外部処理フックなど）を追加したり、新たなカスタムリソースを導入して Envoy Gateway が認識するようにすることが可能です（詳細は拡張性のセクションを参照）。これにより、Envoy 自体を拡張する場合と同様に、Envoy Gateway 上に独自の付加価値（例：カスタム WAF や特化ルーティング）を構築できますが、よりシンプルな形で実現できます。

まとめると、Envoy Gateway は Envoy Proxy の機能を Kubernetes フレンドリーな制御プレーンと融合させています。各ベンダーやプロジェクトが独自に Envoy 制御プレーンを実装する代わりに、共通のコアゲートウェイを提供することでエコシステム内の重複を削減し、ユーザーが高度なカスタマイズが必要な場合にも柔軟に対応できる、強力な API ゲートウェイを最小の労力で利用できるようにします。

Kubernetes およびサービスメッシュとの統合

Envoy Gateway は Kubernetes と深く統合 されています。これは Gateway API を実装する Kubernetes コントローラーとして動作します。ユーザーはクラスタに Envoy Gateway をデプロイし、Gateway、HTTPRoute、TLSRoute などの Kubernetes CRD を作成することで Ingress トラフィックの設定を行います。コントローラーはこれらのリソースを監視し、それらを Envoy の設定へと変換します。標準の Gateway API を利用することで、Kubernetes のリソースモデルに沿った RBAC（ロールベースアクセス制御）と連携し、例えばクラスター管理者が Gateway を管理し、開発チームが HTTPRoute を管理する、といった形で運用が可能となります。この設計は、従来の Ingress API に比べ、より表現力が豊かで拡張性のあるアプローチを提供し、Kubernetes ネイティブな操作感を維持しています。Gateway API リソースを適用すると、Envoy Gateway は Envoy プロキシのプロビジョニング、Service の設定（例：Envoy データプレーン用の LoadBalancer タイプの Service 作成）やルートのプログラミングなど、望ましい状態へのリコンシリエーションを自動で実行します。

サービスメッシュとの統合については、Envoy Gateway は主に 北南トラフィック（クラスタへの出入りや API エッジのトラフィック）を対象とし、内部の 東西トラフィック（サービス間通信）はサービスメッシュが担います。Envoy Gateway はサービスメッシュのエッジに配置することができ、例えば Istio ベースの環境では、Istio 内蔵の Ingress ゲートウェイの代わりまたは併用して Envoy Gateway を利用し、外部からのリクエストをサービスメッシュ内のサービスへルーティングすることができます。最近の強化により、Envoy Gateway 1.1 ではバックエンドとして Service の Cluster IP へ直接ルーティングできるようになり、ゲートウェイは Kubernetes の Service 抽象化を利用してトラフィックを送信し、サービスメッシュのサイドカーがその後の処理を担うように設計されています。
この設計により、Envoy Gateway は Istio や Linkerd などのサービスメッシュと 共存 可能となります。ゲートウェイとメッシュはそれぞれ異なる制御プレーンでトラフィックの異なる側面を管理し、Envoy Gateway はクラスタエッジの Envoy プロキシを設定し、サービスメッシュは内部トラフィックのサイドカープロキシを管理します。互いに干渉することなく連携できるため、Ingress 用に Envoy Gateway を採用しつつ、サービス間通信にはサービスメッシュを利用する、といった運用が可能です。実際、メッシュ内部のサービスにとって、Envoy Gateway は単なるエントリーポイントとなり、ゲートウェイで Envoy を利用する利点は、エッジと内部で同じ技術（Envoy）を利用できる点にあります。Envoy Gateway プロジェクトは、Istio などのサービスメッシュソリューションと「シームレスに連携」することを強調しており、追加の複雑性をもたらすことなく連携できるため、Ingress 用に Envoy Gateway を採用し、後からメッシュを導入する場合にも自然に連携可能な設計となっています。

---

技術的な詳細

アーキテクチャ

Envoy Gateway のアーキテクチャは、制御プレーンとデータプレーンを明確に分離しています。

• データプレーン
  こちらは実際にトラフィックを処理する Envoy Proxy インスタンス（コンテナ群）で構成されます。

• 制御プレーン
  Envoy Gateway コントローラーが該当し、これがプロキシの構成管理やライフサイクルの管理を担当します。
  この設計は、サービスメッシュにおけるサイドカーをオーケストレーションする制御プレーンに類似していますが、ここでは API ゲートウェイのコンテキストに適用されています。

内部的には、Envoy Gateway の制御プレーンは、同一プロセス内で動作する複数の連携コンポーネントで構成されています。

• Resource Watchers (リソースウォッチャー)
  Kubernetes リソース（または他のプロバイダー）の変更を監視します。現在のデフォルトである Kubernetes プロバイダーでは、コントローラーは GatewayClass、Gateway、HTTPRoute などの Gateway API CRD や、BackendTrafficPolicy などのカスタムポリシー CRD に対してインフォーマーを設定し、ユーザーがこれらのリソースを作成または更新すると、その変更を検知します。

• Resource Translator (リソーストランスレーター)
  ウォッチャーから受け取った Kubernetes オブジェクトを内部モデルに変換します。Envoy Gateway は、Kubernetes API と Envoy の設定を切り離すために、中間表現 (Intermediate Representation, IR) を定義しています。

  • インフラストラクチャ IR：Envoy のデプロイ方法（レプリカ数、使用する Service タイプなど）を記述
  • xDS IR：リスナー、ルート、クラスタの構成を記述
    リソーストランスレーターは、Gateway API の概念をこの IR にマッピングします。例えば、Gateway とその Listeners を Envoy のリスナーの IR 表現に変換し、各 HTTPRoute を Envoy のルート構成の IR に変換します。この抽象化により、フロントエンドを Kubernetes 以外のもの（例：ファイルプロバイダー）に変更しても、プロバイダーとトランスレーターを差し替えるだけで、残りのパイプラインはそのまま利用可能となります。

• xDS Translator & Server (xDS トランスレーターとサーバー)
  xDS IR を、Envoy が理解する実際の xDS リソース（Listener、RouteConfiguration、Cluster、Endpoint リソースなど）に変換します。Envoy Gateway はこれらのリソースを xDS サーバー（gRPC）を介して Envoy プロキシへ提供します。Envoy Gateway は Envoy の Go 制御プレーンライブラリを活用し、Delta xDS プロトコル（効率的なインクリメンタル更新のためのプロトコル）を実装しています。つまり、Envoy Gateway は構成サーバーとして機能し、Envoy プロキシはこれに接続してリアルタイムで設定更新を受け取ります。ルートやポリシーが変更されると、制御プレーンは差分を計算し、再起動なしで Envoy に新しい構成をプッシュします。

• Infra Manager (インフラマネージャー)
  Envoy プロキシインスタンスや補助インフラの管理を担当します。Kubernetes モードでは、インフラマネージャーはインフラ IR に基づいて Envoy 用の Deployment や DaemonSet の作成・更新、Service（ClusterIP/LoadBalancer）の作成などを行います。たとえば、新たに Gateway リソースがデプロイされると、（該当する GatewayClass 用の Envoy Deployment がすでに存在しない場合は）新しい Envoy Deployment や Service を起動することがあります。また、必要に応じてスケーリングやプロキシのアップグレードも管理します。さらに、グローバルレートリミットなどの特定の機能に必要な補助的な制御プレーンサービスもセットアップします。グローバルレートリミットの例では、Envoy は分散型レートリミットをサポートするために Redis バックエンドのレートリミットサービスを必要としますが、Envoy Gateway のインフラマネージャーはこのサービスおよび Redis のデプロイと設定を自動で行い、Envoy プロキシに連携させます。これにより、ユーザーの手動設定作業を大幅に軽減します。

まとめると、Envoy Gateway の制御プレーンは、ユーザーが Kubernetes リソースとして宣言した望ましい状態と、実際の Envoy デプロイメントおよび稼働中の設定状態との間を継続的に調整（リコンシリエーション）します。フローとしては、
ユーザーが K8s の CR を通じて意図を宣言 → リソースウォッチャーがそれを検知 → トランスレーターが IR を生成 → xDS サーバーが Envoy の設定を生成／更新 → Envoy プロキシが xDS を介して更新を受け取り適用
となります。Envoy のホットアップデート機能により、ルートやポリシーの変更は接続を切断することなく伝播します。このアーキテクチャは、イベント駆動型の更新とインクリメンタルな差分更新によって効率的かつ応答性の高いシステムを実現しており、Envoy インスタンスが停止した場合や新たに立ち上がった場合でも、xDS サーバーが再接続時に正しい構成状態へと同期させます。要するに、Envoy Gateway は Envoy をゲートウェイとして利用するために特化した軽量な制御プレーンを実装しています。

xDS 管理と構成の更新

xDS（Envoy のディスカバリー API）は、Envoy Gateway が Envoy の設定管理を行う中心的な仕組みです。Envoy Gateway は xDS 制御サーバー として動作し、各 Envoy プロキシは xDS クライアントとなります。すべての Envoy 設定（リスナー、ルート、クラスタ、エンドポイントなど）は、この動的 API を通じて配信されます。ユーザーが Gateway API リソースや関連ポリシーを変更すると、Envoy Gateway は必要な Envoy の設定を再計算し、xDS を通じてプロキシへ更新をプッシュします。この動的アプローチにより、Envoy の設定ファイルを手動で作成する必要がなく、変更がほぼリアルタイムに反映されます。

Envoy Gateway の xDS サーバーは Envoy の go-control-plane ライブラリを基に構築され、インクリメンタル変更のみを送信する Delta xDS を実装しています。例えば、新たな HTTPRoute を追加すると、Envoy Gateway は全ルートを再送信するのではなく、RDS（Route Discovery Service）の更新として新しいルートのみを送信します。これにより負荷が軽減され、システムは多数のルートやバックエンドに対しても効率的に動作できます。xDS サーバーは複数の Envoy インスタンス（例：3 レプリカ）との長時間の gRPC ストリームを管理し、各プロキシがどの設定を受領したかを追跡し、変更があった場合のみ更新をプッシュします。

また、Envoy Gateway は Kubernetes Gateway API のセマンティクスに厳密に従い、それらを Envoy のモデルにマージまたは変換します。例えば、Gateway API では、複数の HTTPRoute リソースが独立して Gateway にアタッチされることが可能ですが、Envoy Gateway はこれらのルートを Envoy のルートテーブルに適切に統合します。また、同一ポートとプロトコルを共有する複数のリスナーが存在する場合、Envoy Gateway はそれらを１つの Envoy リスナー内の複数のバーチャルホストとしてまとめ、設定の最適化を図ります。これらの判断はトランスレーション時に行われ、結果として Envoy に渡される設定が望ましい状態を正確に再現するようになっています。

実際の運用では、Kubernetes リソースが更新されると、Envoy Gateway の制御プレーンが常に最新の Envoy 設定を計算し、プロキシに送信します。もしエラーや無効な設定が導入された場合、Envoy Gateway はそのポリシーを拒否したり、最後に正しく動作していた設定を引き続き提供するなどして、接続の中断を回避します。IR を介した切り離しと xDS 更新のトランザクション性により、一貫性が維持されます。xDS の利用により、設定変更時に Envoy のリロードや再起動が不要となり、接続を切断することなくスムーズな更新が可能となります。

さらに、xDS は サービスディスカバリー のためにも利用されます。Envoy Gateway は Kubernetes の Service や Endpoint を監視し、EDS（Endpoint Discovery Service）を通じて Envoy のクラスタ設定を更新します。たとえば、Service の Pod 集合が変化した場合、Envoy Gateway は EDS の更新を送信し、Envoy のクラスタ内エンドポイントを調整します。これらすべてが xDS 経由で実施されるため、Envoy は常に最新のエンドポイント情報を持ち、ポーリングを行う必要がありません。

まとめると、Envoy Gateway の xDS 管理は、Envoy プロキシが宣言された望ましい状態と常に同期することを保証します。Kubernetes 主導の設定と動的な xDS 更新の組み合わせにより、静的なゲートウェイソリューションに比べ、設定変更が迅速かつ一貫してプロキシ群全体に伝播できる、堅牢なシステムを実現しています。

レート制限とコストメカニズム

Envoy Gateway における レート制限 は、サービスを保護するためにルートまたはゲートウェイにアタッチ可能なポリシーとして実装されています。Envoy Gateway は、グローバルレート制限 と ローカルレート制限 の両方式をサポートしており、これらは BackendTrafficPolicy というカスタムリソース（CRD）を介して設定されます。

BackendTrafficPolicy (BTP)

このポリシー CRD は、Envoy がバックエンドとどのように通信するかを定義するもので、主な用途の一つとしてレートリミットルールの指定があります。BTP は、ゲートウェイ全体に適用するグローバルな設定としても、特定のルート（HTTPRoute/GRPCRoute）にアタッチして個別に設定することも可能です。ゲートウェイレベルにアタッチされた場合は全ルートに対するデフォルトとなり、ルート個別の BTP が存在すればそのルールが優先されます。この階層構造により、グローバルなデフォルトを設定しつつ、特定のエンドポイントに対して異なる制限を適用できます。BackendTrafficPolicy 内では、ローカルもしくはグローバルのレート制限設定を定義できます。

• ローカルレート制限
  Envoy インスタンス 1 つあたり のリクエスト上限を設定します。例えば、「各 Envoy プロキシにつきこのサービスへのリクエストを 1 秒間に 100 件以下にする」といった制限です。Envoy は各プロキシでトークンバケット方式を用いてこれを実現します。個々のバックエンドインスタンスのトラフィックを平滑化する際や、分散によるオーバーヘッドを避けたい場合に有効ですが、クラスタ全体での一貫した制限は実現しません（各プロキシが独自に許容するリクエスト数の合計となるため）。

• グローバルレート制限
  すべての Envoy ゲートウェイに対して 共有のレート制限 を適用します。Envoy のグローバルレート制限は、外部サービスを利用してカウンターを管理します。Envoy Gateway の場合、グローバルレート制限を有効にすると、Envoy にレートリミットフィルターが設定され、外部の Rate Limit Service (RLS) と連携する形になります。通常、RLS は Redis をバックエンドに持つ gRPC サービス（Envoy がオープンソースのリファレンス実装を提供）となります。例えば、ある API に対して 1 分間に 100 リクエストというグローバルな制限を設定した場合、5 つの Envoy Pod が存在しても全体で 100 リクエスト／分が適用され、各 Pod が独自に 100 リクエストを許容することはありません。どのプロキシも同じカウンターを参照し、1 つのプロキシが RLS にリクエスト許可を求めると、共有のカウンターから減算されます。これにより、クライアントが複数のゲートウェイ Pod にリクエストを分散して制限を回避することが防止されます。

BackendTrafficPolicy を用いることで、運用者は高レベルな意図（例えば、クライアント IP ごとに 1 分間に 100 リクエストなど）を宣言的に記述できます。BTP が該当する Gateway または Route に紐付けられると、Envoy Gateway が Envoy の HttpRateLimit フィルターを設定し、グローバルの場合は RLS との通信のためのクラスタも自動的に構成します。ひとつの BTP により、レートリミットのキー（例：IP、ユーザーID、APIキーなど）とレート値を指定することができ、内部では Envoy のレートリミット descriptor と RLS の設定に変換されます。なお、グローバルレート制限を持つ BTP が複数のルートを持つ Gateway に適用される場合、各ルートはデフォルトで独自のバケットが割り当てられます（特に設定しない限り、異なるルート間でリミットが共有されることはありません）。

Envoy Gateway v1.3 で導入された強力な機能として、コストベースのレート制限 が挙げられます。通常、各リクエストはレートリミットに対して「1」としてカウントされますが、コスト指定子 (cost specifier) を用いることで、特定のリクエストがバケットから消費するトークン数を多く（または少なく）設定することができます。例えば、計算リソースを多く消費する処理を 5 リクエスト分としてカウントする、といったことが可能です。Envoy Gateway では、BackendTrafficPolicy のレートリミットルール内でこのコストを指定でき、さらに、Envoy の ダイナミックメタデータ からそのコストを動的に取得することも可能です。
ダイナミックメタデータは、リクエストの流れの中で Envoy フィルターが追加情報を付与する仕組みで、例えば外部認証フィルターがユーザーのサブスクリプション階層や特定のコスト情報をタグ付けすることができます。Envoy のレートリミットフィルターはこの情報を基に、リクエスト毎に適切なクォータを消費するよう動作します。
この仕組みにより、例えば無料プランのユーザーは 1 リクエストにつき 1 とカウントし、プレミアムユーザーの場合は別のコストを適用するといった、きめ細かなレート制限が実現可能となります。コスト指定子は、レートリミットポリシー内でメタデータまたはヘッダーに対応するフィールドを指定することで設定され、実行時に Envoy がその値を評価し、適切な分だけクォータから差し引きます。

さらに、BackendTrafficPolicy は、Envoy とバックエンド間の通信設定（ロードバランシング戦略、サーキットブレーカー、プロトコルの詳細設定など）も統合して管理します。これにより、通常は複数の Envoy YAML ファイルに分散して記述するような設定も、BTP の数行の YAML 記述で済むようになり、運用のシンプルさが大幅に向上します。

実際の運用では、グローバルレート制限機能を有効にした Envoy Gateway をデプロイし、例えばクライアント IP ごとに 1 分間に 100 リクエストという設定を BackendTrafficPolicy オブジェクトとして作成し、HTTPRoute（または Gateway）にアタッチします。Envoy Gateway は、クラスタ内の各 Envoy にこのルールを適用し、最初のリクエスト時に RLS に確認を行い、上限を超えた場合は HTTP 429 (Too Many Requests) を返します。コストメカニズムにより、リクエストごとに異なる消費量を設定することが可能となり、これらすべてが宣言的な設定で管理され、Envoy の RLS 設定を直接編集する必要がなくなります。

拡張性

Envoy Gateway は、開発者やベンダーが基本の Gateway API を超えた機能を追加・カスタマイズできるように、拡張性を考慮して設計されています。拡張のレイヤーとして、主に以下の仕組みがあります。

1. EnvoyExtensionPolicy を通じた外部フィルター
Envoy Gateway では、HTTP やネットワークフィルターといった Envoy フィルターを、外部フィルターとして組み込むことが可能です。これは EnvoyExtensionPolicy CRD を通じて実現されます。例えば、WASM モジュールを利用したカスタムな認証チェックの実装や、Envoy の ExtProc (External Processing) フィルターを利用して外部 gRPC サービスへ処理をオフロードする、といったケースが考えられます。EnvoyExtensionPolicy を用いることで、Kubernetes ネイティブな方法で外部フィルターの設定が可能になり、内部的には適切な位置に Envoy のフィルター設定が反映されるため、低レベルな Envoy 設定を手動でパッチする必要がなくなります。以前は、EnvoyPatchPolicy を用いて直接 Envoy の設定を編集するなど、深い知識が必要な方法が主流でしたが、EnvoyExtensionPolicy によりより安全かつシンプルに拡張が実現できます。HTTP フィルターだけでなく、TCP 処理の拡張が必要な場合のネットワークフィルターもサポートされ、複数のポリシーをアタッチしてフィルターの順序（プライオリティ）を制御することも可能です。

2. Extension Service を通じたカスタム xDS トランスフォーメーション
より高度な拡張のために、Envoy Gateway は Extension Service インターフェイスを提供しています。これにより、拡張開発者は外部 gRPC サービスを介して Envoy Gateway の構成生成プロセスにフックすることができます。Extension Service は、ルート生成後、バーチャルホスト生成後、リスナー生成後、さらには全体の翻訳後（PostTranslate）の各フックポイントに登録され、Envoy Gateway は生成した xDS リソースをこのサービスに渡します。サービス側は必要に応じて設定を変更または追加し、その結果を Envoy Gateway に返すことで、Envoy に渡される最終的な設定がカスタマイズされます。これにより、例えば、独自の A/B テストや WAF ルールエンジンなど、Gateway API ではカバーされない特定の機能に対応するための Envoy 設定を、拡張として実装することが可能です。
この仕組みでは、カスタム CR（例：WAFPolicy）を作成し、HTTPRoute に ExtensionRef を付与すると、Envoy Gateway はその情報を Extension Service に転送し、そこで Envoy の設定が適切に修正され、xDS に組み込まれる仕組みになっています。Extension Service はプロセス外（場合によっては Envoy Gateway コントローラーのサイドカーとして動作）で実行され、独自の Kubernetes 監視を行うことなく、Envoy Gateway 経由でカスタム CR を受け取り、Envoy 設定へ変換します。これにより、複数の拡張が連携して動作する可能性もあり、コア部分を変更することなく高度なカスタム機能を実装できます。

3. ポリシーのアタッチとカスタムリソース
前述の BackendTrafficPolicy や EnvoyExtensionPolicy のように、Envoy Gateway は Gateway API のポリシーアタッチ機構を活用して拡張性を提供しています。また、ClientTrafficPolicy（ゲートウェイへのクライアント接続の設定、例：TLS バージョンや HSTS の設定）や SecurityPolicy（認証、CORS など）といった拡張 CRD も存在し、今後さらに新たなポリシーを追加する仕組みが用意されています。例えば、カスタムヘッダーの正規化フィルターなど、既存の Gateway API でカバーされない機能を実装する場合、これらの拡張ポイントを利用することで、Envoy Gateway の制御プレーンを変更することなく柔軟に対応可能です。

また、ダイナミックメタデータは、カスタムフィルターと他のポリシー間の連携を実現する重要な仕組みとして機能します。外部認証サービスなどで付与されたメタデータに基づき、例えばユーザーのロールに応じたレートリミットやルーティングの分岐を行うといった実装も可能となります。これにより、ユーザーは Gateway API の基本機能に縛られることなく、独自の拡張をシームレスに組み込むことができます。

パフォーマンスの考慮事項とスケーラビリティ

Envoy Gateway のパフォーマンスは、主に Envoy Proxy 自体のパフォーマンスに依存しており、Envoy は C++ で実装された非同期・イベント駆動型のネットワークスタック（libevent/epoll など）を用いるため非常に高いスループットを誇ります。実際、Lyft や Google などの大規模な導入例からも、Envoy は毎秒数百万リクエスト、数千の上流クラスタを低レイテンシで処理できることが証明されています。Envoy Gateway はこの Envoy の能力を最大限に活用し、Ingress トラフィック向けに最適な設定を行います。以下の点がパフォーマンス向上に寄与します。

• データプレーンの水平スケーリング
  Envoy プロキシは通常のコンテナ（例：Deployment）として動作するため、負荷に応じて Pod 数を増やすことでスケールアウトが容易です。各 Envoy インスタンスが X RPS を処理できれば、N インスタンスでは理論上 N×X の処理能力を発揮します。Envoy Gateway は、これらの Pod を Kubernetes Service（LoadBalancer や NodePort）として登録し、負荷分散が自動で行われるように設計されています。

• 制御プレーンの分離
  Envoy Gateway のコントローラーはリクエスト経路上には存在せず、構成更新の速度にのみ影響します。通常、ルート更新などの変更頻度はリクエスト数に比べると極めて低いため、制御プレーンの負荷はごく軽微です。インクリメンタルな xDS 更新により、環境が大規模になっても制御プレーンにかかる負荷は最小限に抑えられます。

• 最適化された設定とマージ
  Envoy Gateway は生成する Envoy 設定を最適化するよう努めています。例えば、同一ポートや互換性のあるリスナーは可能な限り統合し、リスナー数を抑えることで Envoy 側の負荷を軽減します。複数の小さなリスナーより、統合された大規模なルートテーブルの方が効率的に動作する場合があります。Gateway API の仕様に従いつつも、不要なリスナーのマージやルートの統合を行い、オーバーヘッドを最小化しています。

• リロードによるダウンタイムがない更新
  従来のプロキシでは、設定変更時にフルリロードが必要な場合があり、これがトラフィックの一時的な途絶や CPU 負荷の急増を招く可能性がありました。しかし、Envoy の xDS ホットリロード機能により、接続を切断することなくスムーズに構成変更が行われます。これにより、特に高トラフィック環境においても、接続途絶なく運用が可能です。

• Envoy の最適化機能
  Envoy Proxy 自体が、スレッドプール、コネクション再利用、バッファ制限など、多くのパフォーマンスチューニングオプションを提供しています。Envoy Gateway はこれらのデフォルト値を賢明に設定するとともに、BackendTrafficPolicy やその他の CRD を通して一部の設定をユーザーが調整できるようにしています。例えば、コネクションプーリングやアウトライヤー検出（不調なホストの排除）などの機能は、システム全体のパフォーマンス向上に寄与します。

• 可観測性によるパフォーマンスチューニング
  Envoy Gateway は、Prometheus や Grafana などと統合され、p99 レイテンシや上流の遅延など、詳細なメトリクスを提供します。これにより、運用者はリソースの割当や Pod 数の調整、スレッド数のチューニングなど、最適なパフォーマンスを引き出すための判断が迅速に行えます。

• クラウドスケーリングとの連携
  Kubernetes 上で動作する Envoy Gateway の Service（例：AWS や Azure の LoadBalancer Service）は、各 Envoy Pod へのトラフィック分散を自動で行います。これにより、クラウドプロバイダーが持つ負荷分散機能（クロスゾーン負荷分散やヘルスチェックなど）と連携し、信頼性とスループットを向上させることができます。

まとめると、Envoy Gateway のパフォーマンスは、Envoy の高いパフォーマンスと水平スケーリングの容易さを最大限に活用する設計になっています。制御プレーンはトラフィック経路上に存在しないため、データプレーンのスケーリングにほとんど影響を与えず、設定更新もシームレスに行われます。適切なリソース割当とチューニングを行えば、Envoy Gateway は大規模な本番環境においても十分なパフォーマンスを発揮できるでしょう。

また、Envoy Gateway は、Istio のような Envoy ベースの Ingress ゲートウェイと同様のパフォーマンスを提供しつつ、フルメッシュが不要な場合にはより軽量な選択肢となります。NGINX Ingress と比較しても、Envoy（および Envoy Gateway）は高並列時のスループットに優れ、HTTP/2 や gRPC といった先進的な機能をより robust にサポートします。