エッジからマルチクラスタ メッシュへ: GKE Gateway と Cloud Service Mesh を介して公開されるグローバルに分散されたアプリケーション

Last reviewed 2024-06-30 UTC

このリファレンス アーキテクチャでは、サービス メッシュ内の複数の GKE クラスタで実行されている Google Kubernetes Engine（GKE）Gateway を介してアプリケーションを外部に公開するメリットについて説明します。このガイドは、プラットフォーム管理者を対象としています。

複数の GKE クラスタにアプリケーションを一貫してデプロイすると、各クラスタが追加の障害発生ドメインになり、サービスの復元性と冗長性が向上します。たとえば、単一の GKE クラスタにデプロイされたサービスレベル目標（SLO）が 99.9% のサービスは、2 つの GKE クラスタにデプロイされると SLO が 99.9999% になります（1 - (0.001)²）。レイテンシが最も少なく、利用可能なメッシュ Ingress ゲートウェイに受信リクエストが自動的に転送されるエクスペリエンスをユーザーに提供することもできます。

単一のクラスタで実行されるサービス メッシュ対応アプリケーションを公開するメリットについては、エッジからメッシュへ: GKE Gateway を介したサービス メッシュ アプリケーションの公開をご覧ください。

アーキテクチャ

次のアーキテクチャ図は、データが Cloud Ingress と Mesh Ingress を通過する方法を示しています。

上の図は、次のデータフロー シナリオを示しています。

• 独自の Google マネージド TLS 証明書を使用して Google Cloud ロードバランサで終端するクライアントからのフロー。
• 独自の自己署名 TLS 証明書を使用した、Google Cloud ロードバランサからメッシュ Ingress プロキシへのフロー。
• サービス メッシュ対応の mTLS を使用した、Mesh Ingress ゲートウェイ プロキシからワークロード サイドカー プロキシへのフロー。

このリファレンス アーキテクチャには、次の 2 つの上り（内向き）レイヤがあります。

• Cloud Ingress: このリファレンス アーキテクチャでは、Kubernetes Gateway API（および GKE Gateway コントローラ）を使用して、外部マルチクラスタ HTTP(S) ロード バランシング レイヤをプログラムします。ロードバランサは、複数のリージョンにわたる Mesh Ingress プロキシをチェックし、最も近い正常なクラスタにリクエストを送信します。また、Google Cloud Armor セキュリティ ポリシーも実装します。
• Mesh Ingress: メッシュでは、バックエンドでヘルスチェックを直接実行し、ロード バランシングとトラフィック管理をローカルで実行できます。

上り（内向き）レイヤを組み合わせて使用する場合、各レイヤには補完的な役割があります。Google Cloud は、次の目標を達成するために、Cloud Ingress レイヤと Mesh Ingress レイヤから最も適切な機能を最適化します。

• 低レイテンシの実現。
• 可用性の向上。
• Cloud Ingress レイヤのセキュリティ。
• メッシュ上り（内向き）レイヤのセキュリティ、認可、オブザーバビリティ。

Cloud Ingress

Mesh Ingress と組み合わせて使用する場合、Cloud Ingress レイヤはエッジ セキュリティとグローバル ロード バランシングに最適です。Cloud Ingress レイヤは次のサービスと統合されているため、これらのサービスをメッシュ外のエッジで実行することに優れています。

• DDoS 対策
• Cloud Firewall
• 認証と認可
• 暗号化

通常、Cloud Ingress レイヤのルーティング ロジックは単純です。ただし、マルチクラスタ環境やマルチリージョン環境では、複雑になる可能性があります。

インターネットに接続するロードバランサの重要な機能のため、Cloud Ingress レイヤはプラットフォーム チームが管理します。このチームはインターネット上でのアプリケーションの公開方法や保護方法について独占的に制御します。この制御により、このレイヤはデベロッパー主導のインフラストラクチャよりも柔軟性や動的性能が低くなります。このレイヤへの管理者権限とそのアクセス方法を決定する際は、次の要素を考慮してください。

Mesh Ingress

Cloud Ingress と組み合わせて使用する場合、Mesh Ingress レイヤは、トラフィックがサービス メッシュにアクセスするためのエントリ ポイントを提供します。このレイヤは、バックエンド mTLS、認可ポリシー、柔軟な正規表現照合も提供します。

Mesh Ingress レイヤとともに外部アプリケーション ロード バランシングをメッシュ外にデプロイすると、特にインターネット トラフィックの管理には大きなメリットがあります。サービス メッシュと Istio Ingress ゲートウェイはメッシュ内の高度なルーティングとトラフィック管理を提供しますが、一部の機能はネットワークのエッジで提供されます。Google Cloud の外部アプリケーション ロードバランサを介したインターネット エッジ ネットワークを活用すると、メッシュベースの Ingress よりも、パフォーマンス、信頼性、セキュリティ関連の大きな利点が得られます。

