Skip to main content
Version: 3.1

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:

FieldDescriptionTypeDefault valueOptional
-h, --helpHelp for migration schedules
--admin-cluster-pairSpecify the name of the admin ClusterPair used to migrate cluster-scoped resources, if the ClusterPair is present in a non-admin namespace.stringYes
--annotationsAdd required annotations to the resource in comma-separated key value pairs. key1=value1,key2=value2,...map [string] stringYes
-c, --cluster-pairSpecify the name of the ClusterPair in the same namespace to be used for the migration.stringNo
--disable-auto-suspendPrevent automatic suspension of DR migration schedules on the source cluster in case of a disaster.booleanfalseYes
--disable-skip-deleted-namespacesIf 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.booleanfalseYes
--exclude-resource-typesComma-separated list of the specific resource types which need to be excluded from migration, ex: Deployment,PersistentVolumeClaim.stringsYes
--exclude-resourcesIf present, Kubernetes resources will not be migrated.booleanfalseYes
--exclude-selectorsResources with the provided labels will be excluded from the migration. All the labels provided in this option will be OR'ed.map [string] stringYes
--exclude-volumesIf 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.booleanTrue for Sync-DR and False for Async-DR use cases.Yes
--ignore-owner-references-checkIf set, resources with ownerReferences will also be migrated, even if the corresponding owners are getting migrated.booleanfalseYes
--include-jobsSet this flag to ensure that K8s Job resources are migrated. By default, the Job resources are not migrated.booleanfalseYes
--include-network-policy-with-cidrIf set, the underlying network policies will be migrated even if a fixed CIDR is present on them.booleanfalseYes
-i, --intervalSpecify the time interval, in minutes, at which Stork should trigger migrations.int30Yes
--namespace-selectorsResources in the namespaces with the specified namespace labels will be migrated. All the labels provided in this option will be OR'ed.map [string] stringYes
--namespacesSpecify the comma-separated list of namespaces to be included in the migration.stringsYes (From Stork version 23.5.0)
--post-exec-ruleSpecify the name of the rule to be executed after every migration is triggered.stringYes
--pre-exec-ruleSpecify the name of the rule to be executed before every migration is triggered.stringYes
--purge-deleted-resourcesSet this flag to automatically delete Kubernetes resources in the target cluster when they are removed from the source cluster.booleanfalseYes
-s, --schedule-policy-nameName of the schedule policy to use. If you want to create a new interval policy, use the --interval flag instead.stringdefault-migration-policyYes
--selectorsOnly resources with the provided labels will be migrated. All the labels provided in this option will be OR'ed.map [string] stringYes
--skip-service-updateIf set, service objects will be skipped during migration.booleanfalseYes
-a, --start-applicationsIf present, the applications will be scaled up on the target cluster after a successful migration.booleanfalseYes
--suspendFlag to denote whether schedule should be suspended on creation.booleanfalseYes
--transform-specSpecify the ResourceTransformation spec to be applied during migration.stringYes
Was this page helpful?