Gateway API の現在地 〜これまでとこれから〜
この記事は Kubernetes Advent Calendar 2023 の 1 日目の記事です。
こんにちは。サイバーエージェントの青山（@amsy810）です。
2017 年から 12/1 の初日に記事を書き始め、早いもので 7 年目になりました。
2020/2021 年の、おうち Kubernetes のために Synology CSI に追加実装をしたりした話もネタとして面白いのでぜひ見てみてください。
今年は約 1 ヶ月前に GA した Gateway API の現在地、将来的に Gateway API がどう発展していきそうかについてお話ししたいと思います。
Gateway API の GA Release
Gateway API はこの記事執筆時点 12/1 の約一ヶ月前の 2023/10/31 に v1.0.0 で GA リリースされました。
GKE を利用しているユーザーは、もっと前に GA していたはずと思った方もいらっしゃるかもしれませんが、GA したものが異なります。 GKE では Gateway API をサポートする GKE Gateway Controller が提供されており、GKE Gateway Controller 自体は、API の GA よりもいち早く 2022/11 に GA しています。
今回 GA したのは Gateway API（Gateway / HTTPRoute / etc などのリソース）の方で、これにより基本的な仕様は大まかに固まったということになります。
Gateway API とは？
Gateway API では、Ingress で生じていた課題を解決することができるようになっています。 例えば、インフラ提供者・クラスタ運用者・アプリケーション開発者のそれぞれで、Ingress で設定を行いたい責務が異なります。Ingress ではクラスタ運用者とアプリケーション開発者の関心事に対する設定を単一の Ingress リソースで行っていましたが、Gateway API では Gateway・XXXRoute（HTTPRoute や TCPRoute）の複数のリソースで設定を行います。また、Namespace を跨いだ委譲なども可能な仕組みになっています。
- インフラ提供者
- 利用可能な Gateway 実装の設定（インストール）
- クラスタ運用者
- アプリケーション開発者
- パスベースのルーティング設定（特定のパス > 特定の Service）
- 加重ルーティングの設定
ここでは Gateway API の詳細については詳しくは説明しませんが、興味のある方は公式サイトのIntroductionを読んでみてください。
Gateway API のこれまでの歩み
Ingress に生じていた課題の精査、Gateway API が Ingress v2 として設計が始まった背景、そして現在の Gateway API の設計に至るまでの経緯については、KubeCon + CloudNativeCon NA 2023 の「Gateway API: The Most Collaborative API in Kubernetes History Is GA - Rob Scott, Google & Nick Young, Isovalent」でもまとめられているので、Gateway API の 4 年の Upstream の歴史について興味のある方は見てみると楽しめると思います。
なお、最初期は Ingress v2 として始まった Gateway API プロジェクトですが、Ingress 自体は今後も利用可能で、非推奨にする計画は現時点ではありません。Ingress は HTTP エンドポイントを公開するシンプルな仕組みとして残り続け、Gateway API は汎用的で高機能な仕組みとして提供される予定です。これは KubeCon などでも幾度となくメッセージとして伝えられていたものなので、現時点での信憑性はかなり高いものでしょう。
現時点で Gateway API に対応している実装
Gateway API が利用できる環境は公式サイトで公開されており、記事執筆時点でもかなり多くの実装が行われています。 パブリッククラウド環境の場合は、GKE は GA ステータスとなっていますが、EKS や AKS は preview や alpha ステータスとなっているため、利用には注意が必要です。
オンプレミス環境やパブリッククラウドにセルフデプロイする場合の選択肢としては、「Contour（beta）」「Envoy Gateway（beta）」「Cilium（beta）」などが適しています。Cilium は CNI Plugin のため、別の CNI Plugin を利用している Kubernetes クラスタでは追加でインストールして利用することなどもできないため注意してください。
また、Gateway API は、Service Mesh でも利用できるようになっています。Service Mesh における Gateway API 実装は、GAMMA (Gateway API for Mesh Management and Administration) initiative によって進められており、 v0.8.0 の時点で Experimental なステータスです。 そのため、やや Too much な構成としてはサービスメッシュ実装でもある「Istio（beta）」も選択肢としては挙げられます。
一方で、Ingress 実装として最もメジャーとも言える「ingress-nginx」の Gateway API 対応はされないのでしょうか？
ingress-nginx の Gateway API 対応について
kubernetes/ingress-nginx の Gateway API については、2021年ごろに Issue #7517 が建てられ始め、Gateway API の仕様成熟に伴い、実装に向かっています。
kubernetes/gateway-nginx のように新しいリポジトリで新しいものを実装するのではなく、同一リポジトリで両サポートする方向で実装が進められているため、将来的にはバージョンアップすることでIngressとGateway APIの両方が利用できるようになっていきそうです。
また、先日のKubeConであった「What's Happening with Ingress-Nginx! - James Strong, Chainguard & Ricardo Katz, VMware」のセッションでも、2024 年の計画として Gateway API への対応について言及されています。 Issueやセッションを見るとわかるのですが、ingress-nginxプロジェクトでは現在 Gateway API 実装の前段として、大幅な実装変更の前に優先度の高い「利用されていない機能の削除・リファクタリング」・セキュリティ対策のための「Controlplane（Kubernetes Controller） と Dataplane（Nginx）の分離」などが進められています。そのため、Gateway API 対応の実装が少し遅くなっている状況のようです。
Gateway API に関する機能強化 Gateway Enhancement Proposals（GEPs）
Gateway API に関する機能強化は、Gateway Enhancement Proposals（GEPs）によって管理されています。 Kubernetes に対する機能強化提案 Kubernetes Enhancement Proposals（KEPs）と類似したフローで管理されています。
将来的に追加が検討されている Experimental な GEPs には、下記のようなものが存在します。Experimental ステータスな GEPs はいくつかの実装がすでに用意されていることもあります。
- GEP-1016（Status = Experimental）
- GRPCRoute の追加
- GEP-1651（Status = Provisional）
- GEP-1742（Status = Experimental）
- HTTPRoute での timeout 設定の追加
- GEP-1867（Status = Experimental）
- GEP-2162（Status = Experimental）
- Gateway Controller がサポートしている機能セットを GatewayClass で列挙可能にする
Service の Gateway API への統合案
Kubernetes の共同創設者であり、現在もコアメンテナーを務める Tim Hockin 氏が KubeCon + CloudNativeCon NA 2023 で講演した LT 「Lightning Talk: Why Service Is the Worst API in Kubernetes, & What We’re Doing About It」では、Service リソースの問題点と、Gateway API を利用した変更案を紹介していました。 現状の Service リソースはさまざまな拡張が行われた結果、非常に多くの機能を持っており、かつ重要なコア API のため影響度が高く、改修が困難な状況になってしまっています。 Tim のこのセッションでは、Service を Pod をひとまとめにする抽象的な概念にする部分のみに機能を絞り、ClusterIP や LoadBalancer などの Pod に対する接続性を用意する部分は Gateway API で担うといった変更案をアイデアとして語られています。
Kubernetes を初めて触った時に、Service と Ingress や Service と Gateway API をみて、ロードバランサーを制御する API が 2 通りあり違和感を感じた方もいらっしゃるかと思います。 この改修が入ることによって、Service は Pod を抽象的にまとめるもの・Gateway API は接続性を担うものと責務の分離がされるとよりわかりやすいと感じる方もいるかと思います。
今回のセッションではいちアイデアとして語られていただけなので今後の方向性が確定しているわけではありませんが、Gateway API を通じて、また数年かけて最古の API の一つである Service の改修が進んでいくことも楽しみです。
まとめと今後
弊社ではプライベートクラウド上に独自の Kubernetes as a Service の AKE を提供しており、独自の Ingress Cont¥roller や Cloud Controller Manager を実装しています。そして Gateway API の GA に伴い、じきに Gateway Controller の実装も検討しています。今後は上記のような実装に関わりそうな GEPs のフィールド変更などを適切にウォッチしていくため、続報や実装時にはまた改めてブログにでもまとめさせていただきます。 なお、こうした仕事にご興味がある方がいらっしゃれば、ぜひ採用サイトを覗いてみてください。
