open-consul/website/content/docs/k8s/installation/multi-cluster/index.mdx

76 lines
3.7 KiB
Plaintext

---
layout: docs
page_title: Multi-Cluster Federation Overview
description: >-
Installing on multiple Kubernetes clusters.
---
# Multi-Cluster Federation Overview
In Consul, federation is the act of joining two or more Consul datacenters.
When datacenters are joined, Consul servers in each datacenter can communicate
with one another. This enables the following features:
- Services on all clusters can make calls to each other through Consul Service Mesh.
- [Intentions](/docs/connect/intentions) can be used to enforce rules about which services can communicate across all clusters.
- [L7 Routing Rules](/docs/connect/l7-traffic) can enable multi-cluster failover
and traffic splitting.
- The Consul UI has a drop-down menu that lets you navigate between datacenters.
## Traditional WAN Federation vs. WAN Federation Via Mesh Gateways
Consul provides two mechanisms for WAN (Wide Area Network) federation:
1. Traditional WAN Federation
1. WAN Federation Via Mesh Gateways (newly available in Consul 1.8.0)
### Traditional WAN Federation
With traditional WAN federation, all Consul servers must be exposed on the wide area
network. In the Kubernetes context this is often difficult to set up. It would require that
each Consul server pod is running on a Kubernetes node with an IP address that is routable from
all other Kubernetes clusters. Often Kubernetes clusters are deployed into private
subnets that other clusters cannot route to without additional network devices and configuration.
The Kubernetes solution to the problem of exposing pods is load balancer services but these can't be used
with traditional WAN federation because it requires proxying both UDP and TCP and Kubernetes load balancers only proxy TCP.
In addition, each Consul server would need its own load balancer because each
server needs a unique address. This would increase cost and complexity.
![Traditional WAN Federation](/img/traditional-wan-federation.png 'Traditional WAN Federation')
### WAN Federation Via Mesh Gateways
To solve the problems that occurred with traditional WAN federation,
Consul 1.8.0 now supports WAN federation **via mesh gateways**. This mechanism
only requires that mesh gateways are exposed with routable addresses, not Consul servers. We can front
the mesh gateway pods with a single Kubernetes service and all traffic flows between
datacenters through the mesh gateways.
![WAN Federation Via Mesh Gateway](/img/mesh-gateway-wan-federation.png 'WAN Federation Via Mesh Gateway')
## Network Requirements
Clusters/datacenters can be federated even if they have overlapping pod IP spaces or if they're
on different cloud providers or platforms. Kubernetes clusters can even be
federated with Consul datacenters running on virtual machines (and vice versa).
Because the communication between clusters is end-to-end encrypted, mesh gateways
can even be exposed on the public internet.
The only requirement is that the mesh gateways for each cluster can route to
one another. For example, if using a load balancer service in front of each cluster's
mesh gateway, the load balancer IP must be routable from the other mesh gateway pods.
If using a public load balancer, this is guaranteed. If using a private load balancer
then you'll need to make sure that its IP is routable from your other clusters.
In addition, if ACLs are enabled, primary clusters must be able to make requests to the Kubernetes API URL of
secondary clusters.
## Next Steps
Now that you have an overview of federation, proceed to either the
[Federation Between Kubernetes Clusters](/docs/k8s/installation/multi-cluster/kubernetes)
or [Federation Between VMs and Kubernetes](/docs/k8s/installation/multi-cluster/vms-and-kubernetes)
pages depending on your use case.