EZswitch operates as a Kubernetes Custom Resource (CR) managed by a controller. It coordinates syncing jobs (using rsync under the hood), the final switchover to a Zesty-based StatefulSet (with the same properties as the initial STS), and supports both automatic or manual migration phases.
Migration statuses (.status.status)
After EZswitch starts, it follows these steps in completing the migration:
InstallRequirements: Sets up necessary RBAC permissions and prerequisites.
Init: Creates corresponding PVCs under the Zesty storage class.
CreateSyncJobs: Launches sync jobs to copy data from the original PVCs to the new PVCs.
Syncing: Continuously synchronizes data to ensure the new PVCs mirror the old ones in near real-time.
ReadyForMigration:
If autoMigrate=false, the migration pauses here until resumed with the migrate command or by setting autoMigrate=true on the EZswitch resource.
If autoMigrate=true, the migration proceeds by scaling down the original StatefulSet.
CreatingFinalSyncJobs: Sets up final sync jobs to ensure data consistency before the final cutover.
SyncingFinalJobs: Runs a final round of synchronization to confirm all data is up to date.
WaitingForZestySTS: Deploys the new Zesty-based StatefulSet and waits for it to become fully ready.
Success: Cleans up finalizers and completes the migration.
You can follow the EZswitch status through the migration process. For more information, see the status<stsName> command in EZswitch command reference.
Limitations and considerations
Only one EZswitch migration per StatefulSet is currently supported.
Ensure sufficient cluster resources for EZswitch synchronization jobs. Which includes:
A pod per workload replica
2 pods per PVC
There’s a maximum pods limitation for each cluster node, defined by the node parameter value .status.allocatable.pods
Avoid scaling the StatefulSet during migration.
Migration duration depends on PVC size and cluster load.