 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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.
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.
az provider register --namespace Microsoft.Kubernetes
az provider register --namespace Microsoft.KubernetesConfiguration
We also need to register an extension for the az CLI to work with Arc enabled Kubernetes clusters. Run the below commands to register.
az extension add --name connectedk8s
az extension add --name k8sconfiguration
We also need the latest version of Helm installed. On macOS install it through Homebrew.
brew install helm
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.
az group create --name arc-demo-clusters -l WestEurope
We are now ready to register the cluster. Make sure your KUBECONFIG environment is pointing to the correct cluster.
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:
az connectedk8s connect \ --name arc-demo-gke \ --resource-group arc-demo-clusters
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:
az connectedk8s list -o table
You can also verify the registration through Azure Portal.
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.
az k8sconfiguration create \ --name cluster-config \ --cluster-name arc-demo-gke \ --resource-group arc-demo-clusters \ --operator-instance-name cluster-config \ --operator-namespace cluster-config \ --repository-url https://github.com/janakiramm/arcdemo \ --scope cluster \ --cluster-type connectedClusters
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.
