Kubernetes Gateway APIがGA——Ingress時代の終わりが来た

Kubernetesのトラフィック管理に革命が起きている。長年「Ingress」リソースが担ってきた外部トラフィックのルーティングに、ついに正式な後継が登場した。Gateway APIは2023年10月にv1.0（GA）に到達し、2026年3月現在のv1.2ではGRPCRoute、TLSRouteもGA（安定版）となり、実運用での採用が急速に進んでいる。

Ingressの「アノテーション地獄」に悩まされてきたKubernetesユーザーにとって、Gateway APIは待望の標準化だ。本記事では、Gateway APIの仕組み、Ingressからの移行方法、各クラウドプロバイダーの対応状況を詳しく解説する。

なぜIngressを置き換える必要があったのか

Ingressの限界

KubernetesのIngressリソースは2015年にv1beta1として導入され、2020年にGAとなった。しかし、以下の根本的な問題を抱えていた。

アノテーション依存: Ingress仕様はHTTPルーティングの最低限しか定義しておらず、レートリミット、リダイレクト、ヘッダー操作などは全てIngress Controllerごとのアノテーションで対応。NGINX、Traefik、HAProxy Ingressで全く異なるアノテーションを記述する必要があった
プロトコル制限: HTTPとHTTPSのみ。gRPC、TCP、UDPのルーティングはIngressの範囲外
権限分離の欠如: Ingressリソースは単一のAPIで、インフラ管理者とアプリ開発者の責務を分離できなかった
トラフィック管理機能の不足: カナリアリリース（重み付けルーティング）、リクエストミラーリング、ヘッダーベースルーティングなどが標準仕様に含まれていなかった

以下の図は、IngressとGateway APIの機能差を比較しています。

IngressとGateway APIの機能比較。Ingressの制限事項とGateway APIでの解決を対比

Gateway API の設計思想

3層の責務分離

Gateway APIの最大の革新は、トラフィック管理を3つのレイヤーに分離した点だ。

以下の図は、Gateway APIの3層アーキテクチャを示しています。

Gateway APIの3層モデル。GatewayClass、Gateway、Route（HTTPRoute/GRPCRoute/TLSRoute）の関係

GatewayClass（インフラ提供者）

GatewayClassは、Gateway実装を識別するリソースだ。StorageClassがストレージプロバイダーを抽象化するのと同様に、GatewayClassはロードバランサー/プロキシの実装を抽象化する。

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

Gateway（クラスター管理者）

Gatewayは、実際のロードバランサーインスタンスを表す。リスナー（ポート、プロトコル、TLS設定）を定義し、どのNamespaceのRouteをアタッチ可能かを制御する。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: infra
spec:
  gatewayClassName: envoy-gateway
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-cert
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"

Route（アプリ開発者）

HTTPRoute、GRPCRoute、TLSRouteなどのRouteリソースは、アプリ開発者が自分のNamespace内で定義する。Gateway管理者の許可を得て、特定のGatewayリスナーにアタッチされる。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: my-app
spec:
  parentRefs:
    - name: production-gateway
      namespace: infra
  hostnames:
    - "myapp.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v2
      backendRefs:
        - name: my-app-v2
          port: 8080
          weight: 90
        - name: my-app-v3
          port: 8080
          weight: 10

上記の例では、/api/v2 へのトラフィックをv2サービスに90%、v3サービスに10%振り分けている。Ingressでは不可能だった標準的な重み付けルーティングがYAMLレベルで記述できる。

Route タイプ詳解

Route タイプ	ステータス	用途	主な機能
HTTPRoute	GA (v1.0+)	HTTP/HTTPS	パスマッチ、ヘッダーマッチ、リダイレクト、URL書き換え、重み付け
GRPCRoute	GA (v1.1+)	gRPC	サービス/メソッドマッチ、ヘッダーマッチ
TLSRoute	GA (v1.2+)	TLS passthrough	SNIベースルーティング
TCPRoute	Experimental	TCP	L4ルーティング
UDPRoute	Experimental	UDP	L4ルーティング

HTTPRouteの高度な機能

HTTPRouteは以下の高度な機能を標準でサポートしている（Ingressではアノテーションが必要だったもの）。

リクエストヘッダーの追加・削除・変更
レスポンスヘッダーの操作
URLリライト（パスプレフィックスの置換）
リクエストリダイレクト（301/302）
リクエストミラーリング（本番トラフィックのコピーをテスト環境に送信）
タイムアウト設定
リトライポリシー

Gateway API 実装比較

