A ‘big’ Kubernetes cluster is 5000+ nodes or 150,000+ pods. K8s supports up to 5000 nodes per cluster by default (5000-node, 300000-pod limits from upstream). The team that runs at this scale changes patterns: etcd becomes a SRE concern, the API server needs sharding, scheduling gets careful (taints, affinity, topology spread), and many clusters become more common than one giant cluster.
Table of contents
- The Kubernetes scale limits
- How big is a real cluster
- Where the bottlenecks hit
- One big cluster vs many smaller clusters
- Multi-cluster patterns
- FAQ
The Kubernetes scale limits
Upstream Kubernetes documents these per-cluster limits:
- Nodes: 5,000
- Pods: 300,000 (total across all nodes)
- Pods per node: 110 (default; tunable)
- Services: 10,000
- Namespaces: 10,000
- Pods per namespace: 3,000 (depends on quota)
- Secrets/configmaps: 1,000 per namespace (depends on etcd size)
- Objects per namespace: 100,000 (API server default)
The team that approaches these limits sees API server latency increase, etcd compaction lag, and scheduler throughput drop. The fixes are tuning (etcd backend size, API server flags) or splitting into multiple clusters.
How big is a real cluster
Most K8s clusters in 2026 are 5-100 nodes. Big clusters:
- Small: 1-10 nodes (dev, small production).
- Medium: 10-100 nodes (typical SaaS).
- Large: 100-1000 nodes (large SaaS, big data).
- Very large: 1000-5000 nodes (Google, Facebook-scale internal).
The team that has 5000+ nodes is in the very-large category. Public references: Google’s GKE Autopilot clusters, Facebook’s (Meta’s) internal K8s, large telcos, some financial institutions.
Where the bottlenecks hit
At 5000 nodes, the bottlenecks are:
- etcd: Each pod/service update hits etcd. With 300K pods updating every few minutes, etcd write throughput is the bottleneck. Solution: shard etcd, increase backend size, use watch caches.
- API server: Each request consumes CPU and memory. Solution: horizontal scaling, request prioritizers, mutating-webhook-aware limits.
- Scheduler: Each pod triggers a scheduling decision. Solution: scheduler sharding (one scheduler per region/zone).
- Networking: 300K pods need IPs and connectivity. Solution: IPv6 dual-stack, Cilium’s eBPF data plane (more efficient than iptables), VPC-native CNIs.
- Image distribution: 300K pods pulling images from a registry. Solution: regional registries, image pre-pulling, P2P distribution (Dragonfly, Kraken).
The team that hits these bottlenecks sees latency and eventually OOMs. The team that plans for them up front has a smoother scale-out.
One big cluster vs many smaller clusters
The choice between one giant cluster and many smaller clusters is a constant debate.
One big cluster:
- Pro: single API, single RBAC, shared services (Istio, monitoring), simpler networking.
- Con: blast radius is the whole cluster, scaling limits hit faster, noisy neighbors.
Many smaller clusters:
- Pro: isolation per cluster (blast radius), independent scaling, simpler per-cluster ops.
- Con: harder to share services, more API endpoints to manage, cluster sprawl.
The team that picks multi-cluster usually has team boundaries (each team owns a cluster) or environment boundaries (dev/staging/prod as separate clusters). The team that picks one big cluster has a centralized platform team.
Multi-cluster patterns
Common multi-cluster patterns:
- Hub-spoke: One hub cluster for control plane tools (Argo CD, monitoring), many spoke clusters for workloads.
- Per-region: One cluster per cloud region for latency.
- Per-environment: dev, staging, prod as separate clusters.
- Per-team: Each team gets its own cluster, shared services in a central cluster.
- Active-active: Multiple clusters serving the same workload for DR.
Tools: Cluster API (CAPI) for cluster lifecycle, Argo CD for multi-cluster GitOps, Submariner for cross-cluster networking, KubeFed (mostly deprecated in favor of Argo).
FAQ
Can Kubernetes really run 5000 nodes?
Yes, with tuning. Google’s GKE, AWS EKS, and Azure AKS all support 5000-node clusters in 2026 (with caveats). The team that runs at this scale uses commercial KaaS or has a strong platform team.
How many pods is too many?
300,000 is the documented limit. The team that approaches 100,000 pods per cluster sees scheduler latency. Splitting into multiple clusters is usually easier than tuning a single cluster past 100K.
Is one cluster or many clusters better?
Depends. The team that has strict team boundaries uses per-team clusters. The team that has shared services uses one big cluster. Most enterprises end up with a mix (one cluster per environment, plus per-region within prod).
What about Kubernetes Federation?
KubeFed v2 was deprecated in favor of cluster API + Argo CD. The team that wants multi-cluster GitOps uses Argo CD’s cluster registry and ApplicationSet controller. Federation-as-a-built-in-concept is largely abandoned.
How do I know if my cluster is too big?
Watch API server latency (p99 should be <1s), etcd write latency (p99 <50ms), and scheduler throughput. The team that sees these climb is approaching the limits and should plan the split before they get worse.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: