- **Cluster Peering (GA):** This version promotes Cluster Peering, a new model to federate Consul clusters for both service mesh and traditional service discovery, to General Availability. Cluster peering allows for service interconnectivity with looser coupling than the existing WAN federation. For more information, refer to the [cluster peering](/docs/connect/cluster-peering) documentation. Some notable improvements to Cluster Peering include:
- **Cluster Peering Failover:** Cluster Peering now supports the ability to redirect to services running on cluster peers with service resolvers. More details for configuring failover across peers is provided in the Service Resolver [failover](/docs/connect/config-entries/service-resolver#failover) stanza.
- **Control Plane traffic over Mesh Gateways:** Cluster Peering now supports the establishing peering through Mesh Gateways. More detail on using Mesh Gateways for Cluster Peering are found in [Enabling Peering Control Plane Traffic](/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways). Mesh Gateways are used by default for [Cluster Peering on Kubernetes](/docs/connect/cluster-peering/k8s).
- **Simplified Service Mesh with Consul Dataplane:** Support for a new `consul-dataplane`, a lightweight process for managing Envoy proxies introduced in Consul v1.14.0. Consul Dataplane removes the need to run client agents on every node in a cluster for service discovery and service mesh. Instead, Consul deploys sidecar proxies that provide lower latency, support additional runtimes, and integrate with cloud infrastructure providers. Read more in [Simplified Service Mesh with Consul Dataplane](/docs/connect/dataplane).
~> **Note:** Currently `consul-dataplane` is only supported on clusters running on Consul on Kubernetes 1.0+.
## What's Changed
- 1.14 adds a new `ports.grpc_tls` configuration option. This introduces a new port to better separate TLS config from the existing `ports.grpc` config. The new `ports.grpc_tls` only supports TLS encrypted communication. The existing `ports.grpc` now only supports plain-text communication.
- `peering` and `connect` are default.
- The gRPC TLS port default value to 8503
- Removes support for Envoy 1.20.x and adds Envoy 1.24.0 to support matrix.
- Renames `PeerName` to `Peer` on prepared queries and exported services.
- Converts service mesh failover to use Envoy's aggregate clusters. This
changes the names of some [Envoy dynamic HTTP metrics](https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats#dynamic-http-statistics).
## Upgrading
For more detailed information, please refer to the [upgrade details page](/docs/upgrading/upgrade-specific#consul-1-14-0) and the changelogs.
## Known Issues
The following issues are known to exist in the 1.14.0 release:
- Prior to Consul 1.14, cluster peering and Consul service mesh were disabled by default. A breaking change was made in Consul 1.14 that enabled cluster peering and Consul service mesh by default. To disable both, set `peering.enabled` and `connect.enabled` to false. The changes to Consul service mesh in version 1.14 are incompatible with Nomad 1.4.2 and earlier. If you operate Consul service mesh using Nomad 1.4.2 or earlier, do not upgrade to Consul 1.14 until hashicorp/nomad#15266 is fixed.
- For 1.14.0, there is a known issue with the `consul connect envoy` CLI command. If the command is configured to use TLS for contacting the HTTP API, it will also incorrectly enable TLS for gRPC. Users should not upgrade to 1.14.0 if they are using plaintext gRPC connections in conjunction with TLS-encrypted HTTP APIs.
## 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.
