Make the New GCP Cluster Self-Managed
DKP 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.
Before starting, ensure you create a workload cluster as described in Create a New GCP Cluster.
Make the new Kubernetes cluster manage itself
Follow these steps:
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 Configure HTTP Proxy.
The output resembles: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=gcp-example.conf get nodes
NOTE: To ensure only one set of cluster lifecycle services manages the workload cluster, DKP first pauses reconciliation of the objects on the bootstrap cluster, then creates the objects on the workload cluster. As DKP copies the objects, the cluster lifecycle services on the workload cluster reconcile the objects. The workload cluster becomes self-managed after DKP creates all the objects. If it fails, the
move
command can be safely retried.Wait for the cluster control-plane to be ready:
CODEkubectl --kubeconfig ${CLUSTER_NAME}.conf wait --for=condition=ControlPlaneReady "clusters/${CLUSTER_NAME}" --timeout=20m
CODEcluster.cluster.x-k8s.io/gcp-example condition met
Use the cluster lifecycle services on the workload cluster to check the workload cluster status:
NOTE: After moving the cluster lifecycle services to the workload cluster, remember to use DKP with the workload cluster kubeconfig.CODEdkp describe cluster --kubeconfig ${CLUSTER_NAME}.conf -c ${CLUSTER_NAME}
CODENAME READY SEVERITY REASON SINCE MESSAGE Cluster/gcp-example True 14s ├─ClusterInfrastructure - GCPCluster/gcp-example ├─ControlPlane - KubeadmControlPlane/gcp-example-control-plane True 14s │ ├─Machine/gcp-example-control-plane-6fbzn True 17s │ │ └─MachineInfrastructure - GCPMachine/gcp-example-control-plane-62g6s │ ├─Machine/gcp-example-control-plane-jf6s2 True 17s │ │ └─MachineInfrastructure - GCPMachine/gcp-example-control-plane-bsr2z │ └─Machine/gcp-example-control-plane-mnbfs True 17s │ └─MachineInfrastructure - GCPMachine/gcp-example-control-plane-s8xsx └─Workers └─MachineDeployment/gcp-example-md-0 True 17s ├─Machine/gcp-example-md-0-68b86fddb8-8glsw True 17s │ └─MachineInfrastructure - GCPMachine/gcp-example-md-0-zls8d ├─Machine/gcp-example-md-0-68b86fddb8-bvbm7 True 17s │ └─MachineInfrastructure - GCPMachine/gcp-example-md-0-5zcvc ├─Machine/gcp-example-md-0-68b86fddb8-k9499 True 17s │ └─MachineInfrastructure - GCPMachine/gcp-example-md-0-k8h5p └─Machine/gcp-example-md-0-68b86fddb8-l6vfb True 17s └─MachineInfrastructure - GCPMachine/gcp-example-md-0-9h5vn
Remove the bootstrap cluster, as the workload cluster is now self-managed:
CODEdkp delete bootstrap --kubeconfig $HOME/.kube/config ✓ Deleting bootstrap cluster
Known Limitations
Be aware of these limitations in the current release of DKP.
DKP only supports moving all namespaces in the cluster; DKP does not support migration of individual namespaces.