Kubernetes Ingress、もう本当に手放すべきでしょうか？Gateway APIを徹底解説 🚀

8月 12, 2026

—

こんにちは！Kubernetes環境でサービスを運用されていますか？もしそうなら、外部トラフィックをクラスター内部サービスに接続する「Ingress」には非常によくご存知のことでしょう。Ingressは長らくKubernetesの標準的なゲートウェイの役割を担ってきました。

しかし、サービスが複雑化し、要件が多様化するにつれて、このようなことを一度は考えたことがあるのではないでしょうか。

「モバイルユーザーにだけ別のページを表示したいんだけど… 🤔」「新しいバージョンのアプリを、まず10%のトラフィックにだけデプロイできないかな？🐦」「特定のHTTPヘッダーを持つリクエストだけを別のサービスに送りたいんだけど… 🧐」

Ingressの基本機能だけでは、このような高度なルーティング戦略を実装するのは困難です。もちろん、Ingress Controllerごとに提供されるアノテーションを使用すれば一部可能ですが、これは特定のベンダーに依存し、標準化されていないため、移植性が低いという問題がありました。

まさにこの点で、Kubernetesの次世代ネットワーキング標準であるGateway APIが登場します！

🧱 Ingressの限界：なぜ私たちは新しいものを必要とするのか？

Gateway APIを理解する前に、既存のIngressが持つ限界を明確に把握しておくことが重要です。

限定的なルーティングルール: Ingressは基本的にホスト名(hostname)とパス(path)ベースのルーティングのみを標準でサポートします。ヘッダー、クエリパラメータ、重み付けベースのルーティングなどは標準機能ではありません。
ベンダー依存の設定: 上述の通り、高度な機能を使用するには、nginx.ingress.kubernetes.io/rewrite-targetのような特定のIngress Controllerのアノテーションに依存する必要があります。これは、別のIngress Controllerに交換する際に、すべての設定を再度変更する必要があることを意味します。😩
権限管理の難しさ: Ingressリソースは通常、クラスター管理者やプラットフォームチームが管理します。しかし、アプリケーション開発者が特定のパスに対するルーティングルールを修正したい場合、巨大なIngress YAMLファイルを一緒に修正する必要があるため、権限分離が難しく、衝突のリスクが存在します。

これらの問題を解決するために、より柔軟で、表現力豊かで、役割ベースで設計されたGateway APIが誕生しました。

✨ Gateway APIの登場：何が違うのか？

Gateway APIはIngressの後続プロジェクトであり、ネットワーキング設定を複数の独立したリソースに分離することで、管理の柔軟性を最大限に高めます。以下の3つの主要なコンポーネントを覚えておいてください。

GatewayClass: クラスター全体に適用されるテンプレートです。どのような種類のロードバランサー（例：AWS LB, NGINX, Istio）を使用するかを定義します。（主にクラスター管理者が担当）☁️
Gateway: GatewayClassの実際のインスタンスです。特定のIPアドレス、ポート、TLS設定などを定義し、ロードバランサー自体を表します。（主にインフラ運用者が担当）🚪
HTTPRoute: 実際のルーティングルールを定義します。「/loginパスはauth-serviceに送り、/api/v2パスはnew-api-serviceに送る」といったアプリケーションレベルのルールを含みます。（主にアプリケーション開発者が担当）🗺️

この構造の最大の利点は、役割の分離（Separation of Concerns）です。インフラチームはGatewayを通じて安定したゲートウェイを提供し、開発チームは自分たちのサービスに必要なHTTPRouteルールだけを気にすればよいのです。互いの領域を侵犯することなく、独立して作業できます。🤝

🎯 主要機能：比類なきトラフィック制御能力

それでは、Gateway APIがなぜ「よりきめ細やかなトラフィック制御（More granular control over traffic routing）」を可能にするのか、実際の例を通して見ていきましょう。

1. ヘッダーベースルーティング (Header-based Routing)

モバイルアプリユーザーとウェブユーザーを区別して、異なるバックエンドサービスに送りたいと仮定してみましょう。User-Agentヘッダーを基準にルーティングを分岐させることができます。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mobile-routing-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["example.com"]
  rules:
  - matches:
    - headers:
      - type: Exact
        name: User-Agent
        value: "MyMobileApp/1.0"
    backendRefs:
    - name: mobile-app-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-app-service
      port: 8080

上記のHTTPRouteは、User-AgentヘッダーがMyMobileApp/1.0であるリクエストをmobile-app-serviceに、それ以外のすべてのリクエストをweb-app-serviceに送ります。Ingressアノテーションなしで標準機能だけでこれが可能です！

2. カナリアデプロイのための重み付けベースルーティング (Weight-based Routing) 🐦

新しいバージョンのmy-app-v2をデプロイし、全体のトラフィックの10%だけを先に送って安定性をテストしたいとします。Gateway APIは、これのためのweightフィールドを標準で提供します。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-deployment-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["api.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-app-v1 # 既存バージョンサービス
      port: 80
      weight: 90
    - name: my-app-v2 # 新しいバージョンサービス
      port: 80
      weight: 10

この設定一つで完了です！my-app-v1サービスが90%のトラフィックを、my-app-v2が10%のトラフィックを受け取ることになります。もはや複雑な追加ツールや非標準のアノテーションに依存する必要はありません。⚖️

🌐 全体的な文脈：なぜGateway APIに移行すべきなのか？

個々の機能の強力さも重要ですが、Gateway APIがもたらすより大きな変化は、Kubernetesネットワーキングの標準化と移植性です。

役割ベースAPI: インフラチームと開発チームの責任と権限を明確に分離し、協業を円滑にし、ミスを減らします。
移植性: すべてのルーティングルール（ヘッダー、重みなど）が標準仕様に含まれています。つまり、NGINX Gateway Fabricを使用していたとしても、IstioベースのGatewayに切り替えても、HTTPRouteの定義はほぼそのまま再利用できます。ベンダー依存性から解放されるのです。🌍
表現力と拡張性: HTTPRoute以外にも、TCPRoute、UDPRoute、TLSRouteなど多様なプロトコルをサポートし、カスタムフィルターを通じてルーティングルールを無限に拡張できます。

結論

Ingressは依然として、シンプルなウェブサービスを公開するための優れたツールです。しかし、マイクロサービスアーキテクチャが複雑化し、カナリアデプロイ、A/Bテスティング、きめ細やかなトラフィック制御などの高度な機能が必須となった今日、Ingressの限界は明確です。

Gateway APIは単なるIngressの代替品ではなく、現代のクラウドネイティブ環境の要件を満たすために設計された次世代標準です。今すぐすべてのIngressを置き換える必要はありませんが、新しいプロジェクトを開始したり、既存システムの限界を感じているのであれば、Gateway APIを積極的に検討する時期です。✨