EKS节点宕机后EBS持久卷分离重挂的默认超时调整问询

延迟根因说明 #

你观测到的约20分钟的卷迁移等待窗口，不是EKS的固定硬限制，是三个组件的默认超时逻辑叠加产生的：

• Kubernetes节点控制器（Node Controller）默认连续40s未收到节点心跳，会将节点标记为NotReady，之后默认等待5分钟（pod-eviction-timeout参数）才会强制驱逐节点上的所有Pod
• 卷分离挂载控制器（Attach-Detach Controller, ADC）只有在目标节点上所有Pod的绑定关系、VolumeAttachment对象完全清理后，才会触发EBS卷从故障实例的分离操作
• EKS托管节点组自身的不健康节点替换流程，会额外叠加数分钟的节点移除等待时间

可调整的优化项 #

1. 缩短节点故障后的Pod强制驱逐等待时间 #

• 调整Node Controller的--pod-eviction-timeout参数：该参数控制节点被标记为NotReady后，强制删除其上所有Pod的等待时长，默认值为5分钟，可根据容灾需求调整为30s~1分钟区间。如果使用EKS托管控制平面，该参数属于控制平面组件配置，需通过EKS官方提供的控制平面参数定制入口调整；如果是自建控制平面的集群，可直接修改kube-controller-manager的启动参数
• 针对运行EBS卷的Pod，自定义terminationGracePeriodSeconds：避免使用默认30s的终止宽限期，将其设置为10s以内，进一步缩短Pod被强制终止的等待时长
• 缩短节点故障判定阈值：调整Node Controller的--node-monitor-grace-period参数，默认值40s，可根据集群网络情况缩短至15~20s，更早将失联节点标记为NotReady

2. 提前触发EBS卷的分离流程 #

• 确认节点完全宕机后，直接执行kubectl delete node <故障节点名称>：该操作会立即清理节点的所有元数据关联，ADC会立刻判定节点上无活跃Pod绑定，直接触发EBS卷从故障EC2实例的强制分离，无需等待默认的5分钟驱逐超时
• 调整ADC的状态同步周期：修改kube-controller-manager的--attach-detach-reconcile-sync-period参数，默认值1分钟，可调整为15s级别，让控制器更快检测到卷绑定关系的变化，触发分离或挂载动作

3. 规避跨可用区挂载前置阻塞 #

EBS是可用区级块存储资源，本身不支持跨可用区挂载，需在StorageClass中通过allowedTopologies固定EBS卷的创建可用区，保证Pending Pod被调度的节点与EBS卷处于同一可用区，否则就算卷分离流程完成，也无法挂载到其他可用区的节点上 #

Multi-Attach 报错的本质 #

你遇到的Multi-Attach error for volume "xxx" Volume is already used by pod(s)报错，并非卷实际处于双挂载状态，而是故障节点上的Pod元数据未被完全清理，ADC仍维持卷与旧Pod的绑定关系导致的。只有当旧Pod的绑定关系、对应的VolumeAttachment对象完全删除，且EBS卷从旧实例完成分离后，新的Pending Pod才能正常获得卷的挂载权限。

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