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

このガイドでは、Traffic Director の構成に関する問題を解決する際に有用な情報を提供します。

プロキシを Traffic Director に接続できない

サイドカープロキシを Traffic Director に接続できない場合は、次の手順を実行してください。

サイドカープロキシのログで trafficdirector.googleapis.com への接続エラーを確認します。
すべてのトラフィックをサイドカープロキシにリダイレクトするように（iptables 経由で）netfilter を設定している場合は、プロキシを実行するユーザー（UID）がリダイレクトから除外されていることを確認します。除外していないと、トラフィックはプロキシに継続的にループバックします。
プロジェクトで Traffic Director API を有効にしたことを確認してください。プロジェクトの API とサービスで、Traffic Director API のエラーを探します。
[API ライブラリ] ページに移動
VM の API アクセススコープが GCP API へのフルアクセスを許可するように設定されていることを確認します。これを行うには、VM の作成時に --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 が 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

VM インスタンスが GCP Console で作成された場合、一部の IPV6 関連モジュールは再起動するまでインストールされず使用できません。これにより依存関係が欠落するため、iptables が失敗します。この場合は、VM を再起動して設定プロセスを再実行すると問題が解決します。gcloud コマンドを使用して作成した Compute Engine VM では、この問題は発生しないと考えられます。

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_LISTENER:
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 の自動デプロイのトラブルシューティング

このセクションでは、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 ゲスト属性は次のいずれかに設定されます。
- [なし] は、インストールがまだ開始されていないことを示します。VM がまだ起動中である可能性があります。数分後にもう一度ステータスを確認してください。
- IN PROGRESS は、サービスプロキシコンポーネントのインストールと構成がまだ完了していないことを示します。プロセスの更新についてステータスチェックを繰り返します。
- FAILED は、コンポーネントのインストールまたは構成が失敗したことを示します。gce-service-proxy/bootstrap-last-failure1 属性をクエリして、エラーメッセージを確認します。
- 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 が必要です。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 サービスの 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 分を超えると、エージェントは停止します。コマンド gcloud compute instance-groups managed recreate-instance を使用して VM を再作成する必要があります。
agent-last-failure 属性は、エージェントで発生した最後のエラーを公開します。これは、エージェントが次にチェックを行うときに解決される一時的な問題である可能性があります。たとえば、エラーは Cannot reach the Traffic Director API server であるか、永続的なエラーである可能性があります。数分待ってから、エラーを再確認してください。

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