問題背景：
生產環境中部署的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/