如何排查GKE集群节点健康异常及Pod操作缓慢问题？

让我一步步帮你拆解这个GKE集群的问题，先从你遇到的核心症状入手，梳理可能的原因和落地的调试方法：

第一步：先解决SSH超时的障碍 #

SSH连不上节点是你排查深层问题的最大阻碍，先搞定这个：

• 优先用GCP官方命令行替代直接SSH：gcloud compute ssh <节点名称>，这个命令会自动处理GKE节点的认证和防火墙规则，比手动SSH更可靠。
• 如果还是超时：
  1. 检查GKE集群的防火墙规则，确认是否存在允许SSH的规则（默认GKE会创建gke-<集群名称>-ssh规则，允许35.191.0.0/16和你的公网IP访问节点22端口）。
  2. 注意：NotReady状态的节点本身可能已经失联，这类节点SSH连不上是正常的，先聚焦在Ready状态但有异常的节点上排查。

核心问题分析：从日志看根源 #

从你给出的症状，最关键的两个信号是PLEG健康错误和CNI网络未初始化，这是节点状态波动、Pod操作超时的核心原因。

一、PLEG（Pod生命周期事件生成器）异常的排查 #

PLEG是kubelet用来跟踪Pod状态的核心组件，它超时说明kubelet和Docker（容器运行时）之间的通信完全卡住了，常见原因和调试步骤：

• 检查节点磁盘压力：
  用kubectl describe node <节点名称>查看节点Conditions，重点看DiskPressure是否为True。即使你说CPU/内存使用率低，磁盘IO慢、磁盘空间满或者inode耗尽，都会导致Docker响应缓慢，进而引发PLEG超时。
• 查看kubelet日志（无需SSH）：
  打开GCP控制台的Logs Explorer，用以下过滤条件定位kubelet日志：

  resource.type="gke_node" 
  AND resource.labels.node_name="<你的节点名称>" 
  AND logName="projects/<你的项目ID>/logs/kubelet"
  

  重点搜索docker相关错误，比如Cannot connect to Docker daemon、Docker API超时等，这些都是PLEG异常的直接诱因。
• 抢占式节点的特殊情况：
  抢占式节点会在24小时内被GCP强制回收，回收过程中可能出现节点状态波动，但你日志里的PLEG错误更偏向节点内部故障，而非单纯的抢占回收。可以尝试删除运行超过20小时的抢占式节点，让节点池自动创建新节点，看是否恢复正常。

二、CNI网络未初始化的问题 #

你看到的network plugin is not ready: cni config uninitialized说明节点的CNI网络插件（GKE默认用Calico）没有正常启动，导致Pod无法分配网络，进而引发启动/终止超时：

• 检查kube-system中的CNI Pod：
  执行kubectl get pods -n kube-system -o wide | grep calico，查看Calico相关Pod是否在有问题的节点上正常运行，有没有CrashLoopBackOff状态。如果这些Pod异常，会直接导致节点网络初始化失败。
• 检查节点初始化Pod：
  GKE节点启动时会运行初始化Pod来配置CNI，执行kubectl get pods -n kube-system -o wide | grep node-init，看这些Pod是否在异常节点上成功运行，有没有日志错误。

三、Pod操作超时的连锁反应 #

Pod启动/终止超30分钟是节点异常的直接后果：

• 节点NotReady时，kubelet无法处理Pod的创建/删除请求，导致请求堆积超时；
• 如果Docker daemon卡住，Pod的生命周期命令无法传递给容器运行时，也会引发超时；
• 额外排查API Server状态：执行kubectl get apiservices，确认所有API服务都是Available状态，虽然你说请求量低，但API Server的隐性延迟也可能影响Pod操作。

四、集群状态不健康的排查 #

GKE集群状态不健康通常和控制平面或节点池配置有关：

• 检查控制平面状态：在GCP控制台的GKE页面，查看控制平面是否有警告（比如etcd节点异常、API Server延迟高）；
• 确认节点池自动修复是否开启：如果开启了自动修复，GKE会自动重启NotReady节点，但如果修复后仍回到异常状态，说明问题根源未解决。

临时紧急修复（业务优先） #

如果业务受影响严重，可以先做临时修复：

1. 驱逐并删除NotReady节点：

   kubectl drain <节点名称> --ignore-daemonsets
   kubectl delete node <节点名称>
   

   GKE节点池会自动创建新节点替换，观察新节点是否能保持Ready状态。
2. 重置抢占式节点池：直接删除异常的抢占式节点池，重新创建一个配置相同的池，快速恢复可用节点。

内容的提问来源于stack exchange，提问作者Achton