Envoy デプロイに関するトラブルシューティング
このガイドでは、Google API を使用して Cloud Service Mesh を実行するときに Envoy クライアントの構成に関する問題を解決する際に有用な情報を提供します。Cloud Service Mesh に関する問題の調査にクライアント ステータス ディスカバリ サービス(CSDS)の API を使用する方法については、Cloud Service Mesh のクライアント ステータスについてをご覧ください。
VM にインストールされている Envoy のバージョンの判別
次の手順を使用して、仮想マシン(VM)インスタンスで実行されている Envoy のバージョンを確認します。
Envoy のバージョンを検証または確認するには、次のいずれかを行います。
パス gce-service-proxy/proxy-version
で VM のゲスト属性を確認します。
gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME
--zone ZONEc --query-path=gce-service-proxy/proxy-versionNAMESPACE 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 インスタンスに接続します。パスは次のようになります。
/var/log/envoy/envoy.err.log
プロキシを Cloud Service Mesh に接続できない
プロキシが Cloud Service Mesh に接続しない場合は、次の操作を行います。
Envoy プロキシのログで
trafficdirector.googleapis.com
への接続エラーを確認します。すべてのトラフィックを Envoy プロキシにリダイレクトするように
netfilter
を設定した場合(iptables
を使用)は、プロキシを実行するユーザー(UID)がリダイレクトから除外されていることを確認してください。除外していないと、トラフィックはプロキシに継続的にループバックします。プロジェクトで Cloud Service Mesh API が有効になっていることを確認します。プロジェクトの API とサービスで、Cloud Service Mesh 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.24.9 以降であることを確認します。
Cloud Service Mesh で構成されたサービスにアクセスできない
Cloud Service Mesh で構成されたサービスにアクセスできない場合は、サイドカー プロキシが実行中で、Cloud Service Mesh に接続できることを確認します。
Envoy をサイドカー プロキシとして使用している場合は、次のコマンドを実行して確認できます。
コマンドラインから、Envoy プロセスが実行されていることを確認します。
ps aux | grep envoy
Envoy のランタイム構成を調べて、Cloud Service Mesh によって動的リソースが構成されていることを確認します。構成を表示するには、次のコマンドを実行します。
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 アクセス ロギングが構成されている場合にサービスにアクセスできなくなる
Cloud Service Mesh の 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 ユーザーが書き込めるようにします。
構成に問題があることを示す Envoy ログのエラー メッセージ
このセクションは、ロード バランシング API を使用するデプロイに適用されます。
Cloud Service Mesh の構成に問題がある場合は、Envoy のログに次のエラー メッセージが記録されることがあります。
warning envoy config StreamAggregatedResources gRPC config stream closed: 5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in project "PROJECT_NUMBER".
warning envoy upstream StreamLoadStats gRPC config stream closed: 5, Cloud Service Mesh 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.
Cloud Service Mesh configuration was not found.
最後のエラー メッセージ(Traffic Director configuration was not found
)は通常、Envoy が Cloud Service Mesh の構成をリクエストしたが、一致する構成が見つからないことを示しています。Envoy が Cloud Service Mesh に接続すると、VPC ネットワーク名(my-network
など)が提示されます。次に、Cloud Service Mesh は、INTERNAL_SELF_MANAGED
負荷分散スキームを持ち、同じ VPC ネットワーク名を参照する転送ルールを探します。
このエラーを解決するには、次の手順を行います。
ネットワークに負荷分散スキーム
INTERNAL_SELF_MANAGED
の転送ルールがあることを確認します。転送ルールの VPC ネットワーク名をメモします。Compute Engine の Envoy の自動デプロイで Cloud Service Mesh を使用している場合は、
--service-proxy:network
フラグの値が転送ルールの VPC ネットワーク名と一致していることを確認します。Compute Engine の Envoy 手動デプロイで Cloud Service Mesh を使用している場合は、Envoy ブートストラップ ファイルで次のことを確認します。
TRAFFICDIRECTOR_NETWORK_NAME
変数の値が転送ルールの VPC ネットワーク名と一致することを確認します。TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
変数でプロジェクト番号が設定されていることを確認します。
GKE でデプロイし、自動インジェクタを使用している場合は、自動 Envoy インジェクションによる GKE Pod での Cloud Service Mesh の設定の手順を行い、プロジェクト番号と VPC ネットワーク名が正しく構成されていることを確認します。
Compute Engine のトラブルシューティング
このセクションでは、Compute Engine で Envoy をデプロイした場合のトラブルシューティングについて説明します。
Envoy と VM のブートストラップ プロセスとその後のライフサイクル管理オペレーションは、一時的な接続の問題、リポジトリの破損、ブートストラップ スクリプトや VM 上のエージェントのバグ、予期しないユーザー アクションなど、多くの理由で失敗する可能性があります。
トラブルシューティング用の通信チャネル
Google Cloud には、ブートストラップ プロセスと VM 内に存在するコンポーネントの現在の状態を理解する際に役立つ通信チャネルが用意されています。
仮想シリアルポート出力のロギング
VM のオペレーティング システム、BIOS、その他のシステムレベルのエンティティは通常、シリアルポートに出力を書き込みます。この出力は、システムのクラッシュ、起動の失敗、起動時の問題、シャットダウン時の問題などのトラブルシューティングに役立ちます。
Compute Engine ブートストラップ エージェントは、実行された一連のアクションを含むシステム イベントをシリアルポート 1 に記録します。これには、基本的なパッケージのインストールから、インスタンスのメタデータ サーバーからのデータ取得、iptables
構成、Envoy のインストール ステータスを含みます。
VM 上のエージェントは、Envoy プロセスのヘルス ステータス、新しく検出された Cloud Service Mesh サービスと、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 から Cloud Service Mesh サービスに到達できない
この問題を解決するには、次の手順を行います。
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-failure1
属性をクエリして、エラー メッセージを確認します。FINISHED
は、インストールと構成のプロセスがエラーなしで終了したことを示します。次の手順で、トラフィック インターセプトと Envoy プロキシが正しく構成されていることを確認します。
VM 上のトラフィック インターセプトが Cloud Service Mesh ベースのサービスに対して正しく構成されていません。 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)のエントリがない場合は、Cloud Service Mesh から Envoy プロキシ構成を追加する際に問題が発生したか、VM 上のエージェントで障害が発生しました。Envoy プロキシが、Cloud Service Mesh からの構成をまだ受信していません。 VM にサインインして、Envoy プロキシの構成を確認します。
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dump
Cloud Service Mesh から受信したリスナー構成を調べます。次に例を示します。
"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
は、Cloud Service Mesh サービスの仮想 IP アドレス(VIP)です。これは、td-routing-rule-1
という URL マップを指します。接続するサービスがリスナー構成にすでに含まれているかどうかを確認します。VM 上のエージェントが実行されていません。新しい Cloud Service Mesh サービスが作成されると、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 Cloud Service Mesh 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-failure1
属性をクエリして、エラー メッセージを確認します。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 プロキシが、Cloud Service Mesh からの受信ポートの構成をまだ受信していません。 VM にサインインして、Envoy プロキシの構成を確認します。
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dump
Cloud Service Mesh から受信した受信リスナー構成を探します。inbound
"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
のリスナー構成に含まれているかどうかを確認します。
接続がサーバー ファーストのプロトコルを使用するときの問題
MySQL などの一部のアプリケーションでは、サーバーが最初のパケットを送信するプロトコルを使用します。つまり、初回接続時にサーバーが最初のバイトを送信します。これらのプロトコルとアプリケーションは Cloud Service Mesh ではサポートされていません。
サービス メッシュの状態のトラブルシューティング
このガイドでは、Cloud Service Mesh の構成に関する問題を解決する際に有用な情報を提供します。
大部分のエンドポイントが正常でない場合の Cloud Service Mesh の動作
信頼性を高めるために、99% のエンドポイントが異常な状態になると、Cloud Service Mesh はエンドポイントのヘルス ステータスを無視するようにデータプレーンを構成します。データプレーンは、サービスポートが引き続き機能している可能性があることから、すべてのエンドポイントでトラフィックを分散します。
正常でないバックエンドが原因でトラフィックが最適に分散されない
Cloud Service Mesh は、バックエンド サービスに接続されている HealthCheck
リソースの情報を使用して、バックエンドの状態を評価します。Cloud Service Mesh は、このヘルス ステータスを使用して、最も近い正常なバックエンドにトラフィックを転送します。一部のバックエンドが異常な状態の場合、トラフィックは引き続き処理されますが、分散が最適化されません。たとえば、正常なバックエンドが存在するリージョンにトラフィックが転送されても、クライアントから距離がある場合は、レイテンシが発生します。バックエンドのヘルス ステータスを特定してモニタリングするには、次の手順を試してください。
- Google Cloud コンソールでバックエンド サービスのヘルス ステータスを確認します。
Cloud Service Mesh サービスに移動 HealthCheck
リソースでロギングが有効になっていることを確認します。- ヘルスチェックが最近失敗した場合は、Cloud Audit Logs で
HealthCheck
の構成が最近変更されたかどうかを確認します。
次のステップ
- プロキシレス gRPC サービスをデプロイするときに構成の問題を解決するには、プロキシレス gRPC を使用したデプロイのトラブルシューティングをご覧ください。
- Cloud Service Mesh の使用に関するその他のサポートについては、サポートの利用をご覧ください。