ノードの問題の検出機能は、ノードの状態をモニタリングし、ハードウェア、カーネル、コンテナ ランタイムなどの一般的なノードの問題を検出するオープンソース ライブラリです。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 ストレージ ドライバ ディレクトリ内にファイル システムの問題または不整合があります。 | いいえ |
OrphanContainers 2 |
コンテナに固有の Pod が削除されたが、対応するコンテナはノードにまだ存在する。 | いいえ |
FailedCgroupRemoval 2 |
一部の 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 時点では、自動修復をサポートする NodeCondition
は FailedCgroupRemoval
のみです。
検出された問題を確認する方法
次の kubectl describe
コマンドを実行して、NodeConditions
と Events
を検索します。
kubectl describe node NODE_NAME \
--kubeconfig=KUBECONFIG
次のように置き換えます。
NODE_NAME
: 確認するノードの名前。KUBECONFIG
: クラスタの kubeconfig ファイルのパス。
ノードの問題の検出機能を有効または無効にする方法
デフォルトでは、ノードの問題の検出機能は有効になっていますが、node-problem-detector-config
ConfigMap リソースで無効にできます。明示的に無効にしない限り、ノードの問題の検出機能は、ノードの問題を示す特定の条件についてノードを継続的にモニタリングします。
ノードの問題の検出機能を特定のクラスタに対して無効にする手順は次のとおりです。
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
リソースを編集できるテキスト エディタが自動的に起動します。node-problem-detector-config
リソース定義でdata.enabled
をfalse
に設定します。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
フィールドがないため、追加する必要が生じる場合があります。リソースを更新するには、変更を保存してエディタを閉じます。
ノードの問題の検出機能を再度有効にする際も上記の手順で操作しますが、node-problem-detector-config
のリソース定義で data.enabled
を true
に設定します。
自動修復を有効または無効にする方法
バージョン 1.32 以降では、ノードの問題の検出機能が特定の NodeConditions
をチェックし、ノードで対応する問題を自動的に修復します。デフォルトでは、サポートされている NodeConditions
に対して自動修復が有効になっていますが、node-problem-detector-config
ConfigMap リソースで無効にできます。
特定のクラスタで自動修復の動作を無効にするには、次の操作を行います。
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
リソースを編集できるテキスト エディタが自動的に起動します。node-problem-detector-config
リソース定義でdata.check-only
をtrue
に設定します。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"
に設定すると、サポートされているすべての条件で自動修復が無効になります。リソースを更新するには、変更を保存してエディタを閉じます。
自動修復をサポートするすべての 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 カスタマーケアにお問い合わせください。サポート リソースの詳細(以下の内容など)については、サポートを受けるもご覧ください。