EKS集群缩容至0节点后扩容，动态EBS(PV)被删除的根因排查

问题现象梳理 #

• EKS集群ASG全量缩容到0节点，间隔18-24小时再扩容时，动态创建的EBS PV（已将Delete on termination设为No）会被删除
• 仅缩容1/2个节点，或缩容后1-2小时内扩容，PV均可正常保留
• 当前PV的回收策略为Delete

可能的根因及排查步骤 #

1. Kubernetes节点垃圾回收+PV绑定关系的连锁反应 #

当所有节点被终止后，K8s会将这些节点标记为NotReady，默认节点失联超过5分钟就会启动节点垃圾回收。如果PV的nodeAffinity绑定了已被彻底清理的节点，且集群长时间无节点，PV控制器可能判定该PV为“无主资源”，结合Delete回收策略触发删除。

排查动作：

• 查看缩容前PV的绑定信息：kubectl describe pv <目标PV名称>，确认Node Affinity是否绑定了特定节点
• 查看EKS审计日志（CloudTrail或EKS内置审计日志），搜索PV删除的API请求，确认发起请求的组件是否为persistentvolume-controller

2. EBS CSI驱动的闲置卷清理逻辑 #

EBS CSI驱动会跟踪卷的挂载状态，当集群全空且长时间无节点时，驱动内部的清理任务可能误判卷已无使用场景，主动触发删除——注意Delete on termination仅控制EC2实例终止时是否删除卷，无法阻止CSI驱动发起的删除请求。

排查动作：

• 拉取CSI控制器日志：kubectl logs -n kube-system -l app=ebs-csi-controller，搜索目标PV对应的EBS卷ID，查看是否有删除相关日志条目
• 检查CSI驱动配置，确认是否添加过自定义的闲置卷自动清理规则

3. PV的保护Finalizer丢失 #

PV默认带有kubernetes.io/pv-protection finalizer，用于防止意外删除。若集群全缩容后，K8s API Server因一致性校验问题移除该finalizer，再加上PVC若意外被删除，PV会被Delete策略直接清理。

排查动作：

• 确认对应PVC是否存在：kubectl get pvc -n <PVC所在命名空间>，检查PVC与PV的绑定状态
• 查看PV的finalizers字段：kubectl get pv <目标PV名称> -o jsonpath='{.metadata.finalizers}'，确认是否包含kubernetes.io/pv-protection

4. EKS控制平面的孤儿资源清理 #

EKS控制平面在集群长时间无节点（约18-24小时）后，会自动清理“孤儿资源”，包括未绑定节点且无PVC关联的PV。此时无论Delete on termination如何设置，只要K8s发起删除请求，AWS就会执行删除操作。

排查动作：

• 在CloudTrail中搜索目标EBS卷的DeleteVolume事件，确认请求来源是否为EKS控制平面或CSI驱动
• 查看AWS控制台EC2卷详情页的事件历史，确认删除操作的触发方

验证方案 #

1. 缩容到0节点后，手动为缺失kubernetes.io/pv-protection的PV添加该finalizer，等待24小时后扩容，观察PV是否被删除
2. 临时将PV回收策略改为Retain，重复缩容等待扩容的流程，验证是否仍会触发删除

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