ノードの問題の検出機能

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

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

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

検出できる問題

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

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

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

ノードの問題の検出機能によって検出される NodeConditions には次のようなものがあります。

  • KernelDeadlock
  • ReadonlyFilesystem
  • FrequentKubeletRestart
  • FrequentDockerRestart
  • FrequentContainerdRestart
  • FrequentUnregisterNetDevice
  • KubeletUnhealthy
  • ContainerRuntimeUnhealthy
  • CorruptDockerOverlay2

ノードの問題の検出機能によって報告される 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.

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

ノードで次の kubectl describe コマンドを実行して、NodeConditions と Events を検索します。

kubectl --kubeconfig=KUBECONFIG_PATH describe node NODE_NAME

このコマンドで、次のエントリを環境に固有の情報に置き換えます。

  • KUBECONFIG_PATH: ターゲット クラスタの kubeconfig ファイルのパス。通常、kubeconfig ファイルのパスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。ただし、WORKSPACE_DIR フラグを使ってワークスペースを指定した場合、パスは WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig になります。

  • NODE_NAME: 状態の情報を取得するノードの名前。

ノードの問題の検出機能の有効化と無効化の方法

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

  1. クラスタの ConfigMap ファイル（node-problem-detector-config）を編集します。

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

    このコマンドにより、node-problem-detector-config ファイルを編集できるテキスト エディタ（vim や nano など）が自動的に起動します。このコマンドで、次のエントリをクラスタ環境に固有の情報に置き換えます。

    • KUBECONFIG_PATH: 管理クラスタの kubeconfig ファイルのパス。通常、kubeconfig ファイルのパスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。ただし、WORKSPACE_DIR フラグを使ってワークスペースを指定した場合、パスは WORKSPACE_DIR/CLUSTER_NAME/CLUSTER_NAME-kubeconfig になります。
    • CLUSTER_NAMESPACE: ノードの問題の検出機能を有効にするクラスタの Namespace。

  2. 初期状態では、node-problem-detector-config ConfigMap に data フィールドはありません。次の Key-Value ペアを使用して、data フィールドを構成マップに追加します。

    data:
  enabled: "true"

クラスタの Namespace で Node Problem Detector を無効にする場合にも、上記のステップ 1 と 2 を行います。その際、ステップ 2 で enabled キーの値を 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 をカスタマイズする。
  • ユーザー定義のモニタリング スクリプトを実行する。

次のステップ