K8S集群中Pod资源处于Terminating或Unknown状态排查思路
文章目录
1.Pod资源处于Terminating状态和Unknown状态的原因
Terminating状态表示Pod正在删除，Pod处于Terminating状态的原因有以下几点：
- 人为手动删除Pod，这时Pod就会处于该状态，若是人为手动触发，那么该状态就属于正常现象，如果长时间还没有删除成功，则执行强制删除的命令。
- 当Pod资源中容器里的服务异常挂掉了，健康检查失败，Pod就会处于该状态。
- 当K8S集群中某个Node节点挂掉或者失联后，在k8s1.5版本之后，不会因为Node节点异常而自动删除运行在该Node节点上的Pod，而是将运行在该Node节点中的Pod资源被标记为Terminating状态或者Unknown状态，此时就需要去排查Node节点了。
Unknown是未知状态，Pod处于Unknown状态的原因很有可能就是Master和Node节点之间通信有问题，从而导致Pod处于Unknown未知状态，处于Unknown状态的Pod不能通过Kubelet向Apiserver汇报当前的状态。
当Node节点挂掉后，在集群列表中也会显示Unknown状态。
2.Pod资源由于Node节点原因处于Terminating状态的排查思路
人为删除Pod资源、Pod资源中容器服务挂掉，这两个原因导致Pod处于Terminating状态，都算是一个比较正常的现象，人为删除肯定会被标记为Terminating状态，当服务挂掉后，配合健康检查机制，也会将Pod资源删除重建，所以说这两种原因算是较为正常的现象。
当Node节点出现问题后，Pod资源也会被标记为Terminating状态，如果该Node节点不恢复，那么Pod将一直处于该状态。
接下来描述由于Node节点出现故障，导致Pod处于Terminating状态的排查思路：
1）首先查看应用服务的所有Pod是否全部处于Terminating状态，如果全部都是Terminating状态，集群中也有多个Node节点，那么就不一定是Node节点的问题，可能就是容器服务的问题，如果发现只是某个Node节点上的Pod资源处于了Terminating状态，那么90%的概率是这台Node节点出问题了。
2）通过查询Node节点的状态，此时应该会处于NoReady的状态，此时就需要去查看该Node节点上kubelet、calico、kube-proxy各个组件是否正常运行，如果是kubeadm安装的集群，可以先将该Node节点上的calico、kube-proxy组件重启，如果还是无法解决，则去该Node节点中查询kubelet的日志，定位问题的原因。
3）如果Node节点不管怎么尝试，都无法恢复，那么就将该Node节点从集群中先删除，然后重新配置后再次加入，删除前，可以先记录该Node节点上运行了那些服务的Pod资源，然后将该Node节点上的Pod资源进行驱逐（如果不驱逐，Pod资源会一直在这个Node节点上处于Terminating状态，也可以不驱逐，当Node节点恢复后，可以观察Pod会自动修复），最后手动在集群中将这个Node节点删除下线。
kubectl delete node <node_name>
4）删除该Node节点中部署的K8S组件，重新部署该Node节点，然后将该Node节点重新加入到K8S集群，如果Node节点恢复成功，处于Ready状态，那么Kubelet会与Apiserver通信确认处于Terminating状态的Pod，然后决定是删除重建这些Pod还是继续运行这些Pod，也可以人为手动将这些Pod删除，然后重新调度到该节点，如果在Node节点下线时进行了驱逐，就不需要观察Pod的状态了，Node恢复后Pod会往这个Node上调度。
- 强制删除处于Terminating状态的Pod资源：
kubectl delete pod <pod_name> --force --grace-period=0
5）Node节点此时已经恢复，之前驱逐后，Pod资源限制没有往该Node节点上调度的，我们可以手动重新分配一下，缓解其他节点的压力。
- 重新加载一下Pod资源的编排文件即可。
6）如果之前没有驱逐Pod，Pod长时间还是处于Terminating状态，也可以手动重启一下Kubelet，或许也会恢复。
如果Node节点出现了故障，下线该Node节点时，最好先将该节点上的Pod驱逐，当Node修复好了重新加入集群后，直接重新加载资源编排文件就可以完成Pod的分配，可以避免很多麻烦的发生。
3.Pod资源由于Node节点原因处于Unknown状态的排查思路
排查思路几乎和Terminating状态一样，两种状态基本上都是一个意思，就是因为Node节点无响应才触发的。
Unknown也可能是由于Node节点和Apiserver不通信导致，可以按照下面的步骤进行排查。
1）首先排查Kubelet的状态，从kubelet的日志中发现问题
2）然后排查Node节点状态是否异常，异常情况下无法解决，可以删除该Node然后重新加入。
3）最后排查Apiserver是否出现问题。