Skip to content

Multi-Region & Multi-Cloud

Spreading a cluster across regions only delivers availability when three decisions line up: where the user enters, where the workload runs and where the data is. This page covers the first two — the third is in Stateful Workloads.

Nodes identified by region and zone

Every worker node carries topology information identifying its physical or logical location. Kubernetes uses those labels when deciding where each workload may run.

Nodes labelled by region and zone, with stateless workloads spread and stateful workloads pinned

Infrastructure topology becomes part of the application's scheduling policy.

An application can require three replicas with one in br-sp-1, one in br-sp-2 and one in the public cloud — or a workload can be explicitly restricted:

database   →  br-sp-1 only
frontend   →  br-sp-1, br-sp-2 and public cloud

The mechanisms are Kubernetes' own:

  • Topology Spread Constraints — balanced distribution across zones;
  • Pod Anti-Affinity — replicas of the same service on different nodes or zones;
  • PodDisruptionBudget — an availability floor during maintenance and upgrades;
  • Node Affinity / zone selectors — pinning workloads that depend on local data;
  • Minimum replicas per region — guaranteed presence in each failure domain.

Global load balancing with Cloudflare

In multi-region architectures, external traffic is distributed through Cloudflare Global Load Balancing, which takes endpoint availability and the application's geographic strategy into account. If a region stops responding correctly, traffic is directed to the healthy regions.

Cloudflare distributing traffic across regions, and the three decision layers: user, execution and data

Redirecting traffic does not mean the application's data is available in the destination region.

Useful for: regional failover, globally distributed applications, disaster recovery, reducing latency for end users, traffic distribution and planned regional maintenance.

A global load balancer does not make an application multi-region

The load balancer decides where to send the user. Kubernetes decides where to execute. The data architecture ensures where data is available. The three layers are complementary — putting a global balancer in front of an application whose data lives in a single region only forwards users to somewhere that cannot serve them.

Network partition between regions

A multi-region architecture has to account not only for the complete loss of a datacenter but also for a network partition: both sides keep operating while losing communication with each other.

For stateless workloads this is handled with replicas, health checks and load balancing — each side serves with what it has.

For stateful workloads the architecture must provide quorum, leader election, fencing, replication, split-brain prevention and data consistency. Those mechanisms are defined per technology, case by case — what holds for PostgreSQL is not what holds for Kafka. InteSys evaluates that requirement together with the cluster design.

If a region loses connectivity

Workloads already running on worker nodes do not depend continuously on the control plane to keep running. If a group of nodes temporarily loses communication with the management layer:

  • existing containers keep running and can be restarted locally where applicable;
  • new scheduling decisions and state changes that depend on cluster communication become temporarily limited;
  • when connectivity is restored, Kubernetes resumes reconciliation toward the desired state.

For stateful workloads, the additional quorum, replication and split-brain protections described above apply.

Cost is not the same in every region

Computing capacity is not priced the same everywhere. A worker on InteSys infrastructure may cost differently from an equivalent worker on AWS, Azure, Google Cloud, DigitalOcean, OVHcloud or Hetzner — and the differences show up in CPU, memory, storage, IOPS, outbound traffic, public IPs, load balancers, snapshots, backups and inter-region traffic.

That difference is used as an architecture tool:

Workload Where it usually goes
Critical, latency-sensitive workload Premium region, with high availability
Asynchronous processing Lower-cost region
European users European region
Data under residency requirements Brazilian regions

Pricing is defined according to the region and provider selected for each group of nodes.

No infrastructure lock-in

A cluster that is not tied to a single hyperscaler can evolve without rebuilding the application platform around proprietary services. Provider-specific services remain available whenever they bring a technical advantage — but they become an architectural choice, not a Kubernetes platform requirement.