Kubernetes Cluster Capacity Planner: Pods, CPU, Memory and Node Count

Estimate how many equivalent Kubernetes worker nodes a workload needs from pod replicas, CPU and memory requests, node allocatable resources, per-node DaemonSet overhead, growth, headroom, and failed-node reserve.

All calculations run locally in your browser. Inputs are not sent to Starlight Tools. Treat the result as an initial homogeneous-node-pool estimate, then validate it with scheduler events, workload telemetry, autoscaler behavior, provider quotas, and failure tests.

By Technically reviewed: 28 July 2026Calculator version 1.0

Cluster inputs

Example data loaded: replace the illustrative workload and node shape with measured pod requests and allocatable values from the node pool you are planning.

Workload demand
pods
Exclude the per-node DaemonSet pods entered below.
%
Applied once to pod count and total requested resources.
mCPU
Use aggregate requested millicores ÷ workload pod count.
MiB
Use aggregate requested MiB ÷ workload pod count.
Equivalent worker node
cores
Enter Node Allocatable, not raw VM or machine CPU.
GiB
Enter allocatable GiB after system and kube reservations.
pods
Use the lower effective limit from kubelet, CNI/IP capacity, provider, and node type.
nodes
A policy floor for placement or operations, before failed-node reserve.
Planning ceilings and failed-node reserve
%
Percentage of allocatable CPU available to planned requests.
%
Percentage of allocatable memory available to planned requests.
%
Leaves pod slots for rollout and operational flexibility.
nodes
Added after active capacity: 1 models N+1-equivalent worker capacity.
Per-node DaemonSet overhead

Combine the requests of networking, storage, logging, monitoring, security, and other pods that run on every eligible node.

pods
mCPU
MiB
Example capacity plan calculated.

Capacity plan

Total worker nodes3534 active + 1 unavailable
Limiting constraintCPU requestslargest active-node requirement
Planned workload720 pods600 pods + 20% growth
Plan statusCapacity modeledvalidate placement and quotas
Active nodes required by constraint
CPU requests:34 nodes
Memory requests:16 nodes
Pod slots:9 nodes
Minimum policy:3 nodes
Active capacity + unavailable reserve:34 + 1 = 35 nodes
Payload capacity per active node
CPU after ceiling and DaemonSets:5.30 cores
Memory after ceiling and DaemonSets:23.50 GiB
Workload pod slots after ceiling and DaemonSets:85 pods
After modeled node loss
CPU
69.9% / 70%
Memory
34.7% / 75%
Pod slots
22.0% / 80%

Percentages include DaemonSet requests or pods on the 34 surviving nodes.

Normal-state cluster summary
Allocatable CPU:280 cores
Allocatable memory:1.09 TiB
Total pod slots:3,850 pods
Normal CPU / memory request use:68.0% / 33.7%
Extra same-size workload pods before first ceiling:2 pods

Interpretation: CPU requests determine this estimate. The last active node is only partly consumed because node requirements are rounded up.

Advertisement

Advertisement

How to plan Kubernetes worker capacity

  1. Measure schedulable demand: total the CPU and memory requests for the workload pods in this node pool. Divide by workload pod count only if an average-pod model is suitable.
  2. Use allocatable node values: read allocatable CPU and memory from representative nodes. Do not enter raw instance capacity and then subtract system reserve again.
  3. Verify the pod limit: enter the effective lower limit imposed by kubelet configuration, the CNI/IP design, managed service, and node type.
  4. Count node-local overhead: combine the requests and pod slots of DaemonSets that run on every eligible node.
  5. Set explicit policy: choose workload growth, request ceilings, a minimum active-node floor, and the number of nodes the pool must tolerate as unavailable.
  6. Review the largest result: the maximum of CPU, memory, pod slots, and minimum nodes is active capacity. The unavailable-node reserve is added afterward.
  7. Validate placement: test large pods, taints, affinity, topology spread, volume attachment, rollout surge, autoscaler limits, and a real node drain before production use.

Formula and assumptions

Planned pods: ceil(workload pods × (1 + growth %)).

Planned CPU: planned pods × average CPU request mCPU ÷ 1000 cores.

Planned memory: planned pods × average memory request MiB ÷ 1024 GiB.

