Create MigrationSchedule with storkctl

This topic explains how to create and delete a MigrationSchedule using the storkctl command-line tool.

How to use the storkctl command?

To create a MigrationSchedule using storkctl, you can use the create migrationschedules or create migrationschedule command with specific flags to define the schedule details.

note

In the storkctl create command, default values will be applied to all optional parameters in case you do not provide input.

Additionally, validations are implemented that will generate relevant error messages in the event of invalid or incorrect inputs to the command. For example:

error: unable to retrieve transformation default/my-resource-transformation, err: resourcetransformations.stork.libopenstorage.org "my-resource-transformation" not found

Create an interval-based migration schedule

Run the following command to create a migration schedule with specific configurations, including the cluster pair, namespaces to migrate, migration interval, pre-execution rule, resource transformation, and the namespace for migration resources:

storkctl create migrationschedule <migrationScheduleName> \
-c <clusterPairName> \
--namespaces <list of namespaces to migrate> \
-i <time-in-minutes> \
--pre-exec-rule <RuleName> \
--transform-spec <ResourceTransformationName> \
-n <migrationNamespace>

Example command to create a schedule policy with the specified interval:

storkctl create migrationschedule my-migration-schedule \
-c my-cluster-pair \
—namespaces namespace1,namespace2 \
-i 30 \
—pre-exec-rule mysql-pre-rule \
—transform-spec mysql-service-transform \
-n kube-system

my-migration-schedule created successfully

To view the migration schedule, run the kubectl get migrationschedule my-migration-schedule -oyaml command. Example migration schedule:

apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
 name: my-migration-schedule
 namespace: kube-system
spec:
 autoSuspend: true
 schedulePolicyName: my-migration-schedule
 suspend: false
 template:
   spec:
     adminClusterPair: ""
     clusterPair: my-cluster-pair
     excludeResourceTypes: null
     excludeSelectors: null
     ignoreOwnerReferencesCheck: false
     includeNetworkPolicyWithCIDR: false
     includeOptionalResourceTypes: null
     includeResources: true
     includeVolumes: true
     namespaceSelectors: null
     namespaces:
     - namespace1
     - namespace2
     postExecRule: ""
     preExecRule: mysql-pre-rule
     purgeDeletedResources: false
     selectors: null
     skipDeletedNamespaces: true
     skipServiceUpdate: false
     startApplications: false
     transformSpecs:
     - mysql-service-transform

Create a migration schedule with namespace selectors and annotations flags

Run the following command to create a migration schedule with specific configurations, including the cluster pair, namespace selectors, schedule policy, authentication annotations, and the namespace for migration resources:

storkctl create migrationschedule <migrationScheduleName> \
-c <clusterPairName> \
--namespace-selectors <key1>=<value1> \
--schedule-policy-name <your-schedule-policy> \
--annotations openstorage.io/auth-secret-namespace=<namespace-where -the-kubernetes-secret-holding-the-auth-token-resides>,openstorage.io/auth-secret-name=<kubernetes-secret-name-which-holds-the-auth-token> \
-n <migrationNamespace>

Example:

storkctl create migrationschedule my-migration-schedule \
-c my-cluster-pair \
--namespace-selectors stage=production,priority=P0 \
--schedule-policy-name default-daily-policy \
--annotations openstorage.io/auth-secret-namespace=auth-namespace,openstorage.io/auth-secret-name=my-auth-secret \
-n my-migration-namespace

Example migration schedule:

apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
 annotations:
   openstorage.io/auth-secret-name: my-auth-secret
   openstorage.io/auth-secret-namespace: auth-namespace
 name: my-migration-schedule
 namespace: my-migration-namespace
spec:
 autoSuspend: true
 schedulePolicyName: default-daily-policy
 suspend: false
 template:
   spec:
     adminClusterPair: ""
     clusterPair: my-cluster-pair
     excludeResourceTypes: null
     excludeSelectors: null
     ignoreOwnerReferencesCheck: false
     includeNetworkPolicyWithCIDR: false
     includeOptionalResourceTypes: null
     includeResources: true
     includeVolumes: true
      namespaceSelectors:
         priority: P0
         stage: production
     namespaces: null
     postExecRule: ""
     preExecRule: ""
     purgeDeletedResources: false
     selectors: null
     skipDeletedNamespaces: true
     skipServiceUpdate: false
     startApplications: false
     transformSpecs: null

Create a migration schedule with few boolean flags

Run the following command to create a migration schedule with specific configurations, including the cluster pair, namespaces to migrate, exclusion of certain resources, purging of deleted resources, and the namespace for migration resources:

storkctl create migrationschedule <migrationScheduleName> \
-c <clusterPairName> \
--namespaces <list-of-namespaces-to-migrate> \
-- exclude-resources \
-- purge-deleted-resources \
-n <migrationNamespace>

Example:

