Skip to main content
Version: 3.1

schedule-migrations

Create a schedule policy on your source cluster

You have two options for creating a schedule policy:

  • Run the storkctl create migrationschedule command-line tool the along with the required flags. See Create schedule policy with storkctl topic for more information about the commands with examples, or
  • Perform the following steps on your source cluster:

To schedule the migration, you need to define a schedule policy. You can choose between two types: SchedulePolicy or NamespacedSchedulePolicy.

  • SchedulePolicy: This policy is cluster-scoped and applies to the entire cluster.
  • NamespacedSchedulePolicy: This policy is namespace-scoped and applies only to the namespace that is specified in the policy spec.

Perform the following steps on your source cluster to create a schedule policy:

  1. Create a spec file using one of the following methods.

    • For SchedulePolicy, create the following spec file:
    apiVersion: stork.libopenstorage.org/v1alpha1
    kind: SchedulePolicy
    metadata:
    name: <your-schedule-policy>
    policy:
    interval:
    intervalMinutes: 30

    For a list of parameters that you can use to create a schedule policy, see the Schedule Policy page.

    • For NamespacedSchedulePolicy, create the following spec file:
    apiVersion: stork.libopenstorage.org/v1alpha1
    kind: NamespacedSchedulePolicy
    metadata:
    name: <your-schedule-policy>
    namespace: <migrationnamespace>
    policy:
    interval:
    intervalMinutes: 30

    For a list of parameters that you can use to create a namespaced policy, you can use the fields described on the Schedule Policy page, replacing SchedulePolicy with NamespacedSchedulePolicy.

    • You can also use the schedule policies that are installed by default. Run the storkctl get schedulepolicy command to get the list of these policies, then specify a policy name in the next section for creating a migration schedule. You can skip the next step if you are using the default policies, as they are already applied to your cluster.

  1. Verify if the policy has been created:
    storkctl get schedulepolicy <your-schedule-policy>
    NAME                      INTERVAL-MINUTES    DAILY     WEEKLY             MONTHLY
    <your-schedule-policy> 30 N/A N/A N/A

Create a migration schedule on your source cluster

Once a policy has been created, you can use it to schedule migrations.

You have two options for creating a migration schedule:

  • Run the storkctl create migrationschedule command-line tool the along with the required flags. See Create migration schedule with storkctl topic for more information about the commands with examples, or
  • Perform the following steps on your source cluster:
  1. Copy and paste the following spec into a file called migrationschedule.yaml. Modify the following spec to use a different migration schedule name and/or namespace. Ensure that the clusterPair name is correct.

    apiVersion: stork.libopenstorage.org/v1alpha1
    kind: MigrationSchedule
    metadata:
    name: migrationschedule
    namespace: <migrationnamespace>
    spec:
    template:
    spec:
    clusterPair: <your-clusterpair-name>
    includeResources: true
    startApplications: false
    includeVolumes: false
    namespaces:
    - <app-namespace1>
    - <app-namespace2>
    schedulePolicyName: <your-schedule-policy>
    suspend: false
    autoSuspend: true

Check your migration status

  1. Run the following command on your source cluster to check the status of your migration:
storkctl get migration -n <migrationnamespace>
NAMESPACE                      NAME                                                                CLUSTERPAIR                STAGE   STATUS       VOLUMES   RESOURCES   CREATED               ELAPSED                          TOTAL BYTES TRANSFERRED
bidirectional-clusterpair-ns <your-app>-migration-schedule-interval-interval-2023-08-28-015917 birectional-cluster-pair Final Successful 1/1 4/4 27 Aug 23 19:59 MDT Volumes (33s) Resources (1m2s) 4096
  • The output above indicates a successful migration in the Status column. It also provides a list of migration objects along with timestamps associated with your migration.

  1. Verify your application and associated resources have been migrated by running the following command on your destination cluster:

  NAME                      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/zk-service ClusterIP 10.xxx.xx.68 <none> xxxx/TCP 2m13s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/zk 0/0 0 0 2m13s

NAME DESIRED CURRENT READY AGE
replicaset.apps/zk-59d878d987 0 0 0 2m13s

This confirms that the respective namespace has been created and the applications (for example, Zookeeper) are installed. However, the application pods will not be not running because they are running on the source cluster.

Was this page helpful?