We are pleased to announce the following Consul updates.
Consul catalog v2 API: We introduced a new set of APIs for interacting with the catalog, authenticating traffic using identities, and managing Consul service mesh. The Consul catalog v2 API still tracks services and nodes for Consul, but it replaces service instances with workloads and workload identities.
These APIs are the foundation for future versions of Consul and enable new functionalities, such as multi-port and host-name-based canary routing and routing traffic through headless services in native Kubernetes deployments.
For more information, refer to the Catalog API v2 section in the documentation.
NoteThese APIs are in beta and under active development, so we do not recommend using them in production.
Multi-port services in Consul: You can now register services with multiple ports per service. The v2 catalog API enables a single sidecar proxy to support workloads on different ports. This significantly reduces the operational overhead for managing Consul service mesh. Support for other runtimes outside of Kubernetes is planned for future releases of Consul.
NoteMulti-port is currently a beta feature in Consul v1.17.
Locality-aware service mesh routing (Enterprise): Locality-aware routing lets operators prioritize routing to upstream instances located in the same zone over instances in alternate zones. If all of the instances of an upstream service within a zone are unavailable, Consul service mesh automatically fails over to healthy instances in adjacent zones, ensuring service connectivity and availability within the datacenter.
This enables operators to reduce service-to-service latency, which helps improve overall service performance and decrease infrastructure costs.
Refer to the locality-aware service mesh routing documentation for more information.
Sameness groups (Enterprise): Introduced in 1.16, sameness groups are a user-defined set of partitions that Consul uses to identify services that have the same name but are in different administrative partitions as being the same services. You can use sameness groups to create a blanket failover policy for deployments with cluster peering connections. Sameness group is generally available in Consul 1.17.
Enterprises can use sameness groups to simplify operations and increase service availability for multi-cluster or multi-region deployments.
JWT-based authentication and authorization for API Gateway (Enterprise): You can configure API gateway to use policies that control access to services based on JSON Web Tokens (JWT) embedded in the network traffic sent by external clients. These policies can control access to services, and even specific URLs, based on the claims contained in JWTs.
Administrators can control access to services from outside the service mesh without having to modify services that do not support JWT-based authentication/authorization.
Traffic rate limiting for services (Enterprise): You can now configure Consul service mesh to limit the rate of HTTP requests to services. Configure rate limiting per service and apply them per service instance. Operators can set HTTP request rate limits for the service instance or separate rate limits for specific URL paths. The rate limiting configuration includes settings for requests per second (RPS) as well as maximum request burst size.
Rate limiting helps operators protect service instances from becoming overloaded with requests. They also enable operators to define criteria for allowing traffic to service instances and ensure service capacity is shared fairly.
For more information, refer to the rate limiting documentation.
Simplified service mesh deployments on Amazon ECS: Consul on ECS now leverages a simplified service mesh deployment architecture that eliminates the need to deploy Consul clients per task on Amazon ECS. The new architecture deploys a Consul Dataplane container that is injected as a sidecar in the ECS task. This dataplane container image packages both an Envoy container and Consul dataplane binary.
For more information, refer to the Consul ECS documentation.
ACL templated policies: You can now configure Consul tokens for common use cases without needing to manually create a policy. Templated policies can be added to tokens and roles. Consul automatically generates a policy and attach it to the token or role.
For more information, refer to the templated policies documentation.
Non DNS-compatible service names: Starting with this release, non DNS-compatible service names are deprecated. Consul will only accept lowercase alphanumeric characters and
-, and names that start and end with an alphanumeric character. All other characters will be considered incompatible. An example of what is not considered dns-compatible is listed below:
$ consul services register -name 'foo~bar%' Registered service: foo~bar% $ consul catalog services consul foo~bar%
For more detailed information, please refer to the upgrade details page and the changelogs.
The changelogs for this major release version and any maintenance versions are listed below.
NoteThese links take you to the changelogs on the GitHub website.