Make the AWS 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

1. Deploy cluster lifecycle services on the workload cluster:

   CODE

   dkp 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 resembles:

   CODE

   ✓ Initializing new CAPI components

    

2. 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.

   CODE

   dkp move capi-resources --to-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 resembles:

   CODE

    ✓ Moving cluster resources
   You can now view resources in the moved cluster by using the --kubeconfig flag with kubectl. For example: kubectl --kubeconfig=aws-example.conf get nodes

    

   NOTE: 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:

   CODE

   kubectl --kubeconfig ${CLUSTER_NAME}.conf wait --for=condition=ControlPlaneReady "clusters/${CLUSTER_NAME}" --timeout=20m

    

   CODE

   cluster.cluster.x-k8s.io/aws-example condition met

    

4. 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 Konvoy with the workload cluster kubeconfig.
   

   CODE

   dkp describe cluster --kubeconfig ${CLUSTER_NAME}.conf -c ${CLUSTER_NAME}

    

   CODE

   NAME                                                              READY  SEVERITY  REASON  SINCE  MESSAGE
   Cluster/aws-example                                             True                     109s
   ├─ClusterInfrastructure - AWSCluster/aws-example                True                     112s
   ├─ControlPlane - KubeadmControlPlane/aws-example-control-plane  True                     109s
   │ ├─Machine/aws-example-control-plane-55jh4                     True                     111s
   │ ├─Machine/aws-example-control-plane-6sn97                     True                     111s
   │ └─Machine/aws-example-control-plane-nx9v5                     True                     110s
   └─Workers
     └─MachineDeployment/aws-example-md-0                          True                     114s
   	├─Machine/aws-example-md-0-cb9c9bbf7-hcl8z                  True                     111s
   	├─Machine/aws-example-md-0-cb9c9bbf7-rtdqw                  True                     111s
   	├─Machine/aws-example-md-0-cb9c9bbf7-t894m                  True                     111s
   	└─Machine/aws-example-md-0-cb9c9bbf7-td29r                  True                     111s
   

    

5. Remove the bootstrap cluster, as the workload cluster is now self-managed:

   CODE

   dkp delete bootstrap

    

   CODE

    ✓ Deleting bootstrap cluster

Install and Log in to the Kommander UI

You can now proceed to installing the UI with Kommander and applications. After installation, you will be able to log in to the UI to explore it.

DKP Install Configuration

You can configure the Kommander component of DKP during the initial installation, and also post-installation using the Kommander CLI.

The following explains how to run DKP on top of an air-gapped DKP cluster installation with catalog applications.

Depending on your configuration, there are three different ways you can install DKP to an air-gapped environment.
Ensure you follow the correct procedure for your configuration and license type, and ignore the other sections that do not pertain to your environment:

Essential:

• Kommander in an Air-gapped Environment

• Kommander in Air-gapped with DKP Insights

Enterprise:

• Install Air-gapped Kommander with DKP Catalog Applications

• Install Air-gapped Kommander with DKP Insights and DKP Catalog Applications

Known Limitations

• Before making a workload cluster self-managed, be sure that its control plane nodes have sufficient permissions for running Cluster API controllers. See IAM Policy Configuration.

• 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.