Getting started with Azure Arc and Kubernetes

Microsoft announced Azure Arc, an application-centric tool for deploying and managing applications running on virtual infrastructures, towards the end of 2019. Since then it’s rolled out two waves of product previews: the first targeted at virtual machines running on-premises and in the cloud; the second, a more recent release, at applications running on Kubernetes clusters.

Adding Arc to Kubernetes

That latest release is perhaps the most interesting, as it brings aspects of Microsoft’s cloud-native Kubernetes tools to Kubernetes running anywhere. Although the management aspects of Azure Arc are comparable to Google’s Anthos, it’s a much less prescriptive approach to managing Kubernetes. Instead of a complete managed Kubernetes distribution, Azure Arc is intended to work with any Cloud Native Computing Foundation-certified recent release, so you can manage applications running on existing installs without significant changes to the way your underlying infrastructure works.

It’s easy enough to deploy Azure Arc on your Kubernetes installs yourself. Microsoft is working with several partners to simplify integration with common commercial Kubernetes releases. These include RedHat’s OpenShift, Canonical’s Kubernetes distribution, and Rancher Labs’ tools and distributions. With out-of-the-box support for popular tools like these, it should be easy to switch to Arc to manage your applications while still working with familiar platforms and management tools.

Automating application deployment at scale across public and private clouds

One important aspect of the Azure Arc Kubernetes integration is its support for CI/CD (continuous integration/continuous development)-driven application development and management, using git-based techniques to drive application deployment directly from your source control system. With Helm 3 adding support for the Open Container Initiative’s open registry specification, you now have the option to write your code, merge it into your main branch, and automatically deploy all your assets to a single registry before automatically deploying the update via Azure Arc.

Building on GitOps processes like these makes Azure Arc a key element in automating your Kubernetes application deployments and management. If you’re building cloud-native code, the stateless nature of container-based distributed applications should ensure that Arc will be capable of deploying updated application infrastructures without affecting users or the underlying physical and virtual infrastructures, up to and including Kubernetes itself.

Getting started with Azure Arc-enabled Kubernetes

Microsoft has now released a public preview of what it’s calling Azure Arc-enabled Kubernetes. It’s not ready for production, but it’s worth exploring how you might use it with your applications. Like the Arc’s virtual machine support, you need an existing Kubernetes infrastructure to use the Arc service, with Arc agents running in each managed cluster.

Agents run in their own namespace, so they don’t conflict with your running code or need to be deployed as part of a cluster by the cluster administrator. Once they’re in place they connect to Azure to listen for configuration information, delivering logs for analysis by Azure-hosted application monitoring tools. As Arc-managed Kubernetes clusters can be anywhere, Microsoft uses its Cosmos DB distributed database to store and manage data.

Initial setup currently requires some Kubernetes expertise, as you’re working with a live cluster using administrator privileges. A managed cluster needs to support Helm 3 and have the Azure CLI installed. Once the CLI is up and running, download, install, and run the Azure Arc connectedk8s and k8sconfiguration extensions. Microsoft provides a list of TCP ports and end points that need to be opened in your firewall for Azure Arc to operate.

The next step is to register your cluster with Azure Arc using the Azure CLI before attaching your Azure Arc deployment to an Azure Resource Group. Microsoft provides scripts that test connectivity and then deploy Azure Arc agents into your cluster via Helm 3. You can check the azure-arc namespace to see if the agents deployed properly; you should see a series of pods running a mix of different operators. Azure Arc’s agents deploy as Kubernetes operators, handling configuration, monitoring, and identity.

Once the operators are running, Kubernetes infrastructure administrators can concentrate on ensuring that the underlying physical or virtual infrastructure has the appropriate resources for any applications. Application administrators can use the Azure portal to manage applications and a git instance to manage application deployments.

With Azure Arc in place, you can shift to an appops model, using git to host application configuration files and the application repositories. Applications engineers can monitor running applications via the Azure Portal, while the git repositories contain YAML configurations for both base-level Kubernetes cluster configuration and for application-specific cluster details. Using these configurations you can apply standard configurations to all your managed clusters, setting up global roles and namespaces, and then manage applications separately with their own YAML for their own roles and namespaces, and finally Helm charts for application deployments.

Using a GitOps model, application development and testing are managed through git repositories, using separate branches for development and test, with a final production branch for code that’s ready for use. You can configure Azure Arc to deploy new releases on a pull request to the deployment branch, using other Arc instances for test and development Kubernetes clusters.

Azure Arc for software and service providers

One of the more interesting aspects of Azure Arc is its planned integration into Microsoft’s at-scale Azure management tool: Azure Lighthouse. Intended for service providers that need to manage their customers’ Azure instances, it’s a tool that lets subscribers manage many different Azure tenants from the same control panel.

Adding Azure Arc to the Lighthouse suite of tools lets you manage the applications and application infrastructures running in those Azure tenants. Although much of Lighthouse’s tools are targeted at managed service providers, it can be an option for IT departments that are working with Azure at scale across multiple geographies and regions. Using Azure Arc to manage application definitions for the entire organization, the combination of it and Azure Lighthouse ensures that instances of corporate applications will be the same wherever they’re being used.

The combination of Arc and Lighthouse gives you an interesting alternative approach to delivering packaged software offerings through the Azure Marketplace. With Lighthouse as a management layer on top of Arc, you could conceivably use it to build, deploy, and manage complex distributed application solutions that could be sold directly through Azure. It’s not quite the CNAB (cloud-native application bundle) package model and would require more in the way of manual setup, but for complex solutions, it may well be a better approach than the relatively new CNAB package definitions.

Azure Arc isn’t only for consistency across software deployments. It gives you a set of Kubernetes tools for consistent operations. By integrating into the Azure portal, Azure becomes the management plane for your application. You can use tools such as Azure Policy to ensure consistency across all your deployments, whether in the public cloud or on-premises.

With Azure Stack becoming the basis for Microsoft’s edge compute model, Azure Arc should be able to manage deployment and operations across hundreds and even thousands of Kubernetes instances, ensuring every deployment operates the same way, with Azure Policy managing not only your application but also the resources it uses. Separating physical and virtual infrastructure from application infrastructure makes even more sense in a highly distributed environment like this where traditional systems and application management models are unable to scale. To work with code in this new world, we’re going to need more tools like Azure Arc-enabled Kubernetes, and the sooner we have them, the better.