エッジからメッシュへ: GKE Gateway を介したサービス メッシュ アプリケーションの公開

Last reviewed 2023-10-24 UTC

このリファレンス アーキテクチャでは、Anthos Service Mesh と Cloud Load Balancing を組み合わせて、サービス メッシュ内のアプリケーションをインターネット クライアントに公開する方法について説明します。

Anthos Service Mesh は Istio をベースにしたマネージド サービス メッシュで、セキュリティが強化された、観測可能で標準化された通信レイヤをアプリケーションに提供します。サービス メッシュは、メッシュ内で通信するクライアントに包括的な通信プラットフォームを提供します。ただし、メッシュ外にあるクライアントをメッシュ内でホストされているアプリケーションに接続する方法に課題があります。

アプリケーションは、クライアントの場所に応じてさまざまな方法でクライアントに公開できます。このリファレンス アーキテクチャは、Anthos Service Mesh を実行する上級レベルの実務担当者を対象としていますが、Google Kubernetes Engine（GKE）上の Istio でも機能します。

Mesh Ingress ゲートウェイ

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

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

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

Google Cloud の場合、この設定の標準的な例は、パブリック ネットワーク ロードバランサ（L4）をデプロイする外部ロード バランシング サービスです。このロードバランサは、GKE クラスタの NodePort を参照します。これらの NodePort は、下流のメッシュ サイドカー プロキシにトラフィックをルーティングする Istio Ingress ゲートウェイ Pod を公開します。

アーキテクチャ

次の図は、このトポロジを示しています。内部プライベート トラフィックのロード バランシングは、内部パススルー ネットワーク ロードバランサをデプロイする点を除いて、このアーキテクチャと類似しています。

外部ロードバランサは、外部クライアントを Ingress ゲートウェイ プロキシ経由でメッシュにルーティングします。

上の図は、Mesh Ingress ゲートウェイで L4 の透明なロード バランシングを使用すると、次のような利点があることを示しています。

  • この設定により、ロードバランサのデプロイが簡単になります。
  • ロードバランサは、クラスタの変更、ノードの停止、プロセス停止が発生したときに、安定した仮想 IP アドレス（VIP）、ヘルスチェック、信頼性の高いトラフィック分配を提供します。
  • すべてのルーティング ルール、TLS 終端、トラフィック ポリシーは、Mesh Ingress ゲートウェイの 1 つの場所で処理されます。

GKE Gateway とサービス

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

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

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

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

GKE Gateway では、この動作は適切な GatewayClass を指定することで制御されます。

Anthos Service Mesh のデフォルトのロードバランサはネットワーク ロードバランサですが、このリファレンス アーキテクチャでは外部アプリケーション ロードバランサ（L7）を中心に説明します。外部アプリケーション ロードバランサは、Identity-Aware Proxy や Google Cloud Armor などのエッジサービス、URL のリダイレクトや書き換え、グローバルに分散されたエッジプロキシのネットワークとの統合を提供します。次のセクションでは、2 つのレイヤからなる HTTP ロード バランシングを使用する際のアーキテクチャとメリットについて説明します。

Cloud Ingress と Mesh Ingress

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

この L7 ロード バランシングの外部レイヤは、Mesh Ingress で使用されるセルフホストのプロキシではなく、クラウド管理ロードバランサ上に構築されるため、「Cloud Ingress」と呼ばれます。Cloud Ingress と Mesh Ingress を組み合わせる場合、Google Cloud インフラストラクチャとメッシュの補完機能を使用します。次の図は、Cloud Ingress（GKE ゲートウェイ経由）と Mesh Ingress を組み合わせて、インターネット トラフィック用の 2 つのロード バランシング レイヤとして機能する方法を示しています。

Cloud Ingress は、VPC ネットワーク経由でメッシュへの外部トラフィックのためのゲートウェイとして機能します。

上の図のトポロジでは、Cloud Ingress レイヤがサービス メッシュの外部からのトラフィックの供給源となり、そのトラフィックを Mesh Ingress レイヤに転送します。その後、この Mesh Ingress レイヤはメッシュでホストされるアプリケーション バックエンドにトラフィックを転送します。

Cloud Ingress と Mesh Ingress のトポロジ

