讨论： Kubernetes resource requests and limits: scheduling, throttling and OOM kills

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

暂无译文，显示原文。 原文

A detail behind 'watch the restart count and `OOMKilled`': the kernel's OOM killer picks one process in the container's cgroup, normally the largest, and for years that was not necessarily the container's main process, so a killed worker in a multi-process container (a gunicorn or PHP-FPM child, a sidecar thread pool's helper) left PID 1 running, no restart, no `OOMKilled` reason and only a line in the node's kernel log. On cgroup v2 the kubelet has set `memory.oom.group` on container cgroups since Kubernetes 1.28, so an OOM condition kills every process in the container and the event becomes visible as a restart; 1.32 added the kubelet setting `singleProcessOOMKill` to switch back to the old behaviour for workloads that prefer it. Clusters still on cgroup v1, or on older kubelets, should watch the kernel log or the runtime's OOM events as well as the container status. Exit code 137 is 128 plus 9, the SIGKILL the kernel sends.

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

暂无译文，显示原文。 原文

'Be deliberate about CPU limits' is too soft; for most services the deliberate choice is to set a CPU request and no CPU limit, and the article should say why. A request becomes the cgroup's CPU weight, which already guarantees the container its share under contention, so a limit adds nothing to isolation; it only throttles. The throttling is coarser than 'never more than its limit' suggests: the CFS quota is granted per 100 ms period, so a container with a limit of one CPU whose four threads become runnable at once uses the whole period's quota in 25 ms and then waits 75 ms, on every period, which is a latency cliff invisible in CPU utilisation graphs and visible only in `container_cpu_cfs_throttled_periods_total` against `container_cpu_cfs_periods_total`. Limits are still right in three cases: the static CPU manager policy, which needs Guaranteed QoS with integer CPU values to pin cores; a multi-tenant cluster where one tenant must not be able to consume idle capacity that others paid for; and a Pod that must be in the Guaranteed QoS class for eviction ordering, which the article's own QoS section says requires limits equal to requests for CPU as well. Outside those, the memory half of the bullet ('always set') and the CPU half ('be deliberate') should read differently.