MongoDB副本集的PVC无法在线扩容，因StatefulSet绑定的PVC的resources.requests.storage字段创建后不可变，Kubernetes API拒绝修改；需通过备份、卸载、新建更大PV、重装并恢复数据实现存储扩容。
PVC扩容在MongoDB副本集里根本不可行
直接说结论：MongoDB副本集的PVC不能在线扩容，StatefulSet绑定的PVC一旦创建，其resources.requests.storage字段就无法修改。Kubernetes API明确拒绝PATCH或UPDATE对已绑定PVC的spec.resources.requests字段的变更，报错通常是Forbidden: field is immutable after creation。
为什么StatefulSet的PVC不允许改大小
MongoDB副本集依赖StatefulSet保证Pod序号、DNS名和存储绑定关系，每个Pod挂载唯一PVC（如data-my-release-mongodb-replicaset-0）。而PVC扩容需底层StorageClass支持allowVolumeExpansion: true，且必须满足两个前提：
- 卷插件（如
aws-ebs、gce-pd、cstor）本身支持在线扩容； - PVC处于
Bound状态但对应PV尚未被Pod实际使用（即Pod未运行或已删除）——但MongoDB副本集要求所有成员持续在线，不可能停掉Pod腾空PV。
即使强行删Pod再扩PVC，也会触发副本集自动重调度，新Pod可能分配到不同节点，而local PV类存储（如hostPath或local类型PV）根本无法跨节点迁移数据。
替代方案：换PV而不是扩PV
真正可行的操作路径是“替换”而非“扩容”：
- 备份当前数据：用
mongodump --host <replica-set-dns> --username root --password $MONGODB_ROOT_PASSWORD --out /backup/导出； - 停掉整个副本集：
helm uninstall my-release，确保所有StatefulSet、PVC、PV被清理； - 新建更大容量的PV（如果是
local类型，需在对应worker节点上提前准备新目录并创建PV）； - 重新安装Chart，通过
--set persistence.size=50Gi（或其他值）指定新大小，Helm会绑定新PV； - 恢复数据：
mongorestore --host <new-replica-set-dns> --username root --password $MONGODB_ROOT_PASSWORD /backup/。
注意：bitnami/mongodb Chart从v12.x起默认启用volumePermissions.enabled=true，若你用的是自建local PV，务必确认新PV的目录权限为uid=1001,gid=1001（Bitnami镜像默认运行用户），否则Pod卡在Init:CrashLoopBackOff。
Operator方案也绕不开这个限制
哪怕你用mongodb-kubernetes-operator部署，它的MongoDB自定义资源（CR）中spec.persistentSpec.size字段同样不可更新。Operator收到变更后会记录事件Warning FailedUpdate unable to update PVC: persistentvolumeclaims "data-my-mongodb-0" is forbidden: spec.resources.requests is immutable。官方文档明确建议：“扩容存储请先备份，再重建集群”。
所以别在PVC上死磕，把精力放在备份策略、恢复验证和灰度切换流程上更实际——毕竟MongoDB副本集的数据一致性保障，远比单个PV多几个GiB重要得多。
