順を追った Cloud Service Mesh のトラブルシューティング手順

このセクションでは、Cloud Service Mesh の使用時に発生する問題のトラブルシューティングと解決方法について説明します。さらにサポートが必要な場合は、サポートの利用をご覧ください。

トラブルシューティングの手順

Cloud Service Mesh のトラブルシューティングは、次の手順に沿って行います。

構成の自動検証ツールを使用する。
発生している問題が一般的な問題で、既知の解決策があるかどうか確認する。
問題の範囲を絞り込む。
関連するログと情報を確認する。
診断ログを収集して解決策を探す。

Cloud Service Mesh 診断ツールを使って、一般的な構成の問題を検出できます。こちらの手順に沿って、トラブルシューティングツールをインストールします。

始める前に

クラスタの kubeconfig コンテキストが kubeconfig ファイルで使用可能であることを確認します。そうでない場合は、次のコマンドを実行します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION --project=PROJECT_NAME
```
以下を置き換えます。
- CLUSTER_NAME: クラスタの名前。
- CLUSTER_LOCATION: クラスタのゾーンまたはリージョン。
- PROJECT_NAME: プロジェクト名。
アプリケーションのデフォルト認証情報が作成されていることを確認します。作成されていない場合は、次のいずれかのコマンドを実行します。
```
gcloud auth application-default login --billing-project=PROJECT_NAME
```
```
gcloud auth application-default set-quota-project PROJECT_NAME
```
PROJECT_NAME は、プロジェクト名に置き換えます。

コントロールプレーンのステータスを確認する

次のコマンドを使用すると、Cloud Service Mesh のコントロールプレーンのステータスを確認できます。

管理対象

Cloud Service Mesh コントロールプレーンへのクライアント接続ステータスのリストを取得します。

gcloud beta container fleet mesh debug proxy-status \
    --membership=MEMBERSHIP_NAME \
    --location=MEMBERSHIP_LOCATION \
    --project=PROJECT_NAME

以下を置き換えます。

MEMBERSHIP_NAME: メンバーシップの名前。
MEMBERSHIP_LOCATION: メンバーシップのリージョン。FLEET_PROJECT_ID をフリートプロジェクト ID に置き換え、gcloud container fleet memberships list --project FLEET_PROJECT_ID を使用してメンバーシップのロケーションを確認できます。
PROJECT_NAME: プロジェクト名。

次の表に、回答の説明を示します。

不明	（デフォルト）⁣ステータスの情報は利用できないか、不明です。
同期済み	コントロールプレーンがクライアントに構成を送信し、クライアントから ACK を受信しました。
エラー	コントロールプレーンがクライアントに構成を送信し、クライアントから NACK を受信しました。
最新でない	コントロールプレーンがクライアントに構成を送信しましたが、クライアントから ACK も NACK も受信しませんでした。
未送信	構成を送信できませんでした。
なし	該当なし
非対応	同期ステータスは、トラブルシューティング API ではサポートされていません。

クラスタ内

kubectl get pods -n istio-system
kubectl describe -n istio-system
istio-system 内のすべての Pod の場合: kubectl logs -n istio-system -l istio --all-containers
istioctl version
istioctl proxy-status
kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml
kubectl top pods -n istio-system

デプロイの規模を確認するには、次のコマンドを使用します。

kubectl get nodes
kubectl get services --all-namespaces
kubectl get pods --all-namespaces

プロキシ構成を表示する

次のコマンドを使用すると、Cloud Service Mesh プロキシの構成を確認できます。

管理対象

gcloud beta container fleet mesh debug proxy-config POD_NAME.NAMESPACE \ 
    --type=TYPE \
    --membership=MEMBERSHIP_NAME \
    --location=MEMBERSHIP_LOCATION \
    --project=PROJECT_NAME

POD_NAME: Pod の名前。
NAMESPACE: Pod の名前空間。
TYPE: cluster、listeners、routes、endpoints、bootstrap、log、secret、all のいずれか。
MEMBERSHIP_NAME: メンバーシップの名前。
MEMBERSHIP_LOCATION: メンバーシップのリージョン。FLEET_PROJECT_ID をフリートプロジェクト ID に置き換え、gcloud container fleet memberships list --project FLEET_PROJECT_ID を使用してメンバーシップのロケーションを確認できます。
PROJECT_NAME: プロジェクト名。

クラスタ内

istioctl proxy-config を使用して、クラスタ内コントロールプレーンのプロキシ構成を表示します。詳細については、Envoy と istiod のデバッグをご覧ください。

問題が解決しない場合は、次のセクションを参照して既知の問題かどうか確認してください。

よくある問題とその解決策を確認する

Cloud Service Mesh の一般的な問題と解決策が機能領域別にまとめられています。発生している症状がこれらの問題に一致しているかどうか確認することで、トラブルシューティングの時間を短縮できます。

ここで問題が解決しない場合は、次のセクションに進んでください。

問題の範囲を絞り込む

Cloud Service Mesh は、相互に連携する複数のテクノロジーで構成されます。つまり、特定の種類の問題が特定の機能領域やコンポーネントに関連していることを意味します。これらのコンポーネントは問題の解決に役立つログを生成します。提供された情報を手動で分析する前に、次の質問に答えて問題の範囲を絞り込みます。

この問題は、コントロールプレーンまたはデータプレーン（istiod や Envoy プロキシなど）で発生していますか？
どの機能領域（ネットワーク、テレメトリー、セキュリティなど）で問題が発生していますか？
トラフィックの損失が発生しているのはサービスメッシュ全体ですか。それとも特定のデプロイメントですか？
サービスメッシュでトラフィックをスケーリングできないため、問題が発生または悪化していますか？
この問題が原因で遅延やその他のパフォーマンスの問題が発生していますか？
問題をオンデマンドで再現できますか？
Istio や GKE など、最近の構成変更後に問題が発生しましたか？
サービスメッシュ内でトラフィックが増加または急増していますか？
このクラスタで、重要な機能が有効になっていますか。あるいは一般的でないデプロイがありますか？
CPU またはメモリの使用率が高くなっていますか。その場合、想定される規模はどの程度ですか？
考慮すべき割り当て制限はありますか？

順を追った Cloud Service Mesh のトラブルシューティング手順

トラブルシューティングの手順

始める前に

コントロール プレーンのステータスを確認する

管理対象

クラスタ内

プロキシ構成を表示する

管理対象

クラスタ内

よくある問題とその解決策を確認する

問題の範囲を絞り込む

関連するログと情報の確認

コントロールプレーンのステータスを確認する