ノードの問題の検出機能

ノードの問題の検出機能は、ノードの状態をモニタリングし、ハードウェア、カーネル、コンテナ ランタイムなどの一般的なノードの問題を検出するオープンソース ライブラリです。Google Distributed Cloud では、各ノードの systemd サービスとして実行されます。

Google Distributed Cloud リリース 1.10.0 以降では、ノードの問題の検出機能はデフォルトで有効になっています。

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。サポート リソースの詳細(以下の内容など)については、サポートを受けるもご覧ください。

  • サポートケースを登録するための要件
  • 環境構成、ログ、指標など、トラブルシューティングに役立つツール
  • サポート対象のコンポーネント

検出できる問題

ノードの問題の検出機能は次のような問題を検出できます。

  • コンテナ ランタイムの問題(ランタイム デーモンの無応答など)
  • ハードウェアの問題(CPU、メモリ、ディスク障害など)
  • カーネルの問題(カーネルのデッドロック状態やファイル システムの破損など)

これはノード上で実行され、NodeCondition または Event として Kubernetes API サーバーに問題を報告します。NodeCondition はノードでの Pod の実行が不能になる問題です。一方、Event は一時的な問題で、Pod への影響は限定的であるものの、要報告と見なされた問題です。

次の表に、ノードの問題の検出機能によって検出された NodeConditions と、それらが自動的に修復できるかどうかを示します。

条件 理由 自動修復に対応1
KernelDeadlock カーネル プロセスが、必要なリソースを解放する他のカーネル プロセスを待機したままになっています。 いいえ
ReadonlyFilesystem ディスクの容量不足などの問題により、クラスタがファイル システムに書き込むことができません。 いいえ
FrequentKubeletRestart kubelet が頻繁に再起動し、ノードで Pod を効果的に実行できません。 いいえ
FrequentDockerRestart Docker デーモンが 20 分間に 5 回超再起動している。 いいえ
FrequentContainerdRestart コンテナ ランタイムが 20 分間に 5 回超再起動している。 いいえ
FrequentUnregisterNetDevice ノードでネットワーク デバイスの登録解除が頻繁に発生しています。 いいえ
KubeletUnhealthy ノードが正しく機能していないか、コントロール プレーンに応答していません。 いいえ
ContainerRuntimeUnhealthy コンテナ ランタイムが正しく機能していないため、Pod がノードで実行またはスケジュールされません。 いいえ
CorruptDockerOverlay2 Docker overlay2 ストレージ ドライバ ディレクトリ内にファイル システムの問題または不整合があります。 いいえ
OrphanContainers2 コンテナに固有の Pod が削除されたが、対応するコンテナはノードにまだ存在する。 いいえ
FailedCgroupRemoval2 一部の cgroup がフリーズ状態です。 はい

1 バージョン 1.32 以降では、検出された問題を自動的に修復する機能が特定の条件でサポートされています。

2 バージョン 1.32 以降でサポートされています。

ノードの問題の検出機能によって報告される Events の種類を以下に例示します。

  • Warning TaskHung node/vm-worker-1-user-a12fabb4a99cb92-ddfce8832fd90f6f.lab.anthos kernel: task docker:7 blocked for more than 300 seconds.
  • Warning KernelOops node/vm-worker-1-user-a12fabb4a99cb92-ddfce8832fd90f6f.lab.anthos kernel: BUG: unable to handle kernel NULL pointer dereference at 00x0.

解決できる問題

バージョン 1.32 以降では、ノードの問題の検出機能が特定の NodeConditions を検出すると、そのノード上の対応する問題を自動的に修復できます。バージョン 1.32 時点では、自動修復をサポートする NodeConditionFailedCgroupRemoval のみです。

検出された問題を確認する方法

次の kubectl describe コマンドを実行して、NodeConditionsEvents を検索します。

kubectl describe node NODE_NAME \
    --kubeconfig=KUBECONFIG

次のように置き換えます。

  • NODE_NAME: 確認するノードの名前。

  • KUBECONFIG: クラスタの kubeconfig ファイルのパス。

ノードの問題の検出機能を有効または無効にする方法

デフォルトでは、ノードの問題の検出機能は有効になっていますが、node-problem-detector-config ConfigMap リソースで無効にできます。明示的に無効にしない限り、ノードの問題の検出機能は、ノードの問題を示す特定の条件についてノードを継続的にモニタリングします。

ノードの問題の検出機能を特定のクラスタに対して無効にする手順は次のとおりです。

  1. node-problem-detector-config ConfigMap リソースを編集します。

    kubectl edit configmap node-problem-detector-config \
        --kubeconfig=KUBECONFIG \
        --namespace=CLUSTER_NAMESPACE
    

    次のように置き換えます。

    • KUBECONFIG: クラスタの kubeconfig ファイルのパス。

    • CLUSTER_NAMESPACE: ノードの問題の検出機能を有効にするクラスタの Namespace。

    このコマンドにより、node-problem-detector-config リソースを編集できるテキスト エディタが自動的に起動します。

  2. node-problem-detector-config リソース定義で data.enabledfalse に設定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      creationTimestamp: "2025-04-19T21:36:44Z"
      name: node-problem-detector-config
    ...
    data:
      enabled: "false"
    

    初期状態では、node-problem-detector-config ConfigMap に data フィールドがないため、追加する必要が生じる場合があります。

  3. リソースを更新するには、変更を保存してエディタを閉じます。

ノードの問題の検出機能を再度有効にする際も上記の手順で操作しますが、node-problem-detector-config のリソース定義で data.enabledtrue に設定します。

自動修復を有効または無効にする方法

バージョン 1.32 以降では、ノードの問題の検出機能が特定の NodeConditions をチェックし、ノードで対応する問題を自動的に修復します。デフォルトでは、サポートされている NodeConditions に対して自動修復が有効になっていますが、node-problem-detector-config ConfigMap リソースで無効にできます。

特定のクラスタで自動修復の動作を無効にするには、次の操作を行います。

  1. node-problem-detector-config ConfigMap リソースを編集します。

    kubectl edit configmap node-problem-detector-config \
        --kubeconfig=KUBECONFIG \
        --namespace=CLUSTER_NAMESPACE
    

    次のように置き換えます。

    • KUBECONFIG: クラスタの kubeconfig ファイルのパス。

    • CLUSTER_NAMESPACE: ノードの問題の検出機能を有効にするクラスタの Namespace。

    このコマンドにより、node-problem-detector-config リソースを編集できるテキスト エディタが自動的に起動します。

  2. node-problem-detector-config リソース定義で data.check-onlytrue に設定します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      creationTimestamp: "2025-04-19T21:36:44Z"
      name: node-problem-detector-config
    ...
    data:
      enabled: "true"
      check-only: "true"
    

    初期状態では、node-problem-detector-config ConfigMap に data フィールドがないため、追加する必要が生じる場合があります。check-only"true" に設定すると、サポートされているすべての条件で自動修復が無効になります。

  3. リソースを更新するには、変更を保存してエディタを閉じます。

自動修復をサポートするすべての NodeConditions で自動修復を再度有効にするには、node-problem-detector-config ConfigMap で data.check-only"false" に設定します。

ノードの問題の検出機能を停止して再起動する方法

ノードの問題の検出機能は、各ノードで systemd サービスとして実行されます。特定のノードのノードの問題の検出機能を管理するには、SSH を使用してノードにアクセスし、次の systemctl コマンドを実行します。

  • ノードの問題の検出機能を無効にするには、次のコマンドを実行します。

    systemctl stop node-problem-detector
    
  • ノードの問題の検出機能を再起動するには、次のコマンドを実行します。

    systemctl restart node-problem-detector
    
  • ノードの問題の検出機能が特定のノードで実行されているかどうかを確認するには、次のコマンドを実行します。

    systemctl is-active node-problem-detector
    

サポートされていない機能

Google Distributed Cloud は、ノードの問題の検出機能の次のカスタマイズをサポートしていません。

  • ノードの問題の検出機能のレポートを Stackdriver や Prometheus などの他のモニタリング システムにエクスポートする。
  • 検索する NodeConditions または Events をカスタマイズする。
  • ユーザー定義のモニタリング スクリプトを実行する。

次のステップ

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。サポート リソースの詳細(以下の内容など)については、サポートを受けるもご覧ください。

  • サポートケースを登録するための要件
  • 環境構成、ログ、指標など、トラブルシューティングに役立つツール
  • サポート対象のコンポーネント