After the launch of Consul 1.8, the HashiCorp team published a set of new practical tutorials to deploy and use the service mesh capabilities of HashiCorp Consul on Kubernetes. The release of version 1.8 aims to enable the gradual adoption and expansion of a service mesh in a range of VM and container-based environments through the use of mesh gateways and ingress and gateway gateways. termination (released in beta). While “extending the mesh” is clearly a popular theme in this release, the focus of the new tutorials suggests that Kubernetes is 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 the adoption of a service mesh in heterogeneous environments”. It does this mainly by relying on the existing mesh gateway and the introduction of a number of new gateways that enable inbound and outbound integrations with a Consul service mesh deployment. This release also adds new corporate Consul (commercial) features that enable identity-based authentication and help meet compliance and regulatory requirements through audit logging.
Consul’s mesh gateway functionality enables the routing of service mesh traffic between different Consul data centers. As noted in the Consul documentation, these data centers can reside in different clouds or runtime environments where general interconnectivity between all services in all data centers is not possible. The latest version of Consul sees the addition of a “WAN Federation over mesh gateway” feature.
Consular data centers must be “WAN joins”For the proper functioning of the mesh gateways, as this allows all the nodes of the Consul server to be able to communicate with each other through the data centers. Previously, this meant that all data centers had to be connected using a VPN or other network tunneling mechanism. The new mesh WAN federation gateway feature simplifies multi-cluster and multi-data center Consul federated data centers by sending all traffic between data centers through mesh gateways.
Among the two new gateways introduced in beta, the entrance gateway aims to provide a “fast path” to allow applications that reside outside the service mesh to communicate with services inside the mesh. Although implemented via Sent proxy, this gateway does not seem to be an alternative for a complete network edge proxy or API gateway.
Finish the gateways allow applications that reside in the service mesh to communicate with existing services outside the mesh. They terminate Connect mTLS connections, apply access control to services intentions, and forward the requests to the appropriate destination. As discussed by the co-founder of HashiCorp Mitchell Hashimoto in the Consul 1.8 launches live streaming, potential external services include legacy systems or cloud-managed services, both of which may not allow the installation of a Consular officer which is required for the compute nodes to join the consular network and the mesh.
The newly released Kubernetes Hands-On Tutorials Consul provide practical work on the features of Consul 1.8 in addition to providing tutorials focusing on the following topics: using the features and benefits of Consul’s service mesh; configure and deploy Consul with the official Helm charter; the deployment of microservices in the Consul service network; and secure service-to-service communication with proxies and sidecar intentions.
The topics of mesh expansion and multi-cluster support are currently popular within the service mesh ecosystem. In a recent InfoQ podcast dedicated to the Istio 1.5 version, Lin Sun and Neeraj Poddar discussed mesh expansion in the context of the future of service mesh technology. The Buoyant team also recently published Linkerd 2.8 which supports “Simple and Secure Multi-Cluster Kubernetes”.