Azure Make new Cluster Self-Managed
Konvoy deploys all cluster lifecycle services to a bootstrap cluster, which then deploys a workload cluster. When the workload cluster is ready, move the cluster lifecycle services to the workload cluster, which makes the workload cluster self-managed. This section describes how to make a workload cluster self-managed.
This page contains instructions on how to make your cluster self-managed. This is necessary if there is only one cluster in your environment, or if this cluster should become the Management cluster in a multi-cluster environment.
If you already have a self-managed or Management cluster in your environment, skip this page.
Make the new Kubernetes cluster manage itself
Deploy cluster lifecycle services on the workload cluster:
CODEdkp create capi-components --kubeconfig ${CLUSTER_NAME}.conf
If your environment uses HTTP/HTTPS proxies, you must include the flags
--http-proxy
,--https-proxy
, and--no-proxy
and their related values in this command for it to be successful. More information is available in Configuring an HTTP/HTTPS Proxy.The output is similar to:
CODE✓ Initializing new CAPI components
Move the Cluster API objects from the bootstrap to the workload cluster:
The cluster lifecycle services on the workload cluster are ready, but the workload cluster configuration is on the bootstrap cluster. The
move
command moves the configuration, which takes the form of Cluster API Custom Resource objects, from the bootstrap to the workload cluster. This process is also called a Pivot.CODEdkp move capi-resources --to-kubeconfig ${CLUSTER_NAME}.conf
CODE✓ Moving cluster resources You can now view resources in the moved cluster by using the --kubeconfig flag with kubectl. For example: kubectl --kubeconfig=azure-example.conf get nodes
To ensure only one set of cluster lifecycle services manages the workload cluster, Konvoy first pauses reconciliation of the objects on the bootstrap cluster, then creates the objects on the workload cluster. As Konvoy copies the objects, the cluster lifecycle services on the workload cluster reconcile the objects. The workload cluster becomes self-managed after Konvoy creates all the objects. If it fails, the move
command can be safely retried.
3. Wait for the cluster control-plane to be ready:
kubectl --kubeconfig ${CLUSTER_NAME}.conf wait --for=condition=ControlPlaneReady "clusters/${CLUSTER_NAME}" --timeout=20m
cluster.cluster.x-k8s.io/azure-example condition met
4. Use the cluster lifecycle services on the workload cluster to check the workload cluster status:
After moving the cluster lifecycle services to the workload cluster, remember to use Konvoy with the workload cluster kubeconfig.
dkp describe cluster --kubeconfig ${CLUSTER_NAME}.conf -c ${CLUSTER_NAME}
NAME READY SEVERITY REASON SINCE MESSAGE
Cluster/azure-example True 55s
├─ClusterInfrastructure - AzureCluster/azure-example True 67s
├─ControlPlane - KubeadmControlPlane/azure-example-control-plane True 55s
│ ├─Machine/azure-example-control-plane-67f47 True 58s
│ ├─Machine/azure-example-control-plane-7pllh True 65s
│ └─Machine/azure-example-control-plane-jtfgv True 65s
└─Workers
└─MachineDeployment/azure-example-md-0 True 67s
├─Machine/azure-example-md-0-f9cb9c79b-6nsb9 True 59s
├─Machine/azure-example-md-0-f9cb9c79b-jxwl6 True 58s
├─Machine/azure-example-md-0-f9cb9c79b-ktg7z True 59s
└─Machine/azure-example-md-0-f9cb9c79b-nxcm2 True 66s
5. Remove the bootstrap cluster, as the workload cluster is now self-managed:
dkp delete bootstrap --kubeconfig $HOME/.kube/config
✓ Deleting bootstrap cluster
Known Limitations
Konvoy supports moving only one set of cluster objects from the bootstrap cluster to the workload cluster, or vice-versa.
Konvoy only supports moving all namespaces in the cluster; Konvoy does not support migration of individual namespaces.