Your hybrid cloud presence is growing exponentially. Isn’t everyone’s? As some operations go all-in on hyperscaler public clouds, others have found a renewed focus toward on-premises, highly specialized clusters built by in-house automation that have long been a staple in the Kubernetes ecosystem. Whether you are all-in on public clouds or have a suite of custom automation to generate the perfect cluster on-premises, Red Hat Advanced Cluster Management for Kubernetes auto-import functionality and automation tools can simplify your management experience.

The function was released in Red Hat Advanced Cluster Management for Kubernetes version 2.3 and supports custom automation with Red Hat Ansible, HashiCorp Terraform, BASH, and beyond. It can leverage auto-import in the YAML file or through cm-cli to quickly and easily import a new cluster into a Red Hat Advanced Cluster Management for Kubernetes hub cluster. Importing the clusters allows you to quickly automate application rollout, leverage policies for easier day-2 configurations, and collect cluster health metrics in a matter of minutes.

Importing a cluster with only oc

Imagine that we have an Ansible Playbook that creates a Red Hat OpenShift Container Platform cluster on-premises. This cluster will be perfect for our workload, and - oh - it just completed. Perfect timing!

Creating a secret

So we now have our new Red Hat OpenShift Container Platform cluster online. Let’s call it my-new-cluster. We also have the cluster kubeconfig. Our next step, while logged into our hub cluster, is to tell the hub cluster how to reach our new cluster. This task is as simple as creating a secret in the namespace that we choose. This Secret is only used during the import process and is automatically removed afterward. We’ll create a secret that is similar to the following example:

apiVersion: v1
kind: Secret
metadata:
 name: auto-import-secret
 namespace: my-new-cluster
stringData:
 autoImportRetry: 10
 kubeconfig: |-
   <the-full-contents-of-my-new-cluster-kubeconfig>
   ...
type: Opaque

There are some optional configuration changes that we can make. For example, we can change the target namespace and the number of retries that are attempted. In the next example, we’ll use a namespace made for this cluster named my-new-cluster with 10 retries.

Also, in case you don’t want to provide your kubeconfig information, you have the option of providing a server and token in the secret instead. See the following example:

apiVersion: v1
kind: Secret
metadata:
 name: auto-import-secret
 namespace: my-new-cluster
stringData:
 autoImportRetry: 10
 token: sha256~xxxxx <put-your-token-here)
 server: https://api.xxxx:6443 <my-new-cluster-api-url>
   ...
type: Opaque

Making our ManagedCluster

Protected with our secret, our hub cluster can now import our cluster. We just have to tell it what to call the new managed cluster, which namespace we would like to use for the ManagedCluster resource and related resources, and what management functions we want active on the cluster. Once again, we’ll run oc apply for the YAML, then the import will automatically begin. See the following example of possible YAML content that will complete the import:

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
 labels:
   cloud: auto-detect
   vendor: auto-detect
 name: my-new-cluster
spec:
 hubAcceptsClient: true
 leaseDurationSeconds: 60
---
apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
 name: my-new-cluster
 namespace: my-new-cluster
spec:
 clusterName: my-new-cluster
 clusterNamespace: my-new-cluster
 clusterLabels:
   cloud: auto-detect
   vendor: auto-detect
 applicationManager:
   enabled: true|false
   argocdCluster: true|false
 policyController:
   enabled: true|false
 searchCollector:
   enabled: true|false
 certPolicyController:
   enabled: true|false
 iamPolicyController:
   enabled: true|false

As you can see, we have lots of fun toggles to modify. For this case, we're just going to enable all of the add-ons. We also need to fill in our cluster name and cluster namespace, as we did previously. After we apply this YAML, the import should begin. In a few minutes, my-new-cluster will be fully managed.

Importing a cluster with cm-cli

The Red Hat Advanced Cluster Management for Kubernetes team’s automation-friendly community CLI, cm-cli, includes a simplified auto-import experience, alongside other handy cluster and kube-context management features.

Let’s assume we’ve created a second cluster using our Ansible playbook and call it my-new-cluster-2. This time, let’s import it with cm.

  1. Make sure you're logged in to your hub cluster.

  2. After you've logged in, we can import with a kubeconfig. See the following command:

    cm attach cluster my-new-cluster-2 --cluster-kubeconfig=<cluster-kubeconfig-file>

    In this case, we set our cluster name inline in the command to my-new-cluster-2, or use the API URL and token:

    cm attach cluster my-new-cluster-2 --cluster-server=<api-url> --cluster-token=<token>

    If you are curious, you can run cm attach cluster -h and customize the example values.yaml file to enable or disable specific add-ons. When you’re ready to import with a customized values.yaml file, run attach cluster as before, but include --values=<values-file-name>.

Detaching a managed cluster

You can also detach a managed cluster. Red Hat Advanced Cluster Management supports cleanly detaching and reattaching clusters easily through the oc and [cm-cli](https://github.com/open-cluster-management/cm-cli) tools.

  • You can detach with oc by running the following command:
oc delete managedcluster <managed-cluster-name>
  • You can detach it by using the cm CLI by running:
cm detach cluster <managed-cluster-name>

Categories

Kubernetes, How-tos, Red Hat Advanced Cluster Management, automation

< Back to the blog