Google Distributed Cloud のオブザーバビリティに関する問題のトラブルシューティング

このドキュメントでは、Google Distributed Cloud のオブザーバビリティに関する問題のトラブルシューティングに活用いただけます。こうした問題が発生した場合は、推奨される修正方法と回避策をご覧ください。

さらにサポートを必要とされる場合は、Google サポートにお問い合わせください。

Cloud Audit Logs が収集されない

クラスタ構成の cloudAuditLogging セクションで Cloud Audit Logs が有効になっているかどうかを確認します。プロジェクト ID、ロケーション、サービス アカウント キーが正しく構成されていることを確認します。プロジェクト ID は、gkeConnect の下にあるプロジェクト ID と同じである必要があります。

Cloud Audit Logs が有効になっている場合、ログが収集されない最も一般的な理由は権限です。この場合、権限拒否のエラー メッセージが Cloud Audit Logs のプロキシ コンテナに表示されます。

Cloud Audit Logs プロキシ コンテナは、次のいずれかとして実行されます。

• 管理クラスタまたはスタンドアロン クラスタ内の静的 Pod として。
• kube-apiserver Pod のサイドカー コンテナとして。

権限エラーが表示された場合は、権限のトラブルシューティングと解決の手順を行ってください。

kube-state-metrics 指標が収集されない

kube-state-metrics（KSM）はクラスタ内の単一レプリカ Deployment として実行され、クラスタ内のほぼすべてのリソースに関する指標を生成します。KSM と gke-metrics-agent が同じノードで実行されている場合、すべてのノードの指標エージェントでサービスの停止が発生するリスクが高くなります。

KSM 指標の名前は、kube_<ResourceKind> のパターン（例: kube_pod_container_info）に従います。kube_onpremusercluster_ で始まる指標は、KSM ではなくオンプレミス クラスタ コントローラから取得されます。

KSM 指標がない場合は、次のトラブルシューティング手順を確認してください。

• Cloud Monitoring で、kubernetes.io/anthos/container/... のようなサマリー API 指標を使用して KSM の CPU、メモリ、再起動回数を確認します。これは KSM とは別のパイプラインです。KSM Pod が充分でないリソースによって制限されていないことを確認します。
  • KSM でこれらのサマリー API 指標が利用できない場合、同じノードの gke-metrics-agent でも同じ問題が発生する可能性があります。
• クラスタ内で、KSM と同じノードの KSM Pod と gke-metrics-agent Pod のステータスとログを確認します。

kube-state-metrics クラッシュ ループが発生する

症状

Cloud Monitoring から kube-state-metrics（KSM）の指標を利用できない。

原因

このシナリオは、大規模なクラスタや大量のリソースを持つクラスタで発生する可能性が高くなります。KSM は単一のレプリカ Deployment として実行され、Pod、Deployment、DaemonSet、ConfigMap、Secret、PersistentVolume などのクラスタ内のほぼすべてのリソースをい知覧表示します。指標は、これらのリソース オブジェクトごとに生成されます。いずれかのリソースに多数のオブジェクトが存在する場合（10,000 Pod を超えるクラスタなど）、KSM のメモリが不足する可能性があります。

影響のあるバージョン

この問題は、Google Distributed Cloud のどのバージョンでも発生する可能性があります。

ここ最新のいくつかの Google Distributed Cloud のバージョンでは、デフォルトの CPU とメモリの上限が引き上げられているため、これらのリソースの問題はあまり発生しません。

修正と回避策

メモリ不足の問題が原因かどうかを確認するには、次の手順を確認します。

• kubectl describe pod または kubectl get pod -o yaml を使用して、エラー ステータス メッセージを確認します。
• 再起動する前に KSM のメモリ消費量と使用率の指標を確認して、上限に達しているかどうかを確認します。

メモリ不足による問題が発生していることを確認したら、次のいずれかの解決策を実施します。