注: このリファレンス アーキテクチャでは、Cloud Ingress レイヤのルーティングを North-South ルーティングと呼びます。Mesh Ingress レイヤとサービスレイヤ間のルーティング、またはサービスレイヤ間のルーティングは、East-West ルーティングといいます。

使用するプロダクトと機能

次のリストは、このリファレンス アーキテクチャで使用する Google Cloud プロダクトと機能の概要を示しています。

• GKE Enterprise: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できるマネージド Kubernetes サービス。このリファレンス アーキテクチャでは、アプリケーションを提供する各 GKE クラスタが同じフリートにある必要があります。
• フリートとマルチクラスタ ゲートウェイ: Google のインフラストラクチャと GKE Enterprise を使用して、エンタープライズ スケールでコンテナ化されたアプリケーションの作成に使用されるサービス。
• Google Cloud Armor: サービス拒否攻撃やウェブ攻撃からアプリケーションとウェブサイトを保護するサービス。
• Cloud Service Mesh: Envoy と Istio をベースとしたフルマネージド サービス メッシュ
• アプリケーション ロードバランサ: サービスを実行してスケーリングできるプロキシベースの L7 ロードバランサ。
• Certificate Manager: Cloud Load Balancing で使用する TLS 証明書を取得、管理できるサービス。

フリート

GKE Enterprise と Google Cloud は、マルチクラスタ デプロイを管理するために、フリートを使用して Kubernetes クラスタを論理的にグループ化して正規化します。

1 つ以上のフリートを使用すると、個々のクラスタの管理からクラスタ グループ全体の管理にレベルアップできます。クラスタ管理の負荷を軽減するため、名前空間の同一性というフリート原則を使用します。フリート内の GKE クラスタごとに、すべての Mesh Ingress ゲートウェイを同じ方法で構成します。

アプリケーション サービスを一貫してデプロイします。これにより、名前空間アカウントのサービス バランス リーダーと、フリートの各 GKE クラスタの同じサービスに関連付けることができます。フリート内で想定される同一性と信頼性の原則により、GKE Enterprise と Google Cloud のフリート対応の機能をすべて使用できます。

サービス メッシュ内の East-West ルーティング ルールとトラフィック ポリシーは、Mesh Ingress レイヤで処理されます。Mesh Ingress レイヤは、フリート内のすべての GKE クラスタにデプロイされます。名前空間の同一性というフリートの原則に従って、各 Mesh Ingress ゲートウェイを同じように構成します。

GKE Gateway には単一の構成クラスタがありますが、フリート内のすべての GKE クラスタ間で GKE Gateway 構成を同期する必要があります。

新しい構成クラスタを指定する必要がある場合は、ConfigSync を使用します。ConfigSync を使用すると、このような構成がフリート内のすべての GKE クラスタ間で同期され、最新でない構成との調整を回避できます。

Mesh Ingress ゲートウェイ

Istio 0.8 では、メッシュ Ingress ゲートウェイが導入されました。ゲートウェイでは、サービス メッシュ外からのトラフィックに公開されるポートの専用プロキシを提供します。これらの Mesh Ingress プロキシでは、アプリケーションのルーティング動作とは別にネットワークの露出動作を制御できます。

このプロキシでは、アプリケーション サイドカーに到達する前に、メッシュ外部トラフィックにルーティングとポリシーを適用することもできます。Mesh Ingress は、メッシュ内のノードに到達した際のトラフィック処理を定義しますが、外部コンポーネントはトラフィックが最初にメッシュに到着する方法を定義する必要があります。

外部トラフィックを管理するには、メッシュ外のロードバランサが必要です。このリファレンス アーキテクチャでは、デプロイを自動化するために、GKE Gateway リソースを介してプロビジョニングされる Cloud Load Balancing を使用します。

GKE Gateway とマルチクラスタ サービス

クラスタ外部のクライアントにアプリケーション アクセスを提供するには、さまざまな方法があります。GKE Gateway は Kubernetes Gateway API の実装の一つです。GKE Gateway は Ingress リソースを進化させ、改善します。

GKE Gateway リソースを GKE クラスタにデプロイすると、Gateway コントローラは Gateway API リソースを監視します。コントローラは、Cloud Load Balancing リソースを調整して、Gateway リソースで指定されたネットワーク動作を実装します。

GKE Gateway を使用する場合、アプリケーションをクライアントに公開するために使用するロードバランサのタイプは、次の要因に大きく依存します。

