Consul
Consul 1.17.0
We are pleased to announce the following Consul updates.
Release highlights
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.
Note
These 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.
Refer to the Multi-port services for service mesh and Configure multi-port services for more information.
Note
Multi-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.
Refer to the documentation for creating sameness groups or creating sameness groups on Kubernetes for more information.
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.
Refer to the API gateway JWT documentation for virtual machines and Kubernetes-orchestrated networks for more information.
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.
What's deprecated
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%
-admin-access-log-path
flag for theconsul connect envoy
command: The-admin-access-log-path
flag for theconsul connect envoy
command is deprecated and will be removed in a future release.-admin-access-log-config
can be used to configure Envoy admin access logs.
What's removed
- Legacy API Gateway support is removed: The Consul API Gateway that was previously packaged as
consul-api-gateway
, released separately from Consul K8s, and deprecated in Consul v1.16.x is now removed. This gateway is referred to as the legacy API Gateway. As of Consul v1.17.0, you must install the native API Gateway and configure it using theconnectInject.apiGateway
stanza.
Upgrading
For more detailed information, please refer to the upgrade details page and the changelogs.
Known Issues
The following issues are known to exist in the v1.17.x releases:
- v1.17.2 - Excessively strict TLS SAN verification is performed by terminating gateways, which prevents connections outside of the mesh to upstream services. Terminating gateway users are advised to avoid deploying these Consul versions. A fix will be present in a future release of Consul 1.17.3 [GH-20360].
Changelogs
The changelogs for this major release version and any maintenance versions are listed below.
Note
These links take you to the changelogs on the GitHub website.