Cloud Service Mesh サービス ルーティング API の概要
このドキュメントは、Cloud Service Mesh とサービス メッシュのコンセプトについて、中級から上級レベルの知識を持ち、VM インスタンスを使用して Compute Engine に Cloud Service Mesh をデプロイするメッシュまたはプラットフォームの管理者とサービス デベロッパーを対象としています。このドキュメントは、Envoy と gRPC クライアントを使用したデプロイメントに適用されます。Cloud Service Mesh のコンセプトの詳細については、一般的な概要をご覧ください。
Cloud Service Mesh は、高度なトラフィック管理、オブザーバビリティ、セキュリティなどのサービス ネットワーキング機能をアプリケーションに提供します。メッシュ管理者とサービス デベロッパーにとって、サービス メッシュの構成と運用は複雑なタスクです。
このドキュメントでは、Cloud Service Mesh を構成するためのサービス ルーティング API について説明します。これらの API は、メッシュ構成の全体的な作業を省力化し、改善するように設計されています。
サービス ルーティング モデルは、Mesh
、Gateway
、Route
という API リソースを使用します。これらのリソースにより、サービス ネットワーキング コントロール プレーンを定義する際に、コンテキストに応じた構成が可能になります。
このドキュメントでは、次のサービス ルーティング API モデルとリソースについて紹介します。
Mesh
リソース- Envoy サイドカー プロキシとプロキシレス gRPC クライアントのサービス間(East-West)トラフィックの管理とセキュリティ構成。
-
- Ingress ゲートウェイとして機能する Envoy プロキシのトラフィック管理とセキュリティ構成。外部クライアントがサービス メッシュに接続(North-South)できるようにします。
次のタイプの
Route
リソース:
Google Cloud コンソールでは、サービス ルーティング API はサポートされていません。これらの API リソースは、Google Cloud CLI または REST API を使用して実装する必要があります。
ユースケースと利点
サービス ルーティング API を使用すると、プロキシレス gRPC と Envoy プロキシの両方のデプロイ用に Cloud Service Mesh を構成できます。サービス ルーティング API モデルには、いくつかの重要な利点があります。
次の図では、サービス メッシュ内の 2 つのサービスが Mesh
リソースによって接続されています。2 つの HTTPRoute
リソースがルーティングを構成します。メッシュまたはプラットフォーム管理者が Mesh
リソースを管理し、2 人のサービス オーナーがサービスのルーティング構成を作成します。
ロール指向の API 設計により責任を明確に分離できる
サービス ルーティング API を使用すると、組織のロールに基づいてメッシュ構成の責任を分離できます。
- メッシュ管理者は、論理メッシュと Ingress ゲートウェイ インフラストラクチャを定義できます。
- サービス所有者(アプリケーション開発者)は、サービスのアクセス パターンを個別に定義できます。また、サービスのトラフィック管理ポリシーを定義して適用することもできます。
次の図では、Cloud Load Balancing と Gateway
リソースが、メッシュ外のクライアントからメッシュに到達するトラフィック用に Ingress ゲートウェイを使用しています。メッシュ管理者は、Gateway
リソースを構成して管理します。サービス オーナーは独自のサービスとトラフィック ルーティングを構成して管理します。
セルフサービス モデルによる高い信頼性
サービス ルーティング API では、プロトコルとルートごとのリソースが使用されています。これにより、個々のサービス オーナーがリソースを構成し、所有できます。このアプローチにはいくつかの利点があります。
- サービス オーナーは、自身が所有するサービスのポリシーの構成方法の決定やトラフィック管理を自律して行うことができます。
- 1 つの
Route
リソースを更新しても、メッシュ内の他のRoute
リソースには影響しません。サービス オーナーが小規模な構成を管理するため、更新プロセスの信頼性が向上します。 - 宛先のサービスまたはホスト名を担当する所有するサービス オーナーが各
Route
リソースを所有します。 - サービス オーナーは、メッシュ管理者に依存することなくルーティングを更新できます。
共有 VPC 環境で複数のプロジェクトにまたがるサービス メッシュを有効にする
サービス ルーティング API モデルを使用すると、サービス オーナーは共有 VPC やその他の接続手段を使用して共有メッシュ インフラストラクチャに参加しながら、サービスに対する独自の制御を維持できます。たとえば、サービス オーナーは自分のプロジェクトで Route
リソースを定義できます。プラットフォーム管理者は、一元管理のホスト プロジェクトで Mesh
を定義し、Route
リソースを共有 Mesh
または Gateway
に接続する IAM 権限をサービス オーナーに付与します。次の図に、共有 VPC を使用した例を示します。
サービス ルーティング API を使用すると、サービス メッシュ クライアントが VPC ネットワーク ピアリングを使用して異なるネットワークに接続することもできます。
サーバー名インジケーターに基づいてトラフィックをルーティングする
TLSRoute
リソースを使用すると、TLS handshake の Server Name Indication(SNI)に基づいて、TLS で暗号化されたトラフィックをルーティングできます。TLSRoute
リソースで SNI 一致を構成することで、適切なバックエンド サービスにルーティングされるように TLS トラフィックを構成できます。これらのデプロイでは、プロキシはトラフィックのみをルーティングし、TLS セッションは宛先のバックエンド インスタンスで終了します。
TLSRoute
リソースは、サイドカー プロキシまたはゲートウェイとしてデプロイされている Envoy プロキシでのみサポートされています。
Mesh
リソースに接続される TLSRoute
リソース
次の図に示すデプロイでは、SNI 拡張機能の値が service1
であるサービス メッシュ トラフィックをバックエンド サービス service1
にルーティングしています。また、SNI 拡張機能の値が service2
であるサービス メッシュ トラフィックは、バックエンド サービス service2
にルーティングされます。SNI 拡張機能の値とバックエンド サービス名は互いに独立しています。
Gateway
リソースに接続される TLSRoute
リソース
次の図に示すデプロイは、SNI 拡張機能の値が serviceA
である Gateway
リソースへの受信トラフィックを、バックエンド サービス serviceA
にルーティングします。また、SNI 拡張機能の値が serviceB
である Gateway
への受信トラフィックは、バックエンド サービス serviceB
にルーティングされます。SNI 拡張機能の値とバックエンド サービス名は互いに独立しています。SNI 拡張機能の値と HTTP リクエストのヘッダーも独立しています。
Gateway
リソースは、Gateway
の Envoy プロキシで TLS 接続を終端しません。代わりに、対応するバックエンド サービスで TLS 接続を終端します。Gateway
は、TLS レイヤで暗号化された情報を検査できません。ただし、ClientHello
には書式なしテキストの SNI 拡張が含まれています。Gateway
は、このモードで TLS パススルーを実行します。暗号化された ClientHello
はサポートされません。
コア gRPC のサポート
メソッドによるマッチングなど、コア gRPC 属性を使用して、プロキシレス gRPC クライアントを構成できます。
TCP トラフィックのトラフィック分割
TCP トラフィックに対して、複数のバックエンド サービスにわたり、重み付けによるトラフィック分割を実装できます。サービスを更新するときに、カナリア(Blue/Green)ロールアウトなどのパターンを構成できます。また、トラフィック分割を行うと、ダウンタイムを発生させずに、制御された方法でトラフィックを移行できます。
トラフィック インターセプト
サービス ルーティング API の Mesh
リソースと Gateway
リソースを使用すると、すべてのトラフィックが自動的にインターセプトされます。詳細については、自動 Envoy デプロイによる Compute Engine VM 設定のオプションをご覧ください。
アーキテクチャとリソース
このセクションでは、サービス ルーティング API モデルとそのリソースについて説明します。また、サービス ルーティング API リソースの連携についても説明します。
Mesh
リソース
Mesh
リソースは、サービス メッシュのインスタンスを表します。このプロジェクトを使用して、プロジェクトに論理サービス メッシュを作成します。各 Mesh
リソースには、プロジェクト内で一意の名前を付ける必要があります。Mesh
リソースを作成した後に、その名前を変更することはできません。
Mesh
リソースは Route
リソースで参照され、メッシュに含まれるサービスのルートが追加されます。
Envoy プロキシとプロキシレス gRPC クライアントは、Mesh
リソースの名前で識別されるサービス メッシュに結合することで、Cloud Service Mesh から構成を受け取ります。Mesh
リソースは、次のデータプレーのデプロイをサポートしています。
- アプリケーションと一緒にサイドカー プロキシとして実行される Envoy
- プロキシレス gRPC クライアント
- Envoy サイドカー クライアントとプロキシレス gRPC クライアントの組み合わせ
Route
リソース
Route
リソースは、サービスにルーティングを設定するために使用します。Route
API リソースには 4 つの種類があります。トラフィックをバックエンド サービスに転送するためのプロトコルを定義します。
HTTPRoute
GRPCRoute
TCPRoute
TLSRoute
この API には Route
API がそのまま含まれていません。構成可能な API リソースは、HTTPRoute
、GRPCRoute
、TCPRoute
、TLSRoute
のみです。
Route
リソースは、1 つ以上の Mesh
リソースと Gateway
リソースを参照し、対応する Mesh
または Gateway
構成に含まれるルートを追加します。Route
リソースは、Gateway
と Mesh
の両方のリソースを参照できます。
Route
リソースは、1 つ以上のバックエンド サービス リソースも参照します。このサービスは、バックエンド サービス API を使用して構成されます。1 つ以上の MIG または NEG バックエンドを参照するバックエンド サービス リソースを作成します。
次の図は、Mesh
、Gateway
、Route
リソース、バックエンド サービス リソース、およびそのバックエンド間の関係を示しています。
ルーティング、ヘッダーの変更、タイムアウト、重みに基づくトラフィック分割などのトラフィック管理機能は Route
リソースで定義します。次の図では、HTTPRoute
リソースが 2 つのバックエンド サービス間で 70% / 30% のトラフィック分割を定義しています。
サービス メッシュの管理を簡素化するために、Mesh
リソースまたは Gateway
リソースに接続されているすべての Route
リソースを一覧表示できます。
TLSRoute
リソース
TLSRoute
リソースを使用して、SNI ホスト名とアプリケーション レイヤ プロトコル ネゴシエーション(ALPN)名に基づいて TLS トラフィックをバックエンド サービスに転送します。TLSRoute
構成は TLS パススルーを意味します。この場合、Envoy プロキシは TLS トラフィックを終端しません。
TLSRoute
リソースは、1 つ以上の Mesh
リソースと Gateway
リソースを参照し、対応するメッシュまたはゲートウェイ構成に含まれるルートを追加します。
TLSRoute
リソースは、1 つ以上のバックエンド サービス リソースも参照します。このサービスは、バックエンド サービス API リソースを使用して構成されます。
Gateway
リソース
Gateway
リソースは、上り(内向き)ゲートウェイとして機能する Envoy プロキシを表すために使用され、外部クライアントがサービス メッシュ(North-South トラフィック)に接続できるようにします。このリソースには、リスニング ポートと scope
パラメータがあります。Ingress ゲートウェイとして機能する Envoy プロキシは、指定されたポートと、ローカル VM 上のすべての IP アドレスを表す 0.0.0.0
にバインドします。次の図は、Ingress サービスとしてデプロイされ、Gateway
リソースによって構成された Envoy プロキシを示しています。この例では、Envoy プロキシは、クライアントからの受信接続をポート 80 でリッスンするように構成されています。
Gateway
API リソースは、Envoy プロキシ データプレーンのみをサポートします。プロキシレス gRPC はサポートされていません。gRPCRoutes
は Gateway
リソースでサポートされていますが、gRPC トラフィックは Envoy プロキシによって転送され、中間プロキシとして機能します。
Gateway
スコープと結合された Gateway
構成とは
Gateway
リソース インスタンスは、ポートと、そのポートで受信したトラフィックに固有の構成を表します。Gateway
API リソースのパラメータ scope
を使用すると、2 つ以上の Gateway
リソースの構成を論理的にグループ化し、マージできます。
たとえば、Gateway
プロキシがポート 80 と 443 でそれぞれ HTTP トラフィックと HTTPS トラフィックを受信するようにする場合は、2 つの Gateway
リソースを作成します。1 つの Gateway
リソースに HTTP トラフィック用のポート 80 を構成し、もう 1 つのリソースで HTTPS トラフィック用のポート 443 を構成します。scope
フィールドには同じ値を設定します。Cloud Service Mesh は、同じスコープを持つすべての Gateway の個別の構成を動的にマージします。データプレーン側では、Ingress ゲートウェイ モードで実行される Envoy プロキシが、Gateway
構成を受け取るため、Cloud Service Mesh に同じ scope パラメータを提供する必要があります。スコープは、Gateway
リソースの作成時に指定します。プロキシのブートストラップ パラメータと同じスコープを指定します。
Gateway
リソースの主要な考慮事項は次のとおりです。
Gateway
スコープ パラメータは必須です。Gateway
が 1 つしかない場合でも、Envoy プロキシのブートストラップ構成でGateway
リソースにスコープを指定します。Gateway
リソースを作成しても、Envoy プロキシを使用してサービスはデプロイされません。Envoy プロキシのデプロイは別のステップです。Gateway
リソースには、Ingress のデプロイタイプを表すtype
があります。このフィールドは将来の使用のために予約されています。現在サポートされている値はOPEN_MESH
のみです。この値はデフォルト値で、変更できません。
プロトコル プレーンとデータプレーンが混在するメッシュのデプロイ
Envoy プロキシとプロキシレス gRPC を組み合わせて同じプロキシ内にデータプレーンをデプロイできます。このようなデプロイを行う場合は、次の点を考慮してください。
- Envoy サイドカー デプロイは、すべての Route(
HTTPRoute
、GRPCRoute
、TCPRoute
、TLSRoute
)をサポートしています。 - プロキシレス gRPC デプロイは
GRPCRoute
のみをサポートします。 GRPCRoute
は、gRPC プロキシレス デプロイでのみサポートされている機能に限定されています。
マルチプロジェクト共有 VPC 環境でサポートされているトポロジ
Cloud Service Mesh は、他のプロジェクトで定義された Route
リソースを、一元管理プロジェクトで定義された Mesh
または Gateway
リソースに追加できます。承認されたサービス オーナーは、サービス ルーティング構成を Mesh
または Gateway
に直接追加できます。
プロジェクトをまたぐ一般的なシナリオでは、Mesh
リソースを作成するメッシュ管理プロジェクトとして 1 つのプロジェクト(ホスト プロジェクトまたは一元管理プロジェクト)を選択します。メッシュ管理プロジェクトのオーナーは、他のプロジェクトの Route
リソースが Mesh
リソースを参照することを承認し、他のプロジェクトからのルーティング構成をメッシュの一部にすることができます。Envoy または gRPC のいずれかのメッシュ データプレーンが、管理プロジェクトから構成をリクエストし、Mesh
に接続されているすべてのルートの結合を受け取ります。Gateway
の場合、同じスコープを使用するすべての Gateways
でもルートがマージされます。
Mesh
管理プロジェクトには任意のプロジェクトを選択できます。共有 VPC または VPC ネットワーク ピアリングを介して、基盤となるプロジェクトに VPC ネットワーク接続が構成されている限り、構成は機能します。
IAM の権限とロール
Mesh
リソースと Route
リソースを安全に取得、作成、更新、削除、一覧表示、使用するために必要な IAM の権限は次のとおりです。
- メッシュ管理者には
networkservices.mesh.*
の権限が必要です。 - ゲートウェイ管理者には
networkservices.gateways.*
の権限が必要です。 - サービス オーナーには、
networkservices.grpcRoutes.*
、networkservices.httpRoutes.*
、またはnetworkservices.tcpRoutes.*
の権限が必要です。
メッシュ管理者は、サービス オーナーが Route
リソースを Mesh
リソースに接続できるように、サービス オーナーに networkservices.mesh.use
権限を付与する必要があります。同じモデルが Gateway
リソースにも適用されます。
Mesh
リソースに対するすべての IAM 権限を確認するには、IAM 権限のリファレンス ページにアクセスして meshes
を検索してください。
追加の事前定義ロールは必要ありません。既存の事前定義ロールの Compute ネットワーク管理者(roles/compute.networkAdmin
)には、デフォルトで networkservices.*
権限が含まれています。場合によっては、前述の権限をカスタムロールに追加する必要があります。
考慮事項と制限事項
- Google Cloud コンソールでは、サービス ルーティング API はサポートされていません。
- xDS API バージョン 3 以降を使用してください。
- Envoy の最小バージョン 1.20.0(サービス ルーティング API は xDS バージョン 3 でのみサポートされているため)
- gRPC ブートストラップ ジェネレータの最小バージョン v0.14.0
TLSRoute
リソースは、サイドカー プロキシまたはゲートウェイとしてデプロイされている Envoy プロキシでのみサポートされています。- 自動 Envoy デプロイを使用する Compute Engine VM と自動 Envoy インジェクションを使用する GKE Pod のみがサポートされます。サービス ルーティング API では手動デプロイを使用できません。
- サービス ルーティング API は、古い API と下位互換性がありません。
TCPRoute
リソースがMesh
リソースに接続されている場合、TCP トラフィックの照合に使用されるポートは、このTCPRoute
によって記述されているトラフィック以外の処理に使用できません。- たとえば、デプロイにポート 8000 と一致する
TCPRoute
リソースと HttpRoute リソースが含まれているとします。両方が同じMesh
リソースに接続されている場合、基盤となる IP アドレスが異なる場合でも、HTTPRoute
リソースによって転送されるトラフィックではポート 8000 を使用できません。この制限は、ポートに一致するルートが最初に割り当てられる Envoy プロキシの実装によるものです。
- たとえば、デプロイにポート 8000 と一致する
Gateway
リソースはマネージド ロードバランサをプロビジョニングせず、Envoy サービスを動的に作成しません。- Ingress ゲートウェイとして自動的にデプロイされる Envoy では、
--service-proxy
フラグにserving_ports
引数を含めないでください。 - 自動的にデプロイされた Envoy の場合、VM のプロジェクトとは異なるプロジェクト番号を指定できません。
次のステップ
Mesh
リソースまたはGateway
リソースに関連付けられた ルート リソースを一覧表示する方法については、Route
リソースを一覧表示するをご覧ください。この機能はプレビュー中です。- サービス ルーティング API については、ネットワーク サービス API のドキュメントをご覧ください。