GKE on VMware のオブザーバビリティに関する問題のトラブルシューティング

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

さらにサポートが必要な場合は、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 Virtual for VMware のどのバージョンでも発生する可能性があります。

ここ最新のいくつかの Google Distributed Cloud Virtual のバージョンでは、デフォルトの CPU とメモリの上限が引き上げられているため、これらのリソースに関する問題の発生頻度が低減されています。

修正と回避策

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

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

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

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

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

    1. Google Distributed Cloud Virtual for VMware バージョン 1.9 以前、1.10.6 以前、1.11.2 以前、1.12.1 以前の場合:

      1. 長期的な解決策はありません。KSM 関連のリソースを編集すると、monitoring-operator によって変更が自動的に元に戻されます。

      2. monitoring-operator を 0 レプリカにスケールダウンしてから、KSM Deployment を編集してリソースの上限を調整できます。ただし、クラスタは monitoring-operator を使用する新しいパッチリリースによって提供される脆弱性パッチを受信しません。

        クラスタを修正後の新しいバージョンにアップグレードした後に、monitoring-operator を忘れずにスケールアップしてください。

    2. Google Distributed Cloud Virtual for VMware バージョン 1.10.7 以降、1.11.3 以降、1.12.2 以降、1.13 以降の場合は、次の定義を使用して、kube-system 名前空間（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

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

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

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

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

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

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

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

ここ最新のいくつかの Google Distributed Cloud Virtual for VMware のバージョンでは、デフォルトの 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 VMware のどのバージョンでも発生する可能性があります。

修正と回避策

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

次のステップ

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