このガイドでは、Traffic Director の構成に関する問題を解決する際に有用な情報を提供します。
Envoy のログの場所
問題のトラブルシューティングを行うには、Envoy プロキシのログを調べる必要があります。
Google Kubernetes Engine で、Envoy プロキシはアプリケーション Pod で実行されるため、istio-proxy
コンテナでフィルタリングすると、アプリケーション 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="istio-proxy"
クラスタでワークロードのロギングが有効になっていない場合は、次のようなコマンドを使用してエラーを確認できます。
kubectl logs $(kubectl get po -l app=WORKLOAD-NAME -o=jsonpath='{.items[0].metadata.name}') -c istio-proxy --tail 50 #NOTE: This assumes the default namespace.
次のフィルタを使用して、すべてのクラスタとワークロードで実行されているすべての Envoy のログを表示することもできます。
resource.type="k8s_container" resource.labels.container_name="istio-proxy"
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 のエラーを探します。
[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 ログのエラー メッセージ
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.
このエラー メッセージは通常、Envoy が Traffic Director の構成をリクエストし、一致する構成が見つからないことを示しています。Envoy が Traffic Director に接続すると、VPC ネットワーク名(my-network
など)が提示されます。Traffic Director は、(1)INTERNAL_SELF_MANAGED
という負荷分散スキームを使用し、(2)同じネットワーク名(my-network
など)を参照している転送ルールを探します。
ネットワークに負荷分散スキーム
INTERNAL_SELF_MANAGED
の転送ルールがあることを確認します。転送ルールの VPC ネットワークをメモしておきます。Compute Engine での Envoy の自動デプロイで Traffic Director を使用している場合は、
--service-proxy:network
フラグの値が転送ルールのネットワーク名と一致していることを確認します。Compute Engine の Envoy の手動デプロイで Traffic Director を使用している場合は、Envoy ブートストラップ ファイルを確認します。
TRAFFICDIRECTOR_NETWORK_NAME
変数の値をチェックし、その値が転送ルールのネットワーク名と一致することを確認します。- Envoy ブートストラップ ファイルの
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
変数でプロジェクト番号が設定されていることを確認します。
GKE にデプロイし、自動インジェクタを使用している場合は、自動 Envoy インジェクションによる Google Kubernetes Engine Pod での 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
ゲスト属性は次のいずれかに設定されます。- [none] は、インストールがまだ開始していないことを示します。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 の外部からポートに接続することができない
次の手順に沿って問題を解決してください。
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 プロキシが、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
のリスナー構成に含まれているかどうかを確認します。
次のステップ
- Traffic Director の仕組みについては、Traffic Director のコンセプトをご覧ください。