Kubernetes 节点异常检测

Kubernetes 集群可能存在的问题 node-problem-detector

基础架构守护程序问题∶NTP服务关闭；

硬件问题CPU，内存或磁盘损坏

内核问题∶内核死锁，文件系统损坏；

容器运行时问题运行时守护程序无响应····

当Kubernetes中节点发生上述问题，在整个集群中，K8s服务组件并不会感知以上问题，就会导致Pod仍会调度至问题节点。

为了解决这个问题，社区引入了守护进程 node-problem-detector，从各个守护进程收集节点问题，并使它们对上游层可见。

Kubernetes 节点诊断的工具，可以将节点的异常，例如∶

我们需要通过某种机制来检查硬件的问题，基础服务的问题，比如NTP，社区提供了一个机制，它提供了node-problem-detector组件，它是一个demonset，在每个节点上面运行守护进程，这个守护进程就会对节点去做健康的诊断，它发现问题之后，就要以某种机制上报给kubernetes。

故障分类

可以看到通过监控系统日志来汇报问题，然后通过某种方式上报给kubernetes集群。

第二类就是，可以自定义去监控ntp服务，你可以去监控这个服务有没有开启，有没有正常工作。

最后就是kubelet发生问题了，kubelet自己是汇报不了状态的，但是有node-problem-detector组件运行在这个节点上面，它可以绕过kubelet向apiserver汇报，这个节点的kubelet发生异常，就相当于在kubelet外面添加了一层额外的守护。

总而言之就是在每个节点上面运行一个守护进程，这个进程会去不断的扫描系统日志，扫描一些服务，然后运行我们自定义的监控规则，然后去判断这个节点是否有异常了，如果有异常就可以直接通过apiserver的调用去更改节点的状态，或者发一些event给kubernetes，这是一个很简单的组件。

问题汇报手段

node-problem-detector通过设置NodeCondition或者创建Event对象来汇报问题。

NodeCondition∶针对永久性故障，会通过设置NodeCondition来改变节点状态。（比如磁盘坏了，它是恢复不了的，它就直接更新这个节点是有问题的）
Event∶临时故障通过Event来提醒相关对象，比如通知当前节点运行的所有Pod。（临时故障都是通过event来告知整个上游这个节点出现了错误）

上手实践

如果这个节点发生了任何的异常，它就会去做一些事情。

这个是往日志里面打印一条kernel bug的日志信息。 node-problem-detector会去监听kmsg的，它会将这条信息认为是系统的异常，并且上报上去。

可以看到以event的发生上报给了kubernetes，可以看到就直接将刚才打印的日志发送出来了。

所以它会去监听kmsg，如果kmsg里面有任何的kernel bug，那么就会认为出现了临时的错误，这个错误以event的方式发出来，发现问题并且上报就结束了。

这个组件在生产化集群里面它是一个非常必要的组件，可以去扩展你任何想要做的监控，当出现问题的时候，你去更新节点的信息，比如condition或者发送event来通知说这个节点出现了问题。

使用插件Pod启用NPD

很多时候是需要将node-problem-detector在集群搭建的时候就自动创建出来，出来静态的pod加载核心控制平面组件之外，还有/etc/kubernetes/addons/这个目录，可以将这个插件对应的yml文件放到这个目录里面，在集群引导的时候就可以自动的加载进来的。

如果你使用的是自定义集群引导解决方案，不需要覆盖默认配置，可以利用插件Pod进一步自动化部署。

创建 node-strick-detector.yaml，并在控制平面节点上保存配置到插件Pod 的目录/etc/kubernetes/addons/node-problem-detector。

NPD只负责获取异常事件，并修改 node condition（如果是永久错误就修改node condition，如果是临时错误就发event），不会对节点状态和调度产生影响。（并不产生后续的修正行为，只负责上报就结束了，可能依然把pod给调度过去，它只是做监听，问题检查和上报一个单纯的组件就行了）

lastHeartbeatTime:"2021-11-06T15:44:46Z

"lastTransitionTime:"2021-11-06T15:29:43Z"

message:'kernel: INFO: task docker:20744 blocked for more than 120 seconds.'

reason: DockerHung

status: "True"type: KernelDeadlock

通常来说需要自定义控制器来完成和NPD的对接（可以自己写一个控制器去监听node condition，如果发现了dockerhung的错误，那么就可以将node打上taint，让上面的pod驱逐出来，这些额外的控制逻辑是需要你自己去写的），监听NPD汇报的condition，taint node，阻止Pod调度到故障节点。
问题修复后，重启NPD Pod来清理错误事件。