AWS EC2上kops集群负载升高时工作节点变为NotReady状态如何解决

1. 节点NotReady根因排查 #

• 先获取节点状态详情，执行kubectl describe node <节点名>，重点查看Conditions字段下的MemoryPressure、DiskPressure、PIDPressure状态，以及最近的Events日志：
  • 若返回MemoryPressure=True：节点内存资源耗尽，kubelet触发驱逐机制清理Pod，最终节点被标记为不可用
  • 若返回DiskPressure=True：节点根分区或kubelet使用的磁盘分区使用率超过默认阈值90%
  • 若返回PIDPressure=True：节点上进程数超过内核限制，kubelet无法正常运行
• 若可SSH登录异常工作节点，执行top、df -h、dmesg -T命令，查看系统资源占用、磁盘使用情况、内核报错日志，重点确认是否存在OOM Kill记录，或EC2实例CPU credits耗尽记录（t系列突发性能实例CPU credits耗尽后性能会被严重限制，导致kubelet无法正常上报心跳）
• 查看kubelet运行日志，执行journalctl -u kubelet -f --since "1 hour ago"，确认是否存在无法连接apiserver、资源不足无法启动进程、证书过期等报错

2. Pod Pending根因排查 #

• 执行kubectl get pods -o wide --all-namespaces确认Pending Pod分布，再执行kubectl describe pod <Pod名> -n <命名空间>，查看Events字段报错：
  • 报错Insufficient cpu/Insufficient memory：集群剩余可分配资源不足以满足Pod的requests配置
  • 报错node(s) had taint <taint名>, that the pod didn't tolerate：节点NotReady后会自动添加node.kubernetes.io/not-ready污点，普通Pod无法容忍该污点所以无法调度
  • 报错node(s) were unschedulable：节点被手动标记为不可调度状态

3. 集群配置层面排查 #

• 检查kops节点组配置，确认工作节点的实例规格、资源限制是否合理，是否配置了Cluster Autoscaler节点自动扩缩容能力
• 检查所有应用的resources.requests和resources.limits配置是否合理，是否存在未配置requests的Pod导致资源超卖严重
• 检查主节点运行状态：t2.medium规格的主节点资源有限，负载升高时如果apiserver、etcd响应过慢，会导致工作节点kubelet无法正常上报心跳，被标记为NotReady

• 资源不足导致的节点NotReady：
  • 临时修复：扩容工作节点组，更换更高规格的EC2实例，增加节点数量缓解资源压力
  • 永久修复：为所有应用配置合理的resources.requests和limits，开启kubelet QoS等级，配置合适的驱逐阈值，避免单个应用耗尽整节点资源
• 无自动扩缩容能力：部署Cluster Autoscaler，配置为根据集群负载自动调整工作节点数量，避免负载升高时节点资源不足
• 主节点性能不足：将主节点规格从t2.medium升级到至少t3.large或m5.large，生产环境etcd需搭配高IO EBS卷，避免apiserver响应延迟过高
• t系列实例CPU credits耗尽：生产环境工作节点不建议使用t系列突发性能实例，优先选择固定性能的计算/内存优化型实例；如果必须使用t系列，开启unlimited模式，避免CPU credits耗尽导致实例性能被限制

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