Hashicorp has announced the beta release of Consul 1.9, adding new features to their service mesh platform. This release includes enhancements to the intentions model to support Layer 7 constructs, new visualizations for verifying configurations, and custom resources for Kubernetes.
With the introduction of application-aware intentions, policies can now be constructed to support Layer 7 interactions. This includes support to allow or disallow service communication based on HTTP request headers and URL paths. In previous versions, intentions only had support for L4 interactions. It is now possible to mix both L4 and L7 into a single intention declaration:
Kind = "service-intentions"
Name = "api"
Sources = [
{
Name = "hackathon-project"
Action = "deny"
},
{
Name = "web"
Action = "allow"
},
{
Name = "nightly-reconciler"
Permissions = [
{
Action = "allow"
HTTP {
PathExact = "/v1/reconcile-data"
Methods = ["POST"]
}
}
]
}
]
The above example defines intentions for a common destination of "api". The first intention denies connections from the source "hackathon-project" while allowing traffic connections from the source "web". From the source "nightly-reconciler", it is allowing HTTP traffic from only the specified path via the POST method.
Traditionally debugging and troubleshooting the setup and configuration of Consul required relying on error logs, command line output, and sending telemetry to external systems. Consul lacked an easy way to visualize the service mesh topology to streamline troubleshooting. With this release, a new topology tab has been added to the UI. This presents topology diagrams along with key service mesh metrics such as requests, error rates, and timings. More details and best practices are available in the maintenance and monitoring operations guides.
Within the topology map it is possible to view the interactions between services within the mesh. An explicit deny will appear as a red line with an x between the two services. It is possible to adjust denies to allow via the topology map.
To improve the Kubernetes-first experience, this release will introduce support for Custom Resource Definitions to streamline configuring Consul via Kubernetes-style objects. It will now be possible to manage configurations for services via CRDs. At the time of release, the following configuration entries were available as CRDs:
proxy-defaults- controls proxy configurationservice-defaults- configures defaults for all the instances of a given serviceservice-resolver- matches service instances with a specific Connect upstream discovery requestsservice-router- defines where to send layer 7 traffic based on the HTTP routeservice-splitter- defines how to divide requests for a single HTTP route based on percentagesservice-intentions- defines restrictions for specific service to service interactions
As an additional improvement to the Kubernetes integration, Consul can now detect health status from Kubernetes via its readiness probe. This will allow for deciding on where traffic should be directed based on both Consul's health checks and now the native Kubernetes health checks on pods.
The introduction of streaming improves both CPU and network bandwidth usage on large-scale deployments of Consul. This change is facilitated by a major architectural improvement in how update notifications for blocking queries are delivered. Streaming is available on the service health HTTP endpoint and can be enabled via configuration flags and the cached URL parameter. Future releases will see streaming added to more endpoints.
Consul 1.9 is available now in beta release. Hashicorp advises that forward compatibility is not guaranteed and as such, it is recommended to install this in a cluster that can be lost. For more details on the release, the changelog is available.