• KSM のメモリ リクエストと上限を増やす。

  注: リソースの増加後に KSM が安定した場合でも、同じノードの gke-metrics-agent が KSM から多数の指標をスクレイピングするときにボトルネックとなる可能性があります。

  KSM の CPU とメモリを調整するには:

  • Google Distributed Cloud バージョン 1.16.0 以降では、Google Cloud Observability が KSM を管理します。KSM を更新するには、Stackdriver コンポーネントのデフォルトの CPU とメモリのリクエストと上限をオーバーライドするをご覧ください。

  • Google Distributed Cloud バージョンが 1.10.7 以降、1.11.3 以降、1.12.2 以降、または 1.13 以降の場合（ただし 1.16.0 より前）は、ConfigMap を作成して CPU とメモリを調整します。

    1. 次の定義を使用して、kube-system Namespace（1.13 以降の場合は gke-managed-metrics-server）に kube-state-metrics-resizer-config という名前の ConfigMap を作成します。必要に応じて、CPU とメモリの数を調整します。

         apiVersion: v1
         kind: ConfigMap
         metadata:
           name: kube-state-metrics-resizer-config
           namespace: kube-system
         data:
           NannyConfiguration: |-
             apiVersion: nannyconfig/v1alpha1
             kind: NannyConfiguration
             baseCPU: 200m
             baseMemory: 1Gi
             cpuPerNode: 3m
             memoryPerNode: 20Mi
         ```
       

    2. ConfigMap を作成したら、次のコマンドを使用して KSM Pod を削除し、KSM Deployment を再起動します。

       kubectl -n kube-system rollout restart deployment kube-state-metrics
       

  • Google Distributed Cloud バージョン 1.9 以前、1.10.6 以前、1.11.2 以前、1.12.1 以前の場合:

    • 長期的な解決策はありません。KSM 関連のリソースを編集すると、monitoring-operator によって変更が自動的に元に戻されます。
    • monitoring-operator を 0 レプリカにスケールダウンしてから、KSM Deployment を編集してリソースの上限を調整できます。ただし、monitoring-operator を使用して新しいパッチリリースで提供される脆弱性パッチはクラスタに配信されません。クラスタを修正後の新しいバージョンにアップグレードした後に、monitoring-operator を忘れずにスケールアップしてください。

• KSM からの指標の数を減らします。

  Google Distributed Cloud 1.13 の場合、KSM はデフォルトではコア指標という少数の指標のみを公開します。この動作は、リソースの使用量が以前のバージョンよりも小さいことを意味しますが、同じ手順に沿って KSM 指標の数をさらに減らすことができます。

  1.13 より前のバージョンの Google Distributed Cloud の場合、KSM はデフォルトのフラグを使用します。この構成では、多数の指標が公開されます。

gke-metrics-agent クラッシュ ループが発生する

gke-metrics-agent で kube-state-metrics が存在するノードでのみメモリ不足の問題が発生する場合、原因は多数の kube-state-metrics 指標にあります。この問題を軽減するには、stackdriver-operator をスケールダウンし、KSM を変更して、前のセクションで説明したように、必要な少数の指標を公開します。クラスタが Google Distributed Cloud 1.13 にアップグレードされた後に stackdriver-operator をスケールアップしてください。1.13 では、KSM は、デフォルトで少数のコア指標を公開します。

メモリ不足イベントに関係のない問題については、gke-metric-agent の Pod ログをご確認ください。Stackdriver カスタム リソースに resourceAttrOverrideフィールドを追加することにより、すべての gke-metrics-agent Pod の CPU とメモリを調整できます。

stackdriver-metadata-agent クラッシュ ループが発生する

症状

Cloud Monitoring で指標をフィルタリングする際に、システム メタデータ ラベルが使用できない。

原因

stackdriver-metadata-agent のクラッシュ ループの最も一般的な原因は、メモリ不足イベントです。このイベントは kube-state-metrics と同類です。stackdriver-metadata-agent はすべてのリソースを一覧表示するわけではありませんが、Pod、Deployment、NetworkPolicy などの関連するリソースタイプのすべてのオブジェクトが引き続き一覧表示されます。エージェントは、レプリカの 1 つの Deployment として実行されるため、オブジェクトの数が多すぎると、メモリ不足イベントが発生するリスクが高くなります。

影響を受けるバージョン

この問題は、Google Distributed Cloud のどのバージョンでも発生する可能性があります。

ここ最新のいくつかの Google Distributed Cloud のバージョンでは、デフォルトの CPU とメモリの上限が引き上げられているため、これらのリソースの問題はあまり発生しません。

修正と回避策

メモリ不足の問題が原因かどうかを確認するには、次の手順を確認します。

• kubectl describe pod または kubectl get pod -o yaml を使用して、エラー ステータス メッセージを確認します。
• 再起動する前に stackdriver-metadata-agent のメモリ消費量と使用率の指標を確認して、上限に達しているかどうかを確認します。

メモリ不足による問題が発生していることを確認したら、Stackdriver カスタム リソースの resourceAttrOverride フィールドのメモリ上限を増やします。

metrics-server クラッシュ ループが発生する

症状

HorizontalPodAutoscaler と kubectl top がクラスタでは機能しない。

原因と影響を受けるバージョン

この問題はあまり一般的ではありませんが、大規模なクラスタまたは Pod 密度が高いクラスタのメモリ不足エラーが原因で発生します。

この問題は、Google Distributed Cloud のどのバージョンでも発生する可能性があります。

修正と回避策

指標サーバーのリソース上限を増やす。Google Distributed Cloud バージョン 1.13 以降では、metrics-server の名前空間とその構成が kube-system から gke-managed-metrics-server に移動しました。

次のステップ

さらにサポートを必要とされる場合は、Google サポートにお問い合わせください。