一般提供開始となったマルチクラスタ Gateway Controller を使用して GKE フリートへの上り（内向き）トラフィックを管理
Google Cloud Japan Team
※この投稿は米国時間 2023 年 11 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。
分散アプリケーションの構築は、Google Kubernetes Engine（GKE）を利用する多くの企業にとって今や主流となっています。過去数年間で Google は、クラスタのフリートの管理において、GKE ユーザーを支援する機能をリリースし、マルチクラスタ Ingress（南北トラフィック）やマルチクラスタ Service（東西トラフィック）を提供してきました。
同時に、Kubernetes コミュニティは、宣言型で拡張可能、ロール指向、ポータブルな Service Networking API である Gateway API を作成しました。Google は、2022 年 12 月に単一クラスタ GKE デプロイ向けの Kubernetes Gateway API の最初の実装を発表しました。
本日、GKE マルチクラスタ Gateway Controller の一般提供が開始されたことをお知らせします。この GKE マルチクラスタ Gateway Controller は、Kubernetes Gateway API を使用して、GKE クラスタのフリートに、統合されたアプリケーション ロードバランサをデプロイすることをネイティブにサポートします。これにより GKE ショップは、アプリケーション ロードバランサに統合された高度なセキュリティ機能により、最も貴重な資産を保護しながら、Blue/Green デプロイや地理的分散アプリケーションなどの洗練されたパターンを実装できます。
GKE マルチクラスタ Gateway Controller とは何か？
GKE Gateway Controller は、Google が Cloud Load Balancing に実装した Gateway API です。他の Kubernetes Controller と同様に Gateway Controller は、Gateway API リソースを監視し、Cloud Load Balancing のマネージド リソースを作成して、Gateway リソースで指定されたネットワーク動作を実装します。
マルチクラスタ Gateway Controller は、Google がホストするマルチテナントのコントローラです。GKE コントロール プレーンノードでは動作せず、Google Cloud の大規模かつ分散されたインフラストラクチャを利用することで、高い可用性と堅牢性を実現しています。
マルチクラスタ Gateway を使ってみる
マルチクラスタ Gateway は、今日のアプリケーションの可用性要件に対応するために複数のクラスタ（マルチクラスタ Service）にデプロイされたサービスを参照するという点を除けば、単一クラスタ Gateway と基本的に違いはありません。
顧客にサービスを提供するための十分な容量を確保したい場合や、Blue/Green デプロイを使用して複数のチームにインフラストラクチャを提供したい場合、リージョン内でダウンタイムが発生した際もアプリケーションを稼働させ続けたい場合など、マルチクラスタ Gateway と Service はアプリケーション インフラストラクチャの設計に不可欠な要素です。
マルチクラスタ Gateway は、GKE Enterprise エディションに追加費用なしで含まれており、GKE Standard エディションをご利用のお客様もスタンドアロン ソリューションとしてご利用いただけます。どちらのエディションでも、GKE Autopilot および GKE Standard クラスタでマルチクラスタ Gateway を利用できます。
サポートされるクラウド ロードバランサ
Google Cloud 内では、Gateway API リソースによって、Cloud Load Balancing の詳細情報を抽象化し、Kubernetes ネイティブの言語を使って一つまたは複数のアプリケーションに対するルーティング インテントを設定できます。
現在、マルチクラスタ Gateway は次のアプリケーション ロードバランサをサポートしており、さまざまなユースケースでお客様を支援しています。
GatewayClass の各機能の詳細については、こちらのガイドをご覧ください。
GKE フリートにおいてグローバルおよびリージョンのルーティングを最適化
Gateway API の利点の一つは、ルーティングとトラフィック管理におけるその表現力であり、Google による実装も例外ではありません。重みやルートルールのフィルタなど、バックエンド属性を使用して、特定の HTTP のパスやヘッダーにマッチするよう Gateway をカスタマイズし、複数のクラスタやリージョンで実行されているバックエンドのリストに洗練されたルーティング ポリシーを適用することができます。
クラウド ロードバランサの機能を活用することで、GKE のプラットフォーム管理者は、アプリケーションチームに対し、より高い可用性でより効果的なサービスを実現する一連のトラフィック管理機能を提供できます。いくつかの例をご紹介します。
段階的なロールアウト（Blue/Green アップグレードまたはデプロイ）
プラットフォーム チームは、新しいクラスタ上での新しい GKE バージョンの動作を確認し、ワークロードとサービスを徐々に新しいクラスタに移行して、いわゆる Blue/Green アップグレードを実行します。複数のクラスタにまたがるトラフィック分割を使用することで、オペレーションが大幅に簡素化され、プラットフォーム チームとアプリケーション チームが GKE アップグレードをスムーズに行うことができます。
アプリケーション チームもマルチクラスタ アーキテクチャを利用し、アプリケーションの新しいバージョンのリリースに Blue/Green デプロイ戦略を使用できます。アプリケーションのバージョン 1 は「ブルー」クラスタ上で実行し、バージョン 2 は「グリーン」クラスタ上で実行します。アプリケーション チームは、アプリケーションが新しいバージョンに完全に移行するまでの間、特定のパスやヘッダーに基づいて、v1 と v2 のトラフィックの切り替えを行えます。
また、アプリケーション チームが最初のクラスタで稼働しているサービスに送られたトラフィックを別のクラスタにミラーリングする必要がある場合（コンプライアンス上の理由、クライアントのトラフィックの分析やトラブルシューティングのためなど）、マルチクラスタ Gateway を使用して、そのトラフィックをミラーリングし、本番環境クラスタと「監査」クラスタに同時に送信することができます。
これらの機能は、クラスタが同じリージョンの異なるゾーンにデプロイされていても、複数のリージョンにデプロイされていても、リージョンおよびグローバルのマルチクラスタ Gateway で利用可能です。
近接ルーティングを持つ分散アプリケーション
複数のリージョンで分散アプリケーションを運用しているお客様は、エニーキャスト IP を使用するグローバルの外部マルチクラスタ Gateway により、クライアントから最も近い Google エッジ ポイント オブ プレゼンス（PoP）にクライアントのトラフィックを誘導し、フリート内のどのクラスタからでもアクセス可能な最も近いリージョンのバックエンドにトラフィックを送信できます。
トラフィックをリージョン内に留める必要がある規制地域のお客様は、リージョン IP を持つリージョンの外部マルチクラスタ Gateway を使用することで、現地の規制を遵守できます。この場合、クライアントのトラフィックは、インターネットを介して Gateway IP が公開されている特定のリージョンにルートされ、そこからリージョンのバックエンドにのみルートされます。
容量ベースのロード バランシング
最後に、サービスの健全性を確保するためにトラフィックのスロットルを必要とするアプリケーションを構築しているお客様は、サービス容量（エンドポイントあたりの最大リクエスト数）を設定し、バックエンド ポッドに送信されるリクエスト数に基づいてトラフィックをロードバランスできます。サービスは複数のクラスタに完全に分散させることができ、マルチクラスタ Gateway はすべてのバックエンド ポッドでトラフィックを最適に分散させ、リクエスト数が設定されたサービス容量より多い場合は、他のリージョンに振り分けます。
マルチクラスタ Gateway で公開されたアプリケーションを保護
インターネットに接続された分散アプリケーションは、GKE クラスタのフリートにデプロイされていると、DDoS 攻撃や他のセキュリティ脅威にさらされやすいため、トラフィックのプライバシーと完全性を守るための追加のセキュリティ層が必要です。マルチクラスタ Gateway は、GKE マネージド アプリケーション ロードバランサの実装であり、Google のロードバランサの高度なセキュリティ機能をすべて利用できます。詳しくは以下をご覧ください。
機密性と完全性を保護するため TLS で暗号化
ウェブ アプリケーションのセキュリティ戦略の最初のステップは、SSL ポリシーを設定することです。そうすることで、バックエンドのポッドではなく、Gateway のレベルで望ましくないトラフィックを遮断します。これにより、アプリケーション レベルでの混雑を未然に防ぐことができます。
そして、HTTPS トラフィックが信頼できるものであることを保証するために、クライアントから Gateway へのトラフィックと Gateway からバックエンドへのトラフィックには、自己署名または証明機関である Google による TLS 証明書を使用します。証明書は GKE クラスタに Secret として保存できますが、この場合はフリート環境での調整が必要となります。もしくは、ロードバランサ レベルで直接保存することも可能です。マルチクラスタ Gateway では、Gateway 自体に最大 15 枚の TLS 証明書を直接保存できます。それを超える場合は、Certificate Manager を使用すると最大 100 万枚の証明書を保存し、アプリケーション トラフィックを安全に保護することができます。
アプリケーション チームは、ポリシーとフィルタを組み合わせてトラフィックを HTTP から HTTPS にリダイレクトすることで、トラフィックを確実にエンドツーエンドで暗号化できます。
Cloud Armor で Gateway バックエンドを管理および保護
多くの場合、セキュリティ チームは、望ましくないインバウンド トラフィックを防ぐために、すべてのプラットフォームやアプリケーションでデフォルトのセキュリティ ポリシーを適用することを求めます。ある地域でのみサービスを提供する組織の場合、その地域からの IP アドレスのみにアプリケーションへのアクセスを制限したいと考えるかもしれません。同様に、DDoS 攻撃を避けるため、悪意のある IP アドレスをブロックしたいと考える組織もあるでしょう。さらに、インターネットに接続されたアプリケーションは、SQLi、XSS などの高度なアプリケーション層攻撃を受ける可能性があります。アプリケーション チームは、ウェブ アプリケーション ファイアウォールを使用して、これらの攻撃を軽減できます。
Cloud Armor は、マルチレイヤーウェブ アプリケーション ファイアウォールであり、ネットワーク レベルでトラフィックをフィルタリングするだけでなく、きめ細かなセキュリティ ポリシーを使用してアプリケーション レベルでディープ パケット インスペクションを実行することで、GKE フリート上のクラウン ジュエルを管理および保護することができます。
プラットフォーム チームとアプリケーション チームは、マルチクラスタ Gateway を使用して、バックエンド ポリシーを設定し、Gateway を参照することで、アプリケーションにこのセキュリティ コントロールを追加できます。
Identity-Aware Proxy によるトラフィックの認証と承認
適切なネットワーク レベルのセキュリティ コントロールが整っている場合（SSL ポリシー、TLS 証明書、Cloud Armor など）、アプリケーション チームは HTTPS アプリケーションに対して、ユーザー ID に基づく認証と承認のレイヤを追加したいと考えるかもしれません。
Identity-Aware Proxy は、このアクセス コントロールをマルチクラスタ Gateway レベルで提供します。ユーザーが誰であるか（Google アカウントの認証情報を確認）、またユーザーの役割と権限（Identity and Access Management を使用）を確認することで、GKE クラスタのフリートで動作しているバックエンドへのアクセスを検証できます。
繰り返しになりますが、アプリケーション チームは、バックエンド サービスに関連付けられたバックエンド ポリシーを使用することで、アプリケーションへの適切なアクセスレベルを設定できます。また、アプリケーションをエンドユーザーやシステムに対して安全に公開し、ユーザーの身元に基づいてアプリケーションへのアクセスを記録することが可能になります。
次のステップ
GKE フリートで GKE Gateway Controller を使用する方法や Gateway API について記載したリソースがたくさんあります。Google の実装と、それが組織にどのような利益をもたらすかについて関心のある方は、以下のリンクをご覧ください。
また Google は、数日後にシカゴで開催される KubeCon NA に参加します。
Google のチームにお気軽にお問い合わせいただき、ブースにもぜひお立ち寄りください。また、Google のセッションに関する情報を確認することや、ミーティングをリクエストして、ご自身のユースケースについて、Google からどのようなサポートを受けられるかを相談することも可能です。Google のブースでは、ライトニング トークを多数開催予定で、11 月 8 日（水）14:00 からは、マルチクラスタ Gateway をテーマとし、分散アプリケーションの可用性を向上させる方法についてお話します。
最後に KubeCon では、Gateway API に関するブレイクアウト セッションも多数実施されます。Kubernetes でのロードバランサの使用やサービス メッシュのユースケースをサポートする GAMMA Initiative などが取り上げられます。このコラボレーティブなネットワーキング API について理解を深めるため、こちらのセッションもぜひご覧ください。
- Gateway API: Kubernetes 史上最もコラボレーティブな API の一般提供を開始 - Google、Rob Scott ＆ Isovalent、Nick Young
- アプリケーションのリソースの可用性とパフォーマンスを向上させる最新のロード バランシング - Google、Antonio Ojea ＆ Gerrit DeWitt
- Istio: プロジェクトとコミュニティの過去、現在、そして未来 - solo.io、Louis Ryan ＆ Google、John Howard（内容: Gateway API）
-シニア プロダクト マネージャー Pierre-Louis Gingembre
-シニア スタッフ ソフトウェア エンジニア、クラウド ネットワーキング Bowei Du
