Kubernetes节点重启后NotReady？这份高效排障指南请收好

Kubernetes节点重启后NotReady？这份高效排障指南请收好

引用

CSDN

等

7

来源

1.

https://m.blog.csdn.net/weixin_43230594/article/details/139346462

2.

https://m.blog.csdn.net/xtjatswc/article/details/109234577

3.

https://lumigo.io/kubernetes-troubleshooting/kubernetes-node-not-ready-error-and-how-to-fix-it/

4.

https://www.groundcover.com/kubernetes-troubleshooting/kubernetes-node-not-ready

5.

https://komodor.com/learn/how-to-fix-kubernetes-node-not-ready-error/

6.

https://stackoverflow.com/questions/47107117/how-to-debug-when-kubernetes-nodes-are-in-not-ready-state

7.

https://www.cnblogs.com/cheyunhua/p/18073023

在Kubernetes集群管理中，节点重启后出现NotReady状态是一个常见的挑战。这种状态不仅会影响集群的正常运行，还可能导致服务中断。本文将通过一个实际案例，介绍如何高效地排查和解决这一问题。

当Kubernetes节点处于NotReady状态时，意味着该节点无法正常接受新的Pod调度。这种状态可能由多种因素引起，包括资源不足、网络配置错误、kubelet或kube-proxy问题等。对于集群管理员来说，及时发现并解决NotReady状态至关重要，因为这直接影响到集群的工作效率和可靠性。

要检查集群中是否存在NotReady状态的节点，可以使用以下kubectl命令：

kubectl get nodes

该命令将列出所有节点及其状态。例如：

NAME                   STATUS     ROLES           AGE   VERSION
k8smaster.pci.co.id    Ready      control-plane   31d   v1.28.8
k8sworker1.pci.co.id   Ready       <none>          31d   v1.28.8
k8sworker2.pci.co.id   NotReady    <none>          31d   v1.28.8

在上述输出中，可以看到k8sworker2.pci.co.id节点处于NotReady状态，需要进一步调查其根本原因。

当发现节点处于NotReady状态时，可以按照以下步骤进行系统性排查：

1. 检查节点状态

使用kubectl get nodes命令检查集群中所有节点的状态。标记为NotReady的节点需要进一步调查。

2. 获取节点详细信息

使用kubectl describe node <node-name>命令获取节点的详细信息，包括其状态、事件和配置。这有助于诊断NotReady状态的根本原因。

3. 查看系统日志

检查节点上的系统日志，特别是kubelet和容器运行时（如Docker或containerd）的日志，以获取更多线索。

4. 检查资源使用情况

使用free -h和df -h等命令检查节点的内存和磁盘使用情况，确保资源充足。

5. 检查网络配置

验证节点与Master节点的网络连通性，检查CNI插件（如Calico或Flannel）的状态。

6. 重启相关服务

如果发现问题，尝试重启kubelet、容器运行时或CNI插件服务。

7. 重置节点

如果上述步骤都无法解决问题，可以考虑重置节点并重新加入集群。

假设我们遇到了一个节点NotReady的问题，以下是具体的排查过程：

1. 首先使用kubectl get nodes命令发现k8sworker2.pci.co.id节点处于NotReady状态。

2. 使用kubectl describe node k8sworker2.pci.co.id获取详细信息：

Name:               k8sworker2.pci.co.id
Roles:               <none>
Labels:             beta.kubernetes.io/os=linux
Annotations:        node.alpha.kubernetes.io/ttl=0
CreationTimestamp:  Thu, 12 May 2024 12:00:00 +0000
Conditions:
  Type             Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message
  ----             ------    -----------------                 ------------------                ------              -------
  MemoryPressure   False     Thu, 12 May 2024 12:30:00 +0000   Thu, 12 May 2024 12:00:00 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False     Thu, 12 May 2024 12:30:00 +0000   Thu, 12 May 2024 12:00:00 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False     Thu, 12 May 2024 12:30:00 +0000   Thu, 12 May 2024 12:00:00 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            False     Thu, 12 May 2024 12:30:00 +0000   Thu, 12 May 2024 12:20:00 +0000   KubeletNotReady              PLEG is not healthy: pleg was last seen active 3m0s ago; threshold is 3m0s
Events:
  Type     Reason                  Age                From                     Message
  ----     ------                  ----               ----                     -------
  Normal   Starting                12m                kubelet, k8sworker2      Starting kubelet.
  Warning  NodeNotReady            3m                 kubelet, k8sworker2      Node k8sworker2.pci.co.id status is now: NodeNotReady
  Warning  ContainerdStartFail     2m

从输出中可以看到，节点的Ready状态为False，原因是PLEG（Pod Lifecycle Event Generator）不健康，最后一次活跃时间超过3分钟。

3. 检查系统日志：

journalctl -u kubelet -l

发现kubelet日志中存在以下错误：

May 12 12:35:00 k8sworker2.pci.co.id kubelet[1234]: E0512 12:35:00.123456   12345 kubelet.go:2234] "PLEG is unhealthy" err="rpc error: code = Unknown desc = failed to list containers: operation not supported"

这表明kubelet无法正常与容器运行时通信。

4. 检查容器运行时状态：

systemctl status containerd

发现containerd服务未正常运行。

5. 重启containerd服务：

sudo systemctl restart containerd

6. 再次检查节点状态：

kubectl get nodes

此时，k8sworker2.pci.co.id节点已恢复正常，状态变为Ready。

1. 系统性思维：按照既定的排障框架，从简单到复杂逐步排查，避免盲目操作。

2. 日志分析：充分利用系统日志和组件日志，它们是定位问题的关键线索。

3. 资源监控：定期监控节点资源使用情况，预防资源耗尽导致的问题。

4. 网络检查：确保节点间的网络连通性，特别是与Master节点的通信。

5. 版本兼容性：确保所有组件版本兼容，避免因版本不一致导致的兼容性问题。

1. 资源预留：为节点预留足够的CPU和内存资源，避免资源耗尽。

2. 健康检查：定期进行集群健康检查，及时发现潜在问题。

3. 监控告警：建立完善的监控和告警系统，对异常状态及时预警。

4. 备份与恢复：定期备份关键配置和数据，制定应急恢复计划。

5. 文档记录：详细记录每次故障处理过程，积累经验，优化排障流程。

通过以上方法，可以更高效地排查和解决Kubernetes节点NotReady的问题，确保集群的稳定运行。