Azure Arc (currently in preview) allows attach and configure Kubernetes Clusters running anywhere (inside or outside of Azure). Once connected the clusters shows up in Azure portal and allows applying tags, policies like other resources. This brings simplicity and uniformity managing both cloud and on-premises resources in a single management pane (Azure Portal).
Azure Arc enabled Kubernetes is in preview. It’s NOT recommended for production workloads.
Following are the key scenarios where Azure Arc adds value:
- Connect Kubernetes running outside of Azure for inventory, grouping, and tagging.
- Apply policies by using Azure Policy for Kubernetes.
- Deploy applications and apply configuration by using GitOps-based configuration management.
- Use Azure Monitor for containers to view and monitor your clusters.
Connect an on-premises (or another cloud) clusters to Azure Arc
I have used the local Kubernetes (docker desktop) for this, however, the steps are identical for any other Kubernetes clusters. All you need is to run the following Azure CLI command from a machine where you can reach both the on-premises Kubernetes cluster and Azure.
az connectedk8s connect --name <ClusterName> --resource-group <ResourceGroup>
It will take moment and then the cluster is connected to Azure. We can see that in Azure portal:
Once we have the connected cluster to Azure – we can create/edit tags just like any other Azure resource. Which is awesome.
Same goes true for the Azure Policies – I can apply any compliance constraints to the cluster and monitor their compliance status in Azure Security center.
GitOps on Arc enabled Kubernetes cluster
The next piece of feature is interesting and can be very useful for many scenarios. This is much like infrastructure-as-code for your Kubernetes configuration (namespaces, deployments etc.). The idea is we define one or more git repository that keeps the desired state of the cluster (i.e. namespaces, deployments etc.) in Yaml files and Azure Resource Manager does the necessary actions to apply those desired state into the connected cluster. Microsoft Document describes how this works:
The connection between your cluster and one or more Git repositories is tracked in Azure Resource Manager as a sourceControlConfiguration extension resource. The sourceControlConfiguration resource properties represent where and how Kubernetes resources should flow from Git to your cluster. The sourceControlConfiguration data is stored encrypted at rest in an Azure Cosmos DB database to ensure data confidentiality.
The config-agent running in your cluster is responsible for watching for new or updated sourceControlConfiguration extension resources on the Azure Arc enabled Kubernetes resource, deploying a flux operator to watch the Git repository, and propagating any updates made to the sourceControlConfiguration. It is even possible to create multiple sourceControlConfiguration resources with namespace scope on the same Azure Arc enabled Kubernetes cluster to achieve multi-tenancy. In such a case, each operator can only deploy configurations to its respective namespace.
An example Git repository can be found in here: https://github.com/Azure/arc-k8s-demo. We can create the configuration from the Portal or via Azure CLI:
az k8sconfiguration create \
--name cluster-config \
--cluster-name AzureArcTest1 --resource-group AzureArcTest \
--operator-instance-name cluster-config --operator-namespace cluster-config \
--repository-url https://github.com/Azure/arc-k8s-demo \
--scope cluster --cluster-type connectedClusters
That’s it, We can see that in Azure Portal:
With that setup committing changes to the Git repository will now reflect in connected cluster.
Monitoring
Connected clusters can also be monitored with Azure Monitor for containers. It’s as simple as creating a Log analytics workspace and configuring the cluster to push metrics to it. This document describes the steps to enable monitoring.
I have seen some scenarios where people running on-premises (or in other cloud) clusters heavily using Prometheus and Grafana for monitoring clusters. Good news, we can get the same on Azure Arc enabled clusters. Once we have the metrics available in Azure Log Analytics, we can use Grafana to point to the workspace – it takes less than a minute and few button clicks (no-code configuration required).
Isn’t it awesome? Go, checkout Azure Arc for Kubernetes today.
Reverse Engineering 