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

自動 Envoy インジェクションを使用して Google Kubernetes Engine Pod を設定する

概要

サービスメッシュでは、アプリケーションコードでネットワーク構成を認識する必要はありません。アプリケーションはデータプレーンを介して通信を行います。データプレーンは、サービスネットワーキングを処理するコントロールプレーンによって構成されます。このガイドでは、Cloud Service Mesh がコントロールプレーンに、Envoy サイドカープロキシがデータプレーンになります。

Google マネージド Envoy サイドカーインジェクタは、Envoy サイドカープロキシを Google Kubernetes Engine Pod に追加します。Envoy サイドカーインジェクタは、プロキシを追加するときに、アプリケーショントラフィックを処理し、Cloud Service Mesh に接続して構成を行うようにプロキシを設定します。

このガイドでは、Google Kubernetes Engine を使用した Cloud Service Mesh の簡単な設定について説明します。この手順を応用することで、複数の Google Kubernetes Engine クラスタや、複数の Compute Engine VM にまたがるサービスメッシュなど、高度な構成を行うことができます。共有 VPC を使用して Cloud Service Mesh を構成する場合にも、これらの手順を使用できます。

設定プロセスでは、次の操作を行います。

ワークロード用の GKE クラスタを作成する。
Envoy サイドカーインジェクタをインストールし、インジェクションを有効にする。
サンプルクライアントをデプロイし、インジェクションを検証する。
テスト用の Kubernetes Service をデプロイする。
Cloud Load Balancing コンポーネントを使用して Cloud Service Mesh を構成し、トラフィックをテストサービスにルーティングする。
サンプルクライアントからテストサービスにリクエストを送信して、構成を確認する。

前提条件

このガイドの手順に進む前に、Envoy とプロキシレスワークロードを使用したサービスルーティング API を設定する準備で説明されている前提条件のタスクを完了します。

サポートされている Envoy のバージョンについては、Cloud Service Mesh リリースノートをご覧ください。

共有 VPC の追加の前提条件

共有 VPC 環境で Cloud Service Mesh を設定する場合は、次の点に注意してください。

共有 VPC に対する適切な権限とロールがある。
正しいプロジェクトと請求が設定されている。
プロジェクトで請求が有効になっている。
ホストプロジェクトを含む各プロジェクトで、Cloud Service Mesh と GKE API が有効になっている。
プロジェクトごとに適切なサービスアカウントが設定されている。
VPC ネットワークとサブネットが作成されている。
共有 VPC が有効になっている。

詳しくは、共有 VPC をご覧ください。

IAM ロールを構成する

この IAM ロール構成の例では、共有 VPC のホストプロジェクトに 2 つのサブネットがあり、共有 VPC に 2 つのサービスプロジェクトがあることを前提としています。

Cloud Shell で、このセクションに関連するファイルを作成する作業フォルダ（WORKDIR)）を作成します。
```
mkdir -p ~/td-shared-vpc
cd ~/td-shared-vpc
export WORKDIR=$(pwd)
```

ホストプロジェクトで IAM 権限を構成して、サービスプロジェクトが共有 VPC のリソースを使用できるようにします。

このステップでは、サービスプロジェクト 1 から subnet-1 にアクセスできるように、またサービスプロジェクト 2 から subnet-2 にアクセスできるように IAM 権限を構成します。Compute ネットワークユーザーの IAM ロール（roles/compute.networkUser）を、各サブネットのそれぞれのサービスプロジェクトの Compute Engine コンピューティングのデフォルトのサービスアカウントと、Google Cloud API サービスアカウントの両方に割り当てます。

サービスプロジェクト 1 の場合は、subnet-1 の IAM 権限を構成します。

export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')

cat > subnet-1-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_1_API_SA}
  - serviceAccount:${SVC_PROJECT_1_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_1_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-1 \
subnet-1-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_1}

サービスプロジェクト 2 の場合は、subnet-2 の IAM 権限を構成します。

export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')

cat > subnet-2-policy.yaml <<EOF
bindings:
- members:
  - serviceAccount:${SVC_PROJECT_2_API_SA}
  - serviceAccount:${SVC_PROJECT_2_GKE_SA}
  role: roles/compute.networkUser
