Traffic Director サービス ルーティング API の概要
このドキュメントは、Traffic Director とサービス メッシュのコンセプトについて、中級以上の知識のあるメッシュまたはプラットフォーム管理者とサービス デベロッパーを対象としています。このドキュメントは、Envoy と gRPC クライアントを使用したデプロイメントに適用されます。 Traffic Director のコンセプトの詳細については、概要とプロキシレス gRPC サービスの概要をご覧ください。
Traffic Director は、高度なトラフィック管理、オブザーバビリティ、セキュリティなどのサービス ネットワーキング機能をアプリケーションに提供します。メッシュ管理者とサービス デベロッパーにとって、サービス メッシュの構成と運用は複雑なタスクです。
このドキュメントでは、Traffic Director を構成するためのサービス ルーティング API について説明します。これらの API は、メッシュ構成の全体的な作業を省力化し、改善するように設計されています。
この API モデルでは、以前の転送ルール、ターゲット プロキシ、URL マップリソースに代わり Mesh、Gateway、Route という API リソースを使用します。これらのリソースにより、サービス ネットワーキング コントロール プレーンを定義する際に、コンテキストに応じた構成が可能になります。
このドキュメントでは、次のサービス ルーティング API モデルとリソースについて紹介します。
Mesh- Envoy サイドカー プロキシとプロキシレス gRPC クライアントのサービス間（East-West）トラフィックの管理とセキュリティ構成。
- サービス メッシュを識別し、トラフィックのインターセプトとルーティング、ポリシーの適用を行うコンポーネントを表します。また、トラフィック インターセプト ポートも識別します。
Gateway- Ingress ゲートウェイとして機能する Envoy プロキシのトラフィック管理とセキュリティ構成。外部クライアントがサービス メッシュに接続（North-South）できるようにします。
- 中間プロキシを識別し、IP address:port ペアのリストをリッスンし、トラフィックをルーティングしてポリシーを適用するコンポーネントを表します。
Route
Google Cloud コンソールでは、サービス ルーティング API はサポートされていません。これらの API リソースは、Google Cloud CLI または REST API で実装する必要があります。また、古い API からサービス ルーティング API に自動的に移行する方法はありません。既存のデプロイを置き換えるには、サービス ルーティング API を使用して新しい Traffic Director デプロイを作成し、古いデプロイをシャットダウンする必要があります。
ユースケースと利点
サービス ルーティング API を使用すると、プロキシレス gRPC と Envoy プロキシの両方のデプロイメントに Traffic Director を構成できます。サービス ルーティング API モデルには、いくつかの重要な利点があります。
次の図では、サービス メッシュ内の 2 つのサービスが Mesh リソースによって接続されています。2 つの HTTPRoute リソースがルーティングを構成します。メッシュまたはプラットフォーム管理者が Mesh リソースを管理し、2 人のサービス オーナーがサービスのルーティング構成を作成します。
ロール指向の API 設計により責任を明確に分離できる
サービス ルーティング API を使用すると、組織のロールに基づいてメッシュ構成の責任を分離できます。
- メッシュ管理者は、論理メッシュと Ingress ゲートウェイ インフラストラクチャを定義できます。
- サービス所有者（アプリケーション デベロッパー）は、サービスのアクセス パターンを個別に定義できます。また、サービスのトラフィック管理ポリシーを定義して適用することもできます。
次の図では、Cloud Load Balancing と Gateway リソースが、メッシュ外のクライアントからメッシュに到達するトラフィック用に Ingress ゲートウェイを使用しています。メッシュ管理者は、Gateway リソースを構成して管理します。サービス オーナーは独自のサービスとトラフィック ルーティングを構成して管理します。
セルフサービス モデルによる高い信頼性
以前の Traffic Director API では、URL マップは、メッシュ内のサービス間通信のルーティングとマネージド ロードバランサ経由でメッシュに到達する外部トラフィックのルーティングを定義します。複数のチームで 1 つの URL マップリソースを編集すると、信頼性の問題が発生する可能性があり、サービスごとの構成をサービス オーナーに委任するプロセスが複雑になります。
サービス ルーティング API では、プロトコルとルートごとのリソースが導入されています。これにより、個々のサービス オーナーがリソースを構成し、所有できます。このアプローチにはいくつかの利点があります。
- サービス オーナーは、自身が所有するサービスのポリシーの構成方法の決定やトラフィック管理を自律して行えるようになりました。
- 1 つの
Routeリソースを更新しても、メッシュ内の他のRouteリソースには影響しません。また、サービス オーナーが管理する構成が大幅に少なくなるため、更新プロセスで発生するエラーも少なくなります。 - 宛先のサービスまたはホスト名を担当する所有するサービス オーナーが各
Routeリソースを所有します。 - サービス オーナーは、メッシュ管理者に依存することなく、一元管理された URL マップリソースを使用してルーティングを更新できます。
関連情報のみを構成する
サービス ルーティング API は、転送ルール、ターゲット プロキシ、URL マップに代わるものです。サイドカー プロキシやプロキシレス gRPC を使用したサービス間通信のために、Virtual Private Cloud（VPC）ネットワークから仮想 IP アドレスを割り振る必要はありません。
共有 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 リソースの名前で識別されるサービス メッシュに参加することで、Traffic Director から構成を受け取ります。Mesh 名は、ブートストラップ パラメータとして Compute Engine 上の Envoy の自動デプロイと GKE の自動 Envoy インジェクタによってサポートされます。
Mesh リソースは、次のデータプレーのデプロイをサポートしています。
- アプリケーションと一緒にサイドカー プロキシとして実行される Envoy
- プロキシレス gRPC クライアント
- Envoy サイドカー クライアントとプロキシレス gRPC クライアントの組み合わせ
Route リソース
Route リソースは、サービスにルーティングを設定するために使用します。Route API リソースには 4 つの種類があります。トラフィックをバックエンド サービスに転送するためのプロトコルを定義します。
この API には Route API がそのまま含まれていません。構成可能な API リソースは、HTTPRoute、GRPCRoute、TCPRoute、TLSRoute のみです。
Route リソースは、1 つ以上の Mesh リソースと Gateway リソースを参照し、対応する Mesh または Gateway 構成に含まれるルートを追加します。Route リソースは、Gateway と Mesh の両方のリソースを参照できます。
Route リソースは、1 つ以上のバックエンド サービス リソースも参照します。このサービスは、バックエンド サービス API と既存の構成フローを使用して構成されます。サービス ルーティング API では、Traffic Director の構成でバックエンド サービスとヘルスチェックを定義する方法は変更されません。これを行うには、1 つ以上の MIG または NEG バックエンドを参照するバックエンド サービス リソースを作成します。
次の図は、Mesh、Gateway、Route リソース、バックエンド サービス リソース、およびそのバックエンド間の関係を示しています。
Route API リソース（クリックして拡大）ルーティング、ヘッダーの変更、タイムアウト、重みに基づくトラフィック分割などのトラフィック管理機能は Route リソースで定義します。次の図では、HTTPRoute リソースが 2 つのバックエンド サービス間で 70% / 30% のトラフィック分割を定義しています。
TLSRoute リソース
TLSRoute リソースを使用して、SNI ホスト名とアプリケーション レイヤ プロトコル ネゴシエーション（ALPN）名に基づいて TLS トラフィックをバックエンド サービスに転送します。TLSRoute 構成は TLS パススルーを意味します。この場合、Envoy プロキシは TLS トラフィックを終端しません。
TLSRoute リソースは、1 つ以上の Mesh リソースと Gateway リソースを参照し、対応する Mesh または Gateway 構成に含まれるルートを追加します。
TLSRoute リソースは、1 つ以上のバックエンド サービス リソースも参照します。このサービスは、バックエンド サービス API リソースと、既存の構成フローおよび 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 フィールドには同じ値を設定します。Traffic Director は、同じスコープを持つ Gateway の個別の構成を動的にマージします。データプレーン側では、Ingress ゲートウェイ モードで実行される Envoy プロキシが、Gateway 構成を受け取るため、Traffic Director に同じ 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 環境でサポートされているトポロジ
Traffic Director は、他のプロジェクトで定義された 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.* 権限が含まれています。場合によっては、前述の権限をカスタムロールに追加する必要があります。
サービス ルーティングと古い API モデルの比較
このセクションでは、古い Traffic Director API モデルとサービス ルーティング API モデルをトピックごとに比較します。
| 古い API | サービス ルーティング API | |
|---|---|---|
| API リソース | 転送ルール、ターゲット プロキシ、URL マップ、バックエンド サービス。 | Gateway、Mesh、Route、バックエンド サービス。 |
| サービスの IP アドレスとポート番号 | サービスの IP アドレスとポート番号をプロビジョニングし、すべてのユースケースで IP:Port ペアに一致する転送ルールを構成する必要があります。 IP アドレスをホスト名に手動でマッピングするか、キャッチオール IP アドレス 0.0.0.0 を使用する必要があります。 |
Mesh または Gateway のユースケースでは、IP アドレスを構成する必要はありません。Gateway にはポート番号を構成する必要があります。 |
| サービス メッシュ スコープ | Traffic Director は、VPC ネットワークに接続されているすべてのプロキシを処理するため、メッシュ スコープは VPC ネットワークになります。 | Traffic Director は、VPC ネットワークに基づいてプロキシを処理しません。 East-West サービス間通信の場合、Envoy とプロキシレス gRPC クライアントは Mesh リソースの名前を使用します。North-South の Ingress ゲートウェイのユースケースでは、 Gateway API の scope パラメータを使用すると、複数の Gateways をグループ化し、マージされた構成を作成できます。 |
| 共有 VPC 環境でのプロジェクト間の参照 | プロジェクト間の参照はサポートされていません。すべての API リソースを同じプロジェクトで構成する必要があります。 | 一元管理されたプロジェクト（ホスト プロジェクト）に Mesh リソースまたは Gateway リソースを作成できます。サービス オーナーは、共有 VPC 環境のサービス プロジェクトに Route リソースを作成できます。Route リソースは、プロジェクト間に配置されている Mesh または Gateway を参照できます。 |
| インターセプト ポート | TRAFFICDIRECTOR_INTERCEPTION_PORT ブートストラップ パラメータは、Traffic Director に接続するすべての Envoy で指定する必要があります。Compute Engine API で自動 Envoy デプロイを行い、GKE で自動サイドカー インジェクションを行う場合、この値はデフォルトの 15001 になります。 |
インターセプト ポートは Mesh リソースで構成され、その Mesh の構成をリクエストするすべての Envoy に自動的に適用されます。指定されていない場合、値はデフォルトの 15001 になります。 |
Compute Engine と GKE での Envoy クライアントと gRPC クライアントのブートストラップ
| 古い API | サービス ルーティング API | |
|---|---|---|
| Compute Engine での自動 Envoy デプロイの使用 | VM テンプレートを作成するときに、コマンドライン パラメータ --service-proxy=enabled を指定します。これにより、必須属性を使用して Envoy プロキシが動的にブートストラップされます。 |
VM テンプレートを作成するときに、追加のパラメータを指定します。たとえば、--service-proxy=enabled、mesh=[MESH_NAME]（Mesh の場合）、--service-proxy=enabled, scope=[SCOPE_NAME]（Gateway の場合）などです。その他の必須属性は動的にブートストラップされます。Gateway として機能する Envoy の場合は、--service-proxy コマンドライン引数に serving_ports を指定しないでください。詳細については、自動 Envoy デプロイによる Compute Engine VM 設定のオプションをご覧ください。 |
| GKE での自動サイドカー インジェクションの使用 | サイドカー インジェクタの configMap で、必要なブートストラップ属性を指定します。 |
configMap で指定された新しい属性を含む同じワークフロー。 |
| GKE での手動サイドカー インジェクションの使用 | こちらで説明されているように、アプリケーション Pod には、必須属性でブートストラップされた Envoy サイドカー コンテナが必要です。 | 新しい属性を含む同じワークフロー。 |
| gRPC クライアントをデプロイするための Compute Engine または GKE の使用 | クライアント アプリケーションは、必須属性でブートストラップされる必要があります。 | 新しい属性を含む同じワークフロー。 |
メッシュとゲートウェイのセキュリティ ユースケースの構成
| 古い API | サービス ルーティング API | |
|---|---|---|
| GKE でのサービス間 mTLS | Envoy のサイドカー ベースのデプロイについては、こちらの手順を行ってください。 プロキシレス gRPC ベースのデプロイについては、こちらの手順を行ってください。 |
同じ手順を行います。 クライアント TLS ポリシーとサーバー TLS ポリシーは、それぞれバックエンド サービスとエンドポイント ポリシー リソースに適用する必要があります。これらの API はどちらもサービス ルーティング API に関係ないため、構成フローは以前と同じです。 |
| 中間プロキシ（Ingress ゲートウェイまたは Egress ゲートウェイ）のデプロイの保護 | この手順を行います。 サーバーの TLS ポリシーと承認ポリシー リソースは、ターゲット HTTPS プロキシ リソースに接続されています。 |
サーバーの TLS ポリシーと承認ポリシー リソースを Gateway に接続します。 |
考慮事項と制限事項
- Google Cloud コンソールでは、サービス ルーティング API はサポートされていません。
- xDS API バージョン 3 以降を使用してください。
- Envoy の最小バージョン 1.24.9。
- gRPC ブートストラップ ジェネレータの最小バージョン v0.14.0
TLSRouteリソースは、サイドカー プロキシまたはゲートウェイとしてデプロイされている Envoy プロキシでのみサポートされています。- 自動 Envoy デプロイを使用する Compute Engine VM と自動 Envoy インジェクションを使用する GKE Pod のみがサポートされます。サービス ルーティング API では手動デプロイを使用できません。
- このリリースでは Terraform はサポートされていません。
- サービス ルーティング 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 のプロジェクトとは異なるプロジェクト番号を指定できません。
次のステップ
- サービス ルーティング API で使用可能な構成については、Traffic Director サービス ルーティング設定ガイドをご覧ください。
- サービス ルーティング API については、ネットワーク サービス API のドキュメントをご覧ください。