ノードの問題の検出機能

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

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

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

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

検出できる問題

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

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

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

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

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

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

² バージョン 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 をカスタマイズする。
ユーザー定義のモニタリングスクリプトを実行する。

次のステップ

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

ノードの問題の検出機能 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。