Link service network east/west on Kubernetes

This topic provides an overview of the strategies and processes for linking defined segments of your service mesh to extend east/west operations across cloud regions and platforms when running Consul on Kubernetes. Linking network segments into an extended service mesh enables advanced strategies for deploying and monitoring service operations in your network.

Introduction

Consul supports two general strategies for extending east/west service mesh traffic across your network:

• Cluster peering
• Wide Area Network (WAN) federation

Consul community edition supports basic cluster peering and federation scenarios. Implementing advanced scenarios such as federated network areas and cluster peering between multiple admin partitions in datacenters require Consul Enterprise. Refer to Consul Enterprise for more information.

Cluster peering

Cluster peering connects two or more independent Consul clusters so that services deployed to different datacenters can communicate. The process to establish a connection generates and exchanges peering tokens between admin partitions in each datacenter.

Peering topologies that include more than one admin partition in a single Consul datacenter require Consul Enterprise. HCP Consul enables additional support for cluster peering lifecycle operations through HCP Consul Central.

Cluster peering in your service mesh enables sameness groups, service failover, and connections between Consul clusters owned by different operators. Refer to the Cluster peering documentation for more information.

Refer to the following pages for guidance about using cluster peering with Consul on Kubernetes:

• Establish cluster peering connections on Kubernetes
• Manage cluster peering connections on Kubernetes

WAN federation

Wide Area Network (WAN) federation joins two or more Consul datacenters. When you enable WAN federation in each server cluster and declare one of them the primary datacenter, Consul agents can communicate using WAN gossip to function as if they were a single datacenter.

WAN federation in your service mesh enables service-to-service communication across cloud regions, key/value store replication, and advanced strategies for traffic management such as service failover. Refer to the WAN federation documentation for more information.

Refer to the following pages for guidance about using WAN federation with Consul on Kubernetes:

• WAN federation between multiple Kubernetes clusters
• WAN federation between virtual machines and Kubernetes clusters

Secure communication with mesh gateways

Mesh gateways route service mesh traffic between Consul datacenters that reside in different cloud or runtime environments where general interconnectivity between all services in all datacenters is not feasible. In hybrid or multi-cloud production environments, mesh gateways secure communication between datacenters deployed to different cloud regions or platforms.

After you register a mesh gateway with Consul, you can configure a service's sidecar proxy to enable the mesh gateway as a service upstream. Refer to the Mesh gateway documentation for more information.

Reference documentation

For reference material related to the processes for extending your service mesh by linking segments of your network, refer to the following pages:

• Proxy defaults configuration reference
• Helm chart reference
• Upstream annotations reference

Constraints, limitations, and troubleshooting

If you experience errors when linking segments of your network, refer to the following list of technical constraints.

• Consul does not support deployments that use WAN federation and cluster peering simultaneously.
• The Consul UI does not support the creation of cluster peering connections, WAN-federated datacenters, federated network areas, or mesh gateways. A dedicated user interface to view, create, and manage cluster peering connections is available through HCP Consul Central.