Traffic Director クライアントのステータスについて
Traffic Director を使用してアプリケーション ネットワーキングを処理する場合、次の 2 つの主要コンポーネントについて考慮してください。
- インフラストラクチャ レイヤ。Envoy サイドカー プロキシやプロキシレス gRPC ライブラリなどのインフラストラクチャ レイヤが、アプリケーションの代わりにネットワークを処理するように構成されます。
- コントロール プレーン、Traffic Director。コントロール プレーンは、インフラストラクチャ レイヤの構成を生成し、それを配信します。
Envoy プロキシまたは gRPC ライブラリが初期化されると、xDS API を使用して Traffic Director に接続されます。プロキシまたはライブラリは、Traffic Director のクライアントとして機能します。クライアントと Traffic Director の間に接続が確立されると、Traffic Director は構成情報をクライアントに送信し、必要に応じて構成を更新します。
Traffic Director に接続しているクライアントを把握することや、Traffic Director がクライアントに生成する構成を検査することが作業に役立つ場合があります。たとえば、問題をデバッグする場合や、Traffic Director の構成時に行ったアクションがクライアントの構成にどのような影響を与えるのかを把握する場合です。
Traffic Director はクライアント ステータス ディスカバリ サービス（CSDS）の API をサポートしています。CSDS クライアントを使用してこの API に対してクエリを実行します。これにより、どのクライアントが Traffic Director に接続しているのかを確認し、Traffic Director がクライアントに生成する構成を検査できます。
CSDS クライアントは、Envoy リポジトリから取得できるオープンソースのツールです。次の図は、CSDS クライアントが Traffic Director の CSDS API に関する情報をクエリで取得する方法を示しています。
CSDS クライアントが Traffic Director に接続して、プロジェクト番号、ネットワーク名、一連の認証情報を提供します。Traffic Director が、接続しているさまざまな Traffic Director クライアントの情報を返します。
CSDS クライアントの詳細については、README ファイルをご覧ください。
前提条件
CSDS API に接続するには CSDS クライアントが必要です。クライアントは次のいずれかの方法で取得できます。
- Cloud Shell を使用してクライアントをビルドする。
- ローカルの開発マシン上にクライアントをビルドする。
Cloud Shell を使用して CSDS クライアントをビルドする
Cloud Shell を使用して CSDS クライアントをビルドする手順は次のとおりです。
- Cloud Shell を無効化またはリセットする手順を行い、Cloud Shell をリセットします。これにより、既存の構成がビルドに影響しないようにすることができます。
- Google Cloud Console から新しい Cloud Shell セッションを開きます。
次のコマンドを実行して、CSDS クライアントのビルドに使用するソースコードを取得します。
git clone https://github.com/envoyproxy/envoy-tools.git
CSDS クライアント ディレクトリに移動して、次のコマンドを実行します。
cd envoy-tools/csds-client/ make init make build
ビルドが完了したら、次のコマンドを使用してテストします。
csds-client -help
ビルドが成功すると、クライアントのヘルプテキストが表示されます。
ローカル開発マシンで CSDS クライアントをビルドする
オープンソース リポジトリの README ファイルに記載されている手順を行うと、ローカルマシンに CSDS クライアントをダウンロードしてビルドできます。この操作を行うには、ご使用の環境に Go と make ツールを設定する必要があります。この準備を行わない場合は、以前の Cloud Shell の手順を行ってください（Go と make ツールが用意されます）。
追加の前提条件
各クライアントのノード ID がサービス メッシュ内で一意であることを確認してください。複数のクライアントが同じノード ID を共有している場合、1 つの構成（Traffic Director に最近接続したクライアントの構成）のみが返されます。
Google のリファレンス パッケージを使用する場合、ブートストラップ ファイルでノード ID を手動で設定する必要はありません。ノード ID は自動的に生成されます。リファレンス パッケージを使用しない場合は、各ブートストラップ ファイルにノード ID を手動で設定する必要があります。
Traffic Director の構成に必要な Identity and Access Management（IAM）権限が付与されたユーザー アカウントにアクセスできることを確認します。次の手順では、Google Cloud CLI を使用して、CSDS クライアントに必要な認証情報を生成し、自動的に提供します。また、CSDS クライアントを使用して認証情報を直接提供することもできます。
現在 Traffic Director に接続しているクライアントを確認する
CSDS クライアントを使用すると、Traffic Director 構成に接続されているクライアントを特定できます。
この情報を取得するには、次の詳細が必要です。
認証情報が生成されたプロジェクトの ID。
サービス ルーティング API を使用している場合は、xDS クライアントが取得するリソースに応じて、次のいずれかになります。
古い API を使用している場合は、Traffic Director の構成時に指定した VPC ネットワークの名前です。このネットワークは、ルーティング ルール マップの転送ルールによって指定されたネットワークです。
サービス ルーティング API
正しい権限を持つアカウントから、次のコマンドを実行します。
gcloud auth application-default login \ --billing-project=BILLING_PROJECT_ID
次の内容のファイルを YAML 形式で作成します。
node_matchers: - node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_MESH_SCOPE_NAME value: string_match: exact: "MESH_OR_SCOPE"次の値を置き換えます。
PROJECT_NUMBER: プロジェクトの IDMESH_OR_SCOPE: xDS クライアントが Mesh リソースを取得する場合は、接頭辞mesh:の後に実際のメッシュ名を使用します。xDS クライアントが Gateway リソースを取得する場合は、接頭辞scope:の後にスコープ パラメータの名前を使用します。
gcloud CLI で生成された認証情報を使用する CSDS クライアントを実行します。
PATH_TO_CSDS_REQUEST_YAML_FILEは、前の手順で作成した YAML ファイルのパスで置き換えます。csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE
出力は次のようになります。
Client ID xDS stream type Config status 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 ADS N/A 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 LRS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 LRS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 ADS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 LRS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 ADS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 LRS N/A
Client ID列に、Traffic Director に接続しているクライアントのクライアント ID が表示されます。これらのクライアント ID は、Traffic Director への接続時に Envoy またはプロキシレス gRPC で使用されるブートストラップ ファイルのnode_idフィールドを使用して提供します。
古い API
正しい権限を持つアカウントから、次のコマンドを実行します。
gcloud auth application-default login \ --billing-project=BILLING_PROJECT_ID
次の内容のファイルを YAML 形式で作成します。
node_matchers: - node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_NETWORK_NAME value: string_match: exact: "NETWORK_NAME"次の値を置き換えます。
PROJECT_NUMBER: Google Cloud プロジェクトの一意の IDNETWORK_NAME: ルーティング ルール マップの転送ルールによって指定された VPC ネットワーク
gcloud CLI で生成された認証情報を使用する CSDS クライアントを実行します。
PATH_TO_CSDS_REQUEST_YAML_FILEは、前の手順で作成した YAML ファイルのパスで置き換えます。csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE
出力は次のようになります。
Client ID xDS stream type Config status 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 ADS N/A 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 LRS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 LRS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 ADS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 LRS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 ADS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 LRS N/A
Client ID列に、Traffic Director に接続しているクライアントのクライアント ID が表示されます。これらのクライアント ID は、Traffic Director への接続時に Envoy またはプロキシレス gRPC で使用されるブートストラップ ファイルのnode_idフィールドを使用して提供します。
特定の Traffic Director クライアントの構成を検査する
前のセクションで取得したクライアント ID を使用して、Traffic Director から特定のクライアントに送信される構成を検査できます。
リソース proto の詳細な構成を調べて、特定のクライアントが使用している xDS API のバージョンを確認できます。たとえば、構成に envoy.api.v2.Cluster が含まれている場合は、クライアントが v2 API を使用していることを意味します。構成に envoy.api.v3.Cluster が含まれている場合は、クライアントが v3 API を使用していることを意味します。
サービス ルーティング API
現在 Traffic Director に接続しているクライアントを確認するで作成した YAML ファイルを更新します。クライアント ID を値として使用する
node-idフィールドを追加します。node_matchers: - node_id: exact: "CLIENT_ID" node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_MESH_SCOPE_NAME value: string_match: exact: "MESH_OR_SCOPE_NAME"次の値を置き換えます。
CLIENT_ID: 構成を検査するクライアントの ID（例:projects/000000/networks/mesh:mesh1/nodes/00000000-0000-0000-0000-00000000~127.0.0.1）PROJECT_NUMBER: Google Cloud プロジェクトの一意の IDMESH_OR_SCOPE: xDS クライアントが Mesh リソースを取得する場合は、接頭辞mesh:の後に実際のメッシュ名を使用します。xDS クライアントが Gateway リソースを取得する場合は、接頭辞scope:の後にスコープ パラメータの名前を使用します。
CSDS クライアントを実行します。クライアントを実行すると、JSON ファイルが生成されます。このファイルには、Traffic Director クライアントに送信される構成が含まれています。
csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \ -output_file FILENAME.JSON
次の値を置き換えます。
PATH_TO_CSDS_REQUEST_YAML_FILE: YAML ファイルのパスFILENAME.JSON: CSDS クライアントの出力を保持するファイルの名前
出力は次のようになります。
Client ID xDS stream type Config status 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS LDS SYNCED RDS SYNCED CDS STALE Config has been saved to FILENAME.JSON詳細な xDS 構成は JSON ファイルで確認できます。この出力には、gRPC の集約ストリーム（ADS）を使用して Traffic Director からクライアントに送信される個々の xDS 構成のステータスが含まれます。
古い API
現在 Traffic Director に接続しているクライアントを確認するで作成した YAML ファイルを更新します。クライアント ID を値として使用する
node-idフィールドを追加します。node_matchers: - node_id: exact: "CLIENT_ID" node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_NETWORK_NAME value: string_match: exact: "NETWORK_NAME"次の値を置き換えます。
CLIENT_ID: 構成を検査するクライアントの ID（例:f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6）PROJECT_NUMBER: Google Cloud プロジェクトの一意の IDNETWORK_NAME: ルーティング ルール マップの転送ルールによって指定された VPC ネットワーク
CSDS クライアントを実行します。クライアントを実行すると、JSON ファイルが生成されます。このファイルには、Traffic Director クライアントに送信される構成が含まれています。
csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \ -output_file FILENAME.JSON
次の値を置き換えます。
PATH_TO_CSDS_REQUEST_YAML_FILE: YAML ファイルのパスFILENAME.JSON: CSDS クライアントの出力を保持するファイルの名前
出力は次のようになります。
Client ID xDS stream type Config status 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS LDS SYNCED RDS SYNCED CDS STALE Config has been saved to FILENAME.JSON詳細な xDS 構成は JSON ファイルで確認できます。この出力には、gRPC の集約ストリーム（ADS）を使用して Traffic Director からクライアントに送信される個々の xDS 構成のステータスが含まれます。
ステータス値
次の表に、xDS 構成のステータス値の一覧を示します。
| 値 | 説明 |
|---|---|
UNKNOWN |
（デフォルト）ステータスの情報は利用できないか、不明です。 |
SYNCED |
Traffic Director がクライアントに構成を送信し、クライアントから ACK を受信しています。 |
ERROR |
Traffic Director がクライアントに構成を送信し、クライアントから NACK を受信しています。 |
STALE |
Traffic Director はクライアントに構成を送信しましたが、クライアントから ACK または NACK を受信しませんでした。 |
NOT_SENT |
構成を送信できませんでした。 |
N/A |
CSDS クライアントにノード ID が含まれていません。接続されているストリームがすべて返されますが、構成ステータスは使用できません。 |
可視化とモニタリング
CSDS クライアント オープンソース ツールには、可視化や継続的なモニタリングなど、必要に応じて使用できる追加機能が用意されています。これらの機能の詳細については、オープンソース リポジトリの README ファイルをご覧ください。
エラー メッセージ
プロジェクトで Traffic Director API のみを有効にすると、CSDS クライアントから次のエラー メッセージが表示されることがあります。
rpc error: code = NotFound desc = Requested entity was not found.
これは想定されている動作です。Traffic Director の構成はネットワーク単位で行われます。ネットワークをまだ作成していないときに CSDS クライアントを実行すると、このエラー メッセージが表示されます。
制限事項
- エンドポイント情報は、CSDS v3 API で使用できないため、CSDS レスポンスには含まれません。
- 各クライアントのノード ID は、サービス メッシュ内で一意である必要があります。複数のクライアントが同じノード ID を共有している場合、1 つの構成（Traffic Director に最近接続したクライアントの構成）のみが返されます。
- YAML ファイルのノード ID フィールドにバックスラッシュ（\）が含まれていることがあります。その場合は、CSDS API に構成情報を照会するときに、追加のバックスラッシュを使用してエスケープします。これは既知の問題です。
次のステップ
- Traffic Director の一般的なトラブルシューティング情報については、Envoy を使用するデプロイのトラブルシューティングをご覧ください。
- プロキシレス gRPC サービスをデプロイするときに構成の問題を解決するには、プロキシレス gRPC を使用したデプロイのトラブルシューティングをご覧ください。