Main content
DevOps

Kubernetes Scaling: Best Practices for Multi-Region Clusters

Running K8s at scale is hard. We share our battle-tested configurations for autoscaling, networking, and disaster recovery across regions — refreshed with our latest Karpenter setup.

Illustration for “Kubernetes Scaling: Best Practices for Multi-Region Clusters”

Kubernetes has won the container orchestration war, but "Day 2" operations remain a challenge. When you're managing multiple clusters across multiple regions, manual kubectl commands don't cut it. You need robust automation and a solid architecture — this is core to our DevOps & platform engineering practice.

Autoscaling Done Right

Many teams rely solely on Horizontal Pod Autoscaler (HPA). We recommend a multi-layered approach:

  • HPA: Scales pods based on CPU/Memory metrics.
  • VPA (Vertical Pod Autoscaler): Recommends request/limit sizing to prevent resource starvation.
  • Cluster Autoscaler / Karpenter: This is critical. We prefer Karpenter on AWS for its lightning-fast node provisioning. It can calculate the exact instance type needed for pending pods and provision it in seconds. We go much deeper on right-sizing and Karpenter migration in our Kubernetes cost optimization guide.

Multi-Region Networking

We use a service mesh (Istio) to manage traffic between regions. This allows for:

  • Locality Load Balancing: Keep traffic in the same region to reduce latency.
  • Failover: Automatically reroute traffic to Region B if Region A goes down.

When a multi-region incident does happen, having a correlation layer that understands cross-region and cross-cloud context matters — see our multi-cloud incident response playbook for how we structure that response.

GitOps with ArgoCD

To manage configuration drift, we use ArgoCD. The entire cluster state is defined in Git. If someone manually changes a deployment, ArgoCD detects the drift and syncs it back to the desired state. This is crucial for compliance and stability — and directly supports the change-management evidence auditors look for, which we cover in our SOC 2 compliance roadmap.

Frequently asked questions

How many Kubernetes clusters should an enterprise run?

There's no universal number, but we generally recommend at least one cluster per region you serve traffic from, separated further by environment (prod/staging). Beyond that, splitting by business unit or compliance boundary is common — clients we work with typically run anywhere from 3 to 15+ clusters depending on scale and regulatory requirements.

What is the fastest way to reduce Kubernetes node costs?

Migrating from Cluster Autoscaler to Karpenter combined with right-sizing pod resource requests, which we detail in our dedicated Kubernetes cost optimization guide.

How do you handle failover between regions in Kubernetes?

A service mesh like Istio handles locality-aware load balancing and automated failover — routing traffic to the healthy region automatically when health checks fail in the primary region, without requiring manual DNS changes.

Turn this into savings on your own estate

Connect a cloud account with read-only access and see costed, ranked findings from the first scan — or talk to our FinOps team about a program.