Cluster peering

This topic provides an overview of cluster peering on HCP Consul. Cluster peering is a feature that connects two or more independent clusters so that services deployed to different partitions or datacenters can communicate. On HCP Consul, you can use cluster peering to connect self-managed Consul clusters deployed in your own compute environment with HashiCorp-managed Consul clusters.

Introduction

If you use HCP to manage your Consul clusters, you can create cluster peering connections within the same HVN, between clusters hosted on two different HVNs or cloud providers, or between HCP-managed and self-managed Consul clusters.

When you create peering connections through the management plane, you can access detailed information about your cluster peering connections. This information includes the connection's current status and the number of services imported and exported to other clusters. Refer to management plane cluster peering for additional details.

For more information about cluster peering, including general usage and Kubernetes-specific information, refer to the cluster peering overview in the Consul documentation.

Multi-region and multi-cloud support

The HCP cluster tier determines whether the Consul cluster can peer to clusters across multiple regions or clouds.

For testing purposes, the development tier supports all cluster peering features. To use cluster peering in production environments, you must have an annual subscription through either an annual entitlement contract or Flex billing.

For more information about how tiers differ in their support for multi-region and multi-cloud cluster peering, refer to HCP Consul tiers. For information about the features available on each tier, refer to HCP Consul features.

Tier limitations

When using cluster peering with HCP Consul, be aware of the following limitations and technical constraints.

• Cluster peering in production environments requires an account with either an annual entitlement contract or Flex billing. Refer to billing models for more information.
• Premium tier clusters are only available with annual entitlement contracts and Flex billing subscriptions.
• Plus tier clusters in Azure are only available with annual entitlement contracts and Flex billing subscriptions.

Cluster peering and WAN federation

As described in the Consul documentation, cluster peering treats each datacenter as a separate cluster, while WAN federation connects multiple datacenters to make them function as if they were a single cluster. As a result, WAN federation requires a primary datacenter to maintain and replicate global states such as ACLs and configuration entries, but cluster peering does not.

On HCP Consul, there are additional distinctions between cluster peering and WAN federation. HCP does not support WAN federation in Azure environments. As a result, it is not possible to connect HashiCorp-managed clusters hosted on AWS and Azure with WAN federation. You also cannot federate HCP-managed and self-managed clusters. However, HCP Consul supports cluster peering between AWS and Azure clusters, as well as cluster peering between HCP-managed and self-managed clusters.

Constraints and considerations

Cluster peering through the management plane on HCP Consul has the following constraints:

• The clusters must run Consul v1.14.2 or later.
• When peering self-managed clusters through the management plane, the self-managed cluster must run Kubernetes and have been originally deployed through the management plane.
• You must create the cluster peering connection using the management plane in order for the cluster and its services to appear in the management plane cluster peering view.
  • When you create a cluster peering connection externally, the connection can still operate but it cannot be edited to make it appear on the HCP platform.
  • If you want to make the existing connection appear on HCP, you must delete the existing cluster peering connection and then establish a new one through the management plane.