Tools such as Kubernetes go a long way to simplifying the process of building distributed applications at scale. But they’re only part of the story, offering ways to replicate containerized microservices between host systems. If we’re to get the benefits of an abstracted data-center-level operating system, then we need to consider how we manage networking at scale, especially when that scale is the size of a massive public cloud like Azure.
One answer to the problem is the service mesh. Best thought of as an abstraction of the control plane of a software-defined network, a service mesh is a way of building a software layer that manages the interprocess communication necessary to support your code.
A well-designed service mesh is a lot more than a simple networking layer. It supports most of the functions you find in network appliances, like load-balancing and encryption, as well as tools for supporting modern systems management models, like observability. There’s support for critical distributed application functions, allowing service discovery so that different application tiers can scale at different rates while still allowing the application to function.
By implementing all these features in sidecar modules, service meshes provide many of the missing features needed to deliver applications on Kubernetes and across clouds. You can build distributed applications without a service mesh, but you’ll be reinventing the wheel. With Azure focusing much of its distributed application development model around Kubernetes, there’s an increasing need for service meshes in Microsoft’s cloud.
Azure and service meshes
Azure offers a service mesh in the shape of its own Service Fabric Mesh, but it’s focused on Microsoft’s Service Fabric platform. That’s fine if you’re building apps that only run on Azure, but if you want multicloud support and service portability, you’re better off choosing one of many open source service meshes that target Kubernetes.
One option is Consul, which is built and maintained by HashiCorp. Microsoft has been working with HashiCorp to define a standard for service mesh interfaces, with a common API that’s implementation agnostic, so it makes sense to use it alongside Azure Kubernetes applications and in the AKS (Azure Kubernetes Service).
Set up HashiCorp Consul on Azure
Setting up Consul in AKS is a relatively simple process. You need an up-to-date AKS cluster running Kubernetes 1.12 or better, as Consul 1.5 has been tested on more recent versions of Kubernetes. Consul uses Helm to manage its install, so once your AKS instance is up, get Helm up and running.
Installing Consul requires first cloning the HashiCorp GitHub repo for the Helm charts. A local copy is essential, as you need to set up the appropriate configuration files for your AKS instance. These configure failover replicas for resilience and ensure that your Kubernetes cluster uses Consul for service discovery. It’s important to ensure that Consul runs on Linux nodes, even if you’re using it to manage Windows Server nodes in the same AKS cluster.
Once the Helm chart runs and installs the Consul services, you can use the Kubernetes command line kubectl to check that they’re running in your cluster, checking both services and pods. Consul runs its own web server for its management UI, and you need to give your local PC a direct secure connection to Consul via Kubernetes before opening the management UI in your browser.
At the heart of a Consul install is the Consul agent. This runs as server or client, with each install needing at least one server. Clients register services and check health, and forward queries to the servers. You will deploy one client per node and at least three servers for reliability. Consul’s Connect service mesh runs on top of this architecture, using sidecar proxies to link your services and manage traffic. Services don’t need to be aware of Consul, making it easy to add it to existing applications. If you decide to standardize on it, then you can start writing Consul-aware code.
Adding service definitions to Consul
Service definitions in the Consul proxies are written in JSON and can be edited on the fly, reconfiguring proxies when reloaded. Proxies can be used to expose external IP ports, binding to internal ports, for example handling encrypted connections. Once Consul proxies are in place they use “intentions,” a set of access control lists to manage service-to-service connections. To control services more fully Consul uses a key value store to dynamically configure applications, using agents to load data into the store. As well as a command line management tool, Consul’s web user interface runs on its servers and gives you a graphical tool for managing nodes and services, as well as managing access control lists and intentions.
There’s a lot in Consul, and it can take time to configure and get running. If you don’t want to spend time implementing Consul, then you can take advantage of an upcoming managed service from HashiCorp. Currently in private preview, it simplifies the process of deploying the infrastructure needed to support Consul in your applications, while speeding up deployment and reducing your management overhead.
Consul as a Service with Azure Managed Applications
HashiCorp’s Consul Service Azure implementation is being built on top of Azure’s Managed Applications service. This is designed for service providers and ISVs to deliver services through the Azure Marketplace or Azure Service Catalog. Users can subscribe to a service, with all servicing delivered by the service provider. There’s no need to maintain or update the services you use, and more importantly, no need to build the skill set needed to handle that maintenance yourself.
To use Consul in your Kubernetes applications on Azure, you need a HashiCorp account as well as an Azure account. Once you’re ready, you implement your Consul service through the Azure Portal and pay for it with your Azure subscription.
Initial set up is a matter of adding a HashiCorp Consul Service to an Azure resource group from the Marketplace. Once you’ve entered your Azure region, your chosen version, and your network details, add the Consul service to your subscription. This provisions the servers, ready to use in your apps and ready to manage through the Consul web UI inside the Azure Portal.
There’s no need to learn anything new; if you’ve implemented Consul on your own network or have installed it on top of an existing Azure infrastructure there’s no difference in how you configure and use a Consul service mesh.
Although the Consul on Azure service is currently in private beta, it’s an example of how Microsoft is expanding Azure’s distributed computing offerings without having to add its own tools. Having a choice of service meshes is important, and giving vendors an opportunity to use the Azure Marketplace to deploy managed services makes it easier for both vendors and developers to take advantage of these services.