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

連載 :

イベント・セミナー2022

2022年6月16日(木)

ubernetesのIngressに替わる新しいネットワーク機能、Gateway APIを解説する。

Cloud Native Computing Foundantion（CNCF）は、API Gatewayをサービスとして提供する新しいネットワーク機能であるGateway APIに関する動画を公開した。これは「Understanding the new Kubernetes Gateway API vs Ingress」というタイトルの動画で、外部からのアクセスを最初に受け取るタスクを担当するGateway APIを、これまで使われてきたIngressと比較しながらデモを使って解説する内容となっている。解説を担当しているのは、Kongのエンジニアだ。

動画：Understanding the new Kubernetes Gateway API vs Ingress Tech Talk

このGateway APIを理解するには「そもそもどうしてGateway APIが誕生したのか？」という背景と、基本的な機能をあらかじめ理解しておく必要がある。そこで今回の記事では、2021年5月にKubeCon EU Virtualで解説された「Gateway API: A New Set of Kubernetes APIs for Advanced Traffic Routing」というセッションから紹介しよう。これはKongのHarry Bagdi氏とGoogleのRob Scott氏が行ったセッションである。

KubeCon EU 2021のGateway APIのセッション動画：Gateway API: A New Set of Kubernetes APIs for Advanced Traffic Routing - Harry Bagdi & Rob Scott

そして次回の記事でKongがIngress Controllerとの違いを解説したセッションを紹介する。

ちなみにGateway APIは、以前はService APIと呼ばれていたAPIで、これまでNetwork SIG（Special Interest Group）で議論されていた。しかしKubernetesでは「サービス」という名称が頻繁に使われていることから、区別を付けるために改名されたという。

Gateway APIをKongとGoogleのエンジニアが解説

そもそもGateway APIに関する議論が実際に始まったのは、2019年のKubeCon NA（サンディエゴ）からである。その理由は、KubernetesのネットワークのモジュールであるIngress Controllerが、シンプルな利用方法しか想定していないことから、現実的な運用方法に合う機能を実装しようというものだ。

Ingressでは実用に耐えないということで議論が始まったGateway API

IngressがHTTPのトラフィックを分散させるロードバランサーといったシンプルな使われ方だけならばそのままでも良かったのだろうが、実際にはさまざまなユースケースがあり、機能が不足していたということだろう。このスライドで「Day 2 Operations」と書かれているのは、ロードバランサーをデプロイするだけではなく、より多くの機能が要求される場合にも対応できるようにIngressを置き換える形でGateway APIが実装されることを意味している。

機能拡張のニーズを満たすためのGateway API

そのために単に新しいAPIを作るだけではなく、ゲートウェイのテンプレートとなるGatewayClass、実体であるGateway、アプリケーションからの要求を実装するRouteという3つに分離させていることに注目したい。

3層に分離されたGateway APIのリソースモデル

ここではインフラストラクチャーを管理するAlice、クラスターを運用管理するBob、アプリケーションデベロッパーのCarolという3者を登場させて、それぞれのDay 2 Operationを例に挙げて説明している。インフラストラクチャー管理者であるAliceはこれまでのロードバランサーから新しいベンダーが提供する別のソフトウェアを別にデプロイしたい、クラスターを管理するBobは新しいバージョンのロードバランサーを試したい、そしてアプリケーションデベロッパーのCarolはアプリケーションの新しいバージョンのためのカナリアデプロイメントを実装したい。3者それぞれの思惑をこれまでのIngressで実装しようとすれば、かなり複雑な構成をシンプルなIngressの構成で乗り切ることになる。そのためにGatewayClass、Gateway、HTTPRoute、TCPRouteというように分離したというのが構成上のポイントだ。

ではこれまでのIngressとはどの程度、重複しているのだろうか？という疑問が湧くだろう。それについてはGoogleが公開している5分程度の動画を参考にして欲しい。これは2021年4月16日に公開された動画で、5分ほどでGateway APIの概略を紹介している。

Google Open Sourceの動画：The Kubernetes Gateway API: Introduction

比較のためにIngressの構成を紹介

このスライドでは、Ingressの設定ファイルでfoo.example.comにアクセスする場合とfoo.example.com/v2にアクセスする場合で呼ばれるサービスが異なるというケースを説明している。これはHTTPにおけるパスによるマッチングとなる。

Gateway APIがカバーする機能とは？

それを踏まえて、新しいGateway APIではHTTPのヘッダーの値をベースにしたマッチングやトラフィックの配分を変えることなどがKubernetesのネイティブのAPIで可能になるという。

ここではコアがIngressと同じ機能を実装し、Extendedという部分で拡張機能を実装することを定義している。またgRPCなどの別のプロトコルに対するルーティングなども、Customという領域で実装することが可能であるという。このコア、拡張、カスタムという領域を定義することで、さまざまなベンダーやOSSプロジェクトがAPIに従ってソフトウェアを開発することが可能になるわけだ。

インフラストラクチャープロバイダー、プラットフォーム管理者、アプリケーションデベロッパーと役割を分割

このスライドでは、Kubernetesが運用されるインフラストラクチャー管理者とアプリケーションデベロッパーという役割だけではなく、中間にクラスターの運用管理者を追加することでインフラストラクチャーとアプリケーションの距離を離すことを意図していると思われる。その結果としてアプリケーションデベロッパーの負担を減らそうという発想だろう。

CNCFのセッションに戻って説明を続けよう。

Gateway APIの設計ゴールとは

このスライドではGateway APIの設計ゴールについて解説している。ロールオリエンテッドというのは、インフラストラクチャー、クラスター、アプリケーションという層に分割してそれぞれの役割に合った設定を行えることを目指している。ポータブルというのはAPIの仕様に準拠していれば入れ替えが可能であること、拡張可能な境界を明確に定義することなどが挙げられている。

コア、拡張、カスタムの包含関係を解説

またルートについてはGatewayから複数のRouteが定義可能となっており、HTTP以外のプロトコルやカスタマイズが必要なユースケースにも対応できるような仕組みになっていることを説明した。

Routeのタイプを紹介

またGatewayとRouteについては、お互いが定義＆参照する2方向からのハンドシェイクで定義されることを解説した。

GatewayとRouteの定義は双方向で行う

ここでシンプルなままのIngressと拡張を可能にするGateway APIの関係について、Ingressはなくならないこと、そしてGateway APIがIngressにも取り込まれる可能性があることなどを説明した。しかしIngressの機能を包含して進化していくのがGateway APIだとすれば、現行のIngressを利用しているシステムについてはどこかのタイミングでGateway APIへの乗り換えを考えるべきだろう。