このドキュメントでは、Google Distributed Cloud のオブザーバビリティに関する問題のトラブルシューティングに活用いただけます。こうした問題が発生した場合は、推奨される修正方法と回避策をご覧ください。
さらにサポートを必要とされる場合は、Google サポートにお問い合わせください。
Cloud Audit Logs が収集されない
クラスタ構成のclusterOperations セクションで disableCloudAuditLogging フラグが設定されていない限り、Cloud Audit Logs はデフォルトで有効になります。Cloud Audit Logs が有効になっている場合、ログが収集されない最も一般的な理由は権限です。この場合、権限拒否のエラー メッセージが Cloud Audit Logs のプロキシ コンテナに表示されます。
Cloud Audit Logs プロキシ コンテナは、すべての Google Distributed Cloud クラスタで 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 でこれらのサマリー API 指標が利用できない場合、同じノードの
- クラスタ内で、KSM と同じノードの KSM Pod と
gke-metrics-agentPod のステータスとログを確認します。
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 の CPU とメモリを調整するには、
kube-state-metricsの Stackdriver カスタム リソースの resourceOverride を使用します。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のメモリ消費量と使用率の指標を確認して、上限に達しているかどうかを確認します。
resourceAttrOverride フィールドのメモリ上限を増やします。
metrics-server クラッシュ ループが発生する
症状
HorizontalPodAutoscaler と kubectl top がクラスタでは機能しない。
原因と影響を受けるバージョン
この問題はあまり一般的ではありませんが、大規模なクラスタまたは Pod 密度が高いクラスタのメモリ不足エラーが原因で発生します。
この問題は、Google Distributed Cloud のどのバージョンでも発生する可能性があります。
修正と回避策
指標サーバーのリソース上限を増やす。Google Distributed Cloud バージョン 1.13 以降では、metrics-server の名前空間とその構成が kube-system から gke-managed-metrics-server に移動しました。
metrics-server-operator をスケールダウンし、metrics-server Pod を手動で変更します。次のステップ
さらにサポートを必要とされる場合は、Google サポートにお問い合わせください。