k8s集群诊断分析总结：应对现场节点NotReady问题的策略与经验

后端

2023-10-26 08:51:39

k8s 集群诊断分析：应对节点 NotReady 问题的策略和经验

背景

在 2019 年，某企业在现场部署了一套 k8s 集群，配置详情如下：

Docker 版本：1.12
Kubernetes 版本：1.8.6
生产环境：58 台物理机
灰度环境：60 台虚拟机（后来发现，灰度环境和生产环境共用同一个 k8s 资源池，通过标签进行区分）

问题

在实际的生产环境中，该 k8s 集群遭遇了节点 NotReady 问题，导致部分业务无法正常运行。

问题分析

经过仔细排查，我们发现导致节点 NotReady 的根本原因有：

网络故障： 部分节点与控制平面失去联系，无法获取服务信息。
存储故障： 部分节点的存储设备出现故障，导致无法挂载持久化存储卷。
内核崩溃： 部分节点的内核存在缺陷，导致系统崩溃。

解决方案

针对上述问题，我们采取了以下解决措施：

网络故障：
- 检查网络连接，确保节点与控制平面之间网络通畅。
- 重启网络服务，释放并重新建立网络连接。
存储故障：
- 检查存储设备健康状况，识别故障设备并进行更换。
- 重新挂载持久化存储卷，确保数据完整性。
内核崩溃：
- 升级内核版本，修复存在的缺陷。
- 重启节点，重新加载更新后的内核。

预防措施

为了防止类似问题再次发生，我们采取了以下预防措施：

定期健康检查： 定期检查节点健康状况，包括网络连接、存储设备和内核版本。
监控系统： 建立完善的监控系统，及时发现和处理潜在问题。
滚动升级： 采用滚动升级策略，逐步升级系统组件，避免大规模故障。

经验总结

通过这次故障分析，我们总结了以下经验教训：

快速定位问题： 明确故障症状，快速定位故障根源，采取针对性措施。
协同解决问题： 协调不同团队合作，包括网络、存储和运维团队。
经验积累： 记录问题解决过程和经验，为后续故障排查提供参考。

代码示例

为了更直观地展示故障排查和修复过程，我们提供了以下代码示例：

# 检查网络连接
kubectl get nodes -o wide | grep NotReady | grep -v taint

# 重启网络服务
sudo systemctl restart kubelet
sudo systemctl restart docker

# 检查存储设备健康状况
kubectl get pv -o wide | grep NotReady | grep -v taint

# 更换故障存储设备
kubectl delete pv <故障存储卷名称>
kubectl create pv <新存储卷配置>

# 升级内核版本
sudo apt-get update
sudo apt-get install linux-image-$(uname -r | sed 's/-generic//')-generic

# 重启节点
sudo reboot