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 を使用する場合は、次のガイドラインに従ってください。

  1. Cloud Service Mesh の転送ルールが 0.0.0.0 仮想 IP アドレス（VIP）を使用していることを確認します。
  2. 限定公開ゾーンがある場合は、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 サービスと通信しないようにするには、他のメカニズムを使用します。

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

ベスト プラクティス

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

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

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

サービス ディスカバリでの Service Directory の使用に関する構成の詳細。
サービス ディスカバリに Service Directory を使用するための構成の詳細（クリックして拡大）

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

  1. Cloud Service Mesh で新しいバックエンド サービスを作成し、バックエンド サービスへのバックエンドは作成しません。
  2. Service Directory サービスにグローバル サービス バインディングを作成します。

  3. このバックエンド サービスに Service Directory サービスをバインドします。必要に応じて、バックエンド サービスに追加のフィールドとポリシーを設定します。

  4. クライアント リクエストを新しいバックエンド サービスにルーティングできるように、新しいルーティング構成を作成するか、既存の構成を更新します。

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

統合を作成する

Cloud Service Mesh を Service Directory と統合するには、次の手順を行います。

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

Cloud Service Mesh のデプロイでバックエンド サービスを作成するには、次の手順を行います。

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

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

  2. 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

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

    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 リソースを作成します。

  1. 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"

  2. 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 が指定されている場合にパスマッチャーが使用されます。

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

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

  2. 既存の 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 のサービスを参照しています。

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

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

  2. 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 \

  3. 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 \

  4. 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 の使用（クリックして拡大）

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

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

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

  2. 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 \

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

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

  4. URL マップを編集して、テスト サービスへのリクエストをミラーリングします。

    gcloud compute url-maps edit my-url-map \
  --region=global

  5. 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 レベルの構成要素ではありません。

次のステップ