经历的背景是某次基础建设小组的某个工具服务突然无法正常工作后进行排查并最终得以解决。

过程描述

首先，当问题出现后，我们利用 kubectl 查看当前服务的运行状态，并发现该服务的状态一直是 Init 的情况，为了进一步分析问题，我们采用 kubectl describe pod <service> 查看该服务的 Events 情况如下：

根据以上的事件进行初步推断 Pod 被分配到 172.30.124.170 这个节点运行，但是没有后续的其他事件产生，我们又利用命令 kubectl describe node <node> 查看了节点的一些运行情况发现该节点的状态是 NotReady 如下：

并且又利用 kubectl top nodes 无法从 metric-server 查看到任何的资源消耗信息，如下所示：

然后，我们进入到该节点所在的 ECS 中利用 journalctl -f -u kubelet 查看其日志如下：

根据日志拿到一个信息 PLEG is not healthy 后我们咨询了阿里云的专家，后来告诉我们如何处理及产生问题的原因是什么样子的，阿里云具体结论的链接如下：

https://developer.aliyun.com/article/699200

专家的反馈是踩到该 systemd 的 bug 并告知执行以下命令修复（之后有条件则最好进行重启）:

1

yum update -y systemd && systemctl daemon-reexec && killall runc

处理方式

为了能够稳定及安全的维护 Worker 节点，我们参考 Kubernetes 的该文档 Safely Drain a Node 然后再进行被告知的操作进行的解决，相关命令如下：

1
2
3

kubectl drain <node name>
yum update -y systemd && systemctl daemon-reexec && killall runc
kubectl uncordon <node name>

追述

其实在问题报到阿里云那边的时候，对方也出现了一些不确定性的问题，需要额外提供一些服务器授权的行为（需要开通一个 Linux 的 SSH 账号供其进一步诊断），以下就是授权开通账号的一些记录，其目的是为了给到后续清理留下踪迹：

• 创建 Linux 用户 (https://www.jianshu.com/p/27a77e3fc573)
• 授权 sudo (https://www.jianshu.com/p/27a77e3fc573)
• 打开 SSH 密码登陆 (https://blog.csdn.net/ch2009120504/article/details/53170102)
• 这个账号已经放入 1Password ，搜索：alicloud - assistance - ssh account