Tested Cluster Limits
Purpose: For platform engineers and operators, documents the tested maximums for openCenter clusters so teams can plan capacity against validated boundaries.
Tested Limits
| Resource | Tested Maximum | Notes |
|---|---|---|
| Nodes per cluster | 200 | Validated with 3 control-plane + 197 workers |
| Pods per node | 110 | Kubelet default; tested stable at 110 with Calico |
| Pods per cluster | 25,000 | At 200 nodes × 110 pods, API server stable |
| Services per cluster | 2,000 | ClusterIP + LoadBalancer combined |
| Namespaces per cluster | 500 | With RBAC and NetworkPolicy per namespace |
| ConfigMaps + Secrets | 10,000 | etcd storage sized accordingly |
| FluxCD Kustomizations | 200 | Concurrent reconciliation throughput |
| HelmReleases | 150 | With dependency ordering |
| Kyverno policies | 50 | ClusterPolicy + Policy combined |
Test Methodology
Limits are validated using:
- kube-burner for pod/service density tests
- Prometheus load generators for metrics pipeline validation
- FluxCD stress profiles for GitOps reconciliation throughput
Tests run against the Large reference topology (3 control-plane nodes, 8 vCPU / 32 GB each; workers at 4 vCPU / 16 GB).
Factors That Reduce Limits
- Pod Security Admission webhook latency at high admission rates
- Kyverno policy complexity (regex-heavy policies reduce throughput)
- etcd disk I/O on spinning disks vs. NVMe
- CNI overlay mode vs. direct routing (overlay adds ~10% latency)
Recommendations
- Monitor etcd
db_sizeand defragment proactively above 4 GB - Shard FluxCD controllers for clusters above 100 Kustomizations
- Use node-local DNS cache for clusters above 50 nodes