K8s中作为PVC挂载的在用EBS卷扩容未生效问题咨询

操作顺序问题导致扩容流程卡住：你提前在EBS控制台手动修改了底层卷容量，后续修改PVC存储请求、开启StorageClass扩容能力的操作，不会被K8s EBS存储插件识别为需要触发扩容。插件默认逻辑是先比对PVC请求容量和底层卷实际容量，发现卷大小已经满足请求时，就不会下发文件系统扩容指令到节点，哪怕删除Pod重建，节点侧也不会执行文件系统扩展，PVC会一直卡在FileSystemResizePending状态，持续显示旧容量。

方案1：触发控制器重协调（优先选择，无侵入无副作用） #

• 先确认StorageClass扩容开关已生效，执行以下命令检查：

kubectl get sc default -o yaml | grep allowVolumeExpansion

确认输出为allowVolumeExpansion: true再进行后续操作。

• 给PVC加临时扩容扰动，强制存储重调度器处理该PVC：把PVC存储请求临时调到比当前EBS实际容量高1Gi，比如当前EBS已经调整到200Gi，就先改成201Gi：

kubectl patch pvc files -p '{"spec":{"resources":{"requests":{"storage":"201Gi"}}}}'

• 等待10~15秒，查看PVC事件，能看到重调度器尝试调整EBS容量，此时它会同步到底层卷实际容量已经是200Gi，再把PVC容量改回目标值200Gi：

kubectl patch pvc files -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'

• 此时PVC会重新进入FileSystemResizePending状态，直接删除该PVC关联的所有Pod，等待Pod重新调度启动后，节点上的kubelet会自动完成文件系统扩容。
• 验证：执行kubectl get pvc files，若CAPACITY列显示200Gi，且无FileSystemResizePending状态提示即为成功，也可进Pod执行df -h <PVC挂载路径>确认实际文件系统容量。

方案2：手动修改PV容量（方案1无效时使用） #

如果重协调逻辑始终无法触发，可以直接修改绑定的PV资源，绕开控制面检查：

• 编辑当前PVC绑定的PV，你的PV名称为pvc-a02bb805-de70-4fc8-bcef-a4943eb4ca0b，执行编辑命令：

kubectl edit pv pvc-a02bb805-de70-4fc8-bcef-a4943eb4ca0b

• 找到spec.capacity.storage字段，把原有值150Gi修改为200Gi，保存退出。
• 删除该PVC关联的所有Pod，等待Pod重新调度到节点后，kubelet检测到底层块设备容量大于当前文件系统大小，会自动根据文件系统类型执行resize2fs（ext4文件系统）或xfs_growfs（xfs文件系统）完成扩容。
• 验证逻辑和方案1一致。

• 不要尝试直接在容器内执行扩容命令：普通容器没有访问宿主机块设备的权限，即使加特权权限也容易出现设备路径映射错误，导致扩容失败甚至文件系统损坏，交给kubelet自动处理是最稳妥的方式。
• 如果是1.23及以前版本使用in-tree EBS存储插件的集群，操作前确认节点kubelet开启了--enable-controller-attach-detach=true参数，否则节点不会自动处理文件系统扩容。
• 所有扩容操作前建议先给EBS卷打快照，避免操作失误导致数据丢失。

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