etag: ${SUBNET_2_ETAG}
EOF

gcloud beta compute networks subnets set-iam-policy subnet-2 \
subnet-2-policy.yaml \
    --project ${HOST_PROJECT} \
    --region ${REGION_2}

各サービスプロジェクトで、ホストプロジェクトの GKE サービスアカウントに Kubernetes Engine Host サービスエージェントユーザーの IAM ロール（roles/container.hostServiceAgentUser）を付与する必要があります。
```
gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
    --role roles/container.hostServiceAgentUser

gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
    --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
    --role roles/container.hostServiceAgentUser
```
このロールにより、サービスプロジェクトの GKE サービスアカウントは、ホストプロジェクトの GKE サービスアカウントを使用して共有ネットワークリソースを構成できます。
各サービスプロジェクトで、ホストプロジェクトの Compute ネットワーク閲覧者 IAM ロール（roles/compute.networkViewer）を Compute Engine のデフォルトサービスアカウントに付与します。
```
gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
    --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
    --role roles/compute.networkViewer

gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
    --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
    --role roles/compute.networkViewer
```
Envoy サイドカープロキシが xDS サービス（Traffic Director API）に接続すると、プロキシは、Compute Engine 仮想マシン（VM）ホストまたは GKE ノードインスタンスのサービスアカウントを使用します。サービスアカウントには compute.globalForwardingRules.get プロジェクトレベルの IAM 権限が必要です。このステップでは、Compute ネットワーク閲覧者のロールで十分です。

プロジェクト情報を構成する

Google Cloud プロジェクトをまだ作成していない場合や、Google Cloud CLI をまだインストールしていない場合は、こちらの手順に沿って操作します。kubectl をまだインストールしていない場合は、こちらの手順に沿ってインストールします。

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should match the channel of your GKE cluster.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

新しいサービスルーティング API を使用している場合は、次の手順で MESH_NAME、MESH_PROJECT_NUMBER、TARGET を設定します。

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

ほとんどのシナリオでは、CLUSTER_PROJECT_ID と MESH_PROJECT_NUMBER は同じプロジェクトを参照します。ただし、共有 VPC を使用するなど、別のプロジェクトを設定する場合、CLUSTER_PROJECT_ID は GKE クラスタを含むプロジェクト ID を指し、MESH_PROJECT_NUMBER はリソースを含むプロジェクト番号を指します。挿入された Envoy が設定を取得できるように、適切な権限が設定されていることを確認してください。

Mesh Config API を有効にする

Google マネージドサイドカーインジェクタの使用を開始するには、次の API を有効にします。

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

ワークロード用の GKE クラスタの作成

GKE クラスタで Cloud Service Mesh を使用するには、次の要件を満たす必要があります。

ネットワークエンドポイントグループのサポートを有効にする必要があります。詳細と例については、スタンドアロンのネットワークエンドポイントグループをご覧ください。
GKE ノードと Pod のサービスアカウントには、Traffic Director API にアクセスする権限が必要です。必要な権限の詳細については、サービスアカウントを有効にして Traffic Director API にアクセスするをご覧ください。

GKE クラスタの作成

優先ゾーン（us-central1-a など）に GKE クラスタを作成します。

gcloud container clusters create YOUR_CLUSTER_NAME \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

kubectl に新しく作成されたクラスタを指定する

次のコマンドを実行して、kubectl の現在のコンテキストを新しく作成したクラスタに変更します。

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Mutating Webhook の構成を適用する

以下のセクションでは、MutatingWebhookConfiguration をクラスタに適用する手順について説明します。Pod が作成されると、クラスタ内アドミッションコントローラが呼び出されます。アドミッションコントローラは、マネージドサイドカーインジェクタと通信して、Envoy コンテナを Pod に追加します。

次の mutating webhook 構成をクラスタに適用します。

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

サイドカーインジェクションを有効にする

次のコマンドは、default Namespace のインジェクションを有効にします。サイドカーインジェクタは、この Namespace の下に作成された Pod にサイドカーコンテナを挿入します。

