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

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

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

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

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

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

始める前に

  1. クラスタの kubeconfig コンテキストが kubeconfig ファイルで利用できることを確認します。そうでない場合は、次のコマンドを実行します。

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION --project=PROJECT_NAME

    以下を置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • CLUSTER_LOCATION: クラスタのゾーンまたはリージョン。
    • PROJECT_NAME: プロジェクト名。

  2. アプリケーションのデフォルト認証情報が作成されていることを確認します。作成されていない場合は、次のいずれかのコマンドを実行します。

    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: メンバーシップのリージョン。メンバーシップのロケーションを確認するには、gcloud container fleet memberships list --project FLEET_PROJECT_ID で FLEET_PROJECT_ID をフリート プロジェクト 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: クラスタ、リスナー、ルート、エンドポイント、ブートストラップ、ログ、シークレット、すべて。
  • MEMBERSHIP_NAME: メンバーシップの名前。
  • MEMBERSHIP_LOCATION: メンバーシップのリージョン。メンバーシップのロケーションを確認するには、gcloud container fleet memberships list --project FLEET_PROJECT_ID で FLEET_PROJECT_ID をフリート プロジェクト ID に置き換えます。
  • PROJECT_NAME: プロジェクト名。

クラスタ内

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

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

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

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

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

問題の範囲を絞り込む

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

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

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

問題の範囲を絞り込むと、特定のログや情報をより効率的に見つけることができます。Cloud Service Mesh によって生成されるログとそのログに含まれる情報の見方については、Cloud Service Mesh ログの解釈方法をご覧ください。