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 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 に接続し、バイナリ バージョンを確認します。

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

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

   ps aux | grep envoy
   

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

   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 を再起動して設定プロセスを再実行すると問題が解決します。gcloud コマンドライン ツールで作成した 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 ルールはプロキシ ユーザーからのトラフィックをインターセプトしません。

大部分のエンドポイントが正常でない場合の Traffic Director の動作

信頼性を高めるために、99% のエンドポイントが異常な状態になると、Traffic Director はエンドポイントのヘルス ステータスを無視するようにデータプレーンを構成します。データプレーンは、サービスポートが引き続き機能している可能性があることから、すべてのエンドポイントでトラフィックを分散します。

構成に問題があることを示す 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 ネットワーク名を参照する転送ルールを探します。

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

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

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

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

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

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

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

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 上のトラフィック インターセプトが 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 上のエージェントで障害が発生しました。

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

4. VM 上のエージェントが実行されていません。新しい Traffic Director サービスが作成されると、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 Traffic Director 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 プロキシが、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"

接続がサーバー ファーストのプロトコルを使用するときの問題

MySQL などの一部のアプリケーションでは、サーバーが最初のパケットを送信するプロトコルを使用します。つまり、最初の接続時にサーバーが最初のバイトを送信します。Traffic Director による Envoy の構成方法が原因で、これらのプロトコルでは接続が失敗する場合があります。

たとえば、ログに次のようなエラーが記録されることがあります。

MySQL Connection Error: (2006) MySQL server has gone away

回避策として、クライアント アプリケーションが MySQL への接続を開こうとすると Envoy をバイパスするように、トラフィック インターセプトをカスタマイズできます。たとえば、自動 Envoy インジェクションで GKE Pod で Traffic Director を使用する場合は、cloud.google.com/excludeOutboundPorts Pod アノテーションを使用します。MySQL（3306）または「サーバーが最初のパケットを送信する」プロトコルを使用する他のアプリケーションに関連付けられているポートを指定します。

次のステップ

• Traffic Director の仕組みについては、Traffic Director の概要をご覧ください。
• プロキシレス gRPC サービスをデプロイするときに構成の問題を解決するには、プロキシレス gRPC を使用したデプロイのトラブルシューティングをご覧ください。
• Traffic Director の使用に関するその他のサポートについては、サポートの利用をご覧ください。