kubectl label namespace default td-injection=enabled

次のコマンドを実行して、default Namespace が適切に有効化されていることを確認できます。

kubectl get namespace -L td-injection

次のような出力が返されます

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Envoy で Cloud Service Mesh のサービスセキュリティを構成する場合は、対象の設定ガイドでテストサービスの設定セクションに戻ってご確認ください。

サンプルクライアントをデプロイしてインジェクションを検証する

このセクションでは、Busybox を実行するサンプル Pod のデプロイ方法について説明します。これは、テストサービスにアクセスするためのシンプルなインターフェースを提供します。実際の環境では、独自のクライアントアプリケーションをデプロイします。

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

Busybox Pod は 2 つのコンテナから構成されています。1 つは Busybox イメージをベースにしたクライアントで、もう 1 つはサイドカーインジェクタによって挿入された Envoy プロキシです。次のコマンドを実行すると、Pod に関する詳細情報を取得できます。

kubectl describe pods -l run=client

次のような出力が返されます

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Cloud Service Mesh Proxy

マネージドサイドカーインジェクタは、Cloud Service Mesh Proxy イメージをプロキシとして使用します。Cloud Service Mesh プロキシは、メッシュ対応インスタンスの Envoy プロキシの起動を担うサイドカーコンテナです。プロキシイメージは、OSS envoy イメージとともに、envoy の起動、ブートストラップ構成の提供、envoy のヘルスチェックを行うプロキシエージェントを使用します。Cloud Service Mesh Proxy イメージのバージョンは、OSS Envoy のバージョンと一致します。利用可能なプロキシイメージのトラッキングは、https://gcr.io/gke-release/asm/csm-mesh-proxy で確認できます。

挿入される Cloud Service Mesh Proxy は、ユーザーが GKE クラスタに選択したチャネルによって異なります。Envoy バージョンは、現在の OSS Envoy リリースに基づいて定期的に更新され、特定の GKE リリースでテストされて互換性が確認されています。

Cloud Service Mesh Proxy のバージョン

次の表は、現在の GKE クラスタチャンネルと Cloud Service Mesh Proxy バージョンのマッピングを示しています。

チャネル	Cloud Service Mesh Proxy のバージョン
Rapid	1.29.9-gke.3
標準	1.28.7-gke.3
Stable	1.27.7-gke.3

Cloud Service Mesh Proxy のアップグレード

最新バージョンにアップグレードすることを強くおすすめします。コントロールプレーンとプロキシのバージョンが異なる場合は、サービスメッシュに問題はありませんが、新しい Cloud Service Mesh バージョンを使用して構成されるようにプロキシを更新することをおすすめします。

マネージドサイドカーインジェクタは Envoy のバージョンを処理し、常に Google が認定した最新の Envoy バージョンを挿入します。Cloud Service Mesh Proxy のバージョンがプロキシバージョンより新しい場合は、サービスのプロキシを再起動します。

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

テスト用の Kubernetes Service をデプロイする

以降のセクションでは、テストサービスの設定手順について説明します。このサービスは、このガイドの後半でセットアップをエンドツーエンドで検証する際に使用します。

NEG を使用して GKE サービスを構成する

GKE サービスは、Cloud Service Mesh バックエンドサービスのバックエンドとして構成できるように、ネットワークエンドポイントグループ（NEG）で公開されている必要があります。Kubernetes サービス仕様に NEG アノテーションを追加し、後で簡単に見つけられるように名前を選択します（以下のサンプルで NEG-NAME と置き換えます）。この名前は、NEG を Cloud Service Mesh バックエンドサービスに接続するときに必要となります。NEG のアノテーションの詳細については、NEG に名前を付けるをご覧ください。

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

このアノテーションは、サービスの Pod の IP アドレスとポートに対応するエンドポイントを含むスタンドアロン NEG を作成します。詳細と例については、スタンドアロンのネットワークエンドポイントグループをご覧ください。

次のサンプルサービスには、NEG アノテーションが含まれています。このサービスは、ポート 80 で HTTP を介してホスト名を提供します。次のコマンドを使用してサービスを取得し、GKE クラスタにデプロイします。

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

