Envoy デプロイに関するトラブルシューティング
このガイドでは、Traffic Director の構成に関する問題を解決する際に有用な情報を提供します。Traffic Director に関する問題の調査にクライアント ステータス ディスカバリ サービス(CSDS)の API を使用する方法については、Traffic Director のクライアント ステータスについてをご覧ください。
VM にインストールされている Envoy のバージョンの判別
次の手順を使用して、仮想マシン(VM)インスタンスで実行されている Envoy のバージョンを確認します。
自動 Envoy デプロイによるバージョンの判別
自動デプロイで Envoy のバージョンを検証または確認するには、次の手順を行います。
パス
gce-service-proxy/proxy-version
で VM のゲスト属性を確認します。gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME \ --zone ZONE --query-path=gce-service-proxy/proxy-version NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
次のようなクエリを使用して、Google Cloud Console の [ロギング] ページの [VM インスタンスの詳細] から、Cloud Logging インスタンスのログを確認します。
resource.type="gce_instance" resource.labels.instance_id="3633122484352464042" jsonPayload.message:"Envoy version"
次のようなレスポンスが返されます。
{ "insertId": "9zy0btf94961a", "jsonPayload": { "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL", "localTimestamp": "2021-01-12T11:39:14.3991Z" }, "resource": { "type": "gce_instance", "labels": { "zone": "asia-southeast1-b", "instance_id": "3633122484352464042", "project_id": "cloud-vm-mesh-monitoring" } }, "timestamp": "2021-01-12T11:39:14.399200504Z", "severity": "INFO", "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent", "receiveTimestamp": "2021-01-12T11:39:15.407023427Z" }
SSH を使用して VM に接続し、バイナリ バージョンを確認します。
YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version /usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
SSH を使用して、VM と管理者インターフェースに root として接続します。
root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info { "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL", "state": "LIVE", "hot_restart_version": "disabled", ... }
手動 Envoy デプロイによるバージョンの判別
手動デプロイで Envoy のバージョンを検証または確認するには、次の手順を行います。
SSH を使用して VM に接続し、バイナリ バージョンを確認します。
YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version /usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL
SSH を使用して、VM と管理者インターフェースに root として接続します。
root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info { "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL", "state": "LIVE", "hot_restart_version": "disabled", ... }
Envoy のログの場所
問題のトラブルシューティングを行うには、Envoy プロキシのログを調べる必要があります。
Google Kubernetes Engine(GKE)では、Envoy プロキシはアプリケーション Pod で実行されます。envoy
コンテナによってフィルタされたアプリケーション Pod のログにエラーが表示されます。
クラスタでワークロード ロギングが有効になっている場合は、Cloud Logging でエラーを確認できます。次のフィルタを使用できます。
resource.type="K8S_CONTAINER" resource.labels.project_id="PROJECT_NAME" resource.labels.location="CLUSTER_ZONE" resource.labels.cluster_name="CLUSTER_NAME" resource.labels.namespace_name="WORKLOAD_NAMESPACE" labels.k8s-pod/app="WORKLOAD_NAME" resource.labels.container_name="envoy"
クラスタでワークロードのロギングが有効になっていない場合は、次のようなコマンドを使用してエラーを確認できます。
kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.
次のフィルタを使用して、すべてのクラスタとワークロードで実行されているすべての Envoy のログを表示することもできます。
resource.type="K8S_CONTAINER" resource.labels.container_name="envoy"
Compute Engine と手動デプロイを使用する場合は、設定ガイドの run.sh
スクリプトを実行する前に、LOG_DIR
を定義します。
次に例を示します。
LOG_DIR='/var/log/envoy/'
デフォルトでは、エラーは次のログに表示されます。
/var/log/envoy/envoy.err.log
ユーザーが Logging にエクスポートするための追加構成を行わなかった場合は、SSH を使用してインスタンスに接続し、このファイルを取得した場合にのみ、エラーが表示されます。
自動 Envoy デプロイを使用する場合は、SSH を使用してインスタンスに接続し、ログファイルを取得できます。パスは、基本的に前述のパスと同じです。
プロキシを Traffic Director に接続できない
プロキシを Traffic Director に接続できない場合は、次の手順を行ってください。
Envoy プロキシのログで
trafficdirector.googleapis.com
への接続エラーを確認します。すべてのトラフィックを Envoy プロキシにリダイレクトするように
netfilter
を設定した場合(iptables
を使用)は、プロキシを実行するユーザー(UID)がリダイレクトから除外されていることを確認してください。除外していないと、トラフィックはプロキシに継続的にループバックします。プロジェクトで Traffic Director API を有効にしたことを確認してください。プロジェクトの API とサービスで、Traffic Director API のエラーを探します。
VM の作成時に次のように指定して、VM の API アクセス スコープが Google Cloud APIs への完全アクセス権を許可するように設定されていることを確認します。
--scopes=https://www.googleapis.com/auth/cloud-platform
サービス アカウントに正しい権限が付与されていることを確認します。詳細については、サービス アカウントを有効にして Traffic Director API にアクセスするをご覧ください。
VM から
trafficdirector.googleapis.com:443
にアクセスできることを確認します。このアクセスに問題がある場合は、ファイアウォールが TCP ポート443
経由でのtrafficdirector.googleapis.com
へのアクセスを阻止しているか、trafficdirector.googleapis.com
ホスト名の DNS 解決に問題があることが原因として考えられます。サイドカー プロキシに Envoy を使用している場合は、Envoy のバージョンがリリース 1.9.1 以降であることを確認します。
Traffic Director で構成されたサービスにアクセスできない
Traffic Director で構成されたサービスにアクセスできない場合は、サイドカー プロキシが実行中で、Traffic Director に接続できることを確認します。
Envoy をサイドカー プロキシとして使用している場合は、次のコマンドを実行して確認できます。
コマンドラインから、Envoy プロセスが実行されていることを確認します。
ps aux | grep envoy
Envoy のランタイム構成を調べて、Traffic Director によって動的リソースが構成されていることを確認します。構成を表示するには、次のコマンドを実行します。
curl http://localhost:15000/config_dump
サイドカー プロキシのトラフィック インターセプトが正しく設定されていることを確認します。
iptables
を使用したリダイレクト設定の場合は、iptables
コマンドを実行してからgrep
を実行し、出力結果にルールが含まれることを確認します。sudo iptables -t nat -S | grep ISTIO
次に、
iptables
が仮想 IP アドレス(VIP)10.0.0.1/32
をインターセプトし、ポート15001
で実行されている Envoy プロキシに UID1006
として転送する出力の例を示します。-N ISTIO_IN_REDIRECT -N ISTIO_OUTPUT -N ISTIO_REDIRECT -A OUTPUT -p tcp -j ISTIO_OUTPUT -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001 -A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN -A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT -A ISTIO_OUTPUT -j RETURN
Google Cloud Console で VM インスタンスを作成した場合、一部の IPv6 関連モジュールは、再起動するまでインストールされず、使用できません。これにより依存関係が欠落するため、iptables
が失敗します。この場合は、VM を再起動して設定プロセスを再実行すると問題が解決します。Google Cloud CLI で作成した Compute Engine VM では、この問題は発生しないと考えられます。
Envoy アクセス ロギングが構成されている場合にサービスにアクセスできなくなる
Traffic Director の Envoy ブートストラップ属性の構成で説明しているように、TRAFFICDIRECTOR_ACCESS_LOG_PATH
を使用して Envoy アクセスログを構成した場合は、Envoy プロキシを実行しているシステム ユーザーが、指定したアクセスログの場所に書き込む権限を持っていることを確認してください。
必要な権限を付与しないと、リスナーがプロキシにプログラミングされません。これは、Envoy プロキシログで次のエラー メッセージを確認することで検出できます。
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT: unable to open file '/var/log/envoy.log': Permission denied
この問題を解決するには、選択したファイルのアクセスログの権限を変更して、Envoy ユーザーが書き込めるようにします。
Traffic Director で構成されていないサービスにアプリケーションから接続できない
Traffic Director で構成されているサービスの IP アドレスに対してのみトラフィック インターセプトを設定していることを確認します。すべてのトラフィックがインターセプトされると、Traffic Director で構成されていないサービスへの接続は、サイドカー プロキシによって自動的に破棄されます。
ノード内でトラフィックがループしている、またはノードがクラッシュする
すべてのトラフィックをインターセプトするように netfilter
(iptables
)を設定している場合は、サイドカー プロキシの実行に使用するユーザー(UID)がトラフィック インターセプトから除外されていることを確認します。除外されていないと、サイドカー プロキシによって送信されたトラフィックは、プロキシに対して無限にループバックされます。その結果、サイドカー プロキシのプロセスがクラッシュする可能性があります。参照構成では、netfilter
ルールはプロキシ ユーザーからのトラフィックをインターセプトしません。
構成に問題があることを示す Envoy ログのエラー メッセージ
Traffic Director の構成に問題がある場合は、Envoy のログに次のエラー メッセージが記録されることがあります。
warning envoy config StreamAggregatedResources gRPC config stream closed: 5, Traffic Director configuration was not found for network "VPC_NAME" in project "PROJECT_NUMBER".
warning envoy upstream StreamLoadStats gRPC config stream closed: 5, Traffic Director configuration was not found for network "VPC_NAME" in project "PROJECT_NUMBER".
warning envoy config StreamAggregatedResources gRPC config stream closed: 5, Requested entity was not found.
warning envoy upstream StreamLoadStats gRPC config stream closed: 5, Requested entity was not found.
Traffic Director configuration was not found.
最後のエラー メッセージ(Traffic Director configuration was not found
)は通常、Envoy が Traffic Director の構成をリクエストしたが、一致する構成が見つからないことを示しています。Envoy が Traffic Director に接続すると、VPC ネットワーク名(my-network
など)が提示されます。次に、Traffic Director は INTERNAL_SELF_MANAGED
負荷分散スキームを持ち、同じ VPC ネットワーク名を参照する転送ルールを探します。
このエラーを解決するには、次の手順を行います。
ネットワークに負荷分散スキーム
INTERNAL_SELF_MANAGED
の転送ルールがあることを確認します。転送ルールの VPC ネットワーク名をメモします。Traffic Director を Compute Engine の Envoy の自動デプロイで使用している場合は、
--service-proxy:network
フラグの値が転送ルールの VPC ネットワーク名と一致していることを確認します。Traffic Director を Compute Engine の Envoy 手動デプロイで使用している場合は、Envoy ブートストラップ ファイルで次のことを確認します。
TRAFFICDIRECTOR_NETWORK_NAME
変数の値が転送ルールの VPC ネットワーク名と一致することを確認します。TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
変数でプロジェクト番号が設定されていることを確認します。
GKE でデプロイし、自動インジェクタを使用している場合は、自動 Envoy インジェクションによる GKE Pod での Traffic Director の設定の手順を行い、プロジェクト番号と VPC ネットワーク名が正しく構成されていることを確認します。
Compute Engine の自動デプロイのトラブルシューティング
このセクションでは、Compute Engine で Envoy を自動デプロイした場合のトラブルシューティングについて説明します。
Envoy と VM のブートストラップ プロセスとその後のライフサイクル管理オペレーションは、一時的な接続の問題、リポジトリの破損、ブートストラップ スクリプトや VM 上のエージェントのバグ、予期しないユーザー アクションなど、多くの理由で失敗する可能性があります。
トラブルシューティング用の通信チャネル
Google Cloud には、ブートストラップ プロセスと VM 内に存在するコンポーネントの現在の状態を理解する際に役立つ通信チャネルが用意されています。
仮想シリアルポート出力のロギング
VM のオペレーティング システム、BIOS、その他のシステムレベルのエンティティは通常、シリアルポートに出力を書き込みます。この出力は、システムのクラッシュ、起動の失敗、起動時の問題、シャットダウン時の問題などのトラブルシューティングに役立ちます。
Compute Engine ブートストラップ エージェントは、基本的なパッケージのインストールから、インスタンスのメタデータ サーバーからのデータ取得、iptables
構成、Envoy のインストール ステータスに至るまで、実行された一連のアクションを含むシステム イベントをポート 1 に記録します。
VM 上のエージェントは、Envoy プロセスのヘルス ステータス、新しく検出された Traffic Director サービスと、VM の問題を調査するときに役立つ可能性のあるその他の情報を記録します。
Cloud Monitoring のロギング
シリアルポート出力で公開されるデータは、Monitoring にも記録されます。Monitoring は、Golang ライブラリを使用してログを別のログにエクスポートし、ノイズを軽減します。このログはインスタンス レベルのログであるため、サービス プロキシのログは他のインスタンス ログと同じページに表示されることがあります。
VM のゲスト属性
ゲスト属性は、インスタンスでの実行中にアプリケーションから書き込み可能な特定の型のカスタム メタデータです。インスタンスのすべてのアプリケーションまたはユーザーは、ゲスト属性メタデータ値にデータを書き込み、読み取ることができます。
Compute Engine Envoy ブートストラップ スクリプトと VM 上のエージェントは、ブートストラップ プロセスと Envoy の現在のステータスに関する情報を含む属性を公開します。すべてのゲスト属性は gce-service-proxy
名前空間で公開されます。
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONE
問題が見つかった場合は、ゲスト属性 bootstrap-status
と bootstrap-last-failure
の値を確認することをおすすめします。FINISHED
以外の bootstrap-status
値は、Envoy 環境がまだ構成されていないことを意味します。bookstrap-last-failure
の値は、問題の原因を示します。
サービス プロキシ対応のインスタンス テンプレートを使用して作成された VM から Traffic Director サービスに到達できない
この問題を解決するには、次の手順を行います。
VM へのサービス プロキシ コンポーネントのインストールが完了していないか、失敗している可能性があります。次のコマンドを使用して、すべてのコンポーネントが正しくインストールされているかどうかを確認します。
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONE
bootstrap-status
ゲスト属性は次のいずれかに設定されます。[none]
は、インストールがまだ開始していないことを示します。VM がまだ起動中である可能性があります。数分後にもう一度ステータスを確認してください。IN PROGRESS
は、サービス プロキシ コンポーネントのインストールと構成がまだ完了していないことを示します。プロセスの更新についてステータス チェックを繰り返します。FAILED
は、コンポーネントのインストールまたは構成が失敗したことを示します。gce-service-proxy/bootstrap-last-failure
属性をクエリして、エラー メッセージを確認します。FINISHED
は、インストールと構成のプロセスがエラーなしで終了したことを示します。次の手順で、トラフィック インターセプトと Envoy プロキシが正しく構成されていることを確認します。
VM 上のトラフィック インターセプトが Traffic Director ベースのサービスに対して正しく構成されていません。VM にログインし、
iptables
構成を確認します。gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo iptables -L -t nat
次のような
SERVICE_PROXY_REDIRECT
エントリのチェーンSERVICE_PROXY_SERVICE_CIDRS
を調べます。Chain SERVICE_PROXY_SERVICE_CIDRS (1 references) target prot opt source destination ... SERVICE_PROXY_REDIRECT all -- anywhere 10.7.240.0/20
サービスごとに、
destination
列に一致する IP アドレスまたは CIDR が必要です。仮想 IP アドレス(VIP)のエントリがない場合は、Traffic Director から Envoy プロキシ構成を追加する際に問題が発生したか、VM 上のエージェントで障害が発生しました。Envoy プロキシが、Traffic Director からの構成をまだ受信していません。VM にログインして、Envoy プロキシの構成を確認します。
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dump
Traffic Director から受信したリスナー構成を調べます。次に例を示します。
"dynamic_active_listeners": [ ... "filter_chains": [{ "filter_chain_match": { "prefix_ranges": [{ "address_prefix": "10.7.240.20", "prefix_len": 32 }], "destination_port": 80 }, ... "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1" ... ]
address_prefix
は、Traffic Director サービスの仮想 IP アドレス(VIP)です。これは、td-routing-rule-1
という URL マップを指します。接続するサービスがリスナー構成にすでに含まれているかどうかを確認します。VM 上のエージェントが実行されていません。新しい Traffic Director サービスが作成されると、VM 上のエージェントはトラフィック インターセプトを自動的に構成します。エージェントが実行されていない場合、新しいサービスへのすべてのトラフィックは Envoy Proxy をバイパスして VIP に直接送信され、タイムアウトします。
次のコマンドを実行して、VM 上のエージェントのステータスを確認します。
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONE
VM 上のエージェントの属性を調べます。
agent-heartbeat
属性の値は、エージェントで最後にアクションを実行したか確認した時刻です。この値が 5 分以上経過している場合は、エージェントが停止します。この場合、次のコマンドを使用して VM を再作成する必要があります。gcloud compute instance-groups managed recreate-instance
agent-last-failure
属性は、エージェントで最後に発生したエラーを公開します。これは、エージェントが次にチェックするときにまでに解決される一時的な問題の可能性があります(たとえば、エラーがCannot reach the Traffic Director API server
の場合もあれば、永続的なエラーである場合もあります)。数分待ってから、エラーを再度確認してください。
受信トラフィック インターセプトがワークロード ポートに構成されているが、VM の外部からポートに接続することができない
この問題を解決するには、次の手順を行います。
VM へのサービス プロキシ コンポーネントのインストールが完了していないか、失敗している可能性があります。次のコマンドを使用して、すべてのコンポーネントが正しくインストールされているかどうかを確認します。
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONE
bootstrap-status
ゲスト属性は次のいずれかに設定されます。[none]
は、インストールがまだ開始していないことを示します。VM がまだ起動中である可能性があります。数分後にもう一度ステータスを確認してください。IN PROGRESS
は、サービス プロキシ コンポーネントのインストールと構成がまだ完了していないことを示します。プロセスの更新についてステータス チェックを繰り返します。FAILED
は、コンポーネントのインストールまたは構成が失敗したことを示します。gce-service-proxy/bootstrap-last-failure
属性をクエリして、エラー メッセージを確認します。FINISHED
は、インストールと構成のプロセスがエラーなしで終了したことを示します。次の手順で、トラフィック インターセプトと Envoy プロキシが正しく構成されていることを確認します。
VM 上のトラフィック インターセプトが、受信トラフィックに対して正しく構成されていません。VM にログインし、
iptables
構成を確認します。gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo iptables -L -t nat
次のような
SERVICE_PROXY_IN_REDIRECT
エントリのチェーンSERVICE_PROXY_INBOUND
を調べます。Chain SERVICE_PROXY_INBOUND (1 references) target prot opt source destination ... SERVICE_PROXY_IN_REDIRECT tcp -- anywhere anywhere tcp dpt:mysql
service-proxy:serving-ports
で定義されているポートごとに、destination
列に一致するポートがあるはずです。ポートのエントリがない場合は、すべての受信トラフィックが Envoy プロキシをバイパスして、このポートに直接送信されます。このポートまたは特定の 1 つのポートを除くすべてのポートにトラフィックをドロップする他のルールがないことを確認します。
Envoy プロキシが、Traffic Director からの受信ポートの構成をまだ受信していません。VM にログインして、Envoy プロキシの構成を確認します。
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dump
Traffic Director から受信した受信リスナー構成を探します。
"dynamic_active_listeners": [ ... "filter_chains": [{ "filter_chain_match": { "prefix_ranges": [{ "address_prefix": "10.0.0.1", "prefix_len": 32 }], "destination_port": 80 }, ... "route_config_name": "inbound|default_inbound_config-80" ... ]
inbound
で始まるroute_config_name
は、受信トラフィックのインターセプトを目的として作成された特別なサービスを示します。接続するポートが、すでにdestination_port
のリスナー構成に含まれているかどうかを確認します。
GKE Pod の自動デプロイのトラブルシューティング
このセクションでは、GKE Pod の Envoy の自動デプロイのトラブルシューティングについて説明します。
自動 Envoy インジェクションを有効にした後 Pod が起動しない
状況によっては、アプリケーション Pod が正しく起動しないことがあります。これは、制限付きのファイアウォール ルールで限定公開 GKE クラスタを使用している場合に発生することがあります。
限定公開 GKE クラスタで Traffic Director を使用する場合は、サイドカー インジェクタ Webhook に追加のファイアウォール ルールを作成する必要があります。GKE コントロール プレーンが TCP ポート 9443
上の Pod に到達できるようにファイアウォール ルールを作成するには、特定のユースケースに対するファイアウォール ルールの追加をご覧ください。
この問題は、スタンドアロン Pod を作成するとき、または Deployment が Pod を作成しようとするときに発生する可能性があります。
スタンドアロン Pod を(kubectl apply
や kubectl run
を使用して)作成するとき、kubectl
コマンドラインから次のようなエラー メッセージが返されることがあります。
Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Deployment から Pod を作成すると、次の問題が発生することがあります。
kubectl get pods
で、Deployment に関連付けられている Pod が表示されない。kubectl get events --all-namespaces
で、次のようなエラー メッセージが表示される。Warning FailedCreate 15s replicaset-controller Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
セットアップ ガイドにどおりに操作すると、サンプル クライアントをデプロイしてインジェクションを検証するのステップでこの問題が最初に発生する可能性があります。kubectl create -f demo/client_sample.yaml
の実行後、kubectl get deploy busybox
を実行して 0/1 READY Pod を表示します。kubectl describe rs -l run=client
コマンドを発行して Deployment に関連付けられている replicaset
を記述した場合も、このエラーが起きることがあります。
構成の確認後に接続が拒否される
自動 Envoy インジェクションで Traffic Director を設定すると、構成の検証時に接続拒否エラーが発生することがあります。考えられる原因は次のいずれかです。
specs/01-configmap.yaml
ファイルのdiscoveryAddress
の値が正しくない。この値はtrafficdirector.googleapis.com:443
にする必要があります。specs/01-configmap.yaml
ファイル内の VPC ネットワークの値が正しくない。specs/01-configmap.yaml
ファイルの Traffic Director プロジェクトの値が正しくない。- Pod 内の
discoveryAddress
の値が正しくない。 - Traffic Director サイドカー インジェクタではなく Istio サイドカー インジェクタが実行されている。
specs/01-configmap.yaml
ファイルのサンプルについては、サイドカー インジェクタを構成するをご覧ください。specs/01-configmap.yaml
ファイルに正しい値が含まれていない場合、Envoy は Traffic Director から修正用の構成を取得できません。この問題を解決するには、specs/01-configmap.yaml
ファイルを調べて、値が正しいことを確認してから、自動インジェクタを再作成します。
specs/01-configmap.yaml
ファイルと Pod 内の discoveryAddress
の値を確認します。Pod では、値はサイドカー インジェクタによって設定されます。Pod 内の discoveryAddress
の値を確認するには、次のコマンドを実行します。
kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'
次のような出力が表示されます。
"discoveryAddress":"trafficdirector.googleapis.com:443"
手動 Envoy インジェクションと GKE Pod で接続が拒否される
接続が拒否されたというメッセージが表示された場合は、busybox ログで Traffic Director API が有効になっているか、Envoy ログで権限が間違っているかどうかを調べてください。
手動 Envoy インジェクションと GKE Pod で接続がタイムアウトする
接続タイムアウト メッセージが表示された場合は、Deployment の URL マップ、転送ルール、またはバックエンド サービスの構成が正しくない可能性があります。これらのリソースが適切に構成されていることを確認してください。
接続がサーバー ファーストのプロトコルを使用するときの問題
MySQL などの一部のアプリケーションでは、サーバーが最初のパケットを送信するプロトコルを使用します。つまり、初回接続時にサーバーが最初のバイトを送信します。これらのプロトコルとアプリケーションは Traffic Director ではサポートされていません。
サービス メッシュの状態のトラブルシューティング
このガイドでは、Traffic Director の構成に関する問題を解決する際に有用な情報を提供します。
大部分のエンドポイントが正常でない場合の Traffic Director の動作
信頼性を高めるために、99% のエンドポイントが異常な状態になると、Traffic Director はエンドポイントのヘルス ステータスを無視するようにデータプレーンを構成します。データプレーンは、サービスポートが引き続き機能している可能性があることから、すべてのエンドポイントでトラフィックを分散します。
正常でないバックエンドが原因でトラフィックが最適に分散されない
Traffic Director は、バックエンド サービスに関連付けられている HealthCheck
リソースの情報を使用して、バックエンドの状態を評価します。Traffic Director はこのヘルス ステータスを使用して、トラフィックを最も近い正常なバックエンドに転送します。一部のバックエンドが異常な状態の場合、トラフィックは引き続き処理されますが、分散が最適化されません。たとえば、正常なバックエンドが存在するリージョンにトラフィックが転送されても、クライアントから距離がある場合は、レイテンシが発生します。バックエンドのヘルス ステータスを特定してモニタリングするには、次の手順を試してください。
- Google Cloud Console でバックエンド サービスのヘルス ステータスを確認します。
Traffic Director のサービスに移動 HealthCheck
リソースでロギングが有効になっていることを確認します。- ヘルスチェックが最近失敗した場合は、Cloud Audit Logs で
HealthCheck
の構成が最近変更されたかどうかを確認します。
バックエンドが予期せずトラフィックを拒否する
Traffic Director サービスのセキュリティを構成した場合は、EndpointPolicy
リソースを使用してセキュリティ ポリシーをバックエンドに適用します。EndpointPolicy
構成に誤りがあると、バックエンドでトラフィックが拒否される可能性があります。次のログを使用して、このシナリオのトラブルシューティングを行ってください。
- Traffic Director から報告されたエンドポイント ポリシーの競合があるかどうか確認します。
- Cloud Audit Logs を調べて、ユーザー構成(具体的には、
EndpointPolicy
、ServerTlsPolicy
、AuthorizationPolicy
)が最近変更されたかどうか確認します。
次のステップ
- Traffic Director の仕組みについては、Traffic Director の概要をご覧ください。
- プロキシレス gRPC サービスをデプロイするときに構成の問題を解決するには、プロキシレス gRPC を使用したデプロイのトラブルシューティングをご覧ください。
- Traffic Director の使用に関するその他のサポートについては、サポートの利用をご覧ください。