実装	提供元	対応Route	特徴	成熟度
Envoy Gateway	CNCF / Envoy	HTTP, GRPC, TLS, TCP, UDP	Envoyベース。拡張性が高い	★★★★☆
Istio	Google / Solo.io	HTTP, GRPC, TLS, TCP	サービスメッシュ統合	★★★★★
Cilium	Isovalent / Cisco	HTTP, GRPC, TLS	eBPFベース。高性能	★★★★☆
NGINX Gateway Fabric	F5 / NGINX	HTTP, GRPC	NGINX Ingress後継	★★★☆☆
Traefik	Traefik Labs	HTTP, GRPC, TLS, TCP	自動証明書管理	★★★★☆
AWS LB Controller	Amazon	HTTP	ALB/NLB統合	★★★☆☆
GCP GKE Gateway	Google	HTTP, GRPC, TLS	Cloud Load Balancer統合	★★★★☆

Envoy Gateway — 推奨実装

Envoy Gatewayは、Gateway APIのリファレンス実装として最も注力されているプロジェクトだ。CNCFのGraduatedプロジェクトであるEnvoyプロキシを基盤としており、以下の理由でファーストチョイスに推奨される。

Gateway APIの全Routeタイプをサポート
拡張ポリシー（レートリミット、認証、CORS）が標準付属
**xDS（Envoyの設定API）**を直接操作する高度なカスタマイズが可能
Kubernetesの外（VM等）でも利用可能

Ingressからの移行ガイド

移行手順

Gateway API CRDのインストール:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

Gateway実装のデプロイ（例: Envoy Gateway）:

helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \
  --version v1.2.0 -n envoy-gateway-system --create-namespace

GatewayClass と Gateway の作成
Ingressの各ルールをHTTPRouteに変換
段階的な切り替え（DNSの重み付けでトラフィックを徐々に移行）

変換例

Ingress（移行前）:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /app
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

HTTPRoute（移行後）:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
  hostnames:
    - "example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /app
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
      backendRefs:
        - name: my-service
          port: 80

アノテーションが消え、すべてが型安全な構造化されたYAMLで記述される。実装（NGINX, Envoy, Traefik）を変更しても、このHTTPRoute定義は変更不要だ。

日本ではどうなるか

採用状況

日本のKubernetesユーザーにおけるGateway APIの採用はまだ初期段階だ。理由は以下のとおり。

NGINX Ingress Controllerの普及率が高い: 日本のKubernetes環境の多くがNGINX Ingress Controllerを利用しており、「動いているものを変える」モチベーションが低い
マネージドKubernetesの進化: EKS、GKEを利用している場合、クラウドプロバイダーのALB/Cloud Load Balancerとの統合がIngress経由で確立されている
情報不足: Gateway APIの日本語ドキュメントや事例記事がまだ少ない

移行が進みやすいケース

gRPCを多用するマイクロサービス: GRPCRouteにより、gRPCのルーティングが標準化される
カナリアリリースを実施するチーム: 重み付けルーティングが標準で利用可能
マルチチームでKubernetesを共有: 3層の権限分離がチーム間の境界を明確にする
Istioユーザー: IstioはGateway APIを推奨APIとして採用しており、VirtualServiceからの移行が進んでいる

Docker Desktop での検証

ローカル開発環境でGateway APIを試すには、Docker DesktopのKubernetesクラスターが最も手軽だ。Envoy GatewayのQuickStartガイドに従えば、5分程度でローカル環境にGateway APIをセットアップできる。

まとめ：Gateway APIへの移行を始めるべきか

Gateway APIは「あったら便利」ではなく、Kubernetesのトラフィック管理の新しい標準だ。以下のアクションステップを推奨する。

現状のIngress設定を棚卸し: 使用しているアノテーションをリストアップし、Gateway APIの標準機能でカバーできるか確認する
Gateway API実装の選定: Envoy Gateway（汎用）、Istio（メッシュ統合）、Cilium（eBPF高性能）から、チームの技術スタックに合うものを選ぶ
開発環境でPoC: まずステージング環境でHTTPRouteを1つ作成し、Ingressとの動作差異を確認する
段階的移行計画の策定: IngressとGateway APIは共存可能。新規サービスからGateway APIを採用し、既存サービスは順次移行する
チームへのナレッジ共有: Gateway APIの3層モデル（GatewayClass / Gateway / Route）の責務分離をチーム内で合意する

Ingressは公式に「メンテナンスモード」に入っている。新機能の追加は予定されていない。新規のKubernetesプロジェクトではGateway APIを第一選択とすべき時期が来ている。