前言
在开始给大家讲解如何通过eventer与npd来实现节点异常告警之前，要稍微给大家解释一下为什么用三篇的篇幅来介绍eventer。在kubernetes中，会将交付场景中的大部分实体都抽象为一个逻辑的概念，例如：接入层抽象为Service，存储层抽象为PV/PVC，不同种类的应用抽象为Deployment、StatefulSet等等。这种抽象的方式不仅仅将交付变成了软件定义式的配置，更多的是规约了一种标准化，这种标准化不仅仅是交付内容的标准化，也包括了交付方式的标准化，甚至交付生命周期的标准化。
交付内容的标准化与交付方式的标准化是非常好理解的，那么交付生命周期的标准化怎么理解呢。我们可以通过kubectl describe deploy [deploy name]的方式查看一个Deployment的状态描述。
在这个例子中，我们查看了coredns这样的一个Deployment的内容，我们会发现除了原本定义的字段之外，kubernetes还会在你定义的数据结构上添加Conditions和Events两个字段，而这两个字段表述的内容实际上定义了应用所处的状态机的状态与状态转换的原因与内容。Conditions中预定义了一些条件，当满足条件时Status字段会变成True，而发生重要的状态转换时，Controller会自动生成相关的Event，Event分为Normal与Warning两个维度，Warning事件通常表示一些需要特别关注bad smell，而这种机制成为了在Kubernetes中实时告警的基础。
节点异常告警
在Kubernetes中，节点是常常被大家忽略的实体，因为大部分的开发人员感知到的内容主要是应用的抽象，而节点作为承载应用的实体直接被运维同学接管，在一个标准的worker节点上，通常会运行一些系统组件的Static Pod与DaemonSet，除此之外，还有最重要的Docker Engine。那么当Docker Engine或者更底层的Linux Kernel出现问题时，有什么办法能够快速告警并处理呢？
在回答这个问题前，我们再看回头看下刚才Deployment的状态描述，开发人员可以通过Deployment的Conditions与Event快速得知应用的状态并进行处理，节点是否也可以通过类似的方式处理呢。带着问题，我们kubectl describe查看一个节点的状态。
不出所料，在Kubernetes中，节点的生命周期管理也是通过同样的机制进行处理的。那么节点上遇到的Docker Engine、Linux Kernel的问题怎么和上述的方式进行整合进行判断与处理呢？
Node Problem Detector(NPD)是Kubernetes中负责节点健康诊断的一个DaemonSet，和传统的诊断告警系统相比，npd的方式更kubernetes，他将诊断的问题进行分类，并转换为不同的Conditions与Event，也就是说，节点上面一旦Docker Engine Hang或者Linux Kernel异常，就会产生一条关于异常节点的事件，运维人员可以通过kubectl describe node [node name]的方式快速查看产生问题的原因和信息。那么如何建立完整的监控链路保证问题的及时发现呢？还记得上篇文章中的eventer中，eventer可以将相关的事件实时告警到钉钉或者离线到SLS。
那么至此，我们只需要将npd与eventer部署到集群中，配置相应的离线链路，即可实现针对节点异常的告警了。
操作步骤
- 登陆
容器服务控制台，使用模板部署npd
npd的部署可以参考这篇文章中介绍的步骤。 - 登陆容器服务控制台，部署
eventer
希望通过钉钉进行实时告警的开发者可以参考这篇文章。希望通过SLS进行关键字告警的开发者可以参考这篇文章。 - 模拟Docker Engine异常的事件，在一个节点上执行如下脚本
echo "Error trying v2 registry: failed to register layer: rename /var/lib/docker/image/test /var/lib/docker/image/ddd: directory not empty.*" |systemd-cat -t docker
AI 代码解读
如果是钉钉实时告警，那么可以收到类似如下的报警信息。
从图片中的信息可以得知，出现问题的节点以及相关的信息，从而可以快速根据关键字进行诊断。
