Pod Overhead Calculation

Pods have overhead beyond app resources.

Sources of pod overhead

Pod overhead has three predictable sources. Sidecar containers (service mesh proxies, log forwarders, metrics agents) add CPU, memory, and startup time; kube-proxy and CNI plugins add network overhead per pod; container runtime overhead from containerd or CRI-O is non-zero and noticeable at small pod sizes.

• Sidecar containers. Service mesh proxies, log forwarders, metrics agents; each adds CPU, memory, startup time.
• kube-proxy and CNI. Network overhead per pod; CPU on every packet traversing the pod boundary.
• Container runtime baseline. containerd or CRI-O; not zero, not negligible at small pod sizes.
• Per-source measurement. Each source measured separately; supports targeted reduction.

Typical overhead percentages

The percentages are predictable. Without service mesh: 10-15% per pod, mostly sidecar agents. With service mesh: 20-35% per pod, Envoy or similar adds CPU and memory. Smaller pods feel the overhead more proportionally: 50m overhead on a 100m CPU pod is 33% waste, the same overhead on a 1000m pod is 5%.

• Without mesh: 10-15%. Mostly sidecar agents (logging, metrics); the baseline cost.
• With mesh: 20-35%. Envoy or similar mesh proxy adds CPU and memory; the mesh tax.
• Smaller pods feel it more. 100m pod with 50m overhead is 33% wasted; 1000m pod is 5%.
• Per-pod-size sensitivity. Pod sizing decisions should account for overhead percentage, not just absolute resource needs.

Planning capacity around overhead

Capacity planning must account for overhead at both pod and node levels. Pod requests include overhead (200m app + 40m overhead = 240m request); node-level reservation covers kubelet, kube-proxy, and CNI; standard reservation is 0.5 cores and 1GB per node, which larger nodes amortise and smaller nodes feel more.

• Pod requests include overhead. If app needs 200m CPU, request 240m to cover sidecar and runtime overhead.
• Node-level reservation. Beyond pod overhead; kubelet, kube-proxy, CNI consume node resources.
• Standard reservation. 0.5 cores and 1GB per node for system; larger nodes amortise, smaller nodes feel it.
• Per-cluster reservation policy. The reservation amount documented per node class; supports consistent capacity planning.

Reducing overhead

Three patterns reduce overhead at scale. Sidecar consolidation folds multiple agents into one process; DaemonSet for shared functionality runs one log forwarder per node instead of one per pod; service mesh sampling captures only a fraction of traces and metrics rather than every request.

• Sidecar consolidation. Multiple agents fold into one; fewer processes, less memory, simpler operation.
• DaemonSet for shared functionality. One log forwarder per node instead of one per pod; massive reduction at scale.
• Service mesh sampling. Sample traces and metrics rather than capturing every request; reduces mesh tax.
• Per-pattern measurement. Each reduction measured for actual savings; supports continued investment.

What to monitor

The overhead signal is in three places. Node-level utilisation vs pod requests (gap is overhead plus headroom); per-pod actual vs requested (overhead shows up as systemic difference between request and use); pod startup time (heavy sidecars dominate, so optimise the slowest sidecar first).

• Node-level vs pod requests. Gap is overhead plus actual headroom; the macro view.
• Per-pod actual vs requested. Overhead shows up as systemic difference between request and use.
• Pod startup time. Heavy sidecars dominate; optimise the slowest sidecar first.
• Per-cluster overhead dashboard. Documented overhead trend; supports the reduction discipline over time.