Can one Kubernetes cluster span multiple cloud providers?
Yes. One Kubernetes cluster can run worker nodes in several cloud providers at once, as long as the control plane and its etcd datastore stay in one low-latency location and every node reaches the API server and the other nodes over an encrypted network. What does not work well is spreading the etcd members themselves across distant clouds, because every write waits for a majority of members to confirm it.
What can be spread across clouds and what cannot
| Component | Spread across clouds? | Why |
|---|---|---|
| Worker nodes | Yes | Nodes reach the control plane only through the API server and take no part in consensus |
| Pod network | Yes, with an overlay | Pods need routable IP addresses between providers, which an encrypted overlay provides |
| etcd members | No, keep them in one region | etcd uses Raft consensus, so write latency grows with the round-trip time to a majority of members |
| API server replicas | Keep them next to etcd | Every API request reads from or writes to etcd |
The Kubernetes documentation describes the supported case for spreading a cluster: “a single Kubernetes cluster can run across multiple failure zones, typically where these zones fit within a logical grouping called a region” (Running in multiple zones). Zones in one region sit a few milliseconds apart. Two cloud providers in different cities can be tens of milliseconds apart.
etcd shows why that matters. Its default heartbeat interval is 100 ms and its default election timeout is 1,000 ms, and the etcd tuning guide says the election timeout must be at least 10 times the round-trip time between members. Members spread across continents need longer timeouts, which slows leader failover, and each write takes at least one round trip to a quorum. Keeping the whole control plane in one place avoids both problems. The Kubernetes control plane article explains what each component does.
How a cluster across clouds works
Networking. Nodes in different providers share no private network. A multi-cloud cluster needs an encrypted overlay, typically WireGuard® or IPsec, so that node-to-node and Pod-to-Pod traffic crosses the internet safely. The overlay adds header overhead, so the Pod network MTU has to be lower than the underlying link. The mechanics are in how nodes in different clouds join one cluster network.
Topology labels. Nodes carry the well-known labels topology.kubernetes.io/region and topology.kubernetes.io/zone (Well-known labels). Platforms that span providers usually add a label for the provider too. With these labels, topology spread constraints spread replicas across providers, and Pod affinity keeps services that talk to each other in the same provider.
Egress cost. Traffic between Pods in different clouds leaves one provider’s network and is billed as outbound data transfer. Two chatty services split across providers can cost more in transfer than they save in compute. See what cloud egress fees are before deciding which services may be separated.
Failure domains. The control plane location becomes the one dependency every node shares. If the provider hosting the control plane has an outage, nodes in other clouds keep running their Pods, but nothing is rescheduled, scaled or rolled out until the API server is back.
One cluster across clouds or one cluster per cloud
The alternative is a separate cluster in each provider, connected by multi-cluster tooling.
| One cluster spanning clouds | One cluster per cloud | |
|---|---|---|
| Control planes to operate | One | One per provider or region |
| Scheduling across providers | The scheduler places Pods on any provider through labels | You decide which cluster gets each workload and redeploy to move it |
| Service discovery | Standard Kubernetes Services work across providers | Needs the Multi-Cluster Services API, a service mesh or DNS-based discovery |
| Blast radius of a control plane failure | Whole cluster stops scheduling | Only one cluster is affected |
| Operation while disconnected | Cut-off nodes keep running Pods but receive no changes | Each cluster continues independently |
Multi-cluster tooling is still maturing. The Multi-Cluster Services API (KEP-1645) defines ServiceExport and ServiceImport resources and the clusterset.local DNS domain, and its API version is still v1alpha1. KubeFed, the earlier federation project, was archived in April 2023. Most multi-cluster setups today combine GitOps for configuration with a service mesh or global DNS for traffic.
When each design wins
A single cluster across clouds fits when you want one scheduler to choose capacity: placing batch jobs where compute is cheapest, using GPUs from whichever provider has them, or bursting into a second cloud. It also makes moving a workload between providers a label change instead of a migration.
One cluster per cloud fits when each environment must survive on its own, when regulators require separate administrative domains, or when a single cluster would exceed Kubernetes scalability limits. Many organizations end up with both: a few clusters, some of which span more than one provider. For the availability side of that decision, see how to make Kubernetes highly available across clusters.
Multi-cloud clusters with Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) runs one cluster across providers: a managed control plane with nodes in AWS, GCP, Hetzner Cloud and any other infrastructure, connected by a full mesh of WireGuard® tunnels. Locality load balancing routes Service traffic to the nearest Pod where it can, to limit cross-cloud transfer. See the networking architecture for details.