Cloud Service Mesh と Traffic Director は Cloud Service Mesh になりました。詳細については、Cloud Service Mesh の概要をご覧ください。

Service Directory とのインテグレーションを設定する

このガイドは、実行中の Cloud Service Mesh デプロイがあり、少なくとも 1 つのサービスが Service Directory に登録されていることを前提としています。この設定手順は、Envoy とプロキシレス gRPC のどちらを使用する場合でも適用されます。

Service Directory と Cloud Service Mesh を使用するには、まずサービスを Service Directory に公開します。一般的な概要情報については、Service Directory へのサービスの公開または Service Directory のドキュメントをご覧ください。

サービスを Service Directory に登録したら、Cloud Service Mesh の API リソースを使用してサービスバインディングを作成します。サービスバインディングを参照するバックエンドサービスにはバックエンドや関連するヘルスチェックを設定できないため、Service Directory との統合に専用のバックエンドサービスを作成します。

ロードバランシング API を使用した Cloud Service Mesh 転送ルールとホストルールの要件

Service Directory で使用するように Cloud Service Mesh を構成したうえで古いロードバランシング API を使用する際は、次のガイドラインに沿って対応してください。

Cloud Service Mesh の転送ルールには必ず仮想 IP アドレス（VIP）0.0.0.0 を使用すること。
限定公開ゾーンがある場合は、Service Directory が Cloud DNS 限定公開ゾーンに構成した DNS 名が URL マップのホストルールに一致していること。

これらのガイドラインに沿っていない場合、アプリケーションからのアウトバウンドリクエストが失敗する可能性があります。

`network-services` API エンドポイントを設定する

バックエンドサービスを作成して使用する前に、network-services リソースの下にあるサービスバインディングリソースが正しく参照されるように、network-services API エンドポイントを設定します。次のコマンドを使用して、network-services API エンドポイントを設定します。

export CLOUDSDK_API_ENDPOINT_OVERRIDES_NETWORKSERVICES="https://networkservices.googleapis.com/"

ロールと権限の要件

Cloud Service Mesh のデプロイを作成する前に、次の権限とロールがあることを確認します。

サービスバインディングの権限とロール

このセクションでは、プロジェクトレベルのオーナー、編集者、閲覧者の権限について説明しません。リソースの作成、読み取り、更新、削除に必要な権限とロールについて説明します。

アクション	権限	ロール
サービスバインディングを作成します。	`networkservices.serviceBindings.create`	ネットワーク管理者
サービスバインディングを取得します。	`networkservices.serviceBindings.get`	ネットワーク管理者、ネットワーク閲覧者
Google Cloud プロジェクトのサービスバインディングを一覧にします。	`networkservices.serviceBindings.list`	ネットワーク管理者、ネットワーク閲覧者
サービスバインディングを更新します。	`networkservices.serviceBindings.update`	ネットワーク管理者
サービスバインディングを削除します。	`networkservices.serviceBindings.delete`	ネットワーク管理者

Service Directory サービスの権限

Service Directory 管理者は、Service Directory サービスにサービスバインディングを適用するサービスアカウントに servicedirectory.services.bind 権限を付与する必要があります。これにより、サービスアカウントが Service Directory サービスを使用できるようになります。つまり、アカウントはサービスバインディング内の Service Directory サービスを参照できるようになります。

権限の適用

IAM 権限のチェックは、Cloud Service Mesh を構成するときに行われます。サービスバインディングを作成し、サービスバインディングを特定の Service Directory サービスに関連付けるには、必要な権限が付与されている必要があります。正しい権限が付与されていれば、Service Directory サービスを学習し、トラフィックを送信するようにメッシュクライアントを構成できます。

これらのチェックは構成時に行われるため、既存の Service Directory サービスのバインディング権限を削除しても、トラフィックフローは中断されません。サービスバインディングを確立した後、権限を削除しても、メッシュクライアントが Service Directory サービスを学習してトラフィックを Service Directory サービスに送信できるかどうかに影響はありません。

メッシュクライアントが Service Directory サービスと通信しないようにするには、他のメカニズムを使用します。

Service Directory サービスへのアクセスを制限します。たとえば、ファイアウォールルールを使用できます。
Service Directory サービスを削除します。
バックエンドサービスからサービスバインディングを削除するなどして、Cloud Service Mesh の構成を更新します。

ベストプラクティス

