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
.
-
Make sure you're logged in to your hub cluster.
-
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 examplevalues.yaml
file to enable or disable specific add-ons. When you’re ready to import with a customizedvalues.yaml
file, runattach 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