このセクションでは、各 Ingress レイヤを一緒に使用するときに補完する役割について説明します。これらの役割は詳細なルールではなく、各レイヤのメリットを使用するガイドラインです。このパターンのバリエーションは、ユースケースによって異なります。

  • Cloud Ingress: Mesh Ingress と組み合わせて使用する場合、Cloud Ingress レイヤはエッジ セキュリティとグローバル ロード バランシングに最適です。Cloud Ingress レイヤには DDoS 対策、クラウド ファイアウォール、認証、暗号化プロダクトがエッジにおいて統合されているため、このレイヤはメッシュ外で上記サービスを実行することに優れています。ルーティング ロジックは通常、このレイヤで比較的単純ですが、マルチクラスタ環境やマルチリージョン環境では、ロジックがより複雑になる可能性があります。インターネットに接続するロードバランサの重要な機能のため、Cloud Ingress レイヤはインフラストラクチャ チームが管理します。このチームはインターネット上でのアプリケーションの公開方法や保護方法について独占的に制御します。この制御により、このレイヤはデベロッパー主導のインフラストラクチャよりも柔軟性や動的性能が低くなります。このことは、このレイヤへの管理者アクセスを提供する対象と方法に影響する可能性があります。
  • Mesh Ingress: Cloud Ingress と組み合わせて使用する場合、Mesh Ingress レイヤはアプリケーションに近い柔軟なルーティングを可能とします。このような柔軟性があるため、複雑なルーティング ロジックやアプリケーション レベルの可視性のために、Mesh Ingress は Cloud Ingress より優れています。Ingress レイヤを分離することで、アプリケーション オーナーは他のチームに影響を与えずにこのレイヤを直接制御するのが簡単になります。アプリケーションを保護するには、L7 ロードバランサの代わりに L4 ロードバランサを介してサービス メッシュ アプリケーションを公開する場合、メッシュ内の Mesh Ingress レイヤでクライアント TLS を終了する必要があります。

ヘルスチェック

L7 ロード バランシングの 2 つのレイヤを使用する複雑さの 1 つは、ヘルスチェックです。各ロードバランサを構成して、次のレイヤの健全性を確認して、トラフィックを受信できるようにする必要があります。次の図のトポロジは、Cloud Ingress によって Mesh Ingress プロキシのヘルスチェックを行う方法と、返されたメッシュでアプリケーション バックエンドの健全性を確認する方法を示しています。

Cloud Ingress は Mesh Ingress のヘルスチェックを行い、Mesh Ingress はアプリケーション バックエンドのヘルスチェックをチェックします。

前述のトポロジには次の考慮事項があります。

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

セキュリティ

上記のトポロジには、いくつかのセキュリティ要素も含まれています。最も重要な要素の 1 つは、暗号化の構成と証明書のデプロイです。GKE Gateway は、Google マネージド証明書と統合されています。Certificate Manager については、Gateway 定義の CertificateMap で参照できます。インターネット クライアントは、公開証明書に対する認証を行い、Virtual Private Cloud（VPC）の最初のホップとして外部ロードバランサに接続します。

Google Front End（GFE）と Mesh Ingress プロキシの間にあるネクストホップは、デフォルトで暗号化されます。GFE とバックエンド間のネットワーク レベルの暗号化は自動的に適用されます。ただし、セキュリティ要件によって、プラットフォーム オーナーが暗号鍵の所有権を保持していると判断された場合、クラスタ Gateway（GFE）と Mesh Ingress（Envoy プロキシ インスタンス）の間で TLS 暗号化による HTTP/2 を有効にできます。このパスで TLS 暗号化による HTTP/2 を有効にすると、GFE は認証されないため、自己署名証明書または公開証明書を使用してトラフィックを暗号化できます。この追加の暗号化レイヤについては、関連するデプロイガイドをご覧ください。証明書の誤処理を防ぐため、パブリック ロードバランサには他の場所の公開証明書を使用しないでください。代わりに、サービス メッシュで別個の証明書を使用することをおすすめします。

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

セキュリティは、メッシュ外のマネージド証明書と、メッシュ内の内部証明書を使用して実装されます。

費用の最適化

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

デプロイ

このアーキテクチャをデプロイするには、エッジからメッシュへ: GKE Gateway を介したサービス メッシュ アプリケーションのデプロイをご覧ください。

次のステップ