Envoy デプロイに関するトラブルシューティング

このガイドでは、Google API で Cloud Service Mesh を実行するときに Envoy クライアントの構成の問題を解決する際に役立つ情報を提供します。Cloud Service Mesh に関する問題の調査に Client Status Discovery Service（CSDS）API を使用する方法については、Cloud Service Mesh のクライアント ステータスについてをご覧ください。

注: このガイドは、Google Cloud APIs を使用する Cloud Service Mesh のみに対応しており、Istio 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-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 インスタンスに接続し、ログファイルを取得できます。パスは次のようになります。

  /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 をサイドカー プロキシとして使用している場合は、次のコマンドを実行して確認できます。

1. コマンドラインから、Envoy プロセスが実行されていることを確認します。

   ps aux | grep envoy
   

2. Envoy のランタイム構成を調べて、Cloud Service Mesh によって動的リソースが構成されていることを確認します。構成を表示するには、次のコマンドを実行します。

   curl http://localhost:15000/config_dump
   

3. サイドカー プロキシのトラフィック インターセプトが正しく設定されていることを確認します。iptables を使用したリダイレクト設定の場合は、iptables コマンドを実行してから grep を実行し、出力結果にルールが含まれることを確認します。

   sudo iptables -t nat -S | grep ISTIO
   

   次に、iptables が仮想 IP アドレス（VIP）10.0.0.1/32 をインターセプトし、ポート 15001 で実行されている Envoy プロキシに UID 1006 として転送する出力の例を示します。

   -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 ネットワーク名を参照する転送ルールを探します。

このエラーを解決するには、次の手順を行います。

1. ネットワークに負荷分散スキーム INTERNAL_SELF_MANAGED の転送ルールがあることを確認します。転送ルールの VPC ネットワーク名をメモします。

2. Compute Engine の Envoy の自動デプロイで Cloud Service Mesh を使用している場合は、--service-proxy:network フラグの値が転送ルールの VPC ネットワーク名と一致していることを確認します。

3. Compute Engine の Envoy の手動デプロイで Cloud Service Mesh を使用している場合は、Envoy ブートストラップ ファイルで次のことを確認します。

   1. TRAFFICDIRECTOR_NETWORK_NAME 変数の値が転送ルールの VPC ネットワーク名と一致することを確認します。
   2. TRAFFICDIRECTOR_GCP_PROJECT_NUMBER 変数でプロジェクト番号が設定されていることを確認します。

4. 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 サービスに到達できない

この問題を解決するには、次の手順を行います。

1. 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 プロキシが正しく構成されていることを確認します。

2. 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 上のエージェントで障害が発生しました。

3. 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 マップを指します。接続するサービスがリスナー構成にすでに含まれているかどうかを確認します。

4. VM 上のエージェントが実行されていません。新しい Cloud Service Mesh サービスが作成されると、VM 上のエージェントはトラフィック インターセプトを自動的に構成します。エージェントが実行されていない場合、新しいサービスへのすべてのトラフィックは Envoy Proxy をバイパスして VIP に直接送信され、タイムアウトします。

   1. 次のコマンドを実行して、VM 上のエージェントのステータスを確認します。

      gcloud compute instances get-guest-attributes INSTANCE_NAME \
         --query-path=gce-service-proxy/ \
         --zone=ZONE
      

   2. VM 上のエージェントの属性を調べます。agent-heartbeat 属性の値は、エージェントで最後にアクションを実行したか確認した時刻です。この値が 5 分以上経過している場合は、エージェントが停止します。この場合、次のコマンドを使用して VM を再作成する必要があります。

      gcloud compute instance-groups managed recreate-instance
      

   3. agent-last-failure 属性は、エージェントで最後に発生したエラーを公開します。これは、エージェントが次にチェックするときにまでに解決される一時的な問題の可能性があります（たとえば、エラーが Cannot reach the Cloud Service Mesh API server の場合もあれば、永続的なエラーである場合もあります）。数分待ってから、エラーを再度確認してください。

受信トラフィック インターセプトがワークロード ポートに構成されているが、VM の外部からポートに接続することができない

この問題を解決するには、次の手順を行います。

1. 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 プロキシが正しく構成されていることを確認します。

2. 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 つのポートを除くすべてのポートにトラフィックをドロップする他のルールがないことを確認します。

3. 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.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 の使用に関するその他のサポートについては、サポートの利用をご覧ください。