背景

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

排查过程：

先大致确定Terminating状态的pod是哪个，然后确定Pod是处于哪个节点。

可以执行kubectl get pod -A -o wide 查看所有namespace下的pod。

• 执行：kubectl get nodes -o wide查看k8s中节点的状态。

发现其中一个节点处于 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状态到K8S API SERVER 这个过程出错了，继续探索详细导致这个问题的原因。

• 登陆有问题的工作节点， 进入终端机机器后，查看系统日志通过执行 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 三分钟没有收到同步数据，三分钟没有收到pod状态反馈，K8S就直接把这个节点设置为NotReady了，具体pleg实现机制。机制可以查看其他资料这里不进行详述了。

是什么原因导致同步Pod状态数据量太大了？

建议解决问题时先执行下面操作：让该节点上的任务迁移到其他任务，以备后面需要用重启大法

 让问题节点不被调度
$ kubectl cordon work01 
# 驱逐问题节点上所有的pod
$ kubectl drain work01 --ignore-daemonsets --delete-local-data --force

通过执行kubectl get pods -A ｜grep work节点 发现在该节点有大量处于失败或者终止这状态的pod

• 查看docker系统占用 docker system df
• 运行docker ps 发现有大量容器active状态而且许多都是同意类型的任务类型说明在这个过程中程序大量docker容器的产生导致同步状态数据量太大

另外有可能导致问题的原因：

• RPC 调用过程中容器运行时响应超时（有可能是性能下降，死锁或者出现了 bug）。
• 节点上的 Pod 数量太多，导致 relist 无法在 3 分钟内完成。事件数量和延时与 Pod 数量成正比，与节点资源无关。
• relist 出现了死锁，该 bug 已在 Kubernetes 1.14 中修复。
• 获取 Pod 的网络堆栈信息时 CNI 出现了 bug。

解决方式：

• 登入到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