Service Directory との統合を設定する

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

Traffic Director を設定するには、ロードバランシング API ではなくサービスルーティング API を使用することを強くおすすめします。

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

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

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

Service Directory で使用するように Traffic Director を構成し、古いロードバランシング API を使用する場合は、次のガイドラインに沿ってください。

Traffic Director の転送ルールが 0.0.0.0 仮想 IP アドレス（VIP）を使用していることを確認します。
限定公開ゾーンがある場合は、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/"

ロールと権限の要件

Traffic Director のデプロイメントを作成する前に、次の権限とロールがあることを確認します。

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

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

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

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

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

Service Directory サービスへのアクセスを制限します。たとえば、ファイアウォールルールまたは Traffic Director の認可ポリシーを使用できます。
Service Directory サービスを削除します。
Traffic Director の構成を更新します。たとえば、バックエンドサービスからサービスバインディングを削除します。

ベストプラクティス

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

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

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

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

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

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

統合を作成する

Traffic Director を Service Directory に統合するには、次の手順を行います。

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

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

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 サービスをバインドした後、Traffic Director は、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

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

Traffic Director を使用すると、複数の 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

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

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

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

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

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

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

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

gcloud compute backend-services create payments-canary-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-canary-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-canary-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 は gcloud の構成要素です。API レベルの構成要素ではありません。

次のステップ

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

Service Directory との統合を設定する

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

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

ロールと権限の要件

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