k8s node节点网络插件工作正常、kubelet工作正常情况下,node状态为NotReady,导致pod调度失败的排查过程。

问题背景:

生产环境中部署的K8S环境,一个业务pod无法异常退出,状态为Termnation状态,导致业务系统部分功能不可用。

排查过程:

1、使用kubectl describe pod $pod_name -n $namespaces查看pod状态,发现pod调度失败,1个node不满足ready的状态,15个node不满足NodeSelector的要求;

2、使用kubectl describe node $node_name 查看node nodeSelector,发现node label和pod的nodeSelector字段相同,满足匹配要求;

3、使用kubectl get nodes 查看node状态,发现node-01状态为NotReady,由此可以判定是node-01处于未准备就绪状态,导致无法调;

4、进入node-01 查看kubelt和cni网络插件都是正常状态,排除网络插件和kubelet问题;

5、使用systemctl restart kubelt 重启kubelet,kubelet关闭成功,启动失败,原因为docker无法连接;

6、使用systemcctl status docekr状态,docker运行正常;

7、使用systemctl restart docker ,docker停止成功,但是启动失败,使用journalctl -xu docker 、systemctl status docker -l 查看系统托管docker日志,发现docker启动失败是因为docker.pid、containerd仍然运行中,无法重启;

8、查看系统内核日志,发现有日志打印:kernel:NMI watchdog: BUG: soft lockup - CPU#6 stuck for 28s! CentOS7;

9、根据内核日志提示,确定node-01发生了软死锁,问题是由于内核某段代码长期占用内核进程,导致内核处于锁死的状态,CPU挂起系统不可用。

10、问题解决办法(/proc/sys/kernel/watchdog_thresh的默认值为10,修改为30):

echo 30 > /proc/sys/kernel/watchdog_thresh 

sysctl -w kernel.watchdog_thresh=30

问题解决参考文档:

解释设什么是软死锁及软死锁的解决办法:

https://blog.csdn.net/jiangganwu/article/details/89711354

解释为什么要用修改proc/sys/kernel/watchdog_thresh的方法解决软死锁问题:

https://blog.csdn.net/ericstarmars/article/details/81750919

https://blog.csdn.net/yhb1047818384/article/details/70833825/

上一篇:Python监控(monitor)文件系统(Linux file system)事件(变化):watchdog、pyinotify


下一篇:Watchdog问题定位及分析方法