K8s节点NotReady恢复方法

问题描述：业务反应有一个K8s pod更新后一直删除不掉，以免影响业务，排查后发现是该pod所在的node节点主机10.10.12.75是NotReady状态。

# kubectl get nodes
NAME        STATUS     ROLES         AGE      VERSION
10.10.12.55   Ready      etcd,master   5y305d   v1.18.5
10.10.12.57   Ready      etcd,master   5y305d   v1.18.5
10.10.12.59   Ready      etcd,master   5y305d   v1.18.5
10.10.12.62   Ready      worker        5y305d   v1.18.5
10.10.12.64   Ready      worker        5y305d   v1.18.5
10.10.12.75   NotReady   worker        5y305d   v1.18.5

生产环境中遇到节点 NotReady，首要原则是先诊断，后操作。任何直接重启节点的行为都应谨慎，以免对运行中的业务造成影响。

1. 获取节点详情

kubectl describe node 10.10.12.75

在命令输出的末尾，重点关注以下两个部分：

Conditions 部分：查看 Ready 状态为 False 还是 Unknown。同时检查 MemoryPressure、DiskPressure、PIDPressure 等是否为 True。如果是 True，说明节点资源耗尽

Events 部分：这里会记录近期发生的关键事件。例如，可能会出现 Failed to create pod sandbox、Unable to attach or mount volumes 或 kubelet stopped posting node status 等错误信息。这些信息是后续排查的根本依据。

2. 检查控制平面组件状态

# kubectl get pods -n kube-system | grep -E 'etcd|apiserver|controller-manager|scheduler'
etcd-10.0.1.55                             1/1     Running   15         5y305d
kube-apiserver-10.0.1.59                   1/1     Running   8          5y305d
kube-controller-manager-10.0.1.55          1/1     Running   98         5y305d
kube-scheduler-10.0.1.55                   1/1     Running   104        5y305d

确保所有控制平面组件的Pod都在运行。

3. （如果可能）登录问题节点，检查基础服务

检查kubelet服务状态及日志信息：

systemctl status kubelet
journalctl -u kubelet -f --lines=50

观察日志末尾是否有明显的错误。常见的有：

• 证书问题: 日志中可能包含 "TLS bootstrap failed" 或 "certificate has expired" 等字样。5年以上的集群，证书过期是常见原因。

• 容器运行时问题: 报错 "failed to connect to containerd" 或 "dial unix /run/containerd/containerd.sock: connect: no such file or directory"，说明容器运行时（containerd/docker）挂了。

• PLEG问题: 报错 "PLEG is not healthy"，通常与容器运行时响应缓慢有关

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

# 如果使用 containerd (K8s 1.18 的常用运行时)
sudo systemctl status containerd

# 如果使用 docker
sudo systemctl status docker

# 检查磁盘空间
df -h /var/lib/kubelet

5、实施恢复（低风险操作）

# 重启docker、kubelet服务
systemctl restart docker
systemctl restart kubelet
# 重启后再次检查其状态和日志
sudo systemctl status kubelet

6、故障转移（业务保护）

 如果节点问题复杂，预计修复时间较长（超过10分钟），为了保障业务，应该先将该节点上的Pod迁移走。

# 封锁节点，使其不再接受新的Pod调度
kubectl cordon 10.10.12.75

# 驱离节点上的现有Pod，使其重新调度到其他健康节点
# --ignore-daemonsets: 忽略DaemonSet管理的Pod
# --delete-emptydir-data: 删除那些使用了临时存储的Pod（谨慎使用）
kubectl drain 10.10.12.75 --ignore-daemonsets --delete-emptydir-data

Kubernetes 中，可以通过 Service 的配置找到关联的 Pod，并获取 Pod 的 IP 地址.

方法一：通过 kubectl describe svc 查看 Endpoints

kubectl describe svc <service-name> -n <namespace>

#输出中会包含 Endpoints 字段，格式为 <pod-ip>:<port>，例如
Endpoints:         10.244.1.5:8080,10.244.2.8:8080,10.244.3.12:8080

方法二：使用 kubectl get endpoints 命令
# 查看单个 Service 的 Endpoints
kubectl get endpoints <service-name> -n <namespace>

# 查看所有 Service 的 Endpoints
kubectl get endpoints -A