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

このページは Cloud Translation API によって翻訳されました。

プロジェクト間のネットワークエンドポイントグループを設定する

プロジェクト間のネットワークエンドポイントグループ（NEG）機能を使用すると、別のプロジェクトの NEG を Traffic Director または Cloud Service Mesh BackendService にアタッチして、次のユースケースを実現できます。

マルチプロジェクトのデプロイでは、BackendServices と、関連するルーティングポリシーとトラフィックポリシーが、異なるプロジェクトのバックエンドエンドポイントを持つ一元化されたプロジェクトに存在します。
マルチプロジェクトデプロイでは、すべてのコンピューティングリソース（Compute Engine VM、GKE NEG など）を単一の中央のGoogle Cloud プロジェクトで管理できます。サービスチームは、それぞれが BackendServices で表されるサービスポリシーと、それぞれのサービスプロジェクトのサービスルーティングルートを定義する Google Cloud サービスプロジェクトを所有します。これにより、異なるサービスチーム間で共有されるコンピューティングリソースを厳密に制御しながら、サービスの管理を委任できます。

このページでは、プロジェクト A の NEG（ワークロードプロジェクト）がプロジェクト B の BackendService（ポリシープロジェクト）に接続されているベースラインの 2 つのプロジェクト設定を作成する方法について説明します。次の例では、ワークロードプロジェクトのデフォルトの VPC ネットワークにワークロード VM を設定し、ポリシープロジェクトの構成に基づいてクライアントがワークロードプロジェクトに転送できることを示します。

ベースラインのクロスプロジェクト NEG の例

より複雑な設定では、複数のプロジェクトにまたがる相互接続されたデータプレーンには、共有 VPC などのソリューションが必要です。また、NEG エンドポイントには一意の IP があることも意味します。この設定例は、ワークロードが複数のプロジェクトにまたがる共有 VPC ネットワークにある、より複雑なシナリオに拡張できます。

制限事項

一般的な Traffic Director の制限事項と BackendService/NetworkEndpointGroup の制限事項が適用されます。

次の制限も適用されますが、マルチプロジェクト設定に固有のものではありません。

1 つの BackendService でサポートできるバックエンド（NEG、MIG を含む）は最大 50 個です。
GCP_VM_IP_PORT タイプのゾーン NEG のみがサポートされます。
プロジェクト間の BackendServices からインスタンスグループ（マネージドまたは非マネージド）への参照はサポートされていません。
特定の BackendService に接続できるプロジェクト間の NEG を一覧表示することはできません。
特定の NEG を使用しているプロジェクト間の BackendService を一覧表示することはできません。

始める前に

プロジェクト間の NEG を設定するには、次の前提条件を満たす必要があります。

必要な API を有効にする

このガイドを完了するには、以下の API が必要です。

osconfig.googleapis.com
trafficdirector.googleapis.com
compute.googleapis.com
networkservices.googleapis.com

次のコマンドを実行して、ワークロードプロジェクトとポリシープロジェクトの両方で必要な API を有効にします。

gcloud services enable --project PROJECT_ID \
    osconfig.googleapis.com \
    trafficdirector.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

必要な IAM 権限を付与する

このガイドを完了するには、十分な Identity and Access Management（IAM）権限が必要です。Cloud Service Mesh を有効にするプロジェクトのオーナーまたは編集者（roles/owner または roles/editor）のロールがある場合は、適切な権限が自動的に付与されます。

それ以外の場合は、次の IAM ロールをすべて付与する必要があります。これらのロールがある場合、Compute Engine IAM ドキュメントで説明されているように、関連する権限も付与されます。

ワークロードプロジェクトとポリシープロジェクトの両方で、次のロールが必要です。

roles/iam.serviceAccountAdmin
roles/serviceusage.serviceUsageAdmin
roles/compute.networkAdmin

次のロールは、ワークロードプロジェクトでのみ必要です。

roles/compute.securityAdmin
roles/container.admin
次の権限を含むロール。NEG を BackendService に接続するために必要なすべての権限を含む最も詳細な事前定義ロールは、roles/compute.loadBalancerServiceUser です。
- compute.networkEndpointGroups.get
- compute.networkEndpointGroups.use

また、Traffic Director で管理される xDS クライアント（Envoy プロキシなど）には、roles/trafficdirector.client の権限が必要です。デモ用に、次のコマンドを使用して、ポリシープロジェクトでこの権限をワークロードプロジェクトのデフォルトのコンピューティングサービスアカウントに付与します。

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:WORKLOAD_PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role "roles/trafficdirector.client"

ここで

POLICY_PROJECT_ID はポリシープロジェクトの ID です。
WORKLOAD_PROJECT_NUMBER は、ワークロードプロジェクトのプロジェクト番号です。

ワークロードプロジェクトでサービスバックエンドを構成する