Service Directory では Service Directory API を使用してエンドポイントを登録できますが、統合が利用可能になったら自動的に Service Directory に登録することをおすすめします。これらの統合の詳細については、GKE 用 Service Directory の概要と Service Directory と Cloud Load Balancing の概要をご覧ください。
サービスが複数のリージョンにまたがってデプロイされている場合でも、特定の論理サービスに同じ名前空間とサービスを使用することをおすすめします。

サービスディスカバリに Service Directory を使用する

次の図は、構成、システム間の相互作用、サービスのエンドポイントに対するリクエストの解決方法など、この構成手順の終了状態の概要を示しています。この例では、Service Directory に登録済みのサービスがすでにあることを前提としています。

次の手順で、Service Directory サービスを Cloud Service Mesh で使用できるようにします。

Cloud Service Mesh で新しいバックエンドサービスを作成します。バックエンドサービスのバックエンドは作成しません。
Service Directory サービスにグローバルサービスバインディングを作成します。
このバックエンドサービスに Service Directory サービスをバインドします。必要に応じて、バックエンドサービスに追加のフィールドとポリシーを設定します。
クライアントリクエストを新しいバックエンドサービスにルーティングできるように、新しいルーティング構成を作成するか、既存の構成を更新します。

サービスバインディングを参照するバックエンドサービスにヘルスチェックを設定することはできません。バックエンドサービスにはバックエンドも設定できません。

統合を作成する

Cloud Service Mesh を Service Directory と統合するには、次の手順で操作します。

バックエンドサービスを作成する

Cloud Service Mesh のデプロイでバックエンドサービスを作成するには、次の手順に沿って操作してください。

Service Directory サービスで使用するバックエンドサービスを作成します。

gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

Service Directory サービスを参照するサービスバインディングを作成します。

gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service

サービスをバックエンドサービスにバインドします。

gcloud beta compute backend-services update td-sd-demo-service \
 --global \
 --service-bindings my-sd-binding

バックエンドサービスを作成し、1 つ以上の Service Directory サービスをバインドすると、Cloud Service Mesh が Service Directory サービスに関連付けられているエンドポイントの追跡を開始します。エンドポイントは、個別の IP とポートのペアです。このサービスをルーティング可能にするには、ルーティングを構成する必要があります。

ルーティングを構成する

次の手順でルーティング構成を更新します。

サービスルーティング API

次の例では、sidecar- mesh という名前の Mesh リソースがあることを前提としています。ホスト名を myservice.example.com に設定し、宛先を前のセクションで作成したバックエンドサービス td-sd-demo-service に設定して、HTTPRoute リソースを作成します。

HTTPRoute 仕様を作成し、httproute.yaml というファイルに保存します。

name: td-sd-demo-route
hostnames:
‐ myservice.example.com
meshes:
‐ projects/PROJECT_NUMBER/locations/global/meshes/sidecar-mesh
rules:
‐ action:
  destinations:
  ‐ serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-sd-demo-service"

HTTPRoute の仕様をインポートします。

gcloud network-services httproutes import td-sd-demo-route \
  --source=httproute.yaml \
  --location=global

ロードバランシング API

次の例では、my-url-map という名前の URL マップを含む基本的なルーティング構成がすでにあることを前提としています。

まず、この URL マップのパスマッチャーを作成します。パスマッチャーは複雑ではありません。使用されると、前の手順で作成した td-sd-demo-service に解決されます。
次に、URL マップにホストルールを追加します。このホストルールにより、リクエストでホスト名 myservice.example.com が指定されている場合にパスマッチャーが使用されます。

バックエンドサービスを参照するシンプルなパスマッチャーを作成します。

gcloud compute url-maps add-path-matcher my-url-map \
 --global \
 --default-service td-sd-demo-service \
 --path-matcher-name my-path-matcher

既存の URL マップの新しいホストルールにバックエンドサービスをマッピングします。

gcloud compute url-maps add-host-rule my-url-map \
 --global \
 --path-matcher-name=my-path-matcher \
 --hosts=myservice.example.com

複数のリージョンから同じサービスを接続する

Cloud Service Mesh を使用すると、複数の Service Directory サービスを同じバックエンドサービスにバインドできます。たとえば、2 つの Service Directory サービスがあり、内容は同じでも、それぞれ異なる Google Cloud のリージョンまたはゾーンにエンドポイントが存在している、という構成にすることもできます。つまり、1 つのグローバルバックエンドサービスに 2 つのグローバルサービスバインディングがあり、1 つは us-east1 のサービスを参照し、もう 1 つは us-west1 のサービスを参照できるということです。

