Kubernetes node sizing calculator: how many nodes your pods need

How it is calculated

EKS and GKE: R_cpu(c) = 6% of the first 1000 m + 1% of the next 1000 m + 0.5% of the next 2000 m + 0.25% above 4000 m
AKS: a documented table (60, 100, 140, 180, 260, 420, 740 m at 1, 2, 4, 8, 16, 32, 64 cores)

EKS:  R_mem = 255 + 11 × P MiB
GKE:  R_mem = 25% of the first 4 GiB + 20% of the next 4 + 10% of the next 8 + 6% of the next 112 + 2% above 128 GiB (255 MiB under 1 GiB)
AKS:  R_mem = min(20 × P + 50 MiB, 25% of node memory)
Generic: R_mem = the percentage you supply × node memory

A_cpu = c − R_cpu
A_mem = M − R_mem − E          (E = hard eviction threshold, 100 MiB)
U = A − D                      (D = DaemonSet request per node; U is what is left for your pods)

S = T × (1 + h) × (1 + f)
n = max( ceil(S_cpu ÷ U_cpu), ceil(S_mem ÷ U_mem), ceil(N_pods × (1 + h) ÷ (P − p_ds)), n_az )

waste = 1 − T ÷ (n × U)   (reported for CPU and memory)
EKS max pods: ENIs × (IPs per ENI − 1) + 2; with prefix delegation the dataset's higher value
monthly cost = n × hourly rate for the pricing mode × 730

Assumptions

• T is the summed pod requests, h the headroom, f the fragmentation, P the max pods per node, p_ds the DaemonSet pods per node and n_az the zone count (the minimum node count).
• Headroom also scales the pod count in the max-pods term. Fragmentation does not.
• All pods are packed onto identical nodes of one instance type. A node must fit the DaemonSets and the largest single pod; an instance that cannot is shown as not fitting.
• The binding constraint is every term equal to n, so ties are all reported. Waste is measured against the requests T, before headroom and fragmentation.
• Reservations are whole millicores and MiB. Summed memory limits are compared with the allocatable memory of all n nodes for the overcommit warning; the table form of the workloads uses each row's own limit when given.
• GKE uses the memory tiers for node pools created on 1.36 or earlier; newer pools can reserve less. AKS uses the 1.29-and-later memory rule and a CPU table that differs from the EKS and GKE schedule.
• Prices are list prices in USD for one region per cloud (US East N. Virginia, us-central1, East US), 730 hours a month. Cluster management fees, storage, network, licences, discounts and autoscaler behaviour are not modelled.
• EKS prices in the dataset are from a third-party aggregator and are flagged unverified. GKE and AKS prices were read from the cloud's own price pages.

The data behind it

Three ways to reduce this number

1. Match the family to the binding constraint: compute-optimized instances when CPU binds, memory-optimized when memory binds.
2. Right-size requests from observed usage. Requests set from guesses are the usual source of idle CPU and memory.
3. Use spot capacity for stateless workloads, and reserve the steady base.

Use it from code

The same engine is available as a REST endpoint and as an MCP tool named calc_kubernetes_node_pod_sizing_calculator. Your scenario as an API call:

curl -X POST 'https://api.x12i.com/v1/calc/kubernetes-node-pod-sizing-calculator' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
  "input": {
    "cloud_target": "eks",
    "service_count": 40,
    "avg_replicas": 3,
    "avg_pod_cpu_request_m": 250,
    "avg_pod_mem_request_mib": 512,
    "daemonset_cpu_m_per_node": 150,
    "daemonset_mem_mib_per_node": 256,
    "daemonset_pod_count": 4,
    "headroom_pct": 25,
    "fragmentation_pct": 5,
    "az_count": 3,
    "eks_prefix_delegation": false,
    "generic_reserved_mem_pct": 10,
    "pricing_mode": "on_demand",
    "platform_team": false
  },
  "options": {
    "explain": false
  }
}'

Copy as API call Schema: GET /v1/calc/kubernetes-node-pod-sizing-calculator/schema

Frequently asked questions

Related calculators