Skip to main content
Version: 3.2

Migration and MigrationSchedule

Synchronous and asynchronous disaster recovery (DR) involves migrating Kubernetes resources from a source cluster to a destination cluster. To set up a migration, you need to pair the source and destination clusters, and then set up a migration schedule to migrate the Kubernetes resources. This document explains the fields that can be used to set up successful migration schedules between the clusters as per your requirements.

MigrationSchedule schema

FieldDescriptionTypeOptionalDefault
clusterPairSpecifies the name of the ClusterPair to be used for the migration.stringNoNA
adminClusterPairSpecifies the name of the admin ClusterPair used to migrate resources scoped for the cluster, if the ClusterPair is present in a non-admin namespace.stringYesNA
namespacesSpecifies the list of namespaces to be included in the migration.stringNo

Yes (From Stork version 23.5.0)
NA
namespaceSelectorsWhen set, resources in the namespaces with the specified namespace labels will be migrated. All the labels provided in this option will be OR'ed. Note that this parameter is only supported on Stork version 23.5.0 and newer.map [string] stringYesNA
ignoreOwnerReferencesCheckWhen set, resources with ownerReferences will also be migrated, even if the corresponding owners are getting migrated. Note that this parameter is only supported on Stork version 23.5.0 and newer.booleanYesfalse
includeResourcesSpecifies whether Kubernetes resources should be migrated.booleanYestrue
excludeResourceTypesComma-separated list of the specific resource kinds which need to be excluded from migration. For example, Deployment,PersistentVolumeClaim[]stringYesNA
includeVolumesSpecifies whether the underlying Portworx volumes should be migrated.booleanYestrue
startApplicationsSpecifies whether the applications should be scaled up on the target cluster after a successful migration.booleanYesfalse
purgeDeletedResourcesIf Kubernetes resources are removed from the source cluster, this flag specifies to delete them from the target cluster.booleanYesfalse
skipServiceUpdateSpecifies whether service objects should be skipped during migration.booleanYesfalse
includeNetworkPolicyWithCIDRSpecifies whether the underlying network policies should be migrated even if a fixed CIDR is present on them.booleanYesFalse
selectorsWhen set, only resources with the provided labels will be migrated. All the labels provided in this option will be OR'ed.map [string] stringYesNA
excludeSelectorsWhen set, resources with these labels will be excluded from migration. All the labels provided in this option will be OR'ed. Note that this parameter is only supported on Stork version 23.4.0 and newer.map [string] stringYesNA
preExecRuleSpecifies the name of the rule to be executed before every migration is triggered.stringYesNA
postExecRuleSpecifies the name of the rule to be executed after every migration is triggered.stringYesNA
includeOptionalResourceTypesSet this flag to ensure that the Kubernetes resources associated with [Job] (https://kubernetes.io/docs/concepts/workloads/controllers/job/) are migrated. By default, the Job resources are not migrated.[]stringYesNA
skipDeletedNamespacesSpecifies if migration should ignore deleted namespaces during migration. If set to false, Stork will fail the migration when it encounters a namespace that is deleted but specified in the namespaces field.booleanYestrue
transformSpecsSpecifies the ResourceTransformation spec to be applied during migration.[]stringYesNA
note

You must specify either the namespaces or the namespaceSelectors parameter.

Was this page helpful?