Announcing HashiCorp Consul 1.11 - Now Generally Available

We are pleased to announce general availability of HashiCorp Consul 1.11. This release represents yet another step forward in our effort to help organizations run Consul to reduce operational complexity and seamlessly integrate service mesh into their application workflows. Consul 1.11 contains a number of important new features, including multi-tenancy with administrative partitions, a new Consul Kubernetes CLI, and HashiCorp Vault integration on Consul Kubernetes.

»Multi-Tenancy with Administrative Partitions (Enterprise)

Two major challenges organizations face when scaling a service mesh are:

1. Increased operational complexity associated with deploying and managing a service mesh across multiple tenants. This can become unmanageable for operators when there are dozens, if not hundreds, of Kubernetes clusters and virtual machines deployed within an organization.
2. Lack of organizational autonomy when providing resources such as networking, namespaces, and services to individual teams.

Typically, operators would have to manage separate control planes for each Kubernetes cluster or virtual machines group, as shown in the architecture below:

This approach is not scalable for two reasons:

1. It requires too much coordination and compute at scale.
2. It’s burdensome for operations teams to manage.

Scaling a more complex architecture, like the one illustrated below, requires enormous amounts of coordination and compute resources, often creating more overhead than operations teams can easily manage.

Consul 1.11 multi-tenancy with admin partitions allows enterprises to provide a shared service-networking solution for multiple tenants — across Kubernetes and VM deployments — within a single Consul datacenter. To support various deployment patterns, admin partitions enable multiple Kubernetes clusters from different tenants to share a single Consul control plane. Admin partitions also help enterprises improve operational efficiency while providing individual teams with organizational autonomy and isolation when managing their services.

This diagram illustrates a single Consul control plane for multiple Kubernetes clusters and VMs.

Consul 1.11 multi-tenancy with admin partitions allows multiple namespaces with the same name to exist independently of each other. Access control lists (ACLs) are augmented to allow a partition administrator full control over their local resources without needing operator permissions for the entire cluster. That helps operations teams to better scale and manage complex architectures, as shown below:

»Introducing the Consul Kubernetes CLI

Consul 1.11 also provides a first-class Consul Kubernetes command line interface (CLI) for a new way of interacting with Consul when deploying on Kubernetes. The primary goal for the Consul Kubernetes CLI is to lower the barrier to adoption for developers who want to use a Consul service mesh on Kubernetes.

Prior to version 1.11, Consul supported only a Helm install-and-uninstall flow. Although Helm provides a fairly easy install and uninstall mechanism for Kubernetes users, a Helm chart can expose an overwhelming number of options. As an alternative, a custom-built CLI provides a more curated experience for those who primarily want to try out Consul service mesh as quickly as possible. The Consul Kubernetes CLI provides a simpler user experience, reduces the number of steps to get a deployment running, and enables preset configurations for application and Kubernetes teams.

Previously, in order to customize your installation, you had to create a values.yaml file and provide config options as described in the Helm Chart Configuration docs, as shown here:

With the Consul Kubernetes CLI, installing Consul on Kubernetes is as simple as:

In addition, there are new preset options to install Consul on Kubernetes in a pre-configured demo or secure setting:

For more information on how to get started with our Consul Kubernetes CLI please see the Consul K8s CLI Reference in our documentation.

»Utilizing Vault as a Secrets Backend for Consul on Kubernetes (OSS)

Consul 1.11 enables users to set Hashicorp Vault as the native secrets backend instead of using Kubernetes secrets, which relies on base64 encoding by default and does not use encryption. Integration with Vault provides a secure and seamless workflow for Consul on Kubernetes users, by making it easier to leverage Vault for storing Consul on Kubernetes secrets and for issuing certificates for Consul components that are deployed onto Kubernetes. This provides a more comprehensive zero trust networking solution for customers and practitioners who are adopting Consul service mesh on Kubernetes.

Now, using the Consul on Kubernetes Helm chart, the Vault secrets backend can be enabled so that Vault is used as the secrets backend of choice:

The Helm chart offers an improved user experience for enabling Vault as the Connect CA, and also now provides the ability to retrieve a stored gossip encryption key from Vault, and issue a server certificate for the Consul servers from the Vault PKI engine. For more details please visit: https://www.consul.io/docs/k8s/installation/vault to learn how to get started.

»Next Steps

We are excited for users to try this release of Consul and further expand their service mesh implementations. The Consul 1.11 release includes enhancements for all types of users leveraging Consul for service discovery and service mesh, across both containerized and non-containerized environments.

Our goal with Consul is to provide an enterprise-ready, consistent control plane to discover and securely connect any application. For more information about Consul, please visit the Consul documentation. To get started with Consul 1.11, please download operating system binaries from our release page or install the latest v0.39.0 Helm chart that supports Consul 1.11 for Kubernetes. Multi-tenancy with admin partitions is part of the Consul Enterprise binaries, and you can get started with a free Consul Enterprise trial here.