インポートした Service Directory サービスにバックエンドサービスを作成します。

gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

Service Directory サービスのサービスバインディングを us-east1 に作成します。

gcloud beta network-services service-bindings create us-east1-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

Service Directory サービスのサービスバインディングを us-west1 に作成します。

gcloud beta network-services service-bindings create us-west1-binding \
 --location global
 --service-directory-region us-west1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

us-east1 サービスと us-west1 サービスをバックエンドサービスにバインドします。

gcloud compute backend-services update td-sd-demo-service \
  --global \
  --service-bindings us-east1-binding,us-west1-binding

高度なトラフィック管理ポリシーを適用する

前のセクションでは、Cloud Service Mesh を使用して、既存の Service Directory サービスに対するルーティングポリシーを設定しました。このパターンは、より高度なトラフィック管理のシナリオにも使用できます。

次のシナリオを見てみましょう。Cloud Service Mesh メッシュの外部に既存のテストサービスがあるとします。このテストサービスは、内部アプリケーションロードバランサのバックエンドです。Cloud Service Mesh のメッシュ内で発生する一部の本番環境トラフィックを、この外部サービスに再送信するとします。Cloud Service Mesh は RequestMirrorPolicy を使用してこの処理を行うため、リクエストの処理時に別のバックエンドサービスにトラフィックを送信できます。このプロセスは「リクエストのシャドーイング」とも呼ばれ、本番環境のサービスに影響を与えることなくトラフィックを検査できます。

Envoy クライアントがテストサービスにトラフィックをシャドーイングするには、Cloud Service Mesh メッシュにテストサービスエンドポイントを手動で追加または削除します。ただし、Service Directory の統合を使用すると、プロセスがより簡単になります。

ミラーリングによるサービスディスカバリでの Service Directory の使用。 — ミラーリングによるサービスディスカバリでの Service Directory の使用（クリックして拡大）

この例では、まずバックエンドサービスの参照先を、決済のテストサービスの Service Directory 登録に設定します。次に、Cloud Service Mesh でサービスにリクエストミラーリングポリシーを追加します。

リクエストミラーリングポリシーにバックエンドサービスを作成します。

gcloud compute backend-services create payments-test-bes \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

Service Directory サービスを参照するサービスバインディングを作成します。

gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

Service Directory サービスをテストバックエンドサービスにバインドします。

gcloud beta compute backend-services update payments-test-bes \
 --global \
 --service-bindings my-sd-binding

URL マップを編集して、テストサービスへのリクエストをミラーリングします。
```
gcloud compute url-maps edit my-url-map \
  --region=global
```

URL マップ構成をエディタに読み込んだら、リクエストミラーポリシーを追加して、既存の Service Directory サービスにリクエストをミラーリングします。

defaultService: my-project/global/default-service
   hostRules:
    - hosts:
      - '*'
      pathMatcher: path-matcher-one
   pathMatchers:
    - defaultService: my-project/global/default-service
     name: path-matcher-one
     pathRules:
      - paths:
        - /payments/
        service: my-project/global/default-service
        requestMirrorPolicy:
          backendService: myproject/global/payments-test-bes

バックエンドサービスからサービスバインディングを削除する

バックエンドサービスからサービスバインディングを削除するには、サービスバインディングの新しいリストを gcloud compute backend-services update コマンドに渡します。新しいリストには、削除するサービスバインディングを含めないでください。

すべてのサービスバインディングを削除するには、--no-service-bindings フラグを設定します。
1 つ以上のサービスバインディングを削除するには、削除するサービスバインディングを除いた新しいサービスバインディングのリストを --service-bindings フラグに渡します。

サービスバインディングの追加または削除を行う

bind-service コマンドを使用すると、バックエンドサービスの既存のサービスバインディングのセットにサービスバインディングが追加されます。

gcloud compute backend-services bind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

unbind-service コマンドを使用すると、バックエンドサービスの既存のサービスバインディングのセットからサービスバインディングが削除されます。

gcloud compute backend-services unbind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

コマンド bind-service と unbind-service は Google Cloud CLI の構成要素です。API レベルの構成要素ではありません。

次のステップ

この統合によるオブザーバビリティの詳細については、Service Directory によるオブザーバビリティとデバッグをご覧ください。

Service Directory とのインテグレーションを設定する

ロード バランシング API を使用した Cloud Service Mesh 転送ルールとホストルールの要件

network-services API エンドポイントを設定する

ロールと権限の要件

サービス バインディングの権限とロール