Consul 1.10 Release Highlights

Consul 1.10 includes the following features, enhancement, and architectural improvements.

Enterprise license changes

Starting with Consul Enterprise 1.10.0, the license enablement process is different.

HashiCorp Enterprise servers will no longer start without a license. Servers require licenses to be provided from either an environment variable or file. If the license is missing, invalid, or expired, the server will immediately exit. This check is part of the server boot-up process.

In previous versions of HashiCorp enterprise products, one server could distribute a license to other servers via the Raft protocol. This will no longer work since each server must be able to find a valid license during the startup process.

Please visit the Enterprise License Tutorial for detailed steps on how to install the license key.

Consul UI redesign and dark mode

The Consul UI has been redesigned to use a sidebar layout. The new sidebar makes it easier to navigate the Consul UI, while its ability to be collapsed allows for maximization of the workspace. The UI also includes a new dark mode.

In addition to the redesign, the UI now restricts the viewing and editing of certain UI elements based on ACL token used to login.

Transparent proxying for Kubernetes

Transparent proxy allows users to reach other services in the service mesh while ensuring that inbound and outbound traffic for services in the mesh are directed through the sidecar proxy. Consul achieves this using iptables. By intercepting all ingoing and outgoing traffic to a node, it is more likely that traffic is secure and only reaches intended destinations since the proxy can enforce security and policy like TLS and Service Intentions.

Previously, service mesh applications had to have explicitly defined upstreams configured on the sidecar proxy, and application code had to be written to talk to the local proxy listener to reach the appropriate upstream. In additions, mesh operators had to define service intentions that specified which applications were allowed communication with each other and in which direction.

Transparent proxying reduces this duplication by inferring upstreams implicitly from service intentions. Explicit upstreams can still be defined and are still supported in the proxy service registration on VMs and via annotations in Kubernetes, however, they are no longer required. This allows users to simplify their configuration over time, with no fear of breakage on upgrade.

Kubernetes

Transparent proxying in a Consul service mesh on Kubernetes environment has some additional implications, including:

• KubeDNS - Since the Envoy proxy is intercepting all incoming and outgoing traffic via iptables rules, developers no longer have to change their application code to communicate over localhost. Instead, application code that relies on Kubernetes DNS can be deployed without modification.
• Upstream annotations are now optional - Since upstreams can be inferred by service intentions, operators no longer need to provide explicit upstream annotations on their service definitions. The exception to this is headless services or any other service that does not have a Cluster IP. Transparent proxying requires a Cluster IP, users will have to configure explicitly upstreams for any service that does not have a Cluster IP.
• Kubernetes service required - a Kubernetes service is now required for all service mesh injected applications. See the official Consul Helm chart release notes for details.
• Transparent proxying in Consul service mesh on Kubernetes has three modes of scope. It can be enabled service mesh-wide by settingconnectInject.tproxy.defaultEnabled. When set, all services in the mesh will run in tproxy mode. This setting is defaulted to true in the Helm chart. Alternately, you can enable tproxy per K8S namespace by overriding labels using kubectl label namespace default consul.hashicorp.com/tproxy=enabled --overwrite. Finally, you can configure tproxy on a per service basis using the consul.hashicorp.com/tproxy-enabled and consul.hashicorp.com/tproxy-outbound-listener-port annotations.

Expanded metrics reporting

With Kubernetes annotations, you are now able to expose both pod and envoy metrics via a single endpoint for Prometheus to scrape metrics. Previously, you needed to choose between either Envoy or Pod metrics since Prometheus annotations only allow you to scrape from a single pod within a container on Kubernetes.

Prometheus Helm chart installation

Consul service mesh on Kubernetes provides a deep integration with Prometheus, and now includes a built-in starter experience for installing Prometheus suitable for use in evaluation, demo, or dev environments.

xDS v3 support

Consul 1.10 defaults to using xDS version 3 when configuring Envoy proxies newer than version 1.15. xDS v2 was deprecated in Envoy 1.17. Consul will fallback to using xDS v2 for older versions.

Streaming enabled by default for service health

A major architectural enhancement in how update notifications for blocking queries are delivered within the service mesh which was introduced in Consul 1.9. Streaming results in a significant reduction of CPU and network bandwidth usage on Consul servers in large scale deployments. Streaming is now available for the service health HTTP endpoint. As of Consul 1.10, streaming is now enabled by default.

HTTP2 Ping health checks

Health checks have been extended to support HTTP2 Ping.

Consul snapshot inspect improvements

The consul snapshot inspect command now provides a flag to print the results in JSON format and adds some extra parameters to inspect the content and size of the KV data. This helps you identify keys or paths that are taking up too much space in your snapshots.

Download Consul 1.10

You can download Consul 1.10 now!