- はじめに
- Ingress が直面した「構造的課題」
- KubeCon 2019：API 再構築という決断
- Gateway API の核心：「ロール指向設計」による解決
- KubeCon Japan 2025 で見た、設計思想の成果
- まとめ
はじめに
この記事は、DMM グループ Advent Calendar 2025の 12 日目の記事です。
こんにちは。プラットフォーム開発本部 第 3 開発部 認可チームのなずな(@na2na_chang)です。
今年 6 月に開催された KubeCon Japan 2025 に参加してきました（参加録はこちら）。 キーノートで Lin Sun 氏が Gateway API を活用したサービスメッシュのデモを披露しており、Kubernetes におけるトラフィック制御の今後の方向性について興味を持ちました。
また、Ingress NGINX が将来的にサポート終了予定であること（参考）も知り、Gateway API がなぜ生まれたのか、Ingress からどのような課題を引き継ぎ、どう解決しようとしているのかを調査してみました。
Ingress が直面した「構造的課題」
私が Gateway API の成り立ちを調査した結果、前身である Ingress の設計が、現代のクラウドネイティブ環境にスケールするうえでいくつかの避けて通れない構造的な課題を抱えていたことを知りました。
Ingress の果たした役割とその後の課題
2015 年に導入された Ingress リソースは、Kubernetes のエコシステムにおいて非常に重要な進歩でした。 というのも、Ingress が登場する以前は、LoadBalancer タイプの Service リソースを使うと、サービスごとに高価なクラウドロードバランサーをプロビジョニングする必要があったからです。Ingress は、単一のロードバランサーで複数のサービスへルーティングを振り分ける（Fan-out）ことを可能にしました。
しかし、Ingress の API 設計には、マルチノード環境や複雑なアプリケーション要件にスケールするうえで、以下のような構造的な課題がありました。
1. 「最低限の共通機能」設計の限界
Ingress の設計哲学は、当時存在していた多様なプロキシ（NGINX、HAProxy、Envoy など）の機能のうち、共通して提供できる機能のみを API 仕様として定義するというものでした。 このアプローチは初期の API 普及には有効でしたが、クラウドネイティブアプリケーションが成熟するにつれて、カナリアリリース、レートリミッティング、認証連携といった高度な機能が求められるようになると、このアプローチでは対応が難しくなりました。
2. 「アノテーション地獄」が招いた移植性の低下
標準 API で高度な機能が不足したため、各 Ingress コントローラーの開発者は metadata.annotations フィールドを拡張領域として利用し始めました。アノテーションは本来メタデータ付与のための仕組みですが、Ingress においては実質的な設定言語として機能し、これをコミュニティでは「アノテーション地獄（Annotation Hell）」と呼ぶようになりました。 アノテーションへの依存は、Kubernetes の最大の価値提案である「ポータビリティ（移植性）」を根本的に損ないました。 例えば、「URL リライト」の設定一つをとっても、Ingress NGINX や AWS Load Balancer (ALB) では異なるキーと構文を要求し、設定が断片化していました。 その結果、環境を移行する際に、マニフェストをベンダー固有の文法に書き換える手間が発生しました。 以下は、同じ機能を実現するための Ingress NGINX と AWS ALB の設定例です。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-nginx
annotations:
# キー: NGINX専用
# 構文: 正規表現のキャプチャグループ($2)を利用
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- http:
paths:
- path: /app(/|$)(.*) # 正規表現パス
pathType: ImplementationSpecific
backend:
service:
name: my-service
port:
number: 80
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-alb
annotations:
# キー: AWS ALB専用
# 構文: エスケープされた JSON オブジェクト
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/actions.rewrite-target: >
{"type":"forward","forwardConfig":{"targetGroups":[{"serviceName":"my-service","servicePort":80}]},"rewriteConfig":{"path":"/"}}
spec:
rules:
- http:
paths:
- path: /app/*
pathType: ImplementationSpecific
backend:
service:
name: rewrite-target # アノテーションで定義したアクション名を指定
port:
name: use-annotation
3. 運用上の摩擦：役割と責任の混在
Ingress リソースは、ロードバランサーのインフラ設定（TLS 証明書、セキュリティポリシーなど）と、アプリケーションのルーティング設定を単一の YAML オブジェクトに混在させていました。 この単一リソースモデルは、役割分担が明確な大規模組織において、インフラ管理者とアプリケーション開発者の間に不必要な摩擦とセキュリティリスクを生みました。
- 開発者がルーティングルールを変更したいだけでも、Ingress リソース全体を編集する必要があり、重要な TLS 設定を誤って破壊するリスクがありました。
- 管理者は、全社的なセキュリティポリシーを適用するために、開発者が管理するすべての Ingress リソースを継続的に監査する必要がありました。
この構造的な課題が、Ingress がマルチテナント環境においてスケーラビリティのボトルネックとなっていた最大の原因だと考えられます。
KubeCon 2019：API 再構築という決断
Ingress が抱える構造的な課題についてコミュニティ内でも議論が進む中、大きな転換点となったのが 2019 年の KubeCon + CloudNativeCon North America でした。
当時の様子や資料を調べてみました。 すると、SIG-Network（Kubernetes のネットワーク領域を担当する分科会に相当する組織）のセッションにおいて、「Ingress v2」を作るのではなく、「全く新しい API をゼロから設計する」という方針が発表されていたことが分かりました。
なぜ「Ingress v2」では駄目だったのか
普通に考えれば、v1 に課題があるなら v2 へバージョンアップすれば良さそうに思えます。実際にコミュニティでも「Ingress v2」の可能性について真剣な議論が交わされていたようです。 しかし、最終的にそのアプローチが見送られたのには、大きく 2 つの理由がありました。
1. 「Ingress（入り口）」という概念の限界
そもそも「Ingress」という言葉は、外部から入ってくるトラフィックを指す言葉です。しかし、新しい API に期待されていた役割は、もっと広範なものでした。 HTTP/HTTPS に限らず、TCP や UDP、gRPC といった多様なプロトコルを扱いたい。さらには、将来的にサービスメッシュの制御も統合したい。 そう考えたとき、「Ingress」というリソース名や概念のまま機能を拡張していくのは、スコープとして狭すぎると判断されたようです。
2. 下位互換性の呪縛
これが決定的な理由だったようですが、前述した「アノテーション地獄」や「役割分担の曖昧さ」は、Ingress の構造そのものに起因する問題でした。 これらを根本的に解決しようとすると、既存の Ingress との互換性を維持することが非常に困難になります。「どうせ破壊的な変更が必要になるなら、既存のしがらみに囚われず、理想的な設計で作り直そう」というのが、開発者たちの決断でした。
「Service APIs」から「Gateway API」へ
こうして、Ingress の教訓を活かした新プロジェクトが立ち上がりました。
当初、このプロジェクトは 「Service APIs」 と名付けられていました。
しかし、「Kubernetes の Service リソースと名前が似ていて紛らわしい」というもっともな指摘を受け、2021 年頃に現在の 「Gateway API」 という名称に変更されたという経緯があります: 参考
Ingress の反省を活かし、Gateway API は最初から以下の点を重視して設計されています。
- 役割の分離: インフラ管理者とアプリ開発者が、それぞれ別のリソースを管理できる
- 移植性の確保: アノテーションに頼らず、高度な機能を標準仕様として盛り込む
- 拡張性: ベンダー独自の機能も、体系的に組み込めるようにする
ここからは、実際に Gateway API がどのようにこれらの課題を解決しているのか、その構造を見ていきたいと思います。
Gateway API の核心：「ロール指向設計」による解決
Gateway API の設計は、Ingress の失敗から学んだ教訓に基づき、公式ドキュメントでも示されている以下の 4 つの柱を中心に構築されました。
- ロール指向（Role-oriented）
- 表現力（Expressive）
- 拡張性（Extensible）
- 移植性（Portable）
ロールとリソースの分離：権限境界の明確化
Gateway API のもっとも革新的な成果は、Ingress 時代に混在していた権限と設定を、使用する人間の役割（ペルソナ）に合わせて別々のリソースに分割した「ロール指向設計」です。
公式ドキュメントでは、以下の 3 つのペルソナが定義されています。
| ペルソナ | 役割と責任 | 担当リソース |
|---|---|---|
| Ian (Infrastructure Provider) | ロードバランサーの種類を定義する | GatewayClass |
| Chihiro (Cluster Operator) | ネットワークの境界（ポート、TLS 証明書）をインスタンス化し、セキュリティを管理する | Gateway |
| Ana (Application Developer) | 自分のアプリケーションへのルーティングルールを定義する | HTTPRoute など |
この分離により、クラスタ管理者（Chihiro）がセキュリティを担保した Gateway リソースを設定できます。 アプリケーション開発者（Ana）はインフラの詳細を気にすることなく、HTTPRoute をその Gateway にアタッチ（接続）し、自律的にルーティング制御を行えるようになりました。
移植性の回復と表現力の向上
Ingress でアノテーションに頼らざるを得なかった高度な機能は、Gateway API では型付きフィールドとして標準化されました。 例えば、カナリアリリースに必要なトラフィック分割は、HTTPRoute リソース内で weight フィールドを使用して定義されます。これにより、ベンダーの実装に関わらず、同じ構文で同じ挙動が保証され、移植性が回復しました。
KubeCon Japan 2025 で見た、設計思想の成果
私が参加した KubeCon Japan 2025 のセッションでは、Gateway API の設計思想が、現代のクラウドネイティブのトレンドにいかに深く組み込まれているかが示されていました。 プラットフォーム開発に携わる立場として、今後のトラフィック制御の方向性を考えるうえで非常に参考になりました。
プラットフォームエンジニアリングの基盤として
KubeCon Japan 2025 のキーノートやセッションでは、プラットフォームエンジニアリングが重要なトピックとして取り上げられていました。プラットフォームエンジニアリングの目標は、開発者に対して複雑な技術を意識させない「自己サービス（Self-Service）」API を提供することです。 Gateway API のロール指向設計は、管理者が設定した安全な境界（Gateway）の上で、開発者がルーティング（HTTPRoute）を自律的に行える構造を提供し、ネットワーキングの分野での自己サービス化を実現するための基盤として機能します。
サービスメッシュへの「ユニバーサル言語」としての統合
Gateway API の汎用的な設計は、外部トラフィックだけでなく、クラスタ内のサービス間通信にも適用されています。これが GAMMA (Gateway API for Mesh Management and Administration) という取り組みです。 Lin Sun 氏によるキーノートでは、サイドカーを使用しない Ambient Mesh 環境において、Gateway API の HTTPRoute を使ってトラフィックシフトを行うデモが披露されました。HTTPRoute が外部公開用途だけでなく、サービスメッシュ内のルーティング設定にも利用できるということは、Gateway API がネットワーキングにおける「ユニバーサル言語」としての地位を確立しつつあることを具体的に示していると思いました。
まとめ
今回の調査を通じて、Gateway API が「なぜこのような設計になっているのか」を理解できました。
Ingress が抱えていたアノテーション地獄や役割混在の問題を、ロール指向設計によって解決しようとした背景を知ったことで、GatewayClass・Gateway・HTTPRoute というリソース分割の意図が腑に落ちました。
すぐに業務へ直結するわけではありませんが、プラットフォーム側で安全な境界を用意しつつ、各開発チームが自己サービス的にルーティングを定義できる世界観は、今後の社内基盤づくりにおいても重要なテーマになりそうです。
KubeCon Japan 2025 で得た気づきをきっかけに、こうした設計思想を学ぶことができ、プラットフォームエンジニアリングの視点を深める良い機会になりました。
最後に
プラットフォーム開発本部では、一緒に働く仲間を募集しています。 ご興味のある方はこちらへ！ dmm-corp.com
