背景
用户反馈一个问题,在删除任务重建任务会提示资源清理不成功,赶紧登陆服务器一通操作 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
- 1
- 2
发现蛛丝马迹:
- 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'
- 1
- 2
- 3
- 4
• 一番查找 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 :1765] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 35h24m17.742968508s ago;
threshold is 3m0s
- 1
- 2
- 3
看来是grpc 数据太大超出了最大限度,synch同步数据跳过了,导致API server 三分钟没有收到同步数据,就直接把这个节点设置为NotReady了,具体pleg机制可以查看其他资料这里不进行详述了。
建议解决问题时先执行下面操作:让该节点上的任务迁移到其他任务,以备后面需要用重启大法
让问题节点不被调度
$ kubectl cordon work01
驱逐问题节点上所有的pod
$ kubectl drain work01 --ignore-daemonsets --delete-local-data --force
- 1
- 2
- 3
- 4
• 查看docker系统占用 docker system df 运行docker ps 发现有大量容器active状态而且许多都是同意类型的任务类型说明在这个过程中程序大量docker容器的产生导致同步状态数据量太大
解决方式:
• 登入到work节点清除不用的容器残留
docker system prune
这里清理掉一些残留的容器后,节点状态就恢复正常了,并不需要重启docker和kubelet
如果不行的话就执行:
service docker restart && service kubelet restart
- 1
参考文档:
/article/t_ZQeWjJLGWGT8BmmiU4
/post/20149
/developer/article/1550038