Compare the 110 default and 250 maximum pods per node against the 4-pods-per-vCPU guideline and your DaemonSet overhead.
Two independent ceilings apply. maxPods is a hard kubelet limit driven by network and runtime scalability, while the pods-per-vCPU guideline reflects the fact that each pod costs the kubelet and the runtime real CPU regardless of what the container does. DaemonSets then take their slots off the top of whichever ceiling is lower. Density decides node size and therefore cost, and a cluster running above 90% of its pod capacity cannot survive a node failure — the evicted pods have nowhere to reschedule.
OpenShift Pod Density
application pods per node = min(maxPods, vCPUs × pods per vCPU) − DaemonSet pods; cluster capacity is that multiplied by the node count.
application pods per node = min(maxPods, vCPUs × pods per vCPU) − DaemonSet pods; cluster capacity is that multiplied by the node count. Two independent ceilings apply. maxPods is a hard kubelet limit driven by network and runtime scalability, while the pods-per-vCPU guideline reflects the fact that each pod costs the kubelet and the runtime real CPU regardless of what the container does. DaemonSets then take their slots off the top of whichever ceiling is lower.
Density decides node size and therefore cost, and a cluster running above 90% of its pod capacity cannot survive a node failure — the evicted pods have nowhere to reschedule.
This calculator takes 6 inputs: Worker nodes, vCPUs per node, Pods per vCPU guideline, maxPods in the kubelet config, DaemonSet pods per node, Application pods running today. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Beyond about 250 pods the kubelet's status reporting, the CNI's IP address management and the iptables or nftables rule set all grow to the point where node status updates and service reconvergence become the bottleneck. 500 is achievable but requires deliberate tuning and testing.