pvmigrate allows migrating PVCs between two StorageClasses by creating new PVs, copying over the data, and then changing
PVCs to refer to the new PVs.
Examples
To migrate PVs from the 'default' StorageClass to mynewsc:
pvmigrate --source-sc default --dest-sc mynewsc
Flags
Flag
Type
Required
Default
Description
--source-sc
String
✓
storage provider name to migrate from
--dest-sc
String
✓
storage provider name to migrate to
--namespace
String
only migrate PVCs within this namespace
--rsync-image
String
eeacms/rsync:2.3
the image to use to copy PVCs - must have 'rsync' on the path
--set-defaults
Bool
false
change default storage class from source to dest
--verbose-copy
Bool
false
show output from the rsync command used to copy data between PVCs
--skip-source-validation
Bool
false
migrate from PVCs using a particular StorageClass name, even if that StorageClass does not exist
Process
In order, it:
Validates that both the source and dest StorageClasses exist
Finds PVs using the source StorageClass
Finds PVCs corresponding to the above PVs
Creates new PVCs for each existing PVC, but using the dest StorageClass
For each PVC:
Finds all pods mounting the existing PVC
Finds all StatefulSets and Deployments controlling those pods and adds an annotation with the original scale
before setting that scale to 0
Waits for all pods mounting the existing PVC to be removed
For each PVC:
Creates a pod mounting both the original and replacement PVC which then rsyncs data between the two
Waits for that invocation of rsync to complete
For each PVC:
Marks all the PVs associated with the original and replacement PVCs as 'retain', so that they will not be deleted
when the PVCs are removed, and adds an annotation to the replacement PV with the original's reclaim policy
Deletes the original PVC so that the name is available, and removes the association between the PV and the removed
PVC
Deletes the replacement PVC so that the PV is available, and removes the association between the PV and the
removed PVC
Creates a new PVC with the original name, but associated with the replacement PV
Sets the reclaim policy of the replacement PV to be what the original PV was set to
Deletes the original PV
Resets the scales of the affected StatefulSets and Deployments
If --set-defaults is set, changes the default StorageClass to dest
Known Limitations
If the migration process is interrupted in the middle, it will not always be resumed properly when rerunning. This
should be rare, and please open an issue if it happens to you
All pods are stopped at once, instead of stopping only the pods whose PVCs are being migrated
PVCs are not migrated in parallel
Constructs other than StatefulSets and Deployments are not handled (for instance, DaemonSets and Jobs), and will
cause pvmigrate to exit with an error
Pods not controlled by anything are not handled, and will cause pvmigrate to exit with an error
PVs without associated PVCs are not handled, and will cause pvmigrate to exit with an error
PVCs that are only available on one node (or some subset of nodes) may not have their migration pod run on the proper
node, which would result in the pod never starting and pvmigrate hanging forever
If the default StorageClass is sc3, migrating from sc1 to sc2 with --set-defaults will not change the default
and will return an error.