Container CPU requests and limits explained with GOMAXPROCS tuning
7 months ago
- #Go Runtime
- #Kubernetes
- #CPU Management
- Kubernetes and Linux kernel manage CPU for containers using cgroups.
- Three QoS classes in Kubernetes: Guaranteed, Burstable, and Best-Effort.
- Guaranteed pods have equal CPU and memory requests and limits.
- Burstable pods have lower requests than limits.
- Best-Effort pods have no requests or limits.
- QoS classes affect OOM scores, influencing process termination during memory pressure.
- CPU requests translate to cpu.shares (v1) or cpu.weight (v2).
- CPU limits become cpu.cfs_quota_us (v1) or cpu.max (v2).
- Linux kernel creates cgroups under /sys/fs/cgroup.
- Kubernetes CPU Manager has two policies: none (default) and static.
- Static policy gives exclusive CPU core access to Guaranteed pods with full CPU requests.
- CFS (Completely Fair Scheduler) handles CPU sharing under the none policy.
- CPU requests influence scheduling and runtime behavior during CPU pressure.
- CPU limits cap CPU time, causing throttling when exceeded.
- Debate on whether to use CPU limits due to potential performance impact.
- CPU weight determines fair CPU time allocation during contention.
- CPU max enforces absolute CPU time limits, unlike weight.
- Go runtime's GOMAXPROCS defaults to node's CPU count, not container limits.
- Setting GOMAXPROCS to match container CPU limits can improve performance.
- uber-go/automaxprocs library adjusts GOMAXPROCS based on cgroup CPU limits.
- cAdvisor provides CPU usage and throttling metrics from /sys/fs/cgroup.
- CPU pressure metrics show task stalls due to CPU contention.