PVC Shrink Migration
How DevZero shrinks an over-provisioned PersistentVolumeClaim by migrating its data to a smaller volume, including StatefulSet handling and rollback.
PVC Shrink Migration
Overview
A PersistentVolumeClaim's spec.resources.requests.storage can be increased, but never decreased -- the Kubernetes API rejects the patch outright. There is no in-place equivalent of in-place vertical scaling for storage.
To shrink a PVC, DevZero instead migrates its data onto a new, smaller volume and swaps it in under the original name -- the owning workload never has to be reconfigured, and the PVC's identity from Kubernetes' perspective (and the underlying PersistentVolume) is preserved. The whole operation runs as a state machine on the PVCRecommendation custom resource, with each phase recorded so it can resume or roll back after a restart.
Migration Flow
Scale the owning workload to zero. The Deployment or StatefulSet that mounts the PVC is scaled down, and DevZero waits for all its pods to terminate before touching any storage.
Create a temporary PVC at the recommended (smaller) size.
Copy the data. A Kubernetes Job mounts both the original and temporary PVCs and runs rsync to copy everything across.
Delete the original PVC, but first mark its underlying PersistentVolume with a Retain reclaim policy so the data survives the deletion.
Delete the temporary PVC (its job -- holding the data on the retained PV -- is done) and clear the PV's claimRef, freeing it to be bound again.
Recreate the PVC using the original name, explicitly bound to that same PersistentVolume, at the smaller size, with the original owner references and labels restored.
Scale the workload back up to its original replica count once the new PVC is bound.
StatefulSet volumeClaimTemplates
StatefulSet-managed PVCs (via volumeClaimTemplates) need one extra precaution: scaling a StatefulSet to zero can delete its PVCs entirely, depending on the StatefulSet's persistentVolumeClaimRetentionPolicy.
Safety and Rollback
Shrinking a PVC takes the workload offline for the duration of the migration -- the data copy and volume swap can't happen while pods are running against the volume.
Every phase of the migration can fail independently (the workload won't scale down, the rsync job errors, the new PVC won't bind, and so on). On failure, DevZero attempts to:
- Scale the workload back up to its original replica count
- Restore the StatefulSet's original
whenScaledpolicy, if it was patched
The overall migration has a 30-minute timeout. If it hasn't completed by then, DevZero treats it as failed and runs the same rollback.