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 拡張機能の値とバックエンド サービス名は互いに独立しています。
TLSRoute リソースと Mesh リソース（クリックして拡大）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 はサポートされません。
TLSRoute リソースと Gateway リソース（クリックして拡大）コア gRPC のサポート
メソッドによるマッチングなど、コア gRPC 属性を使用することで、プロキシレス gRPC クライアントを構成できます。
TCP トラフィックのトラフィック分割
TCP トラフィックに対して、複数のバックエンド サービスにわたり、重み付けによるトラフィック分割を実装できます。サービスを更新するときに、カナリア（Blue/Green）ロールアウトなどのパターンを構成できます。また、トラフィック分割を行うと、ダウンタイムを発生させずに、制御された方法でトラフィックを移行できます。
トラフィック インターセプト
サービス ルーティング API の Mesh リソースと Gateway リソースを使用すると、すべてのトラフィックが自動的にインターセプトされます。詳細については、自動 Envoy デプロイによる Compute Engine VM 設定のオプションをご覧ください。
アーキテクチャとリソース
このセクションでは、サービス ルーティング API モデルとそのリソースについて説明します。また、サービス ルーティング API リソースの連携についても説明します。
Mesh リソース
Mesh リソースは、サービス メッシュのインスタンスを表します。このプロジェクトを使用して、プロジェクトに論理サービス メッシュを作成します。各 Mesh リソースには、プロジェクト内で一意の名前を付ける必要があります。Mesh リソースを作成した後に、その名前を変更することはできません。
Mesh Envoy サイドカーとプロキシレス gRPC のデプロイを使用した API リソース（クリックして拡大）Mesh リソースは Route リソースで参照され、メッシュに含まれるサービスのルートが追加されます。
Envoy プロキシとプロキシレス gRPC クライアントは、Mesh リソースの名前で識別されるサービス メッシュに参加することで、Cloud Service Mesh から構成を受け取ります。Mesh リソースは、次のデータプレーのデプロイをサポートしています。
- アプリケーションと一緒にサイドカー プロキシとして実行される Envoy
- プロキシレス gRPC クライアント
- Envoy サイドカー クライアントとプロキシレス gRPC クライアントの組み合わせ
Route リソース
Route リソースは、サービスにルーティングを設定するために使用します。Route API リソースには 4 つの種類があります。トラフィックをバックエンド サービスに転送するためのプロトコルを定義します。
HTTPRouteGRPCRouteTCPRouteTLSRoute
この 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 API リソース（クリックして拡大）ルーティング、ヘッダーの変更、タイムアウト、重みに基づくトラフィック分割などのトラフィック管理機能は 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 リソースを介したサービス メッシュ Ingress（クリックして拡大）
Gatewayリソース（クリックして拡大）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スコープ パラメータは必須です。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 リソースと Route リソースの間のプロジェクト間参照（クリックして拡大）プロジェクトをまたぐ一般的なシナリオでは、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 リソースを一覧表示する方法については、Routeリソースを一覧表示するをご覧ください。この機能はプレビュー中です。- サービス ルーティング API については、ネットワーク サービス API のドキュメントをご覧ください。