kubernetes - K8S node_problem_detector の使用方法は?

Question

質問

node-problem-detectorは、K8S の場合、 Monitor Node Healthのドキュメントに記載されています。GCE にない場合、どのように使用しますか? ダッシュボードに情報をフィードしたり、API メトリックを提供したりしますか?

Answer 1

「このツールは、さまざまなノードの問題をクラスター管理スタックの上流層に可視化することを目的としています。これは、各ノードで実行され、ノードの問題を検出して apiserver に報告するデーモンです。」

Err Ok but... とはどういう意味ですか? APIサーバーに送信されたかどうかを確認するにはどうすればよいですか?
前と後はどのように見えますか？それを知ることは、それが何をしているのかを理解するのに役立ちます。

Node Problem Detector をインストールする前に、次のように表示されます。

Bash# kubectl describe node ip-10-40-22-166.ec2.internal | grep -i condition -A 20 | grep Ready -B 20
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Thu, 20 Jun 2019 12:30:05 -0400   Thu, 20 Jun 2019 12:30:05 -0400   WeaveIsUp                    Weave pod has set this
  OutOfDisk            False   Thu, 20 Jun 2019 18:27:39 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure       False   Thu, 20 Jun 2019 18:27:39 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Thu, 20 Jun 2019 18:27:39 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Thu, 20 Jun 2019 18:27:39 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Thu, 20 Jun 2019 18:27:39 -0400   Thu, 20 Jun 2019 12:30:14 -0400   KubeletReady                 kubelet is posting ready status

Node Problem Detector をインストールすると、次のように表示されます。

Bash# helm upgrade --install npd stable/node-problem-detector -f node-problem-detector.values.yaml 
Bash# kubectl rollout status daemonset npd-node-problem-detector #(wait for up) 
Bash# kubectl describe node ip-10-40-22-166.ec2.internal | grep -i condition -A 20 | grep Ready -B 20 
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  DockerDaemon         False   Thu, 20 Jun 2019 22:06:17 -0400   Thu, 20 Jun 2019 22:04:14 -0400   DockerDaemonHealthy          Docker daemon is healthy
  EBSHealth            False   Thu, 20 Jun 2019 22:06:17 -0400   Thu, 20 Jun 2019 22:04:14 -0400   NoVolumeErrors               Volumes are attaching successfully
  KernelDeadlock       False   Thu, 20 Jun 2019 22:06:17 -0400   Thu, 20 Jun 2019 22:04:14 -0400   KernelHasNoDeadlock          kernel has no deadlock
  ReadonlyFilesystem   False   Thu, 20 Jun 2019 22:06:17 -0400   Thu, 20 Jun 2019 22:04:14 -0400   FilesystemIsNotReadOnly      Filesystem is not read-only
  NetworkUnavailable   False   Thu, 20 Jun 2019 12:30:05 -0400   Thu, 20 Jun 2019 12:30:05 -0400   WeaveIsUp                    Weave pod has set this
  OutOfDisk            False   Thu, 20 Jun 2019 22:07:10 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure       False   Thu, 20 Jun 2019 22:07:10 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Thu, 20 Jun 2019 22:07:10 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Thu, 20 Jun 2019 22:07:10 -0400   Thu, 20 Jun 2019 12:29:44 -0400   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Thu, 20 Jun 2019 22:07:10 -0400   Thu, 20 Jun 2019 12:30:14 -0400   KubeletReady                 kubelet is posting ready status

注: すべてのノードでこれを確認する方法を考え出すのに助けを求めたところ、Kenna Ofoegbu がこの非常に便利で読みやすい gem を思い付きました。

zsh# nodes=$(kubectl get nodes | sed '1d' | awk '{print $1}') && for node in $nodes; do;  kubectl describe node | sed -n '/Conditions/,/Ready/p' ; done
Bash# (same command, gives errors)

さて、これで Node Problem Detector の機能はわかりましたが、ノードに条件を追加することには何のメリットがあるのでしょうか。

質問: Kubernetes Node Problem Detector の使用方法は?
ユースケース #1: 破損したノードの自動修復
ステップ 1.) Node Problem Detector をインストールして、新しい条件メタデータをノードに添付できるようにします。
ステップ 2.) Planetlabs/draino を活用して、条件の悪いノードを封鎖してドレインします。
ステップ 3.) https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscalerを活用して自動修復します。(ノードが封鎖されてドレインされると、スケジュール不可とマークされます。これにより、新しいノードのプロビジョニングがトリガーされ、不良ノードのリソース使用率が非常に低くなり、不良ノードのプロビジョニングが解除されます)

ソース: https://github.com/kubernetes/node-problem-detector#remedy-systems

ユース ケース #2: 異常なノード イベントを表面化して Kubernetes で検出できるようにし、監視スタックに注入して、イベントがいつ発生したかという監査可能な履歴レコードを保持します。
これらの異常なノード イベントは、ホスト ノードのどこかにログに記録されますが、通常、ホスト ノードは非常に多くのノイズの多い/役に立たないログ データを生成するため、これらのイベントは通常、既定では収集されません。
Node Problem Detector は、ホスト ノードでこれらのイベントを探す場所を認識しており、否定的な結果のシグナルを検出するとノイズをフィルター処理して除外し、それを Pod ログに投稿します。
Pod ログは ELK および Prometheus Operator スタックに取り込まれ、そこで検出、アラート、保存、およびグラフ化される可能性があります。

また、両方のユース ケースの実装を妨げるものは何もないことに注意してください。

---

更新、リクエストごとに node-problem-detector.helm-values.yaml ファイルのスニペットをコメントに追加:

  log_monitors:
#https://github.com/kubernetes/node-problem-detector/tree/master/config contains the full list, you can exec into the pod and ls /config/ to see these as well.
    - /config/abrt-adaptor.json #Adds ABRT Node Events (ABRT: automatic bug reporting tool), exceptions will show up under "kubectl describe node $NODENAME | grep Events -A 20"
    - /config/kernel-monitor.json #Adds 2 new Node Health Condition Checks "KernelDeadlock" and "ReadonlyFilesystem"
    - /config/docker-monitor.json  #Adds new Node Health Condition Check "DockerDaemon" (Checks if Docker is unhealthy as a result of corrupt image)
#    - /config/docker-monitor-filelog.json #Error: "/var/log/docker.log: no such file or directory", doesn't exist on pod, I think you'd have to mount node hostpath to get it to work, gain doesn't sound worth effort.
#    - /config/kernel-monitor-filelog.json #Should add to existing Node Health Check "KernelDeadlock", more thorough detection, but silently fails in NPD pod logs for me.   

  custom_plugin_monitors: #[]
# Someone said all *-counter plugins are custom plugins, if you put them under log_monitors, you'll get #Error: "Failed to unmarshal configuration file "/config/kernel-monitor-counter.json""
    - /config/kernel-monitor-counter.json #Adds new Node Health Condition Check "FrequentUnregisteredNetDevice"
    - /config/docker-monitor-counter.json #Adds new Node Health Condition Check "CorruptDockerOverlay2"
    - /config/systemd-monitor-counter.json #Adds 3 new Node Health Condition Checks "FrequentKubeletRestart", "FrequentDockerRestart", and "FrequentContainerdRestart"