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.
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.
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 |