扩容是安全的追加操作，缩容是不可逆的有损操作，Kubernetes 在 API 层面直接把它禁掉了。
API 层面直接拒绝
PersistentVolumeClaim 的 update 校验里写死了这条规则，新的 spec.resources.requests.storage 不能小于旧值，否则报 field can not be less than previous value。整个特性从一开始就叫 ExpandPersistentVolumes，只定义了”扩”。
CSI spec 同样如此：只有 ControllerExpandVolume 和 NodeExpandVolume 两个 RPC，规范里根本没有 shrink 这个动作。所以就算某个存储后端理论上能缩，也没有接口可以调。
为什么规范只做扩容
- 文件系统层面不对称。 扩容时新增的空间在块设备末尾，已有数据块的物理位置完全不变，ext4/XFS 都支持挂载状态下在线扩容，风险极低。缩容则要先把落在待截断区域里的数据块、inode、extent、日志全部迁移到前面去，本质是一次完整的数据搬迁：resize2fs 缩容必须先 umount（即 Pod 必须停机），而 XFS 压根不支持缩容，且 XFS 是很多发行版的默认文件系统。
- 两步操作没有事务性。 扩容的顺序是先扩底层卷（controller 侧）、再扩文件系统（kubelet 在 node 侧）；缩容顺序必须反过来，先缩文件系统再缩卷。这两步分别由不同组件在不同机器上执行，中间如果崩溃或超时，就会出现”块设备比文件系统小”的状态，文件系统直接损毁且不可恢复。Kubernetes 没有办法保证这个跨节点两阶段操作的原子性。
- 云盘 API 本身不支持。 AWS EBS、GCE PD、Azure Disk 的 modify volume 接口都只接受更大的容量值。
- 语义上会有损。 如果已用空间超过目标容量，缩容意味着必须丢数据。让用户改一个 YAML 数字就静默删掉数据，不是一个可接受的默认行为。另外 requests.storage 的语义是”至少需要这么多”，改小它本来也不必然意味着要求底层收缩。
想缩容怎么办
只能走”新建 + 迁移 + 切换”：建一个小容量的新 PVC，用一个 Job（rsync/cp）把数据拷过去，改工作负载的挂载指向新 PVC，确认无误后删掉旧的。如果存储支持快照，也可以从 snapshot 恢复到一个较小的新卷，但同样要求已用量小于目标容量。
需要注意配额和计费是按 PV 实际容量算的，所以确实有缩容省钱的动机，但没有捷径。
本文作者：jujimeizuo
本文地址： https://blog.jujimeizuo.cn/2026/09/01/Why-Can-t-PVC-Be-Shrinked/
本博客所有文章除特别声明外，均采用 CC BY-SA 3.0 协议。转载请注明出处！