GDCV for Bare Metal のオブザーバビリティに関する問題のトラブルシューティング

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

さらにサポートが必要な場合は、Google サポートにお問い合わせください。

Cloud Audit Logs が収集されない

クラスタ構成の clusterOperations セクションに disableCloudAuditLogging フラグが設定されていない場合、Cloud Audit Logs はデフォルトで有効になります。

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

Cloud Audit Logs プロキシ コンテナは、すべての Google Distributed Cloud Virtual for Bare Metal クラスタで DaemonSet として実行されます。

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

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 Virtual for Bare Metal のどのバージョンでも発生する可能性があります。

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

修正と回避策

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

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

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

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

    KSM の CPU とメモリを調整するには、Stackdriver カスタム リソースの resourceOverride を kube-state-metrics に使用します。

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

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

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

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

gke-metrics-agent で kube-state-metrics が存在するノードでのみメモリ不足の問題が発生する場合、原因は多数の kube-state-metrics 指標にあります。この問題を軽減するには、stackdriver-operator をスケールダウンし、KSM を変更して、前のセクションで説明したように、必要な少数の指標を公開します。クラスタが Google Distributed Cloud Virtual for Bare Metal 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 Virtual for Bare Metal のどのバージョンでも発生する可能性があります。

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

修正と回避策

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

  • kubectl describe pod または kubectl get pod -o yaml を使用して、エラー ステータス メッセージを確認します。
  • 再起動する前に stackdriver-metadata-agent のメモリ使用量と使用率の指標を確認して、上限に達しているかどうかを確認します。
メモリ不足による問題が発生していることを確認したら、Stackdriver カスタム リソースの resourceAttrOverride フィールドのメモリ上限を増やします。

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

症状

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

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

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

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

修正と回避策

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

Google Distributed Cloud Virtual for Bare Metal の場合、nanny 構成ファイルの編集はクラスタの更新またはアップグレード時に元に戻されます。構成の変更を再度適用する必要があります。この制限を回避するには、metrics-server-operator をスケールダウンして、metrics-server Pod を手動で変更します。

次のステップ

さらにサポートが必要な場合は、Google サポートにお問い合わせください。