现有EKS集群新增节点及Pod Pending、节点污点故障排查方案

你看到的0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate报错，本质是工作节点已经处于NotReady失联状态，node.kubernetes.io/unreachable是K8s控制面自动给失联节点打的污点，手动执行taint删除命令没用——只要节点没恢复心跳，控制面会自动把这个污点补回去。
你之前的操作存在误区：删Deployment重建Pod还是Pending，不是单纯的资源不足，是节点本身已经脱离就绪池，调度器根本不会往失联节点上调度Pod。最开始的触发点是单节点内存被新增配置的DaemonSet占满，触发系统OOM，连节点上的kubelet进程都被kill或者无法响应，才导致节点失联、所有Pod调度失败。

不需要新增节点，优先修复失联节点即可：

• 打开EKS控制台定位到唯一的工作节点实例：如果实例状态是运行中但内存占满，直接执行实例重启；如果实例状态异常（比如停止、健康检查失败），直接用节点组的实例替换功能，换一台同规格新实例即可。
• 等节点启动后3-5分钟，执行kubectl get nodes确认节点状态变为Ready，此时控制面会自动清掉unreachable污点，不需要手动删污点。
• 节点就绪后第一时间回滚出问题的DaemonSet，执行命令kubectl rollout undo daemonset <你的DaemonSet名称> -n <所在命名空间>，回到加配置之前的版本，防止DaemonSet启动后再次占满内存把节点搞挂。
• 确认DaemonSet所有Pod运行正常、节点剩余内存满足业务需求后，再重建业务Deployment即可。
  注意：DaemonSet会在所有工作节点上强制跑一个Pod，单节点集群里必须给DaemonSet严格配CPU、内存的request和limit，不然很容易把整个节点资源吃满搞崩集群。

如果要从根源解决单节点资源不足的问题，直接扩容节点池：

• 进入EKS控制台对应集群的节点组配置页，调整节点组的期望实例数，从1改成2及以上（生产环境建议至少3台，跨3个可用区部署），提交配置后EKS会自动拉起新节点、完成组件安装和集群注册，不需要手动配置kubelet。
• 等5-10分钟新节点启动完成，执行kubectl get nodes确认新节点状态为Ready，且没有memory-pressure、disk-pressure、unreachable这类异常污点。
• 新节点就绪后，先给之前出问题的DaemonSet加上资源限制，配置示例：

resources:
  requests:
    memory: "64Mi"
    cpu: "50m"
  limits:
    memory: "128Mi"
    cpu: "100m"

• 确认DaemonSet在所有节点上正常启动后，再部署业务Deployment，Pod会自动调度到新的就绪节点上，服务即可恢复。

提示：如果扩容后原来的旧节点一直卡在NotReady状态，直接执行kubectl delete node <旧节点名称>把它从集群里删掉就行，EKS托管节点组会自动补一台新节点替换掉异常实例，不用手动修旧节点。

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