Resource Migration and Rollback

Objectives

Assuming you have a single kubernetes cluster which already has many native resource installed, furthermore, you want to migrate the existing resource to Karmada and then achieve multi-cluster management.

So, this section will guide you to cover:

  • Migrate application from Kubernetes to Karmada.
  • Rollback application migration.

Prerequisites

Karmada with multi cluster has been installed

Step 1: Run the command

  1. git clone https://github.com/karmada-io/karmada
  2. cd karmada
  3. hack/local-up-karmada.sh
  4. export KUBECONFIG=~/.kube/karmada.config:~/.kube/members.config

Note:

Before guide started, we should install at least three kubernetes clusters, one is for Karmada control plane, the other two for member clusters. For convenience, we use hack/local-up-karmada.sh script to quickly prepare the above clusters.

After the above command executed, you will see Karmada control plane installed with multi member clusters.

Preset resource in a member cluster

To simulate resources already exist in member cluster, we deploy simple Deployment to member1 cluster.

Step 2: Write the code

Create new file /tmp/deployments.yaml and copy text below to it:

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: nginx-deploy
  5. spec:
  6.   selector:
  7.     matchLabels:
  8.       app: nginx
  9.   replicas: 2
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: nginx
  14.     spec:
  15.       containers:
  16.         - name: nginx
  17.           image: nginx:latest
  18.           ports:
  19.             - containerPort: 80

Step 3: Run the command

  1. $ kubectl --context member1 apply -f /tmp/deployments.yaml
  2. deployment.apps/nginx-deploy created
  4. $ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=all
  5. NAME           CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
  6. nginx-deploy   member1   2/2     2            2           15m   N

You will see the current nginx-deploy deployment in the member1 cluster, with ADOPTION=N indicating it is not currently managed by Karmada.

Tutorials

Migrate application to Karmada

To make the tutorial simpler and easier to understand, here we assume the application example contains only a single simple deployment.

Step 1: Run the command

  1. $ kubectl --context karmada-apiserver apply -f /tmp/deployments.yaml
  2. deployment.apps/nginx-deploy created
  4. $ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=all
  5. NAME           CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
  6. nginx-deploy   Karmada   0/2     0            0           7s    -
  7. nginx-deploy   member1   2/2     2            2           16m   N

You will see that the Deployment has been deployed to the Karmada control plane as a ResourceTemplate, but there is currently no matching PropagationPolicy to propagate it.

Step 2: Write the code

Create new file /tmp/pp-for-migrating-deployments.yaml and copy text below to it:

  1. apiVersion: policy.karmada.io/v1alpha1
  2. kind: PropagationPolicy
  3. metadata:
  4.   name: migrate-pp
  5. spec:
  6.   conflictResolution: Overwrite
  7.   placement:
  8.     clusterAffinity:
  9.       clusterNames:
  10.       - member1
  11.   resourceSelectors:
  12.   - apiVersion: apps/v1
  13.     kind: Deployment
  14.     name: nginx-deploy

Note:

You should pay attention to two fields：

  • spec.conflictResolution: Overwrite：the value must be Overwrite.
  • spec.resourceSelectors：selecting resources to migrate, you can define your custom ResourceSelector.

Step 3: Run the Command

Apply the above PropagationPolicy to the Karmada control plane:

  1. $ kubectl --context karmada-apiserver apply -f /tmp/pp-for-migrating-deployments.yaml
  2. propagationpolicy.policy.karmada.io/migrate-pp created

Step 4: Verification

  1. $ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=all
  2. NAME           CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
  3. nginx-deploy   Karmada   2/2     2            2           34s   -
  4. nginx-deploy   member1   2/2     2            2           16m   Y
  6. $ karmadactl --karmada-context karmada-apiserver get pods --operation-scope=all
  7. NAME                            CLUSTER   READY   STATUS    RESTARTS   AGE
  8. nginx-deploy-54b9c68f67-4qjrz   member1   1/1     Running   0          16m
  9. nginx-deploy-54b9c68f67-f4qpm   member1   1/1     Running   0          16m

You will see that all Deployments are ready, which means nginx-deploy in the member1 cluster is successfully taken over by Karmada:

  • AGE=16m indicates the resource is taken over rather than recreated, with corresponding pods no need to be restarted.
  • ADOPTION=Y indicates that the resource is now managed by Karmada.

You have now completed the migration.

Rollback Migration

Step 5: Set preserveResourcesOnDeletion for PropagationPolicy

Run the following command to modify PropagationPolicy/migrate-pp, setting spec.preserveResourcesOnDeletion=true:

  1. $ kubectl --context karmada-apiserver patch pp migrate-pp --type='json' -p '[{"op": "replace", "path": "/spec/preserveResourcesOnDeletion", "value": true}]'
  2. propagationpolicy.policy.karmada.io/nginx-pp patched

Step 6: Delete the Resource Template from the Control Plane

Run the following command:

  1. $ kubectl --context karmada-apiserver delete -f /tmp/deployments.yaml
  2. deployment.apps "nginx-deploy" deleted

Step 7: Verification

Run the following command:

  1. $ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=all
  2. NAME           CLUSTER   READY   UP-TO-DATE   AVAILABLE   AGE   ADOPTION
  3. nginx-deploy   member1   2/2     2            2           17m   N
  4. ...

You will see that the resource template in the control plane has been deleted, and the resources in the member clusters remain intact, with ADOPTION=N indicating that the resource is not managed by Karmada.

You have now completed the migration rollback.