新しいサービスが作成され、アプリケーション Pod が実行されていることを確認します。

kubectl get svc

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

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

このサービスに関連付けられたアプリケーション Pod が実行されていることを確認します。

kubectl get pods

次の結果が返されます。

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

NEG の名前を保存する

上記の例で作成した NEG を探して名前を記録します。この名前は、次のセクションの Cloud Service Mesh の構成で使用します。

gcloud compute network-endpoint-groups list

これにより、次の結果が返されます。

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

NEG の名前を NEG_NAME 変数に保存します。

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Cloud Load Balancing コンポーネントを使用した Cloud Service Mesh を構成する

このセクションでは、Compute Engine 負荷分散リソースを使用して Cloud Service Mesh を構成します。これにより、サンプルクライアントのサイドカープロキシが Cloud Service Mesh から構成を受信できるようになります。サンプルクライアントからの送信リクエストは、サイドカープロキシによって処理され、テストサービスにルーティングされます。

以下のコンポーネントを構成する必要があります。

ヘルスチェック。ヘルスチェックの詳細については、ヘルスチェックのコンセプトとヘルスチェックの作成をご覧ください。
バックエンドサービス。バックエンドサービスの詳細については、バックエンドサービスをご覧ください。
ルーティングルールマップ。これには、転送ルールの作成、ターゲット HTTP プロキシ、URL マップの作成が含まれます。詳細については、Cloud Service Mesh の転送ルールの使用、Cloud Service Mesh のターゲットプロキシの使用、URL マップの使用をご覧ください。。

ヘルスチェックとファイアウォールルールを作成する

ヘルスチェックと、ヘルスチェックプローブに必要なファイアウォールルールを作成するには、次の手順を行います。詳細については、ヘルスチェックのファイアウォールルールをご覧ください。

コンソール

Google Cloud コンソールの [ヘルスチェック] ページに移動します。
[ヘルスチェック] ページに移動
[ヘルスチェックを作成] をクリックします。
[名前] に「td-gke-health-check」と入力します。
プロトコルとして [HTTP] を選択します。
[作成] をクリックします。
Google Cloud コンソールの [ファイアウォールポリシー] ページに移動します。
[ファイアウォールポリシー] ページに移動
[ファイアウォールルールを作成] をクリックします。
ファイアウォールルールの作成ページで、次の情報を入力します。
- 名前: ルールの名前を指定します。この例では、fw-allow-health-checks を使用します。
- ネットワーク: VPC ネットワークを選択します。
- 優先度: 優先度の数値を入力します。数字が小さいほど優先度が高くなります。このファイアウォールルールには、上りトラフィックを拒否する可能性があるその他のルールよりも高い優先度を設定してください。
- トラフィックの方向: [内向き（上り）] を選択します。
- 一致したときのアクション: [許可] を選択します。
- ターゲット: [ネットワーク内のすべてのインスタンス] を選択します。
- ソースフィルタ: 正しい IP 範囲タイプを選択します。
- ソース IP の範囲: 35.191.0.0/16,130.211.0.0/22
- 送信先フィルタ: IP のタイプを選択します。
- プロトコルとポート: [指定したプロトコルとポート] をクリックして、tcp のチェックボックスをオンにします。TCP は、すべてのヘルスチェックプロトコルの基礎となるプロトコルです。
- [作成] をクリックします。

gcloud

ヘルスチェックを作成します。

gcloud compute health-checks create http td-gke-health-check \
  --use-serving-port

ヘルスチェッカーの IP アドレス範囲を許可するファイアウォールルールを作成します。

gcloud compute firewall-rules create fw-allow-health-checks \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --rules tcp

バックエンドサービスの作成

INTERNAL_SELF_MANAGED の負荷分散方式でグローバルバックエンドサービスを作成します。Google Cloud コンソールでは、ロードバランシング方式は暗黙的に設定されます。ヘルスチェックをバックエンドサービスに追加します。

コンソール

Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
[Cloud Service Mesh] ページに移動
[サービス] タブで、[サービスを作成] をクリックします。
[続行] をクリックします。
サービス名に「td-gke-service」と入力します。
Cloud Service Mesh ConfigMap で構成した [ネットワーク] を選択します。
[バックエンドタイプ] で [ネットワークエンドポイントグループ] を選択します。
作成したネットワークエンドポイントグループを選択します。
[最大 RPS] を 5 に設定します。
[分散モード] を [レート] に設定します。
[完了] をクリックします。
[ヘルスチェック] で、作成したヘルスチェック（td-gke-health-check）を選択します。
[続行] をクリックします。

gcloud

バックエンドサービスを作成し、バックエンドサービスにヘルスチェックを関連付けます。

gcloud compute backend-services create td-gke-service \
 --global \
 --health-checks td-gke-health-check \
 --load-balancing-scheme INTERNAL_SELF_MANAGED

前に作成した NEG をバックエンドとしてバックエンドサービスに追加します。ターゲット TCP プロキシを使用して Cloud Service Mesh を構成する場合は、UTILIZATION 分散モードを使用する必要があります。HTTP または HTTPS ターゲットプロキシを使用している場合は、RATE モードを使用できます。
```
gcloud compute backend-services add-backend td-gke-service \
 --global \
 --network-endpoint-group ${NEG_NAME} \
 --network-endpoint-group-zone ZONE \
 --balancing-mode [RATE | UTILIZATION] \
 --max-rate-per-endpoint 5
```

ルーティングルールマップの作成

ルーティングルールマップは、Cloud Service Mesh がメッシュ内のトラフィックをルーティングする方法を定義します。ルーティングルールマップの一部として、仮想 IP（VIP）アドレスと、ホストベースのルーティングなど関連する一連のトラフィック管理ルールを構成します。アプリケーションが VIP にリクエストを送信すると、接続された Envoy サイドカープロキシが次の処理を行います。

リクエストをインターセプトします。
URL マップのトラフィック管理ルールに従って評価します。
リクエスト内のホスト名に基づいてバックエンドサービスを選択します。
選択したバックエンドサービスに関連付けられているバックエンドまたはエンドポイントを選択します。
そのバックエンドまたはエンドポイントにトラフィックを送信します。

Console

Console では、ターゲットプロキシは転送ルールと組み合わされます。転送ルールを作成すると、Google Cloud によってターゲット HTTP プロキシが自動的に作成され、URL マップに接続されます。

ルートルールは、転送ルールおよびホストとパスのルール（URL マップ）で構成されます。

Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。
[Cloud Service Mesh] ページに移動
[ルーティングルールマップ] をクリックします。
[ルーティングルールを作成] をクリックします。
URL マップの [名前] に「td-gke-url-map」と入力します。
[転送ルールを追加] をクリックします。
転送ルール名に「td-gke-forwarding-rule」と入力します。
ネットワークを選択します。
[内部 IP] を選択します。
[保存] をクリックします。
必要に応じて、カスタムホストとパスのルールを追加するか、パスルールをデフォルトのままにします。
ホストを service-test に設定します。
[保存] をクリックします。

gcloud

td-gke-service をデフォルトのバックエンドサービスとして使用する URL マップを作成します。
```
gcloud compute url-maps create td-gke-url-map \
   --default-service td-gke-service
```
ホスト名とパスに基づいてサービスのトラフィックをルーティングする URL マップのパスマッチャーとホストルールを作成します。この例では、サービス名として service-test を使用し、このホスト（/*）のすべてのパスリクエストに一致するデフォルトのパスマッチャーを使用します。
```
gcloud compute url-maps add-path-matcher td-gke-url-map \
   --default-service td-gke-service \
   --path-matcher-name td-gke-path-matcher

gcloud compute url-maps add-host-rule td-gke-url-map \
   --hosts service-test \
   --path-matcher-name td-gke-path-matcher
```

ターゲット HTTP プロキシを作成します。

gcloud compute target-http-proxies create td-gke-proxy \
   --url-map td-gke-url-map

転送ルールを作成します。

gcloud compute forwarding-rules create td-gke-forwarding-rule \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --address=0.0.0.0 \
  --target-http-proxy=td-gke-proxy \
  --ports 80 --network default

この時点で、Cloud Service Mesh は、service-test ホスト名を指定するリクエストを td-gke-service のバックエンドにルーティングするようにサイドカープロキシを構成します。この場合は、以前にデプロイした Kubernetes テストサービスに関連付けられているネットワークエンドポイントグループのエンドポイントになります。

構成の確認

このセクションでは、サンプルの Busybox クライアントから送信されたトラフィックが service-test Kubernetes Service にルーティングされているかどうか検証します。テストリクエストを送信するには、コンテナの 1 つでシェルにアクセスし、次の検証コマンドを実行します。service-test Pod が処理中の Pod のホスト名を返します。

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

構成を確認する方法は次のとおりです。

サンプルクライアントから、service-test ホスト名を指定するリクエストを送信します。
サンプルクライアントには Envoy サイドカーインジェクタによって Envoy サイドカープロキシが挿入されています。
サイドカープロキシがリクエストをインターセプトします。
Envoy が URL マップを使用して service-test ホスト名と td-gke-service Cloud Service Mesh サービスと照合します。
Envoy が td-gke-service に関連付けられたネットワークエンドポイントグループからエンドポイントを選択します。
Envoy が service-test Kubernetes Service に関連付けられた Pod にリクエストを送信します。

マネージドサイドカーインジェクタに移行する方法

このチュートリアルでは、GKE の従来の Cloud Service Mesh サイドカーインジェクタ（クラスタ内サイドカーインジェクタを使用）から、マネージドサイドカーインジェクタを使用するアプリケーションにアプリケーションを移行する手順について説明します。

クラスタ内サイドカーインジェクションを無効にする

次のコマンドは、デフォルト名前空間の従来のクラスタ内サイドカーインジェクタを無効にします。

kubectl label namespace default istio-injection-

クラスタ内サイドカーインジェクタのクリーンアップ

Envoy サイドカーインジェクタをダウンロードして展開します。

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

クラスタ内サイドカーインジェクタリソースを削除する

kubectl delete -f specs/

次のステップ

高度なトラフィック管理について確認する。
Cloud Service Mesh サービスセキュリティについて学習する。
Envoy によるオブザーバビリティの設定方法について確認する。
Cloud Service Mesh のデプロイに関するトラブルシューティング方法について学習する。
自動 Envoy インジェクションを使用した Google Kubernetes Engine Pod の設定オプションについて確認する。

自動 Envoy インジェクションを使用して Google Kubernetes Engine Pod を設定する

概要

前提条件

共有 VPC の追加の前提条件

IAM ロールを構成する

プロジェクト情報を構成する

Mesh Config API を有効にする

ワークロード用の GKE クラスタの作成

GKE クラスタの作成

kubectl に新しく作成されたクラスタを指定する

Mutating Webhook の構成を適用する

サイドカー インジェクションを有効にする

サンプル クライアントをデプロイしてインジェクションを検証する

Cloud Service Mesh Proxy

Cloud Service Mesh Proxy のバージョン

Cloud Service Mesh Proxy のアップグレード

テスト用の Kubernetes Service をデプロイする

NEG を使用して GKE サービスを構成する

NEG の名前を保存する

Cloud Load Balancing コンポーネントを使用した Cloud Service Mesh を構成する

ヘルスチェックとファイアウォール ルールを作成する

コンソール

gcloud

バックエンド サービスの作成

コンソール

gcloud

ルーティング ルール マップの作成

Console

gcloud

構成の確認

マネージド サイドカー インジェクタに移行する方法

クラスタ内サイドカー インジェクションを無効にする

クラスタ内サイドカー インジェクタのクリーンアップ

次のステップ

サイドカーインジェクションを有効にする

サンプルクライアントをデプロイしてインジェクションを検証する

ヘルスチェックとファイアウォールルールを作成する

バックエンドサービスの作成

ルーティングルールマップの作成

マネージドサイドカーインジェクタに移行する方法

クラスタ内サイドカーインジェクションを無効にする

クラスタ内サイドカーインジェクタのクリーンアップ