System Requirements
Kubernetes Cluster: System Requirements
Kubernetes resource consumption depends on the selected topology, installed components, monitoring tools, active workloads, and application demand. The values below are minimum measurements for bare development and production clusters and should not be treated as final sizing targets for loaded environments.
Regional availability: The Kubernetes Cluster package may not be available in every platform region because availability can depend on the hardware characteristics of that region. Contact the hosting provider if the package is unavailable in the required region.
On this page
Minimum Resource Requirements
The following figures were measured on bare Kubernetes clusters with only a sample Hello World deployment and no additional application load.
| Resource | Development Cluster | Production Cluster |
|---|---|---|
| Cloudlets | 14 | 33 |
| RAM & CPU | 1.4 GiB RAM 419 MHz CPU | 3.6 GiB RAM 947 MHz CPU |
| Storage | 5.65 GB | 15.01 GB |
These values are minimum system requirements measured without additional workload. Real production consumption can be significantly higher after applications, monitoring, storage, ingress, and other cluster services are added.
Development Cluster Topology
Master Nodes1 master node.
Worker Nodes1 worker node.
Storage1 storage node.
MonitoringNo monitoring tools in the measured development topology.
The development topology is recommended only for sandbox, learning, testing, and non-production workloads.
Production Cluster Topology
API BalancerDedicated Kubernetes API balancing component.
Master Nodes3 master nodes for a highly available control plane.
Worker Nodes2 worker nodes in the measured baseline.
Storage1 storage node.
MonitoringMonitoring tools included.
Sample WorkloadOnly a sample Hello World deployment.
For production environments, a highly available topology with multiple master nodes is preferred.
Storage and etcd Performance
Fast storage is particularly important for etcd, the distributed key-value store Kubernetes uses to maintain cluster state.
- Slow etcd storage increases cluster-state read/write latency.
- Poor etcd performance can contribute to failed workloads and cluster instability.
- Disk speed and latency should be treated as core infrastructure requirements, not only as storage-capacity considerations.
Critical requirement: Do not size Kubernetes only by total disk capacity. Fast disks are important for etcd and therefore for control-plane stability.
Production Scaling Recommendations
- Add worker nodes as application workload increases.
- Workers can be added manually or through automatic horizontal scaling.
- Add more master nodes only when there is a significant increase in control-plane requests.
Additional master capacity becomes useful when many requests originate from Kubernetes clients and control-plane consumers such as kubectl, Kubernetes Dashboard, continuous-integration jobs, and Kubernetes-native applications.
Worker scaling is driven mainly by application workloads, while additional master capacity is justified primarily by high Kubernetes API and control-plane demand.
Overall sizing rule: Use the published development and production figures only as minimum baselines. Production sizing should account for expected workload, storage performance, monitoring, cluster add-ons, redundancy, and future scaling.