• Kubernetes 节点异常检测


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


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

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

    内核问题∶内核死锁,文件系统损坏;

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

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

     

    node-problem-detector


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

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

    • Runtime无响应
    • Linux Kernel无响应
    • 网络异常
    • 文件描述符异常
    • 硬件问题如CPU,内存或者磁盘故障。

    我们需要通过某种机制来检查硬件的问题,基础服务的问题,比如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的异常处理行为


    • 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来清理错误事件。
  • 相关阅读:
    解读非托管流动性协议Hover: 差异化、层次化的全新借贷体系
    【数字电路基础】格雷码、二进制码与格雷码的转换、独热码
    大数据-玩转数据-Flink状态后端(下)
    Chrome浏览器是如何工作的?(一)
    spark写带sasl认证的kafka
    虹科技术 | 快速准确测量0.05m-500m--虹科dimetix激光测距传感器的优势
    深入理解java垃圾回收机制
    C++界面开发框架Qt入门指南 - Qt Widget样式感知小部件(五)
    python字符串通过切片方式去掉最后一个字符
    深入理解@Transactional注解
  • 原文地址:https://blog.csdn.net/qq_34556414/article/details/126553957