Consul 1.6: Layer 7 Traffic Management and Mesh Gateways

As organizations continue to scale with microservice-based or cloud-native applications, the number of services, the volume of service-to-service traffic, the complexity of service dependency, and the rate of change in services and underlying infrastructures is a lot higher. Traditional approaches to service networking with network middleware lead to complex network topologies and cannot handle the dynamic nature of microservices.

Consul service mesh is designed to simplify microservice networking by shifting routing, authorization, and other networking functionalities from centralized middleware to the endpoints distributed across the network using software proxies, such as Envoy. Consul 1.6 greatly enhanced its service mesh capabilities, including the following key features:

HTTP path-based traffic routing

Consul now supports advanced path-based routing via sidecar proxies. Traffic can be routed to different upstream services based on the HTTP request path, allowing simplified delivery without the need for centralized load balancers.

Traffic shifting / splitting

You can now configure weight-based routing via sidecar proxies. Traffic can be gradually migrated from a group of services to another group. Traffic shifting makes it easy to implement microservice testing and deployment strategies, such as canary deployment.

Mesh Gateways / Multi-cluster gateways

Securely and transparently route traffic across different network environments, without needing to worry about overlapping network addresses or maintaining VPN tunneling. Mesh gateways provide a “flat” network to users without the need for complex routing rules and network configuration.

You can also use Mesh Gateways and its service resolver for secure service failover between different datacenters in different regions, much like prepared queries but with an eye toward the service mesh use case rather than the service discovery use case where you'd use prepared queries.

In this webinar, HashiCorp developer advocate Nic Jackson will demonstrate these new features and show examples of how to simplify service networking with Consul service mesh.

You can follow along with the code in this GitHub repo.

Outline

0:00 — Introduction to Consul and service mesh

12:00 — Introduction to central configuration in Consul

15:00 — Demo: HTTP path-based traffic routing

25:10 — Demo: Traffic shifting / splitting

32:38 — Demo: Mesh Gateways - Multi-cluster gateways

43:20 — Demo: Service failover (cross-cluster, cross-cloud)

49:26 — Q&A

Q&A

• Could / Should Consul replace NGINX as a proxy or is it still better to use Consul Template and replace config files? (Thinking about Consul agents and sidecar) NGINX works as a good north-south (ingress) gateway, but Consul can handle all internal, east-west traffic between services on your network.

• Would there be any issues expected if one were to run a Consul cluster to be used as a stroage backend for Vault via Connect? Theoretically, no.

• How does service resolver compare with prepared queries? Which is the best approach? Is this service resolver going to be available on the Consul Terraform provider? The TF provider updates are coming. In a service mesh use case, use service resolver. In service discovery, use prepared queries.

• Do Consul intentions replicates to second dc for the mesh gateways to allow connections? Yes

Slides