Kubernetes の Ingress の次世代仕様として Gateway API が登場しています。
ただし公式ドキュメントを読んでも：
- 何が変わったのか
- どこが嬉しいのか
- Ingress と何が違うのか
が分かりにくいのも事実です。
この記事では、Traefik を Gateway Controller として使い、最小構成の Gateway API を実際に動かしながら理解します。
この記事でやること
次の構成を実際に作ります：
ブラウザ
↓
Traefik (Gateway Controller)
↓
Gateway
↓
HTTPRoute
↓
Service
↓
Pod (nginx)
つまり：
Gateway API の最小通信経路を構築する
のが目的です。
Gateway API とは何か（Ingress との違い）
まず結論から：
| 項目 | Ingress | Gateway API |
|---|---|---|
| 設計思想 | 単一リソース | 役割分離モデル |
| controller依存 | 強い | 弱い |
| L4対応 | × | ○ |
| namespace分離 | 弱い | 強い |
| マルチテナント | 弱い | 強い |
Ingress：
Ingress
└ routing全部まとめて定義
Gateway API：
GatewayClass
Gateway
HTTPRoute
責任が分離されています。
Gateway API の構造
Gateway API は次の3つが基本です。
GatewayClass
どの controller が処理するかを決めます
例：
controllerName: traefik.io/gateway-controller
意味：
「この Gateway は Traefik が処理する」
Gateway
クラスタの入口を定義します
例：
listeners:
- name: http
port: 80
protocol: HTTP
これは infra 管理者の責任です。
HTTPRoute
どの Service に送るか定義します
例：
backendRefs:
- name: app-svc
port: 80
これはアプリ開発者の責任です。
今回の環境
今回は Traefik を Gateway Controller として使用します。
すでに Traefik がクラスタに存在する前提です。
確認：
kubectl get gatewayclass
例：
NAME CONTROLLER
traefik traefik.io/gateway-controller
Gateway を作成する
demo-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: demo-gateway
spec:
gatewayClassName: traefik
listeners:
- name: http
port: 80
protocol: HTTP
適用：
kubectl apply -f demo-gateway.yaml
確認：
kubectl get gateway
期待結果：
NAME CLASS ADDRESS PROGRAMMED
demo-gateway traefik True
nginx Pod を用意する
kubectl create deployment app --image=nginx
Service を作成：
kubectl expose deployment app --port=80 --name=app-svc
確認：
kubectl get svc
HTTPRoute を作成する
demo-route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: demo-route
spec:
parentRefs:
- name: demo-gateway
rules:
- backendRefs:
- name: app-svc
port: 80
適用：
kubectl apply -f demo-route.yaml
確認：
kubectl get httproute
Traefik にアクセスする
Service を port-forward します：
kubectl port-forward -n kube-system svc/traefik 8000:80
ブラウザ：
http://localhost:8000
nginx の画面が表示されれば成功です。
例：
Server address: 10.42.0.45:80
Server name: app-xxxxx
これは：
Gateway
↓
HTTPRoute
↓
Service
↓
Pod
が正しく接続された証拠です。
確認環境
上記の結果は、macOS(Tahoe 26.3)上のRancher Desktop(Version 1.22.0)を用いて確認しました。
この構成で何が確認できたのか
今回確認できたのは：
| コンポーネント | 状態 |
|---|---|
| GatewayClass | controller登録済 |
| Gateway | listener作成成功 |
| HTTPRoute | Gatewayにattach成功 |
| Service | backend解決成功 |
| Pod | routing成功 |
つまり：
Gateway API の最小構成が成立しました。
Ingress と何が本質的に違うのか
Ingress：
入口定義
routing
backend
TLS
全部1つのリソースに入っています。
Gateway API：
GatewayClass → controller
Gateway → 入口
HTTPRoute → routing
Service → backend
責任が分離されています。
なぜ責任分離が重要なのか
例えば Platform Engineering では：
| 役割 | 管理対象 |
|---|---|
| platform team | GatewayClass |
| infra team | Gateway |
| application team | HTTPRoute |
という運用ができます。
Ingress では難しい構造です。
namespace をまたいだ共有ができる
Gateway API の強みの一つです。
infra namespace
└ Gateway
team-a namespace
└ HTTPRoute
team-b namespace
└ HTTPRoute
同じ入口を複数チームで安全に共有できます。
L4 routing にも対応している
Ingress：
HTTPのみ
Gateway API：
HTTPRoute
TCPRoute
UDPRoute
TLSRoute
GRPCRoute
AI / Edge / IoT では重要な機能です。
まとめ
今回構築した構成：
GatewayClass
↓
Gateway
↓
HTTPRoute
↓
Service
↓
Pod
これは Gateway API の最小動作確認として理想的な構成です。
Ingress との最大の違いは：
routing設定ではなく責任分離モデルになった
点です。
次回予告
次の記事では：
/app1/app2
のように 複数HTTPRouteを1つのGatewayで共有 する構成を作ります。
これにより：
なぜ Gateway API がマルチテナント向けなのか
が理解できるようになります。