HashiCorp Consul 1.6: Dynamic Traffic Management and Gateways

We are excited to announce the beta release of HashiCorp Consul 1.6. This release supports a set of new features to enable Layer 7 routing and traffic management. It also delivers a new feature, mesh gateway, that transparently and securely routes service traffic across multiple regions, platforms, and clouds.

A year ago, Consul 1.2 introduced our service mesh solution, Consul Connect. Our initial release focused on solving security challenges at Layer 4 and leveraging Consul’s service discovery feature to provide service-to-service identity and trust. Since that point, Connect has added support for additional proxies (Envoy), L7 observability, a simpler way to enable Consul ACLs and TLS, and platform integrations with Kubernetes.

Today we're proud to announce a major milestone in realizing our vision for service mesh. With the release of Consul 1.6 we are adding features for traffic management at Layer 7 and enabling transparent, cross-network connectivity with Mesh Gateways. Of course, these features work across platforms, with continued first-class support for Kubernetes and easy deployment across more traditional environments on any cloud or private network. This delivers on HashiCorp's goal for Consul to enable multi-cloud service networking.

»Additional Layer 7 Features

In Consul 1.5 we announced support for Layer 7 observability using Consul Connect and Envoy. This is made possible by configuring Envoy sidecars that proxy all traffic in and out of their associated services. The proxies form a data plane that transports requests, while Consul Connect acts as a control plane that configures all the proxies and responds to dynamic changes in your workloads and network.

Starting in that 1.5 release, Consul users could implement observability at Layer 7 (connections, bytes transferred, retries, timeouts, open circuits, and request rates, response codes) by writing configuration entries that would configure the sidecar proxies to export metrics and tracing data.

Consul 1.6 introduces additional configuration entry types that enable advanced traffic management patterns for service-to-service requests. The additional configuration entry kinds, service-resolver, service-splitter, and service-router, enable increased reliability with advanced service failover, and deployment patterns such as HTTP path-based routing, and traffic shifting.

Users can create configuration entries in HashiCorp Configuration Language (HCL) or JSON, and interact with them via the Consul CLI or API.

»Example

Below is an example set of configurations that resolve a Consul service discovery query and return a different service based on HTTP path, as well as a canary version of that same service, all utilizing the Consul agent caching system so subsequent requests resolve nearly instantaneously.

A request to a service named web in the below example can route a subset of requests based on HTTP path.

Kind = "service-router"
Name = "web"
Routes = [
  {
    Match {
      HTTP {
        PathPrefix    = "/admin"
      }
    }
    Destination {
      Service = "admin"
      PrefixRewrite = "/"
    },
  }
  ...
]

This can then send a percentage of traffic to a subset of services.

Kind = "service-splitter"
Name = "billing-api"
Splits = [						
    {
        Weight        = 10
        ServiceSubset = "v2"						
    }, 
    {						
        Weight        = 90
        ServiceSubset = "v1"
    },   					
]

And finally use custom discovery rules that utilize the Consul API filter language to query on Consul service data such as Service metadata to select a specific version of the service, as shown below.

Kind = "service-resolver"
Name = "admin"
DefaultSubset = "v1"
Subsets = {
  "v1" = {
    Filter = "Service.Meta.version == 1"
  },
  "v2" = {
    Filter = "Service.Meta.version == 2"
  },
}

Consul client agents can automatically configure and reconfigure proxies without redeploying them. Because of this centralized configuration frees operators from the burden of managing a mix of service configuration files, load balancer configs, and application-specific routing definitions. Consul Connect gives centralized control of sidecar proxies to apply advanced traffic management patterns.

Learn more in our docs on the L7 Traffic Management page.

»Mesh Gateway

As organizations distribute their workloads across multiple platforms, data centers, and clouds, the underlying network becomes increasingly fragmented and complex. Services in their respective environments run on independent networks, leading to multiple network silos. Managing connections between multiple network environments is challenging. It requires careful network planning to avoid overlapping IP addresses and typically relies on point-to-point VPN, networking peering, or private links. These approaches add operational overhead to manage and troubleshoot.

Mesh gateways are Envoy proxies at the edge of a network, which enable services in separate networking environments to easily communicate with each other. They are configured by Consul using a similar mechanism as sidecar proxies. If a source service wants to connect with a destination service in a remote cluster/platform/cloud, the traffic is proxied through mesh gateways, which route the traffic to the destination service based on the Server Name Indication (SNI) that is sent as part of the TLS handshake. Because SNI is part of TLS, mesh gateways don't (and can't) decrypt the data of the payload and have no special access to it, which keeps data safe even if a mesh gateway is compromised. Mesh gateways are a routing tool for service-to-service connections and are not suitable for general purpose ingress from non-mesh traffic.

In addition, Consul’s Kubernetes integrations have been updated to enable Kubernetes users to easily deploy gateways. This enables services inside Kubernetes environments to communicate with services running on other platforms without complex configuration.

»Example

Running Envoy as a gateway with Consul is simple, as shown below. Based on availability or performance requirements, as many gateways as necessary can be run in the same way.

$ consul connect envoy \
    -mesh-gateway \
    -register \
    -address "<your private address>" \
    -wan-address "<externally accessible address>"

By default, Connect won't use gateways and will attempt to connect directly to any service even across datacenters. If your datacenters aren't connected, then we have to configure them to use the mesh gateway.

$ cat proxy-defaults.hcl
Kind = "proxy-defaults”
Name = “global”
MeshGateway {
   Mode = “local"
}

$ consul config write proxy-defaults.hcl

This configures sidecar proxies to use a gateway to ensure data is forwarded to gateways in the destination datacenter. This is all that is necessary to enable and utilize gateways for cross-network connectivity.

Learn more in our docs on the Mesh Gateways page.

»Intentions and Certificate Replication

Today we are also open sourcing intention and certificate authority replication features that we originally shipped as part of Consul Enterprise in Consul 1.4. These features make connecting services across logical datacenters in Consul possible, and are vital building blocks for mesh gateways. We recognize that organizations of all sizes are increasingly challenged to manage a variety of infrastructure components across public cloud, private networks, and diverse runtime platforms such as Nomad or Kubernetes.

»Conclusion

You can get started now by following our new guide on Connecting Services Across Networks with the new mesh gateway feature.

Review the v1.6.0-beta1 changelog for a detailed list of changes. Release binaries can be downloaded here. We also welcome your bug reports or feedback on GitHub, and any questions in the new Community Portal.

We encourage you to experiment with these new features, but recommend against using this build in a production environment. Depending on feedback and resolving outstanding issues, we may release further betas, release candidates, and will publish a final generally available 1.6 release when appropriate.

Thank you to our active community members who have been invaluable in adding new features, reporting bugs, and improving the documentation for Consul in this release!