AWS EKS新扩容节点重建Pod持续连接拒绝异常排查

• AWS
• EKS
• Auto Scaling Group (ASG)

• 将集群节点数量从3扩容至4，节点依次命名为node1-4，初始状态下node1-3上运行有多个业务Pod
• 执行kubectl get node -n my-ns命令确认新增节点node4状态为Ready
• 在AWS控制台为node2-4配置scale-in（缩容）保护
• 将集群节点数量从4缩容至3，node1开始进入终止流程
• 原运行在node1上的Pod开始被驱逐
• 从node1驱逐的Pod开始在node2-4节点上重建

• 重建在node2-3（原有存量节点）上的Pod快速进入READY状态，表现符合预期
• 重建在node4（扩容操作新增的节点）上的Pod持续重启，部分Pod耗时12分钟才进入READY状态，最晚的Pod耗时57分钟才就绪，属于明显异常
• 重建在node4上的daemonset Pod在1分钟内即可进入READY状态，无异常

• 查看持续重启的Pod日志，发现如下报错：

Startup probe failed ..... http://x.x.x.x:8080/actuator/health connection refused

• 经过多次重启最终进入READY状态的Pod，手动删除后可快速重新进入READY状态，无反复重启问题
• 手动删除处于持续重启状态的Pod无法解决该异常

高概率根因 #

结合AWS EKS的运维经验，这类新节点上DaemonSet正常、普通业务Pod长时间启动探针失败、节点预热完成后Pod恢复正常的问题，90%以上集中在两类原因：

1. VPC CNI 网络资源预热延迟
   EKS默认使用VPC CNI实现Pod网络，新节点启动后，aws-node组件需要异步完成ENI弹性网卡附加、辅助私有IP分配、路由规则配置等操作，这个过程根据集群规模和AWS API响应速度，可能耗时数分钟到数十分钟。节点状态变为Ready仅代表kubelet完成集群注册，不代表Pod网络已经就绪。
   由于DaemonSet组件（包括aws-node、kube-proxy等）默认使用hostNetwork模式，直接复用节点宿主机网络，不依赖CNI分配的Pod网络栈，因此可以快速就绪；普通业务Pod使用CNI分配的Pod IP，在ENI和IP资源未就绪时，Pod内部网络不通，访问自身端口的启动探针会直接报连接拒绝。等CNI完成所有资源预热后，网络连通性恢复，探针就能成功。节点上一旦有Pod正常运行，后续新建Pod可以直接使用已经预热好的ENI/IP资源，因此手动删除已就绪的Pod可以快速启动。
2. 新挂载EBS卷初始化导致IO性能瓶颈
   新EC2节点附加的EBS数据盘/系统盘在首次访问时存在初始化预热过程，这个阶段磁盘IO性能会远低于标称值，IO等待时间极高。从报错的/actuator/health端点可以判断业务是Spring Boot类Java应用，启动过程需要读取大量依赖文件、做类加载，对磁盘IO性能敏感，在IO瓶颈下启动时间会被拉长到数十分钟，期间服务端口未启动，探针访问会报连接拒绝。等磁盘预热完成、Java进程启动完成后服务恢复正常，后续重建Pod时磁盘已经处于正常性能状态，因此启动速度恢复正常。

其他低概率原因包括：节点iptables/NetworkPolicy规则异步下发拦截流量、节点多网卡路由冲突、kube-proxy规则首次全量同步延迟等。

排查方向 #

• 检查node4上VPC CNI组件日志：执行kubectl logs -n kube-system <node4对应的aws-node Pod名>，重点查看业务Pod调度到节点的时间窗口内，是否有ENI附加失败、IP分配重试、网络配置超时的报错，同时核对aws-node Pod的就绪时间和业务异常时间窗口是否吻合。
• 核对EC2实例的ENI配置：在AWS EC2控制台找到node4对应的实例，查看异常时间段内的网卡操作记录，确认是否存在ENI正在附加、辅助私有IP正在分配的未完成操作，验证是否为CNI资源预热问题。
• 排查节点磁盘性能：在业务Pod异常的时间段，登录node4节点执行iostat -x 1查看磁盘IO等待指标，执行dmesg查看内核日志中是否有块设备报错、EBS卷初始化相关记录，确认是否存在IO瓶颈。
• 定位连接拒绝的具体原因：在异常时间段进入Pod对应的网络命名空间，本地执行curl http://127.0.0.1:8080/actuator/health验证端口是否真的处于监听状态：如果本地访问也报连接拒绝，说明业务进程未完成启动，可直接查看容器内业务进程的启动日志，定位是否卡在资源加载阶段；如果本地访问正常但探针访问失败，说明是Pod网络层面存在连通性问题，可通过tcpdump抓包确认流量是否被拦截。
• 检查节点初始化配置：确认集群是否配置了新节点污点机制——即新节点加入后先打上临时污点，等所有DaemonSet就绪、CNI资源预热完成后再移除污点，避免业务Pod被过早调度到未完全初始化的节点上。如果没有该配置，建议补充相关逻辑，从调度侧规避这类问题。

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