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

概要

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

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 を構成する場合にも、これらの手順を使用できます。

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

  1. ワークロード用の GKE クラスタを作成する。
  2. Envoy サイドカー インジェクタをインストールし、インジェクションを有効にする。
  3. サンプル クライアントをデプロイし、インジェクションを検証する。
  4. テスト用の Kubernetes Service をデプロイする。
  5. Cloud Load Balancing コンポーネントを使用して Cloud Service Mesh を構成し、トラフィックをテストサービスにルーティングする。
  6. サンプル クライアントからテストサービスにリクエストを送信して、構成を確認する。
この設定ガイドでデプロイするコンポーネントの概要(クリックして拡大)
この設定ガイドでデプロイするコンポーネントの概要(クリックして拡大)

前提条件

このガイドの手順に進む前に、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 つのサービス プロジェクトがあることを前提としています。

  1. Cloud Shell で、このセクションに関連するファイルを作成する作業フォルダ(WORKDIR))を作成します。

    mkdir -p ~/td-shared-vpc
    cd ~/td-shared-vpc
    export WORKDIR=$(pwd)
    
  2. ホスト プロジェクトで IAM 権限を構成して、サービス プロジェクトが共有 VPC のリソースを使用できるようにします。

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

    1. サービス プロジェクト 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. サービス プロジェクト 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}
      
  3. 各サービス プロジェクトで、ホスト プロジェクトの 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 サービス アカウントを使用して共有ネットワーク リソースを構成できます。

  4. 各サービス プロジェクトで、ホスト プロジェクトの 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 クラスタで Cloud Service Mesh を使用するには、次の要件を満たす必要があります。

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 クラスタ内部で実行されます。このため、Cloud Service Mesh を使用してマルチクラスタ サービス メッシュをサポートする場合は、クラスタごとにインストールする必要があります。

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

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 を Cloud Service Mesh で使用する Google Cloud Virtual Private Cloud ネットワーク名に置き換えます。この VPC ネットワーク名は、後で Cloud Service Mesh を構成するときに必要になるため、メモしておきます。

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

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

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

$ cat specs/01-configmap.yaml
  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: istio
    namespace: istio-system
  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 Cloud Service Mesh 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 Cloud Service Mesh (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 を構成しないでください。

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

  1. サイドカー インジェクタをデプロイします。

    kubectl apply -f specs/
    
  2. サイドカー インジェクタが動作していることを確認します。

    kubectl get pods -A | grep istiod
    

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

    istio-system   istiod-6b475bfdf9-79965  1/1 Running   0   11s
    

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

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

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

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

  1. クラスタのソース範囲(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)")
    
  2. 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-system      Active   7d15h

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

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

このセクションでは、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 サービスは、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 から構成を受信できるようになります。サンプル クライアントからの送信リクエストは、サイドカー プロキシによって処理され、テストサービスにルーティングされます。

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

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

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

コンソール

  1. Google Cloud コンソールの [ヘルスチェック] ページに移動します。
    [ヘルスチェック] ページに移動
  2. [ヘルスチェックを作成] をクリックします。
  3. [名前] に「td-gke-health-check」と入力します。
  4. プロトコルとして [HTTP] を選択します。
  5. [作成] をクリックします。

  6. Google Cloud コンソールの [ファイアウォール ポリシー] ページに移動します。
    [ファイアウォール ポリシー] ページに移動

  7. [ファイアウォール ルールを作成] をクリックします。

  8. ファイアウォール ルールの作成ページで、次の情報を入力します。

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

gcloud

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

    gcloud compute health-checks create http td-gke-health-check \
      --use-serving-port
    
  2. ヘルス チェッカーの 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 コンソールでは、ロード バランシング方式は暗黙的に設定されます。ヘルスチェックをバックエンド サービスに追加します。

コンソール

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    [Cloud Service Mesh] ページに移動

  2. [サービス] タブで、[サービスを作成] をクリックします。

  3. [続行] をクリックします。

  4. サービス名に「td-gke-service」と入力します。

  5. Cloud Service Mesh ConfigMap で構成した [ネットワーク] を選択します。

  6. [バックエンド タイプ] で [ネットワーク エンドポイント グループ] を選択します。

  7. 作成したネットワーク エンドポイント グループを選択します。

  8. [最大 RPS] を 5 に設定します。

  9. [分散モード] を [レート] に設定します。

  10. [完了] をクリックします。

  11. [ヘルスチェック] で、作成したヘルスチェック(td-gke-health-check)を選択します。

  12. [続行] をクリックします。

gcloud

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

    gcloud compute backend-services create td-gke-service \
     --global \
     --health-checks td-gke-health-check \
     --load-balancing-scheme INTERNAL_SELF_MANAGED
    
  2. 前に作成した 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 サイドカー プロキシが次の処理を行います。

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

Console

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

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

  1. Google Cloud コンソールで [Cloud Service Mesh] ページに移動します。

    [Cloud Service Mesh] ページに移動

  2. [ルーティング ルール マップ] をクリックします。

  3. [ルーティング ルールを作成] をクリックします。

  4. URL マップの [名前] に「td-gke-url-map」と入力します。

  5. [転送ルールを追加] をクリックします。

  6. 転送ルール名に「td-gke-forwarding-rule」と入力します。

  7. ネットワークを選択します。

  8. [内部 IP] を選択します。

  9. [保存] をクリックします。

  10. 必要に応じて、カスタムホストとパスのルールを追加するか、パスルールをデフォルトのままにします。

  11. ホストを service-test に設定します。

  12. [保存] をクリックします。

gcloud

  1. td-gke-service をデフォルトのバックエンド サービスとして使用する URL マップを作成します。

    gcloud compute url-maps create td-gke-url-map \
       --default-service td-gke-service
    
  2. ホスト名とパスに基づいてサービスのトラフィックをルーティングする 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
    
  3. ターゲット HTTP プロキシを作成します。

    gcloud compute target-http-proxies create td-gke-proxy \
       --url-map td-gke-url-map
    
  4. 転送ルールを作成します。

    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 にリクエストを送信します。

次のステップ