• バックエンド サービスが単一の GKE クラスタにあるか、複数の GKE クラスタに分散されているか（同じフリート内）。
• クライアントのステータス（外部または内部）。
• Google Cloud Armor セキュリティ ポリシーとの統合機能など、ロードバランサに必要な機能。
• サービス メッシュのスパン要件。サービス メッシュは、複数の GKE クラスタにまたがることも、単一のクラスタに含めることもできます。

Gateway では、この動作は適切な GatewayClass を指定することで制御されます。Gateway クラスを参照する場合、マルチクラスタ シナリオで使用できるクラスのクラス名は -mc で終わります。

このリファレンス アーキテクチャでは、外部アプリケーション ロードバランサを介してアプリケーション サービスを外部に公開する方法について説明します。ただし、Gateway を使用する場合は、マルチクラスタのリージョン内部アプリケーション ロードバランサを作成することもできます。

マルチクラスタ シナリオでアプリケーション サービスをデプロイするには、次の 2 つの方法で Google Cloud ロードバランサ コンポーネントを定義します。

• マルチクラスタ Ingress と MultiClusterService リソース
• マルチクラスタ Gateway とマルチクラスタ Service

アプリケーション サービスのデプロイに関するこれらの 2 つのアプローチの詳細については、GKE のマルチクラスタ ロード バランシング API を選択するをご覧ください。

注: マルチクラスタ Ingress とマルチクラスタ GKE Gateway はどちらもマルチクラスタ サービスを使用します。マルチクラスタ サービスは、フリート内の GKE クラスタにデプロイできます。クラスタ間のサービス ディスカバリの目的では、マルチクラスタ サービスは同じです。ただし、これらのサービスをフリート内のクラスタ間で公開する方法は異なります。

マルチクラスタ Ingress は、MultiClusterService リソースの作成に依存しています。マルチクラスタ Gateway は、ServiceExport リソースの作成と ServiceImport リソースの参照に依存しています。

マルチクラスタ Gateway を使用する場合は、ポリシーを作成して、基盤となる Google Cloud ロードバランサの追加機能を有効にできます。このリファレンス アーキテクチャに関連付けられているデプロイガイドでは、クロスサイト スクリプティングからバックエンド サービスを保護するために Google Cloud Armor セキュリティ ポリシーを構成する方法について説明します。

これらのポリシー リソースは、複数のクラスタに公開されているフリート内のバックエンド サービスをターゲットとします。マルチクラスタ シナリオでは、このようなポリシーはすべて ServiceImport リソースと API グループを参照する必要があります。

ヘルスチェック

L7 ロード バランシングの 2 つのレイヤを使用する複雑さの一つは、ヘルスチェックです。各ロードバランサを構成して、次のレイヤの健全性を確認する必要があります。GKE Gateway は Mesh Ingress プロキシのヘルスチェックを行い、メッシュはアプリケーション バックエンドのヘルスチェックを行います。

• Cloud Ingress: このリファレンス アーキテクチャでは、GKE Gateway を通じて Google Cloud ロードバランサを構成し、公開されたヘルスチェック ポートで Mesh Ingress プロキシの健全性を確認します。メッシュ プロキシがダウンしている場合、またはクラスタ、メッシュ、リージョンが利用できない場合、Google Cloud ロードバランサはこの状態を検出し、メッシュ プロキシにトラフィックを送信しません。この場合、トラフィックは別の GKE クラスタまたはリージョンの代替メッシュ プロキシにルーティングされます。
• Mesh ingress: メッシュ アプリケーションでは、バックエンドでヘルスチェックを直接実行し、ロード バランシングとトラフィック管理をローカルで実行できます。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティとコンプライアンス、信頼性、費用に関する特定の要件を満たすアーキテクチャを開発するためのガイダンスを示します。

セキュリティ、プライバシー、コンプライアンス

このドキュメントのアーキテクチャ図には、いくつかのセキュリティ要素が含まれています。最も重要な要素は、暗号化の構成と証明書のデプロイです。GKE Gateway は、これらのセキュリティ目的で Certificate Manager と統合されています。

インターネット クライアントは、公開証明書に対する認証を行い、Virtual Private Cloud（VPC）の最初のホップとして外部ロードバランサに接続します。Certificate Manager については、Gateway 定義の CertificateMap で参照できます。ネクストホップは、Google Front End（GFE）と Mesh Ingress プロキシの間にあります。このホップは、デフォルトで暗号化されます。

GFE とバックエンド間のネットワーク レベルの暗号化は自動的に適用されます。ただし、セキュリティ要件によって、プラットフォーム オーナーが暗号鍵の所有権を保持していると判断された場合、クラスタ ゲートウェイ（GFE）と Mesh Ingress（Envoy プロキシ インスタンス）の間で TLS 暗号化による HTTP/2 を有効にできます。

