コンテンツに移動
Containers & Kubernetes

単一クラスタ デプロイ向け Google Kubernetes Engine Gateway Controller の一般提供を開始

2022年11月18日
https://storage.googleapis.com/gweb-cloudblog-publish/images/containers_2022_gIIPiF7.max-2500x2500.jpg
Google Cloud Japan Team

※この投稿は米国時間 2022 年 11 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

今年 7 月、Kubernetes コミュニティは Gateway API のベータ版への移行を発表しました。これは、このネットワーキング API の未来を担うグループのメンバーたちにとって大きな節目となりました。Gateway API は、GAMMA イニシアチブを介したサービス メッシュ機能により Kubernetes クラスタへの、さらにその先へのルーティング インテントを定義します。次世代の Ingress API であり、そのスコープはより広範で、対応可能なユースケースも増加しています。

本日、Google Kubernetes Engine(GKE)Gateway Controller の一般提供が開始されたことをお知らせします。これは Google Cloud が実装した Gateway API で、GKE 1.24 以上のクラスタでの単一クラスタ デプロイをサポートします。

Gateway API の基本情報

プラットフォーム運営事業者は、ネットワーク インフラストラクチャを使用する開発者に柔軟性をもたらすと同時に、チーム間の制御と一貫性を維持するという二重の課題に直面しています。

Kubernetes は、サービス ネットワーキングにオープンソースかつロールベースの標準を提供する Gateway API によって、サービス オーナーとプラットフォーム管理者の間での職掌分散の必要性を排除します。Kubernetes 実装全体、テナント間、Namespace 間でネットワーク サービスを一貫して記述する構造化された手法であり、ネットワーク リソースを適切なロールと一致させることができます。

以前は、サービス オーナーごとに使用する Ingress を独自に選択していましたが、使用できるソリューションの数が多いため、本番環境で不整合が発生することがありました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_gke_Gateway.max-2000x2000.jpg

Gateway API では、プラットフォーム管理者がネットワーク インフラストラクチャのポリシーと制約を定義でき、さまざまなチームまたは組織が共有ネットワーク サービス(L4 / L7 ロード バランシングなど)を使用する一方で、一貫性と制御を維持できるようにします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_gke_Gateway.max-1000x1000.jpg

GKE Gateway Controller

GKE Gateway Controller は、Google Cloud が実装した GKE クラスタ向け Gateway API です。GKE と緊密に統合されたフルマネージド サービスであり、プラットフォーム運営事業者が機能性と拡張性に優れた API を使用して内部および外部の HTTP(S) ロード バランシングを管理できるようにします。Google Cloud は、GKE Ingress コントローラを管理してきた長年の経験に基づき、Google Cloud インフラストラクチャの性能を活かしたコントローラを開発しました。このコントローラは、冗長性とスケーラビリティに優れたマルチテナントのサービスを提供し、一元化されたポリシーと制御によって単一および複数 GKE クラスタ デプロイ向けのロードバランサを管理します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_gke_Gateway.max-1000x1000.jpg

プラットフォーム管理者とサービス オーナー向けの高度な機能

Gateway API は柔軟性に優れ、問題を切り分けることができるため、GKE プラットフォーム管理者は安全な共有ロードバランサを GKE クラスタに接続でき、サービス オーナーがルーティングおよびトラフィック管理ポリシーを定義して、マルチテナント GKE クラスタで実行されている自身のアプリケーションにアクセスできるようにすることが可能です。

Gateway API と GKE を併用することで、プラットフォーム管理者とサービス オーナーは以下の機能を活用できます。

多数のルート / テナント向けの共有 Gateway - Ingress 実装に関して多くのお客様から報告された問題点の一つに、Namespace の増加に応じてクラスタが大きくなることで、ロードバランサが急増してしまうというものがありました。1 つのクラスタに単一の Gateway を定義することで、クラスタ全体に単一の共有ロードバランサが作成され、アプリケーション チームそれぞれが Namespace の予測ルーティング動作を示す独自の Route を定義できます。各 Route は Gateway に接続されます。これにより、Namespace ごとの Kubernetes 構成の分散的な性質を損なうことなく、転送に関する決定を中心的な要素として維持できます。

グローバル外部およびリージョン内部のロード バランシング - GKE Gateway Controller にはデフォルトで 2 つの GatewayClass があります。グローバル外部 HTTP(S) ロードバランサ(クラシック)向けのもの(gke-l7-gxlb)と、リージョン内部 HTTP(S) ロードバランサ向けのもの(gke-l7-rilb)です。各 GatewayClass を同じ GKE クラスタ内で個別に使用して、インターネットから、または VPC 内にある内部リソースあるいは VPC に接続された内部リソースからトラフィックを転送できます。

広範囲でのエンドツーエンドの暗号化 - Gateway API は、クライアントとゲートウェイの間で、またゲートウェイとバックエンド サービスの間で安全な接続を実現するための TLS の実装方法を定義します。GKE Gateway Controller はダウンストリームとアップストリームのトラフィック向けの TLS をサポートするだけでなく、Certificate Manager との統合により、GKE で実行されているアプリケーションに最大 100 万の証明書を提供することで、かつてないほど広範囲でのサポートを実現しています。Google が管理する SSL 証明書または Kubernetes シークレットも、クライアントと Gateway 間の接続を保護するための代替オプションとして使用できます。アップストリームのトラフィック(Gateway とバックエンド サービスの間)に関しては、TLS を使用してクライアントとバックエンド サービスの間でのエンドツーエンドの暗号化を確実に行うこともできます。

