IstioにおけるGateway APIサポートの拡張

本日、私たちはKubernetes SIG NetworkコミュニティによるGateway API仕様のベータリリースを祝福したいと思います。このマイルストーンと同時に、IstioイングレスにおけるGateway APIの使用サポートがベータ版に昇格されたこと、そして将来的にGateway APIをすべてのIstioトラフィック管理のデフォルトAPIにすることを目指していることを発表できることを嬉しく思っています。また、Service Mesh Interface (SMI)コミュニティの皆様を歓迎できることを嬉しく思っています。彼らは、Gateway APIを使用してサービスメッシュのユースケースを標準化する新しい取り組みにおいて、私たちに加わってくれています。

Istioのトラフィック管理APIの歴史

API設計は科学というよりも芸術であり、Istioはしばしば他のAPIの提供を構成するためのAPIとして使用されます！トラフィックルーティングだけでも、プロデューサー対コンシューマー、ルーティング対ポストルーティング、そして複雑な機能セットを適切な数のオブジェクトでどのように表現するかを考慮する必要があります。これらは異なるチームによって所有されていることを考慮に入れる必要があります。

2017年にIstioを立ち上げたとき、私たちはGoogleの生産API提供インフラストラクチャとIBMのAmalgam8プロジェクトからの長年の経験を活かし、Kubernetesにマッピングしました。すぐにKubernetesのIngress APIの限界にぶつかりました。すべてのプロキシ実装をサポートしたいという願望から、Ingressは最も基本的なHTTPルーティング機能しかサポートしておらず、他の機能は多くの場合、ベンダー固有の注釈として実装されていました。Ingress APIは、インフラストラクチャ管理者（「ロードバランサーの作成と構成」）、クラスタオペレーター（「ドメイン全体のTLS証明書を管理する」）、アプリケーションユーザー（「/fooをfooサービスにルーティングする」）の間で共有されていました。

ユーザーのフィードバックに対応し、これらの懸念事項をより適切に解決するために、2018年初頭にトラフィックAPIを書き直しました。

Istioの新しいモデルの主要な機能の1つは、インフラストラクチャ（ロードバランサー、Gatewayで表される）とアプリケーション（ルーティングとポストルーティング、VirtualServiceとDestinationRuleで表される）を記述する個別のAPIを持つことでした。

Ingressは異なる実装間の最小公分母としてうまく機能しましたが、その欠点から、SIG Networkは「バージョン2」の設計を調査しました。2018年のユーザー調査の後、IstioのトラフィックAPIを大部分に基づいて、2019年に新しいAPIの提案が行われました。その取り組みは「Gateway API」として知られるようになりました。

Gateway APIは、より多くのユースケースをモデル化でき、実装間で異なる機能を有効にする拡張ポイントを備えて構築されました。さらに、Gateway APIを採用することで、サービスメッシュはそれをサポートするために記述されたソフトウェア全体のエコシステムとの互換性を得ます。ベンダーにIstioルーティングを直接サポートするように依頼する必要はありません。必要なのはGateway APIオブジェクトを作成することだけで、Istioはすぐに必要なことを実行します。

IstioにおけるGateway APIのサポート

Istioは2020年11月にGateway APIのサポートを追加し、API実装とともにアルファ版としてマークされました。API仕様のベータリリースに伴い、Istioでのイングレス使用のサポートがベータ版に昇格されたことを発表できることを嬉しく思っています。また、メッシュ（サービス間）の使用にGateway APIを試すことを早期導入ユーザーに推奨しており、SIG Networkが必要なセマンティクスを標準化したら、そのサポートをベータ版に移行します。

APIのv1リリースの頃には、Gateway APIをIstioですべてのトラフィックルーティング（イングレス（南北）とサービス間（東西））を構成するためのデフォルトの方法にする予定です。その時点で、ドキュメントと例を推奨事項に合わせて変更します。

KubernetesがGateway APIが安定した後も長年にわたってIngress APIをサポートすることを意図しているのと同様に、Istio API（Gateway、VirtualService、DestinationRule）は今後も見込まれる限りサポートされます。

それだけでなく、既存のIstioトラフィックAPIをGateway APIと併用して使用できます。たとえば、Istio VirtualServiceでHTTPRouteを使用できます。

API間の類似性から、Istio APIオブジェクトをGateway APIオブジェクトに簡単に変換できるツールを提供でき、APIのv1バージョンと一緒にリリースします。

ポリシーやテレメトリなど、Istio機能の他の部分は、これらのユースケースの標準化についてSIG Networkと連携する間、Istio固有のAPIを使用して構成され続けます。

SMIコミュニティをGateway APIプロジェクトへ歓迎

設計と実装を通して、IstioチームのメンバーはSIG Networkのメンバーと協力してGateway APIの実装に取り組み、APIがメッシュのユースケースに適していることを確認してきました。

Linkerd、Consul、Open Service Meshのリーダーを含むService Mesh Interface (SMI)コミュニティのメンバーが、この取り組みへの正式な参加を決定し、APIの取り組みをGateway APIで標準化することにしたことを嬉しく思っています。その目的で、Gateway APIプロジェクト内にGateway API Mesh Management and Administration (GAMMA)ワークストリームを設立しました。Istio技術監視委員会のメンバーであり、当社のNetworking WGのリーダーでもあるJohn Howardがこのグループのリーダーを務めます。

私たちの次のステップは、メッシュのユースケースをサポートするために、Gateway APIプロジェクトに機能強化提案を提供することです。メッシュトラフィック管理のAPIセマンティクスを調査し始め、プロジェクトでGateway APIを実装するベンダーやコミュニティと協力して、標準実装に基づいて構築します。その後、承認と認証ポリシーの表現を構築する予定です。

サービスメッシュコミュニティが同じセマンティクスを使用してGateway APIを実装することを保証するためのベンダーニュートラルなフォーラムとしてSIG Networkがあることで、テクノロジースタックやプロキシに関係なく、すべてのプロジェクトで機能する標準APIを持つことを期待しています。