従来のIngressの限界
Nginx Ingressのアノテーションとの格闘に、これまでどれほどの時間を費やしてきたか分かりません。標準的なIngressを使用してカナリアリリースやブルーグリーンデプロイを実装しようとしたことがあるなら、50行にも及ぶ nginx.ingress.kubernetes.io/... メタデータの壁に直面したことがあるでしょう。これらのアノテーションは壊れやすく、デバッグが困難で、何より特定のベンダーに依存（ロックイン）してしまいます。もしNginxからHAProxyに移行する場合、ルーティングロジックをゼロから書き直さなければなりません。
問題は単なる構文の複雑さではなく、構造そのものにあります。Ingressは、ウェブがもっと単純だった時代に設計されました。「1つのホスト、1つのパス、1つのバックエンド」という基本的なモデルを前提としています。ヘッダーベースのルーティング、トラフィックミラーリング、重み付けによるバランシングといった現代の要件は、その枠組みに収まりません。私たちは長年、ベンダー固有のハックを使ってIngressを無理やり動かしてきましたが、その結果、コントローラー間で設定の互換性がない断片化されたエコシステムが生まれてしまいました。
組織的なボトルネック
実際、最大の摩擦が生じるのは技術的な面よりも、人間（組織）の面であることが多いです。従来のIngressでは、クラスター管理者とアプリケーション開発者が同じYAMLファイルを編集する必要があります。開発者がマイクロサービスのパスを更新する際、セキュリティチームが管理しているグローバルなTLS設定を誤って壊してしまうかもしれません。これは本番環境での障害を招く典型的なパターンです。
Kubernetes Gateway APIは、設定を役割に応じた個別のリソースに分割することで、この問題を解決します。
- GatewayClass: プラットフォームチームが設定し、ロードバランサーのタイプ（AWS、GKE、Envoyなど）を定義します。
- Gateway: クラスターオペレーターが管理し、エントリーポイント、IPアドレス、TLS証明書を処理します。
- HTTPRoute: アプリ開発者が所有し、トラフィックが特定のサービスにどのように到達するかを定義します。
この関心の分離により、ネットワーキングがセルフサービスモデルへと変わります。開発者は、インフラレベルのGateway設定に触れることなく、コードのデプロイやルーティングの変更を行うことができます。
クイックスタート：最初のGatewayをデプロイする（5分）
これを試すには、Gateway APIのカスタムリソース定義（CRD）と、対応するコントローラーが必要です。CiliumやIstioといった選択肢も人気がありますが、軽量で標準に準拠した設計の Envoy Gateway が私のおすすめです。
1. CRD의 설치
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml2. Envoy Gateway의 설치
helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.1.0 -n envoy-gateway-system --create-namespace3. Gateway의 정의
이 리소스는 엔트리 포인트 역할을 합니다. 컨트롤러에게 포트 80에서 HTTP 트래픽을 리슨하도록 지시합니다.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: prod-gateway
namespace: infra-ns
spec:
gatewayClassName: envoy-gateway-class
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All4. HTTPRoute로 서비스 매핑하기
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: api-route
namespace: app-ns
spec:
parentRefs:
- name: prod-gateway
namespace: infra-ns
rules:
- matches:
- path:
type: PathPrefix
value: /v1/api
backendRefs:
- name: user-service
port: 8080「ハンドシェイク」の威力
上記の HTTPRoute にある parentRefs に注目してください。これが重要なポイントです。Routeは明示的にGatewayを指す必要があり、Gatewayはその特定の名前空間からのRouteを許可する必要があります。この双方向の「ハンドシェイク」により、「test」名前空間の開発者が「production」名前空間向けのトラフィックを誤って乗っ取ってしまうことを防ぎます。設計レベルでセキュリティが確保されているのです。
高度なトラフィック制御：サービスメッシュは不要
ネイティブなトラフィック分割こそ、Gateway APIがIngressを圧倒する部分です。カナリアテストを実行するためだけに、重厚なサービスメッシュを導入する必要はもうありません。
カナリアリリースのための重み付けルーティング
チェックアウトサービスの v2 をローンチするとしましょう。重み（weight）を変更するだけで、トラフィックのちょうど10%を新バージョンに送ることができます。
spec:
rules:
- backendRefs:
- name: checkout-v1
port: 80
weight: 90
- name: checkout-v2
port: 80
weight: 10ヘッダーによる精密なルーティング
私は、社内スタッフ向けに実験的な機能をテストする際、ヘッダーベースのルーティングを頻繁に使用します。特定のクッキーやヘッダーを持つユーザーだけを、一般公開に影響を与えることなくベータ版のポッドに誘導できます。
rules:
- matches:
- headers:
- name: x-user-group
value: internal-beta
backendRefs:
- name: feature-lab-service
port: 80
- backendRefs:
- name: stable-service
port: 80本番環境から学んだ3つの教訓
YAMLを書き換えることではなく、クラスターの管理方法を変えることです。複数の本番環境を移行して学んだことを共有します。
1. 「ロードバランサーの乱立」を解消する
AWSのNLBは、データ処理料金を除いても1台あたり月額約18ドルかかります。50のサービスがあり、それぞれが独自のIngressを使用しているクラスターでは、アイドル状態のインフラだけで毎月1,000ドル近くを浪費している可能性があります。Gateway APIを使用すれば、1つのGateway（と1つのIP）を数十の名前空間で共有でき、クラウドのコストを大幅に削減できます。
2. 機能サポートの確認
コアAPIはGA（一般利用開始）されていますが、URLの書き換えやカスタムヘッダーといった高度なフィルターは、プロバイダーによってはまだ「Experimental（実験的）」チャンネルにある場合があります。設計を確定させる前に、必ず kubectl get gatewayclass を実行して、コントローラーが実際に何をサポートしているかを確認してください。
3. ステータスブロックを信頼する
以前のIngressのデバッグは、難解なコントローラーのログを掘り起こす作業でした。Gateway APIは、リソースのステータスにエラーを直接表示します。ルートが失敗した場合は、以下を実行してください。
kubectl describe httproute api-routeConditions セクションを見れば、バックエンドサービスが見つからないのか、あるいはGatewayがアタッチを拒否したのかがすぐに分かります。オンコールエンジニアにとって、これはQOL（生活の質）を劇的に向上させる改善です。
まとめ
Gateway APIは、Kubernetesネットワーキングの新しい標準です。ベンダー固有のアノテーションを、現代のチームの働き方に適したクリーンでポータブルなロジックに置き換えます。小規模で単純なプロジェクトにはまだIngressも有効ですが、数サービス以上にスケールする環境であれば、今すぐGateway APIへの移行を検討すべきです。より表現力が豊かで、運用コストが安く、トラブルシューティングもはるかに容易になります。
