I'm planning to run a Kubernetes cluster across several VPS instances for redundancy if one VPS fails. The providers would be in roughly the same geographic area, such as the U.S. West Coast.
I'm unsure whether this should be considered multi-zone or multi-region, and whether the network latency would make it impractical. I've also read that Kubernetes clusters spanning regions are generally discouraged because of latency.
It seems risky to place several virtual machines on the same physical server, since one hardware failure could take down all of them. However, that appears to be a common setup. Would using VPS instances from different providers provide meaningful fault tolerance?
Once the worker nodes are running and serving traffic, how much does control-plane latency matter? For example, I would not mind if scaling or other Kubernetes management actions took an extra 100 milliseconds. What networking or Kubernetes behavior am I overlooking?
3 Answers
Running several VMs on one physical machine really is a single point of failure, so it does not provide much hardware redundancy. In a professional environment, the VMs would normally be distributed across multiple physical hosts, racks, power systems, and possibly data centers. A VPS provider may hide some of that placement information, so you cannot assume that separate VPS instances are physically independent unless the provider offers that guarantee.
If each VPS is in a completely separate location, using one node per cluster and operating several independent clusters can be more robust than forcing them into one cluster. That approach requires planning for replicated data, storage, ingress, failover, and traffic routing, but it avoids making one Kubernetes control plane depend on a long-distance network.
The concern is not only how long Kubernetes takes to make a scaling decision. Kubernetes components and applications also communicate continuously. The control plane depends heavily on etcd, and etcd requires consistent, low-latency, low-jitter communication for heartbeats, quorum, and leader elections.
If nodes or control-plane members are connected through unreliable public VPS networks, temporary packet loss or jitter can make nodes appear unhealthy, cause leader changes, or trigger unnecessary pod rescheduling. Pod-to-pod traffic, service discovery, storage replication, and ingress can also suffer even if users would tolerate a delayed scaling event.
A cluster across multiple physical hosts in one well-connected data center or across properly designed availability zones is usually safer than a cluster stretched across unrelated providers.
That makes sense. I was focusing on management actions, but the ongoing heartbeats, quorum traffic, and pod communication make the network requirements much stricter.
The important distinction is between zones and regions. In major cloud platforms, one region contains multiple availability zones, usually separate data centers connected with low-latency networking. A cluster can spread its nodes across those zones while keeping the control plane and cluster communication reasonably reliable.
Different VPS providers in the same broad geographic area are not automatically equivalent to availability zones. They may be in separate facilities, but you generally do not get the same predictable private networking or latency guarantees. If the locations are far apart, you are effectively building a multi-region or stretched cluster.
For geographic redundancy, it is often simpler to run separate clusters in different locations and direct traffic between them using DNS, a CDN, or anycast rather than stretching one Kubernetes cluster across distant networks.
The key requirement is that the facilities be independent but still have stable, low-latency links. Geographic proximity alone does not guarantee that.
A multi-cluster design can feel unusual when each cluster is small, but it is often the right model for failure domains. The difficult parts are usually stateful storage and failover, not scheduling the pods.