ノードの問題の検出機能は、ノードの状態をモニタリングし、ハードウェア、カーネル、コンテナ ランタイムなどの一般的なノードの問題を検出するオープンソース ライブラリです。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
: 状態の情報を取得するノードの名前。
ノードの問題の検出機能の有効化と無効化の方法
特定のクラスタでノードの問題の検出機能を有効にする手順は次のとおりです。
クラスタの
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。
- KUBECONFIG_PATH: 管理クラスタの kubeconfig ファイルのパス。通常、kubeconfig ファイルのパスは
初期状態では、
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
をカスタマイズする。 - ユーザー定義のモニタリング スクリプトを実行する。
次のステップ
- さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。