Skip to content
Calcrivo

Pod Resource Calculator

Calculate optimal CPU and memory requests/limits for a Kubernetes pod and the total cluster resources needed across replicas.

Inputs

millicores

CPU request per pod, in millicores (1000m = 1 vCPU).

MiB

Memory request per pod, in MiB.

pods

Number of pod replicas in the deployment.

×

Multiplier applied to requests to derive limits (e.g. 2× means limits are double requests).

Total Cluster CPU Request

0.75cores

Total Cluster Memory Request

0.75GiB

Per-Pod CPU Limit

500millicores

Per-Pod Memory Limit

512MiB

Total Cluster CPU Limit

1.50cores

Total Cluster Memory Limit

1.50GiB

Step by step

  1. CPU limit: request × ratio

    250m × 2

    = 500m

  2. Memory limit: request × ratio

    256MiB × 2

    = 512MiB

  3. Total CPU request across replicas

    250m × 3

    = 750m (0.75 cores)

  4. Total memory request across replicas

    256MiB × 3

    = 768MiB (0.75 GiB)

How it works

Kubernetes schedules pods based on their resource requests, and enforces limits at runtime to prevent a single pod from starving its node. This calculator scales a single pod's CPU and memory request up to the full replica count to show total cluster capacity needed, and applies a limit-to-request ratio to compute the corresponding limits. A ratio of 1 means requests equal limits (Guaranteed QoS); higher ratios allow bursting but increase overcommit risk.

Formulas

Per-pod limit

limit = request × ratio

R
Per-pod resource request (CPU or memory)
\rho
Limit-to-request ratio
L
Per-pod resource limit

Total cluster request

totalRequest = request × replicas

R
Per-pod resource request
N
Number of replicas
T
Total cluster resource request

Frequently Asked Questions

What's the difference between requests and limits?

Requests are what the scheduler reserves for a pod when placing it on a node. Limits are the hard ceiling the kernel enforces — CPU is throttled and memory beyond the limit triggers an OOMKill.

What ratio should I use between requests and limits?

A ratio of 1 (Guaranteed QoS) is safest for predictable latency-sensitive workloads. Ratios of 1.5–3 are common for bursty workloads where you want headroom without over-reserving cluster capacity.

How does replica count affect cluster capacity planning?

Total cluster resources needed scale linearly with replica count. This is what you should compare against your node pool's allocatable capacity when planning autoscaling.

Should I set memory limits equal to requests?

Often yes — unlike CPU, memory can't be reclaimed gracefully, so many teams set memory limits equal to requests to avoid unpredictable OOMKills while still allowing CPU to burst.

You might also need