How Consul 1.13 Simplifies Service Mesh on Kubernetes with CNI and Cluster Peering

HashiCorp released Consul 1.13, a major update that helps organizations lower operational complexity, run Consul at large scale, and securely integrate service mesh into application workflows.

Consul on Kubernetes CNI plugin

Previously Consul injected an init container ( consul-connect-inject-init) that required the pod to have the CAP_NET_ADMIN Linux capability, which posed security concerns for strict environments. In version 1.13 Consul now distributes a chained CNI plugin that configures traffic redirection during the pod lifecycle, eliminating the need for the init container and the privileged capability. The plugin is slated for release in consul-k8s 0.48.0.

Consul on Kubernetes CLI enhancements for Envoy troubleshooting

New CLI commands simplify diagnosing Envoy configuration issues: consul-k8s proxy list – lists all pods with Consul‑managed Envoy proxies and shows their type (sidecar or gateway). consul-k8s proxy read <pod name> – displays the full Envoy configuration for a given pod, including clusters, listeners, endpoints, routes, and secrets.

Namespace: All Namespaces

Namespace Name                                    Type
consul    consul-ingress-gateway-6fb5544485-br6fl Ingress Gateway
consul    consul-ingress-gateway-6fb5544485-m54sp Ingress Gateway
default   backend-658b679b45-d5xlb                Sidecar
default   client-767ccfc8f9-6f6gx                 Sidecar
default   client-767ccfc8f9-f8nsn                 Sidecar
default   client-767ccfc8f9-ggrtx                 Sidecar
default   frontend-676564547c-v2mfq               Sidecar

Envoy configuration for backend-658b679b45-d5xlb in namespace default:

==> Clusters (5)
Name                 FQDN                                                                     Endpoints                                                     Type     Last Updated
local_agent          local_agent                                                               192.168.79.187:8502                                             STATIC     2022-05-13T04:22:39.553Z
client               client.default.dc1.internal…                                             192.168.18.110:20000, 192.168.52.101:20000, 192.168.65.131:20000 EDS     2022-08-10T12:30:32.326Z
frontend             frontend.default.dc1.internal…                                     192.168.63.120:20000                                             EDS     2022-08-10T12:30:32.233Z
local_app            local_app                                                             127.0.0.1:8080                                             STATIC     2022-05-13T04:22:39.655Z
original-destination original-destination                                                                                                             ORIGINAL_DST 2022-05-13T04:22:39.743Z

==> Endpoints (6)
Address:Port         Cluster                                                           Weight Status
192.168.79.187:8502  local_agent                                                             1.00   HEALTHY
… (additional endpoint entries omitted for brevity)

==> Listeners (2)
Name              Address:Port         Direction Filter Chain Match              Filters                                                                     Last Updated
public_listener   192.168.69.179:20000 INBOUND   Any                             * to local_app/                                                             2022-08-10T12:30:47.142Z
outbound_listener 127.0.0.1:15001      OUTBOUND  10.100.134.173/32, 240.0.0.3/32 to client.default… 2022-07-18T15:31:03.246Z

==> Routes (1)
Name            Destination Cluster Last Updated
public_listener local_app/          2022-08-10T12:30:47.141Z

Terminating Gateways enhancements

Version 1.13 improves terminating gateways so they can route traffic to any external destination—whether the service is registered in Consul or not—by allowing administrators to define an allow‑list of external hostnames or IPs. The gateway acts as a central egress point that enforces access policies before traffic leaves the mesh.

Cluster Peering (preview)

Large enterprises often have platform teams that need secure cross‑team connections. Consul 1.13 adds a “cluster peering” feature that lets independent Consul datacenters (clusters) establish direct, secure service connections without a single master datacenter.

Before cluster peering

Consul’s original federation model required all datacenters to share a common management plane, shared keys, policies, and upgrades. This model relied on a full‑mesh WAN connection and a single source of truth for configuration, which limited flexibility for teams that wanted autonomous control.

WAN federation benefits include shared keys, coordinated upgrades, and a static primary datacenter, but it also creates dependencies on the primary and makes complex topologies hard to support.

Using cluster peering

With cluster peering each cluster is autonomous, owning its own keys, service catalog, and ACLs. Peered clusters exchange only the services they explicitly expose, enabling fine‑grained connections, minimal coupling, operational autonomy, and support for hub‑spoke topologies.

Cluster peering in Consul Enterprise

Enterprise Admin Partitions (introduced in Consul 1.11) provide multi‑tenant isolation within a single control plane. Cluster peering extends this by allowing partitions to peer across clusters or regions, independent of other teams’ partitions.

Cluster peering does not immediately replace WAN federation; existing WAN setups can continue while organizations evaluate the new model.

Next steps

Consul aims to be an enterprise‑ready, consistent control plane for discovering and securely connecting any application. For more information, visit the Consul documentation, download the 1.13 binaries, or use the latest Helm chart that supports Consul 1.13 on Kubernetes.