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

概要

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

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

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

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

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

前提条件

このガイドの手順に進む前に、Traffic Director の設定の準備を確認し、ドキュメントに記載されている前提条件のタスクを完了していることを確認してください。

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

共有 VPC の追加の前提条件

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

共有 VPC に対する適切な権限とロールがある。
正しいプロジェクトと請求が設定されている。
プロジェクトで請求が有効になっている。
ホストプロジェクトを含む各プロジェクトで、Traffic Director と 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 ネットワーク閲覧者のロールで十分です。

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

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

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

GKE クラスタの作成

優先ゾーン（us-central1-a など）に traffic-director-cluster という名前の GKE クラスタを作成します。

gcloud container clusters create traffic-director-cluster \
  --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

Envoy サイドカーインジェクタをインストールする

以降のセクションでは、Envoy サイドカーインジェクタのインストール手順について説明します。サイドカーインジェクタを有効にすると、新規および既存の Google Kubernetes Engine ワークロードでサイドカープロキシが自動的にデプロイされます。Envoy サイドカーインジェクタは GKE クラスタ内部で実行されます。このため、Traffic Director を使用してマルチクラスタサービスメッシュをサポートする場合は、クラスタごとにインストールする必要があります。

サイドカーインジェクタをダウンロードする

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

サイドカーインジェクタを構成する

古い API を使用している場合は、specs/01-configmap.yaml ファイルを次のように編集して、サイドカーインジェクタを構成します。

TRAFFICDIRECTOR_GCP_PROJECT_NUMBER で、YOUR_PROJECT_NUMBER_HERE をプロジェクトのプロジェクト番号に置き換えます。プロジェクト番号はプロジェクトの数値 ID です。プロジェクトのリストを取得する方法については、プロジェクトの識別をご覧ください。
TRAFFICDIRECTOR_NETWORK_NAME で、YOUR_NETWORK_NAME_HERE を Traffic Director で使用する Google Cloud Virtual Private Cloud ネットワーク名に置き換えます。この VPC ネットワーク名はメモしてください。後で Traffic Director を構成するときに必要になります。

新しいサービスルーティング API（現在はプレビュー版）を使用している場合:

"" をサービスメッシュの名前に置き換えて TRAFFICDIRECTOR_MESH_NAME を入力し、サービスメッシュの構成を取得します。
- Gateway を構成する場合は、サイドカーインジェクタを使用しないことに注意してください。Envoy プロキシを Pod としてデプロイします。

たとえば、ファイルは次のようになります。

$ cat specs/01-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
name: injector-mesh
namespace: istio-control
data:
mesh: |-
defaultConfig:
discoveryAddress: trafficdirector.googleapis.com:443

# Envoy proxy port to listen on for the admin interface.
proxyAdminPort: 15000

proxyMetadata:
# Google Cloud Project number where Traffic Director resources are configured.
# This is a numeric identifier of your project (e.g. "111222333444").
# You can get a list of all your projects with their corresponding numbers by
# using "gcloud projects list" command or looking it up under "Project info"
# section of your Google Cloud console.
# If left empty, configuration will be attempted to be fetched for the Google Cloud
# project associated with service credentials.
# Leaving empty is not recommended as it is not guaranteed to work in future
# releases.
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "YOUR_PROJECT_NUMBER_HERE"

# Google Cloud VPC network name for which the configuration is requested (This is the VPC
# network name referenced in the forwarding rule in Google Cloud API). If left empty,
# configuration will be attempted to be fetched for the VPC network over which
# the request to Traffic Director (trafficdirector.googleapis.com) is sent out.
# Leaving empty is not recommended as it is not guaranteed to work in future
# releases.
TRAFFICDIRECTOR_NETWORK_NAME: "default"

自動的に挿入されるプロキシでロギングとトレースを有効にすることもできます。この構成の詳細については、サイドカープロキシの追加属性の構成をご覧ください。サイドカーインジェクタを使用する場合、TRAFFICDIRECTOR_ACCESS_LOG_PATH には /etc/envoy/ ディレクトリのファイルを設定する必要があります。たとえば、ディレクトリ /etc/envoy/access.log は有効な場所です。

サイドカーインジェクタによってすでに構成されているため、この ConfigMap では TRAFFICDIRECTOR_INTERCEPTION_PORT を構成しないでください。

サイドカーインジェクタの TLS を構成する

このセクションでは、サイドカーインジェクタの TLS を構成する方法について説明します。

サイドカーインジェクタは、Kubernetes Muting Admission Webhook を使用して、新しい Pod の作成時にプロキシを挿入します。この Webhook は HTTPS エンドポイントのため、TLS の鍵と証明書が必要になります。

openssl を使用すると、秘密鍵と自己署名証明書を作成してサイドカーインジェクタを保護できます。

独自の秘密鍵と、信頼できる認証局（CA）によって署名されている証明書がある場合は、この手順をスキップして次の手順に進んでください。

CN=istio-sidecar-injector.istio-control.svc

openssl req \
  -x509 \
  -newkey rsa:4096 \
  -keyout key.pem \
  -out cert.pem \
  -days 365 \
  -nodes \
  -subj "/CN=${CN}" \
  -addext "subjectAltName=DNS:${CN}"

cp cert.pem ca-cert.pem

この openssl コマンドの例では、4,096 ビットの RSA 秘密鍵を key.pem に出力し、X.509 形式の自己署名証明書を cert.pem に出力します。この証明書は自己署名されているため、ca-cert.pem にコピーされ、署名 CA の証明書として扱われます。証明書の有効期間は 365 日です。パスフレーズは必要ありません。証明書の作成と署名の詳細については、Kubernetes のドキュメントで証明書署名リクエストに関する説明をご覧ください。

