Closely following the launch of Consul 1.8, the HashiCorp team has released a set of new hands-on tutorials for deploying and using the HashiCorp Consul service mesh capabilities on Kubernetes. The 1.8 launch focuses on enabling gradual adoption and expansion of a service mesh across a range of VM- and container-based environments via the use of mesh gateways and ingress and terminating gateways (released in beta). Although "mesh expansion" is clearly a popular theme in this release, the focus of the new tutorials hint at Kubernetes being an important deployment target for HashiCorp customers.
According to the Consul blog post, written by Neena Pemmaraju, director of product management at Hashicorp, Consul 1.8 adds features that “lower the barrier to entry for adopting a service mesh in heterogeneous environments.” It does this primarily by building upon the existing mesh gateway and introducing a number of new gateways that allow inbound and outbound integrations with a Consul service mesh deployment. This release also adds new Consul enterprise (commercial) features that allow identity-based authentication, and help fulfill compliance and regulatory requirements via audit logging.
Consul's mesh gateway feature enables routing of service mesh traffic between different Consul datacenters. As stated in the Consul documentation, these datacenters can reside in different clouds or runtime environments where general interconnectivity between all services in all datacenters is not feasible. The latest release of Consul sees the addition of a "WAN Federation over mesh gateway" feature.
Consul datacenters must be “WAN joined” in order for the successful operation of mesh gateways, as this allows all Consul server nodes to be able to talk to each other across datacenters. Previously this meant that all datacenters had to be connected using a VPN or other network tunneling mechanism. The new WAN federation over mesh gateway feature simplifies multi-cluster and multi-datacenter Consul federated datacenters by sending all cross-datacenter traffic through the mesh gateways.
Of the two new gateways introduced in beta, the ingress gateway aims to provide a “quick on-ramp path” to allow applications that reside outside the service mesh to communicate with services inside the mesh. Although implemented via Envoy proxy, this gateway does not appear to be a drop-in alternative for a full network edge proxy or API gateway.
Terminating gateways allow applications that reside within the service mesh to communicate with existing services outside of the mesh. They terminate Connect mTLS connections, enforce service access control intentions, and forward requests to the appropriate destination. As discussed by HashiCorp co-founder Mitchell Hashimoto in the Consul 1.8 launch live stream, potential external services include legacy systems or cloud-managed services, both of which may not allow the installation of a Consul agent that is required in order for compute nodes to join the Consul network and mesh.
The newly released Consul on Kubernetes hands-on tutorials provide Consul 1.8 feature highlights labs in addition to providing tutorials focused around the following topics: using the service mesh features and benefits of Consul; configuring and deploying Consul with the official Helm chart; deploying microservices into the Consul service mesh; and securing service-to-service communication with sidecar proxies and intentions.
The topics of mesh expansion and multi-cluster support are currently popular within the service mesh ecosystem. In a recent InfoQ podcast focusing on the Istio 1.5 release, Lin Sun and Neeraj Poddar discussed mesh expansion in the context of the future of service mesh technology. The Buoyant team has also recently released Linkerd 2.8 which features support for “simple, secure multi-cluster Kubernetes”.
Consul 1.8 is available for public beta now, with general availability to follow. The 1.8 changelog contains a detailed list of changes and bug fixes. The binaries can be downloaded via the releases website.