☸️ Kubernetes milliCPUs to Core Clusters
1000m = 1 vCPU = 1 hyperthread. 250m = 0.25 cores. Your 32-core node with 64 pods at 500m each — 32 cores requested, 32 cores total, theoretically packed. But requests are not limits. When 12 pods spike to 2000m, your node is overcommitted by 2×. Model the real math before CPU throttling cascades through your deployment.
📐 Cluster Workload Profile
Set pod milliCPU, replicas, and node vCPU capacity. The engine converts milliCPU to fractional vCPUs, computes total cluster demand, and derives minimum nodes at 90% allocatable. Overcommit ratio is surfaced — not hidden.
Kubernetes milliCPU: 1000m = 1 vCPU Core
Kubernetes expresses CPU resources in milliCPU (or millicores), where 1000m = 1 vCPU core. This fractional unit allows fine-grained resource allocation: a pod requesting 250m gets one-quarter of a CPU core's time slice. Under the hood, Kubernetes maps these requests to Linux cgroup CFS (Completely Fair Scheduler) quotas — a 250m request translates to 25 ms of CPU time per 100 ms scheduling period. When a container exceeds its CPU limit, it is throttled (not killed), causing latency spikes that are notoriously difficult to diagnose without kernel-level tracing.
How This Calculator Works
| Step | Formula | Description |
|---|---|---|
| vCPU per Pod | milliCPU ÷ 1000 | Convert pod request from millicores to fractional vCPUs |
| Total CPU Demand | vCPU/Pod × Replicas | Aggregate fleet CPU requirement across all replicas |
| Allocatable per Node | Node vCPUs × 0.90 | Kubernetes reserves ~10% for system daemons (kubelet, container runtime, OS), leaving 90% allocatable |
| Nodes Needed | ceil(Total CPU ÷ Allocatable) | Minimum nodes to satisfy total demand with system reservations |
Compressible vs. Incompressible Resources
CPU is a compressible resource in Kubernetes — when a pod exceeds its CPU limit, the kernel throttles it rather than evicting it. This contrasts with memory, which is incompressible: exceeding the memory limit triggers an OOM kill and pod restart. This fundamental asymmetry means that CPU limits can be set more aggressively than memory limits, but excessive CPU throttling causes tail latency degradation that cascades through microservice dependency chains. Production clusters should monitor container_cpu_cfs_throttled_seconds_total to detect under-provisioned CPU before users notice.
System Reservations and CFS Throttling
The 90% allocatable assumption accounts for Kubernetes system overhead: the kubelet, container runtime (containerd/CRI-O), kube-proxy, and OS-level daemons collectively consume 5–10% of node CPU. Additionally, the CFS scheduler enforces quota periods (default 100 ms) — a pod with a 500m limit can burst for 50 ms but is then throttled for the remaining 50 ms of the period. This CFS quota-based throttling is a leading cause of "mystery latency" in Kubernetes deployments, especially for bursty workloads like API gateways and stream processors.