storkctl create migrationschedule my-migration-schedule \
-c my-cluster-pair \
--namespaces namespace1 \
--exclude-resources \
--purge-deleted-resources \
-n namespace1

Example migration schedule:

apiVersion: stork.libopenstorage.org/v1alpha1
kind: MigrationSchedule
metadata:
 name: my-migration-schedule
 namespace: namespace1
spec:
 autoSuspend: true
 schedulePolicyName: default-migration-policy
 suspend: false
 template:
   spec:
     adminClusterPair: ""
     clusterPair: my-cluster-pair
     excludeResourceTypes: null
     excludeSelectors: null
     ignoreOwnerReferencesCheck: false
     includeNetworkPolicyWithCIDR: false
     includeOptionalResourceTypes: null
     includeResources: false
     includeVolumes: true
     namespaceSelectors: null
     namespaces:
     - namespace1
     postExecRule: ""
     preExecRule: ""
     purgeDeletedResources: true
     selectors: null
     skipDeletedNamespaces: true
     skipServiceUpdate: false
     startApplications: false
     transformSpecs: null

Set up schedule policy for migration schedule

You have three options to set up the schedule policy for the migration schedule:

• Use existing policy: Employ the schedule-policy-name flag to utilize an already existing schedule policy.
• Create new interval policy: Utilize the interval flag to generate a new interval schedule policy with the specified time interval.
• Default Policy: If neither of the above flags is specified, the system will default to using default-migration-policy, which is a schedule policy with a 30-minute interval.

note

You can only provide either the schedule-policy-name or the interval flag; using both is not allowed.

Create migrationschedule command flags

You can include one or more of the following flags when using the storkctl create migrationschedule command based on your specific requirements:

Field	Description	Type	Default value	Optional
-h, --help	Help for migration schedules
--admin-cluster-pair	Specify the name of the admin ClusterPair used to migrate cluster-scoped resources, if the ClusterPair is present in a non-admin namespace.	string		Yes
--annotations	Add required annotations to the resource in comma-separated key value pairs. key1=value1,key2=value2,...	map [string] string		Yes
-c, --cluster-pair	Specify the name of the ClusterPair in the same namespace to be used for the migration.	string		No
--disable-auto-suspend	Prevent automatic suspension of DR migration schedules on the source cluster in case of a disaster.	boolean	false	Yes
--disable-skip-deleted-namespaces	If present, Stork will fail the migration when it encounters a namespace that is deleted but specified in the namespaces field. By default, Stork ignores deleted namespaces during migration.	boolean	false	Yes
--exclude-resource-types	Comma-separated list of the specific resource types which need to be excluded from migration, ex: Deployment,PersistentVolumeClaim.	strings		Yes
--exclude-resources	If present, Kubernetes resources will not be migrated.	boolean	false	Yes
--exclude-selectors	Resources with the provided labels will be excluded from the migration. All the labels provided in this option will be OR'ed.	map [string] string		Yes
--exclude-volumes	If present, the underlying Portworx volumes will not be migrated. This is the only allowed and default behavior in Sync-DR use-cases or when storage options are not provided in the cluster pair.	boolean	True for Sync-DR and False for Async-DR use cases.	Yes
--ignore-owner-references-check	If set, resources with ownerReferences will also be migrated, even if the corresponding owners are getting migrated.	boolean	false	Yes
--include-jobs	Set this flag to ensure that K8s Job resources are migrated. By default, the Job resources are not migrated.	boolean	false	Yes
--include-network-policy-with-cidr	If set, the underlying network policies will be migrated even if a fixed CIDR is present on them.	boolean	false	Yes
-i, --interval	Specify the time interval, in minutes, at which Stork should trigger migrations.	int	30	Yes
--namespace-selectors	Resources in the namespaces with the specified namespace labels will be migrated. All the labels provided in this option will be OR'ed.	map [string] string		Yes
--namespaces	Specify the comma-separated list of namespaces to be included in the migration.	strings		Yes (From Stork version 23.5.0)
--post-exec-rule	Specify the name of the rule to be executed after every migration is triggered.	string		Yes
--pre-exec-rule	Specify the name of the rule to be executed before every migration is triggered.	string		Yes
--purge-deleted-resources	Set this flag to automatically delete Kubernetes resources in the target cluster when they are removed from the source cluster.	boolean	false	Yes
-s, --schedule-policy-name	Name of the schedule policy to use. If you want to create a new interval policy, use the --interval flag instead.	string	default-migration-policy	Yes
--selectors	Only resources with the provided labels will be migrated. All the labels provided in this option will be OR'ed.	map [string] string		Yes
--skip-service-update	If set, service objects will be skipped during migration.	boolean	false	Yes
-a, --start-applications	If present, the applications will be scaled up on the target cluster after a successful migration.	boolean	false	Yes
--suspend	Flag to denote whether schedule should be suspended on creation.	boolean	false	Yes
--transform-spec	Specify the ResourceTransformation spec to be applied during migration.	string		Yes