バックエンド サービスのプロパティのカスタマイズ - 多くのお客様が、ロード バランシングに関して特定のニーズを抱えています。特に、バックエンド サービスでセッションを維持する手法やカスタム ヘルスチェックに関するニーズがよくあります。シンプルなポリシーを Service に接続することで、セッション アフィニティやコネクション ドレインのタイムアウトへの対処方法と、異なるポートまたはパスを必要とするアプリケーションのカスタム ヘルスチェックを定義できます。

高度なトラフィック管理 - Google Cloud が実装した Gateway API では、クライアントからアプリケーションへのトラフィックの処理方法も定義できます。まず、Ingress には欠けていた機能、Namespace をまたがるルーティングを使用できます。さらに、Google Cloud のロードバランサが提供する豊富な機能を利用することで、GKE から直接、トラフィック分割またはカナリア デプロイを使用して新しいバージョンのサービスを段階的にロールアウトできます。バックエンド サービスのプロパティと組み合わせることで、バージョン間の移行を実現する非常に柔軟なツールとなります。

クラスタにデプロイされたさまざまなサービスで、Kubernetes Gateway API がトラフィック分割をどのように簡素化するのか、図で確認してみましょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_gke_Gateway.0896043415910586.max-1500x1500.jpg

このシンプルなトラフィック分割の例では、内部ロードバランサを介して store.example.com に転送されたトラフィックの 90% が store-v1 サービスに送信され、10% が store-v2 サービスに送られています。

この処理は、以下のマニフェストを使用するだけで簡単に実行できます。

読み込んでいます...

今後の展望

単一クラスタ デプロイ向け GKE Gateway Controller の一般提供開始は、GKE を使用するプラットフォーム管理者とサービス オーナーのための真のネットワーキング ツールキット作成への道のりの第一歩にすぎません。現在、以下のようなその他の機能の開発に取り組んでいます。

マルチクラスタ Gateway

今後数か月間は、単一のクラスタだけでなくマルチクラスタ環境にも Gateway と Route をデプロイできるように、コントローラの土台固めを継続します(現在はプレビュー)。GKE クラスタのフリート全体でマルチクラスタ Gateway を使用することで、以下のような新しいユースケースに対応できるようになります。

  • マルチクラスタまたはマルチリージョンの冗長性とフェイルオーバー

  • クライアントに近接している GKE クラスタを使用した、低レイテンシでのサービス提供

  • クラスタ間での Blue / Green トラフィック シフト(こちらのチュートリアルをお試しください)

  • 組織上またはセキュリティ上の制約による複数クラスタへの拡張

マルチクラスタ Gateway とマルチクラスタ Service の併用は、クラスタ間でのトラフィックの転送方法を制御したままアプリケーションの可用性を高めたいと望む、グローバル サービスをデプロイするお客様にとって大きな前進となります。

次世代の Google Cloud ロードバランサ

本投稿で前述したように、GKE Gateway Controller にはデフォルトで 2 つのゲートウェイ クラスがあります。外部ロード バランシング向けのものと、内部ロード バランシング向けのものです。Google Cloud は最近、Envoy プロキシに基づく次世代のグローバル外部 HTTP(S) ロードバランサの一般提供を発表しました。新しい GatewayClass は間もなく GKE Gateway Controller で利用できるようになり、高度なトラフィック管理機能を備えた、この新しいロード バランシング プラットフォームをサポートします。GKE のこれらの新しいロードバランサで皆様が構築されるサービスを楽しみにしております。

セキュリティ 

インターネットにサービスを公開する際に一番に頭に思い浮かぶことの一つは、プラットフォームと公開するアプリケーションをどのように保護すべきかという点です。基盤となるインフラストラクチャ(GKE ノード)の保護は明らかに必須であり、GKE Gateway Controller が特定の Gateway のクラウド ファイアウォール ライフサイクルを管理することによって対処しますが、セキュリティはさまざまなレベルで取り組むべき多次元の問題です。Gateway とコントローラが提供する既存のセキュリティ機能に加えて、アプリケーションのセキュリティ強化のための取り組みも続けており、SSL ポリシーHTTP リダイレクトIdentity-Aware Proxy(IAP)、Cloud Armor などの追加のセキュリティ機能も提供する予定です。

次のステップ

GKE ネットワーキングの世界では、さまざまな取り組みが進行中です。Google Cloud は KubeCon North America で 35 以上のセッションを開催しました。以下は、Kubernetes ネットワーキングについて取り上げたセッションの一部です。

Kubernetes ネットワーキングについてさらに詳しくは、以下を参照してください。


- GKE ネットワーキング担当プロダクト マネージャー Pierre-Louis Gingembre
- GKE ネットワーキング担当アウトバウンド プロダクト マネージャー Susan Wu

投稿先