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/
标签：node,状态,插件,kernel,kubelet,watchdog,docker,pod 来源： https://www.cnblogs.com/zhoujishan/p/15030561.html