Notes / tag / performance

#performance

15 notes across 3 topics

1 — Resource Optimization

Why requests should track real p95 usage while limits stay loose — tight CPU limits throttle a container even when the node has idle capacity sitting unused right next to it.

kubernetes performance book

2 — Scheduler Performance

Why scheduling throughput degrades non-linearly past a few thousand nodes unless percentageOfNodesToScore is tuned down from its default of scoring every feasible node.

kubernetes performance book

3 — Cluster Autoscaler

Why Cluster Autoscaler scales purely on unschedulable pending pods rather than utilization metrics, making it reactive by design and blind to a burst until pods have already failed to schedule.

kubernetes performance book

4 — Karpenter

Why Karpenter provisions right-sized nodes directly from pending pod shape instead of scaling pre-defined node groups, collapsing the ASG-and-node-group abstraction Cluster Autoscaler depends on.

kubernetes performance book

5 — Vertical Pod Autoscaler

Why VPA's Auto and Recreate update modes still evict and restart a pod to resize it — true in-place resize without disruption only lands with the still-maturing InPlacePodVerticalScaling feature.

kubernetes performance book

6 — Horizontal Pod Autoscaler

Why HPA's polling-interval and stabilization-window defaults make it structurally too slow for sub-minute traffic spikes, forcing teams toward custom metrics or KEDA to react in time.

kubernetes performance book

7 — Network Performance

Why the CNI's choice between an overlay (VXLAN/IPIP encapsulation) and native BGP routing is usually the single biggest lever on pod-to-pod latency and throughput, ahead of kube-proxy mode.

kubernetes performance book

8 — Storage Performance

Why local NVMe (local-path or a CSI ephemeral volume) beats network-attached PVs on latency, but only by trading away the pod-to-node decoupling that makes rescheduling safe.

kubernetes performance book

9 — Large Cluster Design

Why Kubernetes' official node-count ceiling is really an etcd write-throughput and API server watch-fanout limit, which is why hyperscalers split fleets into many smaller clusters instead of pushing past it.

kubernetes performance book