Tutorial: Register and Configure Kubernetes Clusters with Azure Arc


This post is the third of a four-part series this week exploring Microsoft Arc, and how it can be used as a control plane to manage services. Check back each day through Thursday for subsequent installments: (

This article is the third part of the Azure Arc series, where we explore Arc enabled Kubernetes clusters. We will also configure GitOps to consistently deploy workloads across all the registered clusters.

We can attach and configure Kubernetes clusters inside or outside of Azure by using Azure Arc enabled Kubernetes. In the below screenshot, we have four clusters deployed in AKS, EKS, GKE, and bare metal with Azure Arc.

By the end of this tutorial, you will be able to attach an existing cluster and deploy the cluster configuration agent on it.

Setting up the Environment

Make sure you have a cluster running in GKE or another environment. Even clusters based on Minikube or Kind can be registered with Azure Arc.

For this tutorial, I am running a four-node cluster in GKE.

Start by registering the provider for your Azure subscription. Please be patient while the providers are registered. This may take a while.

We also need to register an extension for the az CLI to work with Arc enabled Kubernetes clusters. Run the below commands to register.

We also need the latest version of Helm installed. On macOS install it through Homebrew.

Finally, create a resource group for the registered clusters. Make sure the resource group is created in one of the supported regions — East US and West Europe.

We are now ready to register the cluster. Make sure your KUBECONFIG environment is pointing to the correct cluster.

Registering a Google Kubernetes Engine Cluster with Azure Arc

Let’s take a look at the namespaces in our cluster.

Currently, there are no workloads running in the cluster. We only have the default namespaces created during the cluster provisioning.

Registering the Kubernetes cluster with Azure Arc will result in a new namespace. Let’s initiate the registration by running the below command:

Let’s explore the namespaces and the resources created in the new namespace.

Azure Arc agents are deployed in the namespace, azure-arc. These agents maintain the connection between the Kubernetes cluster and the Azure Arc control plane.

We can list all the connected clusters with the below command:

You can also verify the registration through Azure Portal.

Deploying Applications and Configuration through GitOps

GitOps is the practice of declaring the desired state of Kubernetes configuration such as deployments, namespaces, and configmaps in a Git repository followed by polling and pull-based deployment model of these configurations to the cluster using an operator.

With Azure Arc, we can deploy applications and configurations to all the registered clusters by committing the manifests to a Git repository. An agent running in each of the registered clusters will automatically pull the manifests/specifications and applies them to the cluster.

We need a Git repository that will act as the single source of truth for all the participating clusters. For this tutorial, you can use https://github.com/janakiramm/arcdemo that has the popular Azure Vote sample application and an empty namespace called guestbook.

You may also try forking the repository and adding your own manifests to it. In that case, make sure the GitOps agent is pointed to your repository than the one shared above.

Ensure that your KUBECONFIG variable is pointing to the same GKE cluster that we configured earlier. Run the below command to configure the cluster with the GitOps agent.

In a few minutes, the cluster-config namespace will be running the GitOps agent that watches the GitHub repository for new commits.

You will also notice the addition of two namespaces — vote and guestbook which are applied from the specs stored at GitHub repository.

All the clusters registered with Azure Arc and running the cluster configuration agent will have these namespaces and the associated deployments and configuration.

Try making the changes to the manifests, and committing them to the repo. You will notice the changes automatically propagating to all the registered clusters without manual intervention. This is the power of GitOps-based deployment and configuration.

In the next part of this series, we will explore Azure Arc Data Services. Stay tuned!

Janakiram MSV’s Webinar series, “Machine Intelligence and Modern Infrastructure (MI2)” offers informative and insightful sessions covering cutting-edge technologies. Sign up for the upcoming MI2 webinar at http://mi2.live.

Feature image by ipicgr via Pixabay.

Source

Leave a Comment

Your email address will not be published. Required fields are marked *