CPU payload per active node: allocatable cores × CPU ceiling − DaemonSet requested cores.

Memory payload per active node: allocatable GiB × memory ceiling − DaemonSet requested GiB.

Workload pod slots per active node: floor(max pods × pod-slot ceiling) − DaemonSet pods.

Nodes by each resource: ceil(planned demand ÷ payload capacity per active node).

Active nodes: max(CPU nodes, memory nodes, pod-slot nodes, minimum active nodes).

Total nodes: active nodes + nodes allowed unavailable.

Units: CPU uses cores and millicores (1 core = 1,000 mCPU). Memory uses binary units (1 GiB = 1,024 MiB). Every node requirement rounds up to a whole node. The tool assumes one homogeneous worker pool and evenly distributable average demand.

Worked example: 600 pods on 8-core, 32 GiB nodes

With 20% growth, 600 workload pods become 720. At 250 mCPU and 512 MiB each, they request 180 CPU cores and 360 GiB memory.

CPU payload
8 × 70% − 0.3 = 5.3 cores/node
ceil(180 ÷ 5.3) = 34 active nodes
Memory payload
32 × 75% − 0.5 = 23.5 GiB/node
ceil(360 ÷ 23.5) = 16 active nodes
Pod payload
floor(110 × 80%) − 3 = 85 pods/node
ceil(720 ÷ 85) = 9 active nodes
Total
max(34, 16, 9, 3) + 1
35 total nodes

CPU is the binding constraint. After one node is unavailable, 34 nodes provide the planned CPU payload while preserving the selected 70% CPU-request ceiling.

What this estimate does not model

  • Bin-packing fragmentation: averages can fit mathematically even when a large individual pod cannot fit on any remaining node.
  • Placement constraints: node selectors, taints, tolerations, required affinity or anti-affinity, topology spread, zones, and dedicated pools can require more nodes.
  • Other schedulable resources: GPUs, huge pages, ephemeral storage, device claims, host ports, persistent-volume topology, and volume attachment limits are outside this model.
  • Runtime demand: requests drive this planner. CPU limits, memory limits, throttling, OOM risk, application bursts, and node-pressure eviction need separate analysis.
  • Operational transitions: rolling-update surge, drains, upgrades, image pulls, autoscaler delay, Spot/preemptible interruption, and simultaneous failures may need more buffer.
  • Control plane and service quotas: this estimates worker nodes only. Verify control-plane scale, API load, cloud quotas, CNI address space, load balancers, disks, and provider-specific limits.

Engineering limit: this browser tool is a first-pass capacity model, not a guarantee that pods will schedule or remain available. Confirm production sizing with actual manifests, scheduler simulation or staging, observability data, node drains, and official provider guidance.

Frequently asked questions

Should I use CPU and memory requests or limits?

Use requests for this scheduler-capacity estimate. The scheduler checks requested resources when filtering nodes. Review limits separately because they affect CPU throttling, memory enforcement, and runtime risk.

What does allocatable CPU and memory mean?

Node Allocatable is the resource available to pods after configured system and Kubernetes reservations. Use the allocatable values reported for the node, not the machine's raw capacity.

Why is DaemonSet overhead per node?

Node-local networking, storage, logging, monitoring, and security agents commonly run one pod on every eligible node. Each consumes requests and a pod slot, including on reserve nodes while they remain available.

Is 110 pods per node always the limit?

No. It is a Kubernetes large-cluster design consideration, not a universal fixed value. Your kubelet, CNI/IP capacity, managed service, and instance or node type may impose a different effective limit.

Does one reserve node guarantee N+1 high availability?

No. It reserves equivalent capacity in this arithmetic model. Successful recovery still depends on replicas, disruption budgets, topology, storage, control-plane health, and whether the failed-node workloads can be placed on surviving nodes.

When should I split the calculation by node pool?

Run a separate calculation for each materially different pool—such as general compute, memory optimized, GPU, Spot, architecture, zone, taint, or workload class—then review cross-pool failover only where pods can actually move between them.

Method sources

Official documentation checked 28 July 2026. The page deliberately does not load cloud-provider node presets because effective limits and allocatable resources depend on current service, version, CNI, quotas, and node configuration.

Explore more tools