このセクションの手順は毎年繰り返し、新しい鍵と証明書を再生成して適用しなおす必要があります。

鍵と証明書を作成したら、Kubernetes Secret を作成し、サイドカーインジェクタの Webhook を更新する必要があります。

Kubernetes Secret を作成する Namespace を作成します。
```
kubectl apply -f specs/00-namespaces.yaml
```

サイドカーインジェクタに Secret を作成します。

kubectl create secret generic istio-sidecar-injector -n istio-control \
  --from-file=key.pem \
  --from-file=cert.pem \
  --from-file=ca-cert.pem

specs/02-injector.yaml で istio-sidecar-injector-istio-control という名前のサイドカーインジェクション Webhook の caBundle を変更します。
```
CA_BUNDLE=$(cat cert.pem | base64 | tr -d '\n')
sed -i "s/caBundle:.*/caBundle:\ ${CA_BUNDLE}/g" specs/02-injector.yaml
```

GKE クラスタにサイドカーインジェクタをインストールする

サイドカーインジェクタをデプロイします。
```
kubectl apply -f specs/
```

サイドカーインジェクタが動作していることを確認します。

kubectl get pods -A | grep sidecar-injector

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

istio-control   istio-sidecar-injector-6b475bfdf9-79965  1/1 Running   0   11s
istio-control   istio-sidecar-injector-6b475bfdf9-vntjd  1/1 Running   0   11s

限定公開クラスタで必要なポートを開く

Envoy での Traffic Director サービスのセキュリティの設定の手順を実施している場合は、このセクションをスキップして、次のサイドカーインジェクションの有効化セクションに進んでください。

Envoy サイドカーインジェクタを限定公開クラスタにインストールする場合は、Webhook が正常に動作するように、マスターノードへのファイアウォールルールで TCP ポート 9443 を開く必要があります。

次の手順では、必要なファイアウォールルールを更新する方法について説明します。update コマンドは既存のファイアウォールルールを置き換えるため、デフォルトポート 443（HTTPS）と 10250（kubelet）および開く新しいポートを含める必要があります。

クラスタのソース範囲（master-ipv4-cidr）を確認します。次のコマンドで、CLUSTER_NAME をクラスタの名前（traffic-director-cluster）に置き換えます。
```
FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
 --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
 --format="value(name)")
```
TCP ポート 9443 を開くようにファイアウォールルールを更新し、自動インジェクションを有効にします。
```
gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
 --allow tcp:10250,tcp:443,tcp:9443
```

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

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

kubectl label namespace default istio-injection=enabled

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

kubectl get namespace -L istio-injection

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

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-control     Active   7d15h
istio-system      Active   7d15h

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

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

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

kubectl create -f demo/client_sample.yaml

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:
…

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

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

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

GKE サービスは、Traffic Director バックエンドサービスのバックエンドとして構成できるように、ネットワークエンドポイントグループ（NEG）で公開されている必要があります。Kubernetes サービス仕様に NEG アノテーションを追加し、後で簡単に見つけられるように名前を選択します（以下のサンプルで NEG-NAME と置き換えます）。この名前は、NEG を Traffic Director バックエンドサービスに接続するときに必要となります。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 を探して名前を記録します。この名前は、次のセクションの Traffic Director の構成で使用します。

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 コンポーネントを使用して Traffic Director を構成する

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

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

ヘルスチェック。ヘルスチェックの詳細については、ヘルスチェックのコンセプトとヘルスチェックの作成をご覧ください。
バックエンドサービス。バックエンドサービスの詳細については、バックエンドサービスをご覧ください。
ルーティングルールマップ。これには、転送ルールの作成、ターゲット HTTP プロキシ、URL マップの作成が含まれます。詳しくは、Traffic Director の転送ルールの使用、Traffic Director のターゲットプロキシの使用、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 コンソールの [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
[サービス] タブで、[サービスを作成] をクリックします。
[続行] をクリックします。
サービス名に「td-gke-service」と入力します。
Traffic Director 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 プロキシを使用して Traffic Director を構成する場合は、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
```

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

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

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

Console

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

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

Google Cloud コンソールの [Traffic Director] ページに移動します。
[Traffic Director] ページに移動
[ルーティングルールマップ] をクリックします。
[ルーティングルールを作成] をクリックします。
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

この時点で、Traffic Director は、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 Traffic Director サービスと照合します。
Envoy が td-gke-service に関連付けられたネットワークエンドポイントグループからエンドポイントを選択します。
Envoy が service-test Kubernetes Service に関連付けられた Pod にリクエストを送信します。

次のステップ

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

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

概要

前提条件

共有 VPC の追加の前提条件

IAM ロールを構成する

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

GKE クラスタの作成

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

Envoy サイドカー インジェクタをインストールする

サイドカー インジェクタをダウンロードする

サイドカー インジェクタを構成する

サイドカー インジェクタの TLS を構成する

GKE クラスタにサイドカー インジェクタをインストールする

限定公開クラスタで必要なポートを開く

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

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

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

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

NEG の名前を保存する

Cloud Load Balancing コンポーネントを使用して Traffic Director を構成する

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

コンソール

gcloud

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

コンソール

gcloud

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

Console

gcloud

構成の確認

次のステップ

Envoy サイドカーインジェクタをインストールする

サイドカーインジェクタをダウンロードする

サイドカーインジェクタを構成する

サイドカーインジェクタの TLS を構成する

GKE クラスタにサイドカーインジェクタをインストールする

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

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

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

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

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