Kubernetes Gateway API

 (romaglushko.com)
4 ポイント 投稿者 GN⁺ 4 시간 전 | 2件のコメント | WhatsAppで共有
  • 2025年11月、Kubernetesは全クラスタの40%以上で使用されていたNGINX Ingress Controllerの2026年3月のdeprecationを発表し、この決定はGateway APIをIngress APIの後継として位置づける転換点となった
  • Gateway APIはinboundトラフィック管理に必要な幅広い機能を扱い、Ingress APIよりも表現力が高く、チーム間の関心の分離を明確にする
  • Ingress APIの限界としては、狭いAPI範囲、硬直した拡張性、ポリシー強制の欠如、曖昧な所有権の境界、安全なcross-namespaceの未サポートなどがある
  • Gateway APIはGatewayClass、Gateway、Listener、Routeなどの分離されたリソースモデルと、ReferenceGrant、Policy attachmentのようなセキュリティ・拡張メカニズムを提供する
  • NGINX Ingress Controllerで繰り返し発生したCVEは構造的欠陥に起因しており、長期的にはGateway APIへの移行が唯一の根本的な解決策である

Ingressの進化の過程

  • 2014年の初期Kubernetesでは、Serviceリソースがアプリケーションを公開する基本手段だった
    • ClusterIPはクラスタ内部のDNS名のみを提供し、外部アクセスは不可
    • NodePortはすべてのノードで特定ポートを開放して外部トラフィックを受け入れ、ノードIPが公開されれば外部公開が可能
    • LoadBalancerはパブリックIPを持つ外部ロードバランサをプロビジョニングしてトラフィックを転送
    • ExternalNameはCNAMEレコードにより外部サービスのクラスタ内エイリアスを提供
  • 4つのうち外部公開を直接行えるのはNodePortとLoadBalancerのみ
    • NodePortは基礎的なプリミティブだが低レベルすぎて、ノード間の外部ロードバランシングやpathベースのルーティングを自前で実装する必要がある
  • LoadBalancerはNodePortの上にL4ロードバランサ（TCP/UDP）を追加して自動プロビジョニングし、Cloud Controller Managerがこれを担う
    • ただし、多数のパブリックIPとロードバランサを管理する必要がありコストが増加し、トラフィックを一元管理するポイントも存在しない
  • Serviceごとに個別のロードバランサを用意する代わりに、単一のLoadBalancer Serviceがすべてのトラフィックを受けて、NGINXのようなreverse proxy Deploymentへ渡し、パスやホスト名に基づいてルーティングする構成がIngress APIとIngress Controllerの出発点となった

