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

このガイドでは、Google Kubernetes Engine または Kubernetes Pod ホストと、Traffic Director に必要なロード バランシング コンポーネントを構成する方法について説明します。

注: 構成例はデモを目的としたものです。環境と要件に基づいて、追加のコンポーネントのデプロイが必要になることがあります。

このガイドの手順に沿って進める前に、Traffic Director の設定の準備を確認し、前提条件を満たしていることを確認してください。

Traffic Director は、Compute Engine 負荷分散 SDK または REST API を使用して構成できます。負荷分散 API と gcloud のリファレンスをご覧ください。

Traffic Director 用の GKE / Kubernetes クラスタの構成

このセクションでは、GKE / Kubernetes クラスタを Traffic Director と連携させるために必要な手順について説明します。

GKE クラスタの作成

GKE クラスタは次の要件を満たす必要があります。

• ネットワーク エンドポイント グループのサポートを有効にする必要があります。詳細と例については、スタンドアロンのネットワーク エンドポイント グループをご覧ください。スタンドアロンの NEG 機能は、Traffic Director の一般提供で利用できます。
• クラスタノード インスタンスのサービス アカウントには、Traffic Director API にアクセスするための権限が必要です。
  • 必要な権限の詳細については、Traffic Director API にアクセスするためのサービス アカウントの有効化をご覧ください。
  • Traffic Director API を有効にする方法については、Traffic Director API を有効にするをご覧ください。
• コンテナは、OAuth 認証で保護された Traffic Director API にアクセスできる必要があります。詳細については、ホスト構成をご覧ください。

次の例は、us-central1-a ゾーンに traffic-director-cluster という GKE クラスタを作成する方法を示しています。

コンソール

Google Cloud コンソールを使用してクラスタを作成するには、次の手順を行います。

1. Google Cloud コンソールで Google Kubernetes Engine のメニューに移動します。

   Google Kubernetes Engine のメニューに移動

2. [クラスタを作成] をクリックします。

3. 次のフィールドに値を入力します。

   • 名前: 「traffic-director-cluster」と入力します。
   • ロケーション タイプ: Zonal
   • ゾーン: us-central1-a

4. ナビゲーション ペインの [ノードプール] で [default-pool] をクリックします。

5. [サイズ] フィールドは、クラスタ内に作成するノードの数を示します。ノードとそのリソース（ファイアウォール ルートなど）に使用できるリソース割り当てが必要です。

6. ナビゲーション パネルの [default-pool] の下の [ノード] をクリックします。

7. [マシンタイプ] フィールドは、インスタンスに使用する Compute Engine のマシンタイプを示します。マシンタイプごとに課金方法は異なります。マシンタイプごとの料金については、Compute Engine の料金のページをご覧ください。

8. ナビゲーション パネルの [default-pool] で [セキュリティ] をクリックします。

9. [アクセス スコープ] で、[すべての Cloud API に完全アクセス権を許可] をクリックします。

10. 必要に応じてクラスタをカスタマイズします。

11. [作成] をクリックします。

Google Cloud コンソールでクラスタを作成したら、クラスタとやり取りするように kubectl を構成する必要があります。詳細については、kubeconfig エントリの生成をご覧ください。

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

必要な GKE クラスタ権限の取得

GKE の場合は、次のコマンドを実行して、作成したクラスタ（2）に切り替えます。これにより、kubectl は正しいクラスタを指すようになります。

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

GKE / Kubernetes Service の構成

このセクションでは、Traffic Director と連携するための Kubernetes デプロイ仕様の準備方法について説明します。これは、NEG を使用したサービスの構成と、Traffic Director によって管理されるサービスへのアクセスを必要とする Pod へのサイドカー プロキシの挿入で構成されます。

ファイアウォール ルールを構成する

バックエンド Pod が実行されていることを確認するには、ヘルスチェッカーの IP アドレス範囲を許可するファイアウォール ルールを構成する必要があります。

コンソール

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

gcloud

1. 次の gcloud コマンドを使用して、fw-allow-health-checks という名前のファイアウォール ルールを作成します。このルールは allow-health-checks タグを持つネットワーク内のインスタンスに対する受信接続を許可します。NETWORK_NAME はネットワーク名に置き換えてください。

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

