根源
在kubernetes集群上，通常我们只是管制集群本身以及容器的稳定运行。但是这些稳定性都是强依赖节点node的稳定的。可是node的管理，在kubernetes是比较弱的，因为可能对于kubernetes的初始设计来说，这些应该是IaaS的事。但是随着kubernetes的发展，它越来变成了一个操作系统，它管理的内容将越来越多，所以对于node的管理也将纳入kuberntes里管理。所以延伸出了node problem detector(参考1)这个项目。
Node的主要影响kuberntes稳定性的因素
硬件错误
- CPU坏了
- Memory坏了
- 磁盘坏了
kernel问题
- kernel deadlock (内核死锁)
- corrupted file systems (文件系统崩溃)
- unresponsive runtime daemons (系统运行后台进程无响应)
docker问题
- unresponsive runtime daemons (docker后台进程无响应)
- docker image error (docker文件系统错误)
Node问题上报机制
Kubernetes支持两种上报机制：
- NodeCondition(节点状况): 这是指永久性的错误，它将造成pod无法在这个节点运行。这个节点状况只有在节点重启后才会被重置
- Event(事件): 影响节点的临时性问题，但是它是对于系统诊断是有意义的
Node Problem Detector(NPD)
NPD就是利用kubernetes的上报机制，通过检测系统的日志（例如centos中journal），把错误的信息上报到kuberntes的node上。
NPD的架构
(图来源于mastering kubernetes)
NPD支持多种monitor来检测不同的错误类型。然后它把对应的信息上报给api server。
后面NPD也在计划提供一个remedy controller(治疗控制器)，通过捕获这些信息作些补救的处理。例如在公有云可以将硬件错误的机器自动换掉等
部署NPD实践
前提，你需要有一个k8s集群，必须有1个以上的worker节点。有需要你可以在阿里云的容器服务里，几分钟内创建一个k8s集群。
我将对应的内容放到了我的github上，大家可以参考，地址在：https://github.com/vipdocker/npd-centos
因为官网的文档描述不是太清楚，以及对于centos journal的支持也是刚完成，所以文档还跟不上，也造成了我一些弯路
具体步骤参考上面github的README就可，这里就不啰嗦了。
如何验证NPD捕获信息
通常这些错误是比较难真实测试，只能通过发送消息到journal来模拟。
- 发送一个kernel deadlock类型的condition：在对应的node节点上执行以下操作
echo "task docker:7 blocked for more than 300 seconds." |systemd-cat -t kernel
AI 代码解读
然后通过k8s控制台，你可以看到对应的信息：
- 发送一个event
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 代码解读
然后通过以下命令来对应的event
kubectl describe node/xxxx
AI 代码解读
小结
通过NPD，我们可以看到一种node错误检测的增强手段， 后面它也将提供更多的plugin的集成机制来集成其它的监控系统，例如nagios等。
我们或许会看到这样的一个k8s，它已经包罗万象，不在需要“依赖”其它就可以完成的管理好一个集群，它将更像一个分布式的OS。