クラスタ ゲートウェイと Mesh Ingress の間で TLS 暗号化を使用して HTTP/2 を有効にすると、自己署名証明書または公開証明書を使用してトラフィックを暗号化できます。GFE は認証されないため、自己署名証明書または公開証明書を使用できます。この追加の暗号化レイヤについては、このリファレンス アーキテクチャに関連するデプロイガイドをご覧ください。

証明書の誤処理を防ぐため、公開証明書を再利用しないでください。サービス メッシュ内のロードバランサごとに個別の証明書を使用します。

このリファレンス アーキテクチャのデプロイガイドでは、外部 DNS エントリと TLS 証明書の作成に Cloud Endpoints を使用しています。Cloud Endpoints を使用すると、外部で利用可能な cloud.goog サブドメインを作成できます。エンタープライズ レベルのシナリオでは、より適切なドメイン名を使用し、DNS サービス プロバイダのグローバル アプリケーション ロードバランサの IP アドレスを指す A レコードを作成します。

使用しているサービス メッシュで TLS が強制されている場合、サイドカー プロキシ間のすべてのトラフィックと、Mesh Ingress へのすべてのトラフィックが暗号化されます。次の図は、クライアントから Google Cloud ロードバランサ、ロードバランサから Mesh Ingress プロキシ、Ingress プロキシからサイドカー プロキシへの HTTPS 暗号化を示しています。

信頼性と復元力

マルチクラスタ、マルチリージョンのエッジからメッシュへのパターンの主な利点は、アプリケーション サービス間のトラフィックなど、East-West ロード バランシングにサービス メッシュのすべての機能を使用できる点です。

このリファレンス アーキテクチャでは、マルチクラスタ GKE Gateway を使用して、受信 Cloud Ingress トラフィックを GKE クラスタに転送します。システムは、ユーザーとの近さ（レイテンシ）、可用性、健全性に基づいて GKE クラスタを選択します。トラフィックが Istio Ingress ゲートウェイ（Mesh Ingress）に到達すると、サービス メッシュを介して適切なバックエンドに転送されます。

East-West トラフィックを処理する別の方法として、GKE クラスタにデプロイされたすべてのアプリケーション サービスにマルチクラスタ サービスを使用することもできます。フリート内の GKE クラスタ間でマルチクラスタ サービスを使用する場合、サービス エンドポイントは ClusterSet にまとめて収集されます。サービスが別のサービスを呼び出す必要がある場合は、2 番目のサービスの正常なエンドポイントをターゲットにできます。エンドポイントはローテーションで選択されるため、選択されたエンドポイントは別のゾーンまたは別のリージョンにある可能性があります。

マルチクラスタ サービスではなくサービス メッシュを East-West トラフィックに使用する場合の主な利点は、サービス メッシュで局所的なロード バランシングを使用できることです。局所的なロード バランシングはマルチクラスタ Service の機能ではありませんが、DestinationRule で構成できます。

構成すると、あるサービスから別のサービスへの呼び出しは、まず同じゾーンのサービス エンドポイントに到達しようとします。次に、呼び出し元のサービスと同じリージョンで試行されます。最後に、同じゾーンまたはリージョンのサービス エンドポイントを使用できない場合にのみ、別のリージョンのエンドポイントをターゲットとします。

費用の最適化

このマルチクラスタ アーキテクチャを企業全体に広く導入する場合、Cloud Service Mesh とマルチクラスタ Gateway は Google Kubernetes Engine（GKE）Enterprise エディションに含まれています。さらに、GKE Enterprise には、GKE クラスタ、アプリケーション、その他のプロセスを大規模に管理できる多くの機能が含まれています。

デプロイ

このアーキテクチャをデプロイするには、エッジからマルチクラスタ メッシュへ: GKE Gateway と Cloud Service Mesh を介してグローバルに分散されたアプリケーションをデプロイするをご覧ください。

次のステップ

• サービス メッシュで使用できる GKE Gateway によって提供されるその他の機能について学習する。
• GKE で使用できるさまざまなタイプの Cloud Load Balancing について学ぶ。
• Cloud Service Mesh の特徴や提供される機能について学ぶ。
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。

寄稿者

作成者:

• Alex Mattson | アプリケーション スペシャリスト エンジニア
• Mark Chilvers | アプリケーション スペシャリスト エンジニア

その他の寄稿者:

• Abdelfettah Sghiouar | Cloud デベロッパー アドボケイト
• Arunkumar Jayaraman | プリンシパル エンジニア
• Greg Bray | カスタマー エンジニア
• Megan Yahya | プロダクト マネージャー
• Paul Revello | クラウド ソリューション アーキテクト
• Valavan Rajakumar | キー エンタープライズ アーキテクト
• Maridi Raju Makaraju | サポート性に関するテクニカル リーダー