Ingress Controller

  • 2015年、Kubernetesチームは外部HTTP(S)トラフィックを内部Serviceへルーティングするルールを定義する手段としてIngress APIを導入

  • Ingress APIはIngressClassとIngressの2つのリソースで構成され、共通インターフェースのみを定義し、実際の動作にはIngress Controllerの導入が必要

  • IngressClass

    • どのコントローラが特定のIngressリソース群を処理するかを指定するcluster-wideリソース
    • 同一クラスタ内で複数のIngress Controllerを並行運用できるようにし、各コントローラは自分のIngressClassで選択されたリソースだけを監視する
    • コントローラがIngressClassを読み取って利用するにはClusterRole権限が必要

  • Ingressリソース

    • IngressはIngress APIの主要リソースであり、複数の要素を組み合わせる
      • pathベース（exact/prefix）およびhostベースのマッチングルールにより内部Serviceへのルーティングを定義
      • インバウンドトラフィックのTLS設定を定義
    • リソース作成時、Ingress Controllerがこれを検知して自身の設定を更新し、ルーティングルールを適用する

  • Ingress APIの問題点

    • 実運用環境では次の問題が発生した: 非常に限定的なAPI範囲、硬直した拡張性、ポリシー強制の欠如、曖昧な所有権の境界、安全なcross-namespaceの未サポート

  • 非常に限定的なAPI範囲

    • Ingress APIは単純（simple）というより**貧弱（simplistic）**で、イングレストラフィック設定に必要な最小限しか扱わない
    • NGINXで一般的によく求められる次の機能を直接サポートしない
      • request timeout、CORS、max body size制限、sticky cookieセッション、canaryトラフィック分割、rate limiting、header・query・cookieベースのルーティング、headerの変更
    • その結果、追加設定を渡す標準的な方法としてcustom annotationが使われるようになり、Traefikなど一部のコントローラは独自のCRDを使用した
    • 複数のIngress Controllerを同時利用する場合、統一された設定方法がないためコントローラごとにannotationが異なり、移植性が低下する
    • IngressはHTTP(S)ルーティングのみを扱い、gRPC（L7）・TCP・UDP（L4）は実装ごとにcustom annotationで処理される

  • 硬直した拡張性

    • custom annotationは単なる文字列のkey-valueペアにすぎず、複雑な設定を文字列にシリアライズしなければならないため、表現力が不足している

  • ポリシー強制の欠如

    • アプリケーションチームはIngressリソースに任意のannotationを追加でき、たとえばプラットフォームチームが全ルートに期待するrate limitingを無効化することもできる
    • Ingress API自体にはグローバルな動作を強制する仕組みがないため、KyvernoやOPA Gatekeeperのような外部ポリシーエンジンに依存する

  • 曖昧な所有権の境界

    • Ingressリソースには複数の設定が混在している
      • ルーティングルールは通常アプリケーションチームの所有
      • hostname・port設定はDNS・ロードバランサ・ネットワーキングを管理するプラットフォームチームの所有
      • TLS設定は証明書のプロビジョニングを担当するプラットフォームチームの所有
      • custom annotationは両チームのいずれかが所有しうる
    • umbrella Helm chartでデプロイされる複雑なシステムでは、Ingressは通常アプリケーションのsubchart内に置かれるが、プラットフォームチームも一部を更新・強制しなければならない
    • 単一責任の原則の観点では、Ingressは変更理由が2つ以上あるため、より集中したリソースに分離するのが望ましい
    広告

  • 安全なcross-namespaceの未サポート

    • Ingressリソースは自身のnamespace外にあるServiceやTLS secretを参照できず、rules[].backend.serviceにはnamespaceを指定するフィールドすらない
    • 回避策として、同一namespaceにExternalName Serviceを作成し、対象Serviceのクラスタ内DNS名を指すことはできる
    • ただし、この方式にはまさにconfused deputy attackに相当する問題が内包されている

Gateway API

  • Gateway APIはIngress APIの次世代版であり、次の点によってその限界を解消する
    • インバウンドトラフィック管理に必要なはるかに広い機能を扱い、表現力を強化
    • 一般的なリソース所有パターンを反映し、チーム間の関心の分離を明確化
    • policiesという定義済みの拡張メカニズムと、柔軟なcross-namespaceオブジェクト参照を含む

GatewayClass

  • IngressClassと同様に、特定のGatewayコントローラデプロイメントが所有するGatewayの集合を定義し、IngressClassと実質的に同じ意味・構造を持つ
  • 追加の実装固有Gateway設定を含むcustom resourceを参照できる
    • Gateway proxyの公開方式、ブートストラップ・実行時のデフォルト設定、デプロイのロールアウト・スケール方法、その他コントローラ固有のオプションを含む

Gateway

  • Gatewayリソースは動的にプロビジョニングされるedge gatewayを表し、インバウンドトラフィックを受けて適切なバックエンドサービスへルーティングするインフラ抽象化である

    • Ingress設計ではIngress Controllerがこの役割を担っていたため、静的にプロビジョニングされたGatewayインスタンスと見なせる

  • 各GatewayはGatewayClassを参照して、どのコントローラがプロビジョニング・管理するかを指定し、最も重要な構成要素はlistenerの一覧

  • Listeners

    • Gateway がインバウンドトラフィックを受け入れる方法を定義し、各 listener は port・protocol・hostname の組み合わせで記述される個別のエントリポイント
    • TLS termination を設定可能。Ingress の世界ではこの情報は Ingress リソース内に存在していた
    • Route が Gateway に attach できる最も細かい単位

  • ListenerSet

    • listener はエントリポイント設定を一元化するのに適しているが、数百個必要な場合には不向き
    • 主なユースケースは、単一の wildcard TLS 証明書の代わりにサービスごとの hostname・TLS 設定を持つ HTTPS listener であり、マイクロサービスの数だけ listener が発生しうる
    • 単一の Gateway でモデル化すると 2 つの問題が発生
      • Gateway は最大 64 個の listener しかサポートしない
      • 複数チームが listener・TLS を管理すると Gateway が調整のボトルネックになる
    • これを分散・マルチテナント化するために ListenerSet リソースを使用

  • 許可された Listener と Route

    • Gateway と Route の概念を分離した後、どのテナントがどの listener に Route を attach するかを制御する新たな問題が発生
    • listener は共有インフラであり用途も異なる。たとえば、データベースへの passthrough チャネルである tls-passthrough-db listener に HTTPRoute を付けるのは不適切であり、db 以外の namespace から Route を付けるのも不適切
    • Route は自律管理方式で追加されるため、誤設定を防ぐために allowedRoutes メカニズムを使用
    • allowedRoutes は Gateway・ListenerSet と特定の namespace・route タイプの Route の間に信頼関係を確立する