詳細については、ヘルスチェックのファイアウォール ルールの構成をご覧ください。

NEG を使用した GKE / Kubernetes Services の構成

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

注: この設定ガイドに記載されている trafficdirector_service_sample.yaml パッケージは NEG 名 service-test-neg を使用します。

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

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

デモ目的で、HTTP を介してポート 80 でホスト名を提供するサンプル サービスをデプロイできます。

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..]

kubectl get pods

次の結果が返されます。

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

NEG の名前を保存する

上記の例で作成された NEG を見つけて、NEG の名前を記録します。

コンソール

ネットワーク エンドポイント グループのリストを表示するには、Google Cloud Console の [ネットワーク エンドポイント グループ] ページに移動します。
[ネットワーク エンドポイント グループ] ページに移動

gcloud

gcloud compute network-endpoint-groups list

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

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

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

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

注: NEG を使用した GKE サービスの構成で説明したように、NEG に名前を付けた場合は、NEG 名が Kubernetes サービス仕様で指定されたものと一致しているはずです。NEG に名前を付けなかった場合は、名前が自動生成されます。

Traffic Director 用の Google Cloud 負荷分散コンポーネントの構成

このセクションの手順では、他の Google Cloud Load Balancing プロダクトと同様の負荷分散構成を使用して、Traffic Director が負荷分散を行っているサービス VIP の GKE サービスにアクセスできるようにします。

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

• ヘルスチェック。ヘルスチェックの詳細については、ヘルスチェックのコンセプトとヘルスチェックの作成をご覧ください。
• バックエンド サービス。バックエンド サービスの詳細については、バックエンド サービスをご覧ください。
• ルートルール。これには、転送ルールと URL マップの作成が含まれます。詳細については、転送ルールの使用と URL マップの使用をご覧ください。

以下の Traffic Director の構成例では、次のことを前提としています。

1. NEG と他のすべてのリソースは、ゾーン us-central1-a 内の default ネットワークに自動モードで作成されます。
2. クラスタの NEG 名は ${NEG_NAME} 変数に格納されます。

ヘルスチェックの作成

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

コンソール

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

gcloud

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

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

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

コンソール

1. Google Cloud コンソールの [Traffic Director] ページに移動します。

   [Traffic Director] ページに移動

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

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

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

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

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

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

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

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

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

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 を追加します。

   gcloud compute backend-services add-backend td-gke-service \
    --global \
    --network-endpoint-group ${NEG_NAME} \
    --network-endpoint-group-zone us-central1-a \
    --balancing-mode RATE \
    --max-rate-per-endpoint 5
   

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

以下の手順で Traffic Director の構成にルートルール、転送ルール、内部 IP アドレスを作成します。

内部 IP アドレスに送信されたトラフィックは、Envoy プロキシによってインターセプトされ、ホストとパスのルールに従って適切なサービスに送信されます。

転送ルールは、load-balancing-scheme が INTERNAL_SELF_MANAGED に設定されたグローバル転送ルールとして作成されます。

転送ルールのアドレスを 0.0.0.0 に設定できます。このように設定すると、トラフィックは、ホスト名が解決される実際の IP アドレスに関係なく、URL マップで構成された HTTP ホスト名とパス情報に基づいてルーティングされます。この場合、ホストルールで構成されたサービスの URL（ホスト名と URL パス）は、サービス メッシュ構成内で一意である必要があります。つまり、バックエンドのセットが異なる二つのサービスを、両方とも同じホスト名とパスの組み合わせで使用することはできません。

また、サービスの実際の宛先 VIP に基づいてルーティングを有効にすることもできます。サービスの VIP を転送ルールの address パラメータとして構成した場合、その IP アドレスを宛先とするリクエストのみが、URL マップに指定された HTTP パラメータに基づいてルーティングされます。

注: 選択した方法に関係なく、サービスホスト名によって解決される VIP アドレスへのトラフィックは、アクセスが必要なクライアント ホスト上のサイドカー プロキシによってインターセプトされなければなりません。ホストの完全な構成の詳細については、Traffic Director 用の単一の Compute Engine VM の構成をご覧ください。

