Kubernetes Resource Calculator

Formula: Totals = replicas × per-pod value (1 CPU = 1,000m). Surge pods = ceil(replicas × maxSurge). Pods per node = min(floor(usable CPU ÷ CPU request), floor(usable memory ÷ memory request)); nodes = ceil(pods ÷ pods per node).

Worked example:12 pods requesting 250m CPU and 256 MiB request 3 CPU and 3 GiB. With 25% surge the rollout peaks at 15 pods; 13 pods fit on a 4,000m / 16 GiB node with 15% headroom, so 1 node suffices before and 2 during the rollout.

Common mistake or edge case:Schedulers place pods using requests, not limits. Leave capacity for system pods, DaemonSets, and the surge pods a rolling update creates.

Additional official references:

• Kubernetes pod quality of service classes
• Kubernetes Deployment rolling update (maxSurge)

Read the supporting guide and worked examples.

For a standalone Docker host, use the Docker memory calculator instead.

Frequently asked questions

Should cluster capacity planning use requests or limits?

Use requests: the scheduler places pods based on requests, so summed requests tell you what capacity is actually reserved. Limits only cap what a pod can burst to and can safely exceed available node capacity if pods rarely hit them simultaneously.

What QoS class will my pods get?

Guaranteed when every container's CPU and memory requests equal their limits, BestEffort when nothing is set, and Burstable otherwise. The calculator shows the class for the values entered.

Why plan for rollout surge?

A Deployment rolling update creates up to maxSurge extra pods (25% by default, rounded up) before old pods terminate. If the cluster has no room for them, the rollout stalls with Pending pods.