Kubernetesの新しいネットワーク機能、Gateway APIを理解する（後編）

前編ではKubeCon EUで行われたセッションとGoogleが公開しているGateway APIを解説する動画を使って、Ingressに替わる新しいネットワーク機能、Gateway APIを解説した。

Kubernetesの新しいネットワーク機能、Gateway APIを理解する（前編）

後編となる本稿では、KongのVictor Gamov氏が行った「Understanding the new Kubernetes Gateway API vs Ingress」と題されたセッションを取り上げる。この動画はCloud Native Computing Foundation（CNCF）の公式チャネルで公開されたものだ。Kubernetesはクラウドネイティブなシステムのコアとなるわけだが、そのロードバランサー機能を受け持つIngressの置き換えとなる機能を提供するGateway APIについてデモを交えて紹介するものだ。

動画：Understanding the new Kubernetes Gateway API vs Ingress

セッションを担当したのはKongのPrincipal Developer AdvocateであるViktor Gamov氏だ。ちなみにKongはNGINXをベースにしたAPI Gatewayを開発提供しているベンチャー企業だが、今回のGateway APIはKubernetesのNetwork SIGで開発されたIngressに替わるKubernetes純正の新しいネットワークのリソースだ。このリソースにはGatewayClass、Gateway、HTTPRoute、TCPRouteなどが定義され、アプリケーションの実体となるServiceと接続されることになる。リソースの実装はそれぞれのベンダーやオープンソースプロジェクトに任せられ、各種の実装が存在することになる。またGatewayからの通信もHTTP、TCP以外にも別のプロトコルやルーティングが実装できるようなオープンな仕様となっている。

プレゼンテーションを行うGamov氏

これまでのKubernetesにおけるネットワーク、特にNorth-Southと呼ばれる外部との通信は、Ingressと呼ばれるリソースによって主にロードバランサーとして利用されてきた。しかしアプリケーションへのアクセスが増え、実行されるサービス（Pod）が増えることによって複数のノードで同じようなロードバランサーが実行される状態から、Proxyを立てて通信の制御を行う必要が出てくると解説。

単一のロードバランサーをProxyで束ねる形に移行

その結果、例えばBillsというビリングのためのサービスにアクセスするためには/billsというパスを付けてアクセスを行うという例を、Ingressのマニフェストを見せて具体的な設定の例を解説した。

Ingressのマニフェストを使って解説

ここから新しいGateway APIの概要を解説した。Ingressが担っている機能についても触れ、外部からの接点として使われる以外にロードバランシング、カナリアデプロイメント、トラフィック分配などの機能を持っていることを紹介した。

Ingressの受け持つネットワーク機能の概要

その上でGateway APIの基本的な構造を紹介した。ここではインフラストラクチャー管理者が提供するGatewayClass、クラスター管理者が提供するGateway、そしてデベロッパーが設定するRouteについて解説した。それぞれのリソースを3者に分割することで、機能と責任を分離しようという意図を感じる構成だ。

Gateway APIリソースの構造。3つに分割されている

またKubernetesの特徴でもあるネームスペースについても、ロールベースのアプリケーション管理に適したトラフィック制御が可能であると説明した。この特徴についてはGateway APIの公式ページにおいても強調されている。以下は公式ページの引用だが、ロール指向（Role-Oriented）、移植可能（Portable）、明示的（Expressive）そして拡張可能（Extensible）であることが挙げられている。

Gateway APIの特徴

公式ページ：Kubernetes Gateway API

これ以降はデモを見せながら解説を行うフェーズになったが、その前にチャットによる質問に答えていた。「どうしてGateway APIという名前になったのか？」という質問に対して「Kubernetes自体がAPI Serverを中心とした構造になっており、APIを使うことで連携するから」と回答していたが、その後に「以前はService APIと呼ばれていたが、KubernetesではServiceという名称が余りに多く使われているので、誤解を避けるため」とも答えていた。実際にServiceがアプリケーションを指しているとすれば、その上位に位置するIngressの代替として機能を分割する発想であるこの新しいリソースがGateway APIと名乗るのは妥当なことだろう。

デモではKongが公開しているデモアプリケーションの中からKong（NGINX）をIngress Controllerとして使用した。バックトゥザフューチャーの台詞を引用するアプリケーションとチャックノリスの台詞を引用するアプリケーションをKubernetes上にデプロイし、パスやヘッダーの情報によって使いわけるというアプリケーションの設定などを紹介した。デモで使用されたコードは以下のGitHubリポジトリーを参照されたい。

Kongのデモアプリケーション：https://github.com/Kong/demo-scene/tree/main/quotes-service

また後半ではEnvoyをベースに開発されたKumaというサービスメッシュのためのソフトウェアを使って、KongのIngress ControllerとKumaベースのサービスメッシュの2つを同時にデプロイするというデモを行っている。ここではGateway APIのポータビリティが示されていると言えるだろう。

サービスメッシュのKumaをインストール

デモの中でKumaのダッシュボードで実際に稼働している2つのアプリケーションを確認している。

Kumaのダッシュボードでクラスターの中身を参照

Gamov氏のセッションは、ある程度Gateway APIを理解した上でIngressに足らない機能をKubernetesのリソースとして提供するGateway APIを実際に使いながら解説するという内容だ。動画は51分という長さだが、16分辺りから始まるデモを見るだけでもマニフェストと実装の関係やトラフィック制御の具体例などを知ることができる。

またKubernetesのクラスターを操作するCLIとしてK9sというツールが多用されているが、ここでは特に説明されていない。K9sについては別記事で解説することとしよう。

K9s公式ページ：https://k9scli.io/