注: VPC ネットワーク内の転送ルールには、VPC ネットワークごとに IP アドレスとポートの組み合わせが必要です（0.0.0.0 アドレスを含む）。同じ IP アドレスとポートで、特定の VPC ネットワーク内に複数の転送ルールを作成すると、最初の転送ルールだけが有効になります。他の要素は無視されます。

コンソール

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

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

1. Google Cloud コンソールの [Traffic Director] ページに移動します。

   [Traffic Director] ページに移動

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. バックエンド サービスを使用する URL マップを作成します。

   gcloud compute url-maps create td-gke-url-map \
      --default-service td-gke-service
   

2. ホスト名とパスに基づいてサービスのトラフィックをルーティングする URL マップのパスマッチャーとホストルールを作成します。この例では、サービス名として service-test を使用し、このホスト（/*）のすべてのパスリクエストに一致するデフォルトのパスマッチャーを使用します。service-test は、上記のサンプル構成で使用されている Kubernetes Service の構成名でもあります。

   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
   

この時点で、Traffic Director は、URL マップで指定されたサービスのトラフィックをネットワーク エンドポイント グループのバックエンド間で負荷分散するように構成されます。

ネットワークでのマイクロサービスの分散方法によっては、URL マップに転送ルールまたはホストとパスのルールを追加することが必要な場合があります。

テスト用のサンプル クライアントをデプロイして構成を確認する

このセクションでは、クライアント アプリケーションから Traffic Director のバックエンドにアクセスする方法について説明します。

機能を示すために、Busybox を実行しているサンプル Pod をデプロイできます。Pod は、前のセクションで作成した service-test へのアクセス権を持ち、Traffic Director によってロード バランシングされたトラフィックを受信します。

GKE / Kubernetes Pod へのサイドカー プロキシの挿入

Traffic Director によって管理されているサービスにアクセスするには、Pod に xDS API 互換のサイドカー プロキシがインストールされている必要があります。

この例では、リファレンス仕様に従ってデプロイメントに Istio プロキシ サイドカーと init コンテナを追加して、Buybox クライアントをデプロイします。

古い API を使用している場合は、PROJECT_NUMBER 変数と NETWORK_NAME 変数をプロジェクト番号とネットワーク名に置き換えます。

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

新しいサービス ルーティング API（現在はプレビュー版）を使用している場合は、PROJECT_NUMBER 変数と MESH_NAME 変数をプロジェクト番号と Mesh 名前に置き換えます。

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

Busybox Pod では 2 つのコンテナが実行されています。1 つ目のコンテナは Busybox イメージに基づくクライアントであり、2 番目のコンテナはサイドカーとして挿入された Envoy プロキシです。次のコマンドを実行すると、Pod に関する詳細情報を取得できます。

kubectl describe pods -l run=client

バックエンド サービスへのアクセス

構成が完了すると、サイドカー プロキシが挿入された Pod 上のアプリケーションは、Traffic Director サービスが管理するサービスにアクセスできます。構成を確認するには、いずれかのコンテナのシェルにアクセスします。

このガイドで提供されているデモ構成を使用した場合は、次の確認コマンドを実行して、サービング Pod のホスト名が返されることを確認できます。

# Get name of the Pod  with 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.
TEST_CMD="wget -q -O - service-test; echo"

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

サイドカー プロキシによるトラフィックのインターセプトについて

この例では、Busybox クライアントがバックエンド サービスにリクエストを送信すると、各リクエストはサイドカー プロキシによってプロキシされます。

このデモ アプリケーションでは Envoy プロキシを使用します。そのため、クライアントではサーバー レスポンスのヘッダーに「server: envoy」と表示されます。

これを確認するには、次のコマンドを使用します。

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

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

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

この例では、VIP アドレス 0.0.0.0 を使用して転送ルールを作成しました。つまり、Traffic Director は Host ヘッダーのみに基づいてリクエストをバックエンドに転送します。この場合、リクエスト ホストヘッダーが URL マップ service-test で定義されたホストと一致する限り、宛先 IP アドレスは任意のアドレスにできます。

これを確認するには、次のテストコマンドを実行します。

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

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

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

次のステップ

• 高度なトラフィック管理について確認する。
• Traffic Director のデプロイをトラブルシューティングする方法について確認する。
• Envoy によるオブザーバビリティの設定方法について確認する。