Promote legacy workload

Assume that there is a member cluster where a workload (like Deployment) is deployed but not managed by Karmada, we can use the karmadactl promote command to let Karmada take over this workload directly and not to cause its pods to restart.

Example

For member cluster in Push mode

There is an nginx Deployment that belongs to namespace default in member cluster cluster1.

  1. [root@master1]# kubectl get cluster
  2. NAME       VERSION   MODE   READY   AGE
  3. cluster1   v1.22.3   Push   True    24d
  1. [root@cluster1]# kubectl get deploy nginx
  2. NAME    READY   UP-TO-DATE   AVAILABLE   AGE
  3. nginx   1/1     1            1           66s
  5. [root@cluster1]# kubectl get pod
  6. NAME                       READY   STATUS      RESTARTS   AGE
  7. nginx-6799fc88d8-sqjj4     1/1     Running     0          2m12s

We can promote it to Karmada by executing the command below on the Karmada control plane.

  1. [root@master1]# karmadactl promote deployment nginx -n default -c member1
  2. Resource "apps/v1, Resource=deployments"(default/nginx) is promoted successfully

The nginx deployment has been adopted by Karmada.

  1. [root@master1]# kubectl get deploy
  2. NAME    READY   UP-TO-DATE   AVAILABLE   AGE
  3. nginx   1/1     1            1           7m25s

And the pod created by the nginx deployment in the member cluster wasn’t restarted.

  1. [root@cluster1]# kubectl get pod
  2. NAME                       READY   STATUS      RESTARTS   AGE
  3. nginx-6799fc88d8-sqjj4     1/1     Running     0          15m

For member cluster in Pull mode

Most steps are same as those for clusters in Push mode. Only the flags of the karmadactl promote command are different.

  1. karmadactl promote deployment nginx -n default -c cluster1 --cluster-kubeconfig=<CLUSTER_KUBECONFIG_PATH>

For more flags and example about the command, you can use karmadactl promote --help.

Note: As the version upgrade of resources in Kubernetes is in progress, the apiserver of Karmada control plane cloud be different from member clusters. To avoid compatibility issues, you can specify the GVK of a resource, such as replacing deployment with deployment.v1.apps.