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

本文主要是介绍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/

这篇关于k8s node节点网络插件工作正常、kubelet工作正常情况下，node状态为NotReady，导致pod调度失败的排查过程。的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！