K8S Pod 停止不掉一直处于Terminating状态问题解决

背景

用户反馈一个问题，在删除任务重建任务会提示资源清理不成功，赶紧登陆服务器一通操作 kubectl发现Pod一直处于Terminating状态： 管它三七二十一 先执行： kubectl delete pod spark-xxx --grace-period=0 --force --namespace 先强制干掉再细细分析；

排查实录：

• 先执行：kubectl get nodes -o wide 发现其中一个节点处于 NotReady状态，断定节点有点问题。 • 接着执行查看节点具体状态

kubectl get nodes hwy-hn1-inner-bdi-fp-prd-002  -o yaml
kubectl describe nodes hwy-hn1-inner-bdi-fp-prd-002

发现蛛丝马迹：

- lastHeartbeatTime: "2021-11-08T02:24:14Z"
    lastTransitionTime: "2021-11-06T00:27:22Z"
    message: PLEG is not healthy: pleg was last seen active 50h0m1.184263736s ago;
      threshold is 3m0s

• 一番查找 PLEG 是啥情况得出： PLEG 全称叫 Pod Lifecycle Event Generator，即 Pod 生命周期事件生成器。实际上它只是 Kubelet 中的一个模块，主要职责就是通过每个匹配的 Pod 级别事件来调整容器运行时的状态，并将调整的结果写入缓存，使 Pod 的缓存保持最新状态。 看来是轮训同步Pod状态这个过程出错了，继续探索 • 登陆有问题的工作节点ssh 进入查看系统日志 journalctl 执行 解释下：journalctl 用来查询 systemd-journald 服务收集到的日志。systemd-journald 服务是 systemd init 系统提供的收集系统日志的服务。

GenericPLEG: Unable to retrieve pods: rpc error: code = ResourceExhausted desc = grpc: trying to send message larger than max (16783506 vs. 16777216)
 E1102 19:06:57.103683   30435 kubelet.go:1765] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 35h24m17.742968508s ago; 
threshold is 3m0s

看来是grpc 数据太大超出了最大限度，synch同步数据跳过了，导致API server 三分钟没有收到同步数据，就直接把这个节点设置为NotReady了，具体pleg机制可以查看其他资料这里不进行详述了。 建议解决问题时先执行下面操作：让该节点上的任务迁移到其他任务，以备后面需要用重启大法 让问题节点不被调度

$ kubectl cordon work01 
驱逐问题节点上所有的pod
$ kubectl drain work01 --ignore-daemonsets --delete-local-data --force

• 查看docker系统占用 docker system df 运行docker ps 发现有大量容器active状态而且许多都是同意类型的任务类型说明在这个过程中程序大量docker容器的产生导致同步状态数据量太大 解决方式： • 登入到work节点清除不用的容器残留 docker system prune 这里清理掉一些残留的容器后，节点状态就恢复正常了，并不需要重启docker和kubelet 如果不行的话就执行：

service docker restart && service kubelet restart

参考文档：

https://www.infoq.cn/article/t_ZQeWjJLGWGT8BmmiU4 https://lattecake.com/post/20149 https://cloud.tencent.com/developer/article/1550038