次のコマンドを実行して Google Cloud CLI をポリシープロジェクトにポイントし、優先する Google Cloud コンピューティングゾーンを設定します。
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
ここで
- WORKLOAD_PROJECT_ID は、ワークロードプロジェクトの ID です。
- ZONE は GKE クラスタのゾーンです（例: us-central1）。
GKE クラスタを作成する。デモ用に、次のコマンドでゾーン GKE クラスタを作成します。ただし、この機能はリージョン GKE クラスタでも機能します。
```
gcloud container clusters create test-cluster \
    --scopes=https://www.googleapis.com/auth/cloud-platform
    --zone=ZONE
```
ファイアウォールルールを作成します。
```
gcloud compute firewall-rules create http-allow-health-checks \
    --network=default \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --rules=tcp:80
```
ファイアウォールルールにより、 Google Cloud コントロールプレーンは、デフォルトの VPC ネットワーク内のバックエンドにヘルスチェックプローブを送信できます。
kubectl の現在のコンテキストを新しく作成したクラスタに変更します。
```
gcloud container clusters get-credentials test-cluster \
    --zone=ZONE
```

whereami サンプルアプリを作成してデプロイします。

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami
  template:
    metadata:
      labels:
        app: whereami
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: whereami
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-neg"}}}'
spec:
  selector:
    app: whereami
  ports:
  - port: 8080
    targetPort: 8080
EOF

次のコマンドを実行して、NEG への参照を変数に格納します。
```
NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
```
NEG コントローラは、各ゾーンのサービスバックエンドにゾーン NetworkEndpointGroup を自動的に作成します。この例では、NEG 名は example-neg にハードコードされています。変数として保存すると、次のセッションでこの NEG をポリシープロジェクトの BackendService に接続するときに役立ちます。

$NEG_LINK の例は次のようになります。
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
または、サービスの neg-status アノテーションを読み取ることで、NEG URL を取得することもできます。
```
kubectl get service whereami -o jsonpath="{.metadata.annotations['cloud\.google\.com/neg-status']}"
NEG_LINK="https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT_ID/zones/ZONE/networkEndpointGroups/example-neg"
```

ポリシープロジェクトで Google Cloud ネットワーキングリソースを構成する

Google Cloud CLI をポリシープロジェクトに指すようにします。
```
gcloud config set project POLICY_PROJECT_ID
```
メッシュリソースを構成します。
```
gcloud network-services meshes import example-mesh --source=- --location=global << EOF
name: example-mesh
EOF
```
メッシュリソースの名前は、サイドカープロキシがサービスメッシュの構成をリクエストするために使用する鍵です。

ヘルスチェックを使用してベースライン BackendService を構成します。

gcloud compute health-checks create http http-example-health-check

gcloud compute backend-services create example-service \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --protocol=HTTP \
  --health-checks http-example-health-check

前のセクションで作成した NetworkEndpointGroup を BackendService に接続します。

gcloud compute backend-services add-backend example-service --global \
  --network-endpoint-group=${NEG_LINK} \
  --balancing-mode=RATE \
  --max-rate-per-endpoint=5

ホストヘッダー example-service を含むすべての HTTP リクエストをワークロードプロジェクトのサーバーに転送する HTTPRoute を作成します。

gcloud network-services http-routes import example-route --source=- --location=global << EOF
name: example-route
hostnames:
- example-service
meshes:
- projects/POLICY_PROJECT_NUMBER/locations/global/meshes/example-mesh
rules:
- action:
    destinations:
    - serviceName: "projects/POLICY_PROJECT_NUMBER/locations/global/backendServices/example-service"
EOF

ここで、POLICY_PROJECT_NUMBER はポリシープロジェクトのプロジェクト番号です。

設定を確認する

設定を確認するには、HOST ヘッダーを example-service に設定した HTTP リクエストを、Traffic Director 管理のサイドカープロキシの背後にある VIP に送信します。

curl -H "Host: example-service" http://10.0.0.1/

出力は次のようになります。

{"cluster_name":"test-cluster","gce_instance_id":"4879146330986909656","gce_service_account":"...","host_header":"example-service","pod_name":"whereami-7fbffd489-nhkfg","pod_name_emoji":"...","project_id":"...","timestamp":"2024-10-15T00:42:22","zone":"us-west1-a"}

Pod からのすべてのアウトバウンドトラフィックは、サービスメッシュ内の Envoy サイドカーによってインターセプトされ、前の HTTPRoute は L7 属性（ホストヘッダー）のみに基づいて、すべてのトラフィックを「whereami」Kubernetes Service に送信するように構成されていることに注意してください。このコマンドの VIP は 10.0.0.1 ですが、VIP には任意の IP を使用できます。

サイドカープロキシは、ポリシープロジェクトのメッシュリソースに関連付けられた構成をリクエストする必要があります。そのためには、ノード ID が次の形式で設定されていることを確認します。

projects/POLICY_PROJECT_NUMBER/networks/mesh:example-mesh/nodes/UUID"

次のステップ

プロジェクト間のメッシュルートを設定する