Routes

  • listener はトラフィックを受け取るが、その後の処理方法は知らず、これを Route リソース が担う。Gateway API の柔軟性の中核

  • 複数のプロトコルを扱う 5 種類の Route リソースが存在

    • HTTPRoute: 強化・拡張された HTTP トラフィックルーティング
    • GRPCRoute: gRPC 対応ルーティング
    • TLSRoute: TLS SNI ベースのルーティング
    • TCPRoute・UDPRoute: listener ポートの TCP/UDP トラフィックをバックエンドへ直接転送
    広告

  • すべての Route リソース（総称して xRoutes）は類似した envelope 構造を持つ

    • parentRefs は Route を受け入れる親リソース（主に Gateway、ListenerSet、service mesh の Service など）への typed object reference で、オプションの sectionName・port で特定の listener を指定可能
    • rules はプロトコルごとのルーティングルール・フィルター・設定を含み、各 rule は matches、任意の filters、任意の backendRefs で構成される。フィルターがリクエストを完全に処理する場合は backendRefs を省略可能
    • プロトコルが許可する場合、hostnames フィールドで Route レベルのホストベースルーティングが可能

  • HTTPRoute

    • L7 レベルの HTTP(S) トラフィックルーティングルールを定義

    • Traffic Matching

      • Ingress に似た path・host ベースのルーティングに加え、header・query・method ベースのマッチングルールをサポート
      • 例: 内部クライアント専用の canary リリースを、header ベースのマッチングで test deployment にルーティング可能
      • データプレーンは最も具体的なルールを適用するため、ルール定義の順序は無関係

    • URL Rewrites

      • filter を使ってバックエンド到達前にリクエスト URL の一部を書き換え可能

    • Header Modifications

      • request・response header を追加・削除・変更する HeaderModifier フィルターを提供
      • Cross-Origin Resource Sharing 設定用の専用 CORS フィルターを提供。概念的には response header 変更の特殊ケースだが、別個のフィルタータイプとして公開される

    • Redirects

      • バックエンド転送の代わりにクライアントへ redirect レスポンスを返せる。3xx の path ベース redirect および HTTP→HTTPS redirect をサポート

    • Traffic Control

      • weight によってバックエンドサービス間でトラフィック分割が可能で、blue-green デプロイや A/B テストなどに有用
      • traffic mirroring は本番トラフィックのコピーを追加のバックエンドへ送り、RequestMirror フィルターで設定する。元のリクエストは既定のバックエンドへ進む
      • mirroring はリファクタリングやマイグレーション時に旧版・新版の結果を比較する tap-and-compare testing の中核要素

    • Sticky Sessions

      • session persistence をサポートし、cookie・header をセッションマーカーとして設定して同一クライアントのリクエストを同一バックエンドインスタンスへ一貫してルーティング

    • External Authentication

      • gRPC または HTTP ベースの実験的 external authentication フィルターをサポートし、Gateway はバックエンド転送前に外部認証サービスへリクエスト header を送信する。リクエスト本文は明示的に有効化した場合のみ送信
      • gRPC の場合、外部認証サービスは Envoy の ext_authz protobuf API を実装する必要がある
      • HTTP の場合、認証成功時に 200 を返し、それ以外のステータスは認証失敗として扱う

    • Retries & Timeouts

      • 特定のルートに retry を設定可能。BackendTrafficPolicy は retry storm を防ぐためのグローバル retry budget を提供

  • GRPCRoute

    • gRPC は HTTP/2 ベースのため HTTPRoute でも扱えるが、別リソースとしてモデル化する理由がある
      • URL rewrite のように gRPC では意味をなさないオプションを分離し、各リソースがプロトコルに合わせて独立して進化できる
      • gRPC レスポンスは HTTP 200 を返しつつも grpc-status・grpc-message header でアプリケーションエラーを表現し、これは正しい retry・メトリクスに重要
      • 高水準の gRPC 用語でルールを定義することでユーザー体験が向上
    • HTTPRoute の path matcher は method matcher に置き換えられ、内部的には path をマッチングするが、service・method 形式で公開される
    • request・response header の処理は可能だが、gRPC payload はデコードしないため特定の protobuf フィールドに基づくルーティングは不可
    • traffic mirroring・weighted load balancing、header 変更など HTTPRoute フィルターの一部をサポート

  • TCPRoute と UDPRoute

    • listener ポートに到達したトラフィックをバックエンドサービスへ単純転送し、現時点では matcher・filter は未サポート
    • 両タイプとも複数バックエンド間の weighted load balancing をサポート

  • TLSRoute

    • TLS handshake 中に提供される SNI に基づいて TLS 暗号化トラフィックをバックエンドへルーティング
    • 主に TLS passthrough に使われ、Gateway が SNI を確認してバックエンドを選択した後、TLS 終端を行わずに暗号化接続を転送し、バックエンドが TLS 終端を担当
    • Envoy Gateway や kgateway など一部の実装は edge での TLS termination もサポートするが、これは拡張機能
    • Route には hostname の明示が必要で、SNI 値とマッチし、Gateway listener の hostname と共通部分が必要。matcher・filter は未サポートだが weighted load balancing はサポート

  • Route Filter Extensions

    • HTTPRoute と GRPCRoute は extensionRef フィルターにより、custom フィルターやリクエスト/レスポンス処理の拡張メカニズムを含み、typed object reference で別のリソースを参照する
    • 例: Envoy Gateway はバックエンドサービスなしで直接レスポンスを返す HTTPRouteFilter CRD を提供

  • バックエンドターゲット

    • 基本的に標準の Service（最も一般的）と、マルチクラスター向けの ServiceImport をバックエンドターゲットとしてサポート
    • typed object reference で指定されるため、実装ごとの custom resource に拡張可能
    • 例: Envoy Gateway は、FQDN・IP・UNIX ソケットなどの外部 upstream を指す custom Backend リソースをサポート
    広告

  • ReferenceGrant

    • Gateway API は cross-namespace 参照を標準設計の第一級概念として扱うが、セキュリティリスクがある
    • confused deputy attack の例: 攻撃者がある namespace を掌握すると、Ingress・Service・EndpointSlice の作成権限によって保護されたサービスへのアクセスを漏えいさせられる可能性がある
      • 新しい Ingress が、侵害された namespace の新規 Service を指す
      • その Service は selectorless で、どの deployment ともマッチしないため、EndpointSlice を手動で提供できる
      • 攻撃者は、別 namespace の保護されたバックエンド pod IP を含むように EndpointSlice を偽装し、ポート整列によって保護された API への第2の入口を作る
      • ExternalName Service でも同じ結果に到達できる
    • これを緩和するために ReferenceGrant リソースが導入され、ある namespace が自分のリソースを参照できる namespace を定義する双方向の信頼メカニズムを提供する
    • Gateway Controller は、バックエンドターゲットや TLS secret への cross-namespace 参照時に ReferenceGrant を考慮し、confused deputy attack を困難にする
    • ただし、ReferenceGrant は参照の正当性だけを保証し、トラフィック転送後の動作には関与しないため、NetworkPolicies によって保護された API ポートへのアクセスを遮断して補完できる

Policies

  • Policy attachment は、元のリソースを変更せずに、1つ以上の Gateway API コンポーネントに 階層的 に動作や効果を適用する強力な拡張パターン
  • 認証が代表的な例
    • Gateway（または ListenerSet）全体に認証を適用すると、現在および将来アタッチされるすべての Route に階層的に影響し、同時に公開ルートのような Route レベルの例外も可能
    • 認証は Gateway・Route とは無関係のチームが制御できるため、それらのリソースを直接変更しないように設計されている
    • OAuth 2・OIDC などの標準があっても、認証設定は実装依存性が高く、すべての実装で通用する抽象化は難しい
  • 例: Envoy Gateway の SecurityPolicy リソースで JWT トークン検証を設定でき、Policy は Ingress 時代の annotation ベース設定を置き換える、現代的で表現力の高い方式
  • 組み込み Policy は2つ בלבד
    • BackendTLSPolicy: Gateway が upstream バックエンドへ TLS で接続するよう指示
    • BackendTrafficPolicy: 特定バックエンドの retry budget を指定し、グローバルな retry 許容量を超えると 503 を返す。circuit breaker のように動作し、retry storm を防ぐ

Ownership

  • クラスター内の Gateway API リソースは通常2つのチームが所有する
    • Platform team は GatewayClass・Gateway・ListenerSet と LoadBalancer・TLS 設定を定義し、一部または全 Gateway に適用されるグローバル Policy を管理できる
    • Application/Service team は主に自分たちの Route リソースに集中し、必要に応じて Route レベルの Policy を適用する
  • 柔軟性が高く、Route をプラットフォームチームが1つの namespace に集約して所有するなど、さまざまな所有モデルを構成できる

Typical Architecture

  • Gateway API は実装アーキテクチャを大きく仮定しないが、一般的な方式は control plane と data plane の分離
  • Gateway Controller は control plane の役割を担う Kubernetes operator で、Gateway API リソースと CRD を監視して望ましい data plane 設定を集約し、リソースの読み取り・変更のための拡張権限が必要
  • Gateway data plane は設定に従ってトラフィックを処理する proxy で、一般に Envoy Proxy・NGINX・Traefik などが使われ、実装によって Gateway ごとに proxy をプロビジョニングする場合も共有する場合もある
  • control/data plane の分離は、NGINX Ingress Controller で見つかった根本的なセキュリティ欠陥を回避するうえで有利な設計選択

Ingress 移行

  • NGINX Ingress Controller の deprecation への対応オプションは4つあり、侵襲性の低い順に検討する

  • 何もしない

    • 最善ではないが、一部のケースでは可能で、homelab では動機が弱いかもしれない

    • エンタープライズでは、保守・パッチ適用されたソフトウェア運用が期待される規制・セキュリティ・コンプライアンスのフレームワークがあるため、許容しにくい

      • ISO 27001: 脆弱性管理・パッチ・EOL 追跡が期待される
      • SOC 2 Type II: 脆弱性スキャン・パッチ管理・是正 SLA が期待される
      • HIPAA Security Rule: レガシー・未パッチソフトウェアをリスク分析に含める必要がある
      • PCI DSS v4.0.1: サポート対象外コンポーネントの特定・是正計画が求められ、重大な脆弱性の対処期限も規定される
      • FedRAMP: サポート対象外ソフトウェアを保守される代替手段に置き換えることが期待され、重大度ごとの是正期限がある

    • ほとんどのフレームワークでは、EOL ソフトウェアは新しい脆弱性が公開された時点で実質的な問題になる

    • CVE 分析

      • 過去5年間の NGINX Ingress Controller の CVE 状況
        • 脆弱性は合計 20件
        • 2021年は secret 漏えい関連の High が4件
        • 2022年はコントローラー credential 漏えい関連の High が1件
        • 2023〜2024年は High が3件
        • 2025年は6件で、Critical 1件（IngressNightmare）と NGINX 設定注入関連の High 4件を含む
        • 2026年は6件で、NGINX 設定注入関連の High 3件を含む
      • 2021〜2022年の CVE は主に annotation 内の未サニタイズなユーザー提供 NGINX 設定の問題で、設定注入・情報漏えい・secret 漏えいを引き起こし、Kubernetes が validation を追加した
      • 2023〜2024年の CVE は主にその annotation validation の回避
      • IngressNightmare(CVE-2025-1974) は状況を悪化させた。従来は Ingress リソースの作成・変更権限が必要だったが、admission controller へのネットワークアクセスさえあれば、設定注入に類似したバグによって ingress-nginx コントローラーのコンテキストでリモートコード実行が可能となり、その後コントローラーがアクセス可能な Secret を漏えいさせ得る
      • 2026年の事例でも、annotation・path・comment を通じた設定注入パターンが継続している
      • これらの脆弱性は、設計上の同じ弱点を繰り返し狙っている
        • コントローラーは非常に柔軟で広範な NGINX 機能を公開しており、完全な validation が難しいため、設定注入が繰り返し発生する
        • コントローラーは control plane と data plane を 同じ pod で実行し、ファイルシステムを共有するため、インシデント時の影響範囲が拡大する
        • コントローラーはクラスター全体の Secret にアクセスすることが多く、設定注入の成功がクラスター全体の secret 漏えいにつながり得る
      • 構造的な問題により、今後も追加の CVE が予想され、移行計画なしに元のコントローラーに留まるのは危険な選択
      広告

  • NGINX Controller Fork の利用

    • 最も単純な道は、保守されている fork へ切り替えること
      • Chainguard の fork はビルド済みイメージを提供していないようで、これは販売対象の一部となっている
    • 新たな CVE への露出リスクを減らし、大きな変更なしにシステムを維持できるが、短期的な解決策
    • Chainguard は、長期プロジェクトとしてコントローラーを継続開発するのではなく、ユーザーに移行時間を確保してもらうための best-effort な CVE 修正を提供している

  • 他の Ingress Controller を使う

    • Ingress リソース自体は deprecated ではないため、維持されている他の Ingress Controller へ移行するのも有効で、代表例として HAProxy・Istio・Traefik がある
    • システム全体で annotation の移行が必要で、NGINX 特化機能への依存度によって難易度は異なる
    • 今後はより多くのプロジェクトが Gateway API へ移行し、Ingress の比重は下がっていくが、当面は Ingress でも十分に問題ない

  • Gateway API へマイグレーション

    • 唯一の長期的な選択肢は Ingress API から Gateway API への移行
      • Gateway API の CRD・実装のインストール
      • GatewayClass・Gateway・必要に応じて Policy リソースを設定
      • 既存の Ingress リソースを Route へ移行
    • Kubernetes チームが作成した ingress2gateway CLI が best-effort の自動変換を提供するが、custom annotation は後で手動で再確認する必要がある
    • timeout、file upload の上限、body size の上限などを正確に移行する必要があり、漏れや誤ったマッピングがあるとアプリケーションの前提を静かに壊してしまう可能性がある
    • Ingress Controller の LoadBalancer から新しい Gateway proxy の LoadBalancer へのトラフィック切り替えは慎重に計画すべきで、big-bang である必要はない
      • Ingress Controller を公開エントリポイントとして一時的に維持しつつ、一部のトラフィックだけを Gateway API data plane に送り、本番トラフィックでテストした後に段階的に切り替えることができる

どの Gateway を選ぶべきか

  • マイグレーションを決めた後の最初の大きな問いは、どの Gateway API 実装を使うかだ

  • 本稿における generic API Gateway の定義は、完全に制御された環境にデプロイされる public な North-South トラフィック向けのスケーラブルなゲートウェイで、一般的な認証パターンと柔軟な rate limiting を標準で提供するもの

  • API Gateway のほかに LLM Gateway・Agent Gateway も存在するが、本節では古典的な API Gateway に焦点を当てる

  • Gateway API Conformance

    • Kubernetes チームは、実装の中核となるプロトコル処理の正確性を検証する 標準 conformance テスト を用意しており、主に機能的な動作に焦点を当てている。信頼性・性能・拡張性・運用の複雑さといった非機能面は含まれない
    • conformant な実装を優先すべきであり、公式サイトに結果がなければメンテナーに conformance レポートを求めることが推奨される

  • Public Benchmarks

    • 公式テストのほかにも、信頼性や性能を扱う公開ベンチマークがある。Istio コントリビューターであり Solo.io の社員でもある John Howard が主要実装のベンチマークを作成しており、Solo.io は kgateway の親会社だ
    • Route attachment・伝播・スケール・一般的なトラフィック処理性能など、有用なテストケースが含まれている。本人の経験に基づくため特定のユースケースに偏る可能性はあるが、評価の一つの視点として活用できる

  • OSS vs Proprietary

    • 現在は強力な本番向け OSS Gateway API 実装が多く、評価時には真剣に検討する価値がある。多くの組織では OSS が出発点としての標準だ
    • OAuth2・OIDC のように、かつて商用製品の購入を正当化していた機能は commodity 化しており、OSS コントローラーでも標準提供される
    • OSS は導入前に自分で品質を評価できる一方、商用製品は早い段階でベンダーを信頼する必要がある

  • Recommendations

    • data plane ごとにグループ化

      • Envoy Proxy ベース: Envoy Gateway、Istio、Cilium、kgateway など
      • NGINX ベース: NGINX Gateway Fabric、Kong
      • その他の proxy: HAProxy Ingress、Traefik

    • Envoy Gateway

      • Envoy Proxy チームが開発した Envoy Proxy ベースのオープンソース Gateway API コントローラーで、Envoy の機能を Gateway API にできるだけ直接マッピングしているため、Istio より製品固有の抽象化が少なく理解しやすい
      • Ingress API は未サポートで、Envoy AI Gateway によって LLM・MCP gateway・Inference Pools 機能へ拡張できる
      • 軽量でデプロイ・運用が簡単であり、API Gateway（North-South）に集中している。対応機能は以下の通り
        • external authentication・JWT 検証・JWT claim ベースの authorization・OIDC・IP allowlisting・static API key 認証・credential injection などのセキュリティパターン
        • グローバルおよびルート単位の設定、shadow mode、request cost 設定などを備えた柔軟な global rate limit policy
        • connection・bandwidth・file size 制限、availability zone を考慮したルーティング、ServiceImport ベースの基本的なマルチクラスタ、Brotli・gzip・zstd のレスポンス圧縮、direct response・response override
        広告
      • 拡張性も高く、リクエスト・レスポンス・xDS 設定を変更するための gRPC サービスを書けるほか、Lua または WASM にコンパイル可能な言語（Go・Rust）でプラグインを書ける
      • FQDN・IP の外部リソースや、sidecar 用 UNIX ソケットを指す custom Backend リソースも含む
      • 現在は一部のスキップされたテストのため partially conformant として掲載されているが、機能面ではほぼすべての項目を満たしており、KEDA・KNative などの CNCF プロジェクトとも統合されている
      • 高機能な API Gateway だけが必要なら有力な選択肢だ

    • Istio

      • Envoy Proxy ベースの service mesh であり CNCF Graduated プロジェクトでもあり、Gateway API テストでは conformant として掲載されている
      • Ingress Controller・Gateway API コントローラー・service mesh を含むパッケージで、agentgateway との連携により LLM・MCP・A2A gateway 機能も提供できる
      • Admiral などによる高度なマルチクラスタ対応、広いデプロイプロファイル、大きなコミュニティ、O'Reilly の書籍など豊富な資料があり、mTLS ベースの pod-to-pod 暗号化により政府機関や FedRAMP 環境でも有用だ
      • 欠点として、sidecar モードではリソース消費が大きく、独自概念も多いため 学習曲線 が急だ
      • ambient mode により軽量な setup を提供するが、高度な L7 のユースケースでは sidecar ほど機能的ではない可能性がある。より強いポリシーや L7 制御が必要なら、Envoy Gateway を ingress gateway・waypoint proxy として併用することも検討できる
      • service mesh が主で Gateway API が従である場合には最適だが、API gateway だけが必要ならやや物足りなく感じるかもしれない

    • kgateway

      • Gloo プロジェクトをベースにしたオープンソースの CNCF Sandbox ゲートウェイで、data plane として Envoy Proxy と agentgateway（AI gateway 機能）をサポートし、外部で管理される独自の data plane インスタンスも利用できる
      • 完全な Gateway API conformance を備え、ほぼ唯一すべての項目を満たしている
      • Envoy data plane では JWT 検証・OAuth2/OIDC・external authentication・IP アクセス制御、Envoy global rate limiting、ext_proc ベースのリクエスト・レスポンス処理を公開しているが、Lua・WASM プラグインや raw xDS の直接変更は公開していないようだ
      • MiniJinja テンプレートベースの強力な transformation engine により、TrafficPolicy リソースで header・response body・status 変換を宣言的に定義できる
      • Istio と edge proxy として統合できるが、それ自体が service mesh の役割を果たすわけではない。1 つの Route が別の Route にトラフィック処理を委譲する 階層的 Route をサポートし、AWS Lambda を直接呼び出す custom AwsLambda CRD も持つ
      • ベンダーは幅広い導入実績を主張しているものの、独立したフィードバックはまだ多くなく、公開コミュニティの観点ではなお成長途上のプロジェクトに見える

  • Traefik

    • Goで書かれた人気のオープンソース reverse proxy で、Ingress API と Gateway API の両方をサポートし、優れたドキュメント・整理されたコードベース・簡単な設定・容易なデプロイにより、特に homelab コミュニティで人気

    • 中核となる Gateway API 機能と一部の追加機能をサポートするが、ListenerSet と Gateway API による traffic mirroring はまだ未対応（カスタム TraefikService バックエンドでは mirroring 可能）

    • 拡張モデルは middleware ベースで、ExtensionRef フィルタにより Route を Middleware CRD に接続し、組み込み middleware として ForwardAuth（外部認証の委譲、Envoy ext_authz に類似）、IP allowlisting・CORS、接続制限・retry・circuit breaker、圧縮・custom error page などを提供

    • Plugin middleware により custom YAEGI・WASM プラグインを接続可能（主にリクエスト・レスポンスの変更）。JWT 検証・OIDC・OAuth2 Client Credentials は有料プラグインでのみ提供

    • Middleware CRD により基本的な分散 rate limiting をサポート（IP・host・header バケット）するが、設定の柔軟性は高くなく、policy attachment ではなく ExtensionRef で付与するため、グローバル適用後にルートレベルで override するような階層化が難しい

    • 明確な control plane / data plane の分離がなく、アーキテクチャは NGINX Ingress に近い。同一 pod がリソース監視とトラフィック処理を担い、Gateway ごとの proxy を動的にプロビジョニングせず、単一 deployment が監視 namespace のすべての Gateway を管理するため、単一障害点や分離性低下により大規模環境では復元性の問題が生じる可能性がある

    • 選定時には想定トラフィックでの load test を推奨。特に Traefik の性能への不満を耳にすることがあるため、より慎重な検証が必要

    • NGINX Gateway Fabric

      • NGINX ベースの F5 公式 Gateway API 実装（NGF）で、堅牢な conformance を持ち、最近のバージョンでは Gateway API 1.5 と、標準 HTTPRoute フィルタによる CORS・request/response header 変更のサポートが追加された
      • JWT・OIDC 認証、cookie ベースの session persistence、NGINX reload なしの upstream 更新など一部機能は依然として NGINX Plus に依存しており、これらは一般的な API Gateway 要件でもある
      • custom SnippetsPolicy・SnippetsFilter により、生成される config の複数レベルに custom NGINX 設定を注入でき、既存の NGINX Ingress にある膨大な custom 設定を書き直さずに移行しやすくなる
      • custom RateLimitPolicy により rate limiting をサポートするが、local rate limiting であるため状態は NGINX data plane に存在し、複数の NGF レプリカを運用するとインスタンス数に応じて実効上限が変わるため、厳密なユーザー単位の制限は難しい
      • NGINX 自体の拡張 escape hatch として軽量な JavaScript・Lua スクリプティング、外部認証委譲用の auth_request（Envoy ext_authz・Traefik ForwardAuth に類似）、custom C モジュールを提供するが、ext_proc 方式の外部サービスベースのリクエスト/レスポンス変更は未対応
      • NGF 2.0 ではアーキテクチャを刷新し、control plane / data plane の分離と複数 Gateway リソースのサポートを実現。以前はアーキテクチャが大きな懸念点だった

    • Cilium Service Mesh

      • 多くのクラスターが CNI として Cilium を使用しており、eBPF ベースの sidecar-less service mesh に Envoy Proxy ベースの Gateway API 実装が含まれるため、構成要素を減らして技術スタックをスリム化できる
      • ただし主に Gateway API conformance に焦点を当てており、Gateway API 以外の有用な Envoy 機能が第一級の設定として公開されていない。たとえば Envoy 拡張・プラグイン、IP allowlisting、JWT 検証・claim ベースの authorization・OIDC の第一級サポートがない
      • Cilium の現在の Gateway API 機能で十分だと確信できない限り、Envoy Gateway・kgateway・Istio など、より機能豊富な選択肢よりも汎用 API Gateway としては推奨しない

    • Kong

      • NGINX ベースの人気 API Gateway で、Kong Operator は Ingress・Gateway API の両方をサポート
      • 主な懸念は OSS 戦略 で、新しいオープンソース Gateway バージョンの prebuilt Docker イメージ公開を停止したように見え、OSS イメージは 3.10 リリースライン付近で止まっており、自前でビルド・パッチ適用・強化・保守が必要になる可能性がある
      • この措置が enterprise 顧客の離脱抑制と関連しているという公開の推測はあるが、確定した事実とは言えず、それでも OSS の方向性が以前より予測しにくく感じられる
      • したがって、enterprise ライセンスを購入するか、OSS のパッケージングと保守を自ら担う準備がない限り推奨しない

Summary

  • Kubernetes のイングレスパターンの進化を初期から Gateway API 時代までたどり、Gateway API プロトコル自体も深く扱う
  • GAMMA（Gateway API のアイデアを service mesh に拡張）と Inference Extension（Kubernetes 推論ワークロードの定義・最適化）は意図的に範囲外とされており、別途深掘りが必要なテーマ
  • 利用可能な Gateway API 実装と、その選定基準もあわせて検討

関連記事

2件のコメント

 
click 2 시간 전

去年NGFを使ってみようとしたのですが、Authorization ヘッダー ベースの認証を作る方法がなくて、envoyに行った記憶がありますね
envoyよりはnginxのほうが好みなので、Gateway APIが全体的にサポートされたら次はNGFを使ってみようかなと思っています
 
hmmhmmhm 2 시간 전

Envoy がさらに注目されそうですね