Kubernetes Resource Requests und Limits: Scheduling, Throttling und OOM-Kills

Worum es geht

Jeder Container in einem Pod kann resources.requests und resources.limits für CPU und Memory deklarieren. Die zitierte Kubernetes-Dokumentation trennt die beiden Rollen: Der Scheduler verwendet Requests, um einen Node mit ausreichend unreservierter Kapazität auszuwählen, und das Kubelet reserviert für den Container mindestens den angeforderten Betrag; Limits werden vom Kubelet und der Container-Runtime und letztlich vom Kernel über Cgroups durchgesetzt. Die Durchsetzung unterscheidet sich je nach Ressource: CPU-Limits werden per Throttling durchgesetzt, sodass ein Container nie mehr CPU erhält als sein Limit; Memory-Limits werden reaktiv durch Out-of-Memory-Kills durchgesetzt, die laut Dokumentation nur eintreten, wenn der Kernel Speicherdruck erkennt, sodass ein Container eine Weile mehr als sein Memory-Limit nutzen kann, bevor er getötet wird. Wird ein Limit ohne Request gesetzt, kopiert Kubernetes das Limit in den Request.

Die zitierte QoS-Seite leitet aus diesen Feldern eine Klasse ab: Guaranteed, wenn jeder Container für CPU und Memory gleiche Requests und Limits hat, Burstable, wenn mindestens ein Container einen Request oder ein Limit hat, die Kriterien für Guaranteed aber nicht erfüllt sind, und BestEffort, wenn nichts gesetzt ist. Unter Node-Druck werden zuerst BestEffort-Pods entfernt, dann Burstable, dann Guaranteed, und nur Pods, die ihre Requests überschreiten, kommen als Entfernungskandidaten infrage.

Warum es wichtig ist

Requests entscheiden über Bin-Packing und damit über Kosten; Limits entscheiden über die Art des Ausfalls. Ein CPU-Limit nahe an der typischen Nutzung verwandelt Latenzspitzen in Throttling, das in Anwendungsprotokollen unsichtbar bleibt; ein Memory-Limit unterhalb des realen Working Set verwandelt ein langsames Leck in periodische Neustarts mit Exit-Code 137. Pods ohne Requests landen dort, wo gerade Platz ist, und werden als Erste entfernt.

So wird es angewendet

• Immer Memory-Requests und -Limits setzen; sie für Dienste, deren Entfernung einen Vorfall darstellen würde, gleich setzen, was die Klasse Guaranteed ergibt.
• CPU-Requests anhand der beobachteten Nutzung setzen; bei CPU-Limits bewusst vorgehen, denn die Überschreitung kostet Throttling, nicht Entfernung.
• Die Neustartanzahl und den letzten Beendigungsgrund des Containers (OOMKilled) sowie CPU-Throttling-Metriken der Runtime beobachten, nicht nur die Anwendungslatenz.
• Namespace-Standardwerte mit LimitRange anwenden, damit vergessene Felder nicht stillschweigend BestEffort-Pods erzeugen, und Gesamtwerte mit ResourceQuota begrenzen.
• Requests für den JVM-, Node.js- oder Python-Prozess selbst bemessen, einschliesslich seiner Heap-Einstellungen zur Laufzeit, nicht für den untätigen Container.

Stolpersteine

Ein Memory-Limit ist keine Speicherreservierung für den Node: Die Summe der Limits über alle Pods kann die Kapazität des Nodes überschreiten. Das Ändern von Requests oder Limits bedeutete historisch, den Pod neu zu erstellen; die zitierte Seite beschreibt eine In-Place-Grössenänderung, deren Verfügbarkeit von der Cluster-Version abhängt.

CPU-Limits: meist besser weglassen

Ein CPU-Request wird in das CPU-Gewicht der Cgroup umgesetzt, das dem Container bei Konkurrenz auf dem Node bereits seinen Anteil garantiert; ein CPU-Limit bringt nur zusätzliches Throttling. Das CFS-Quota wird pro 100-ms-Periode gewährt, sodass ein auf eine CPU begrenzter Container, dessen vier Threads gleichzeitig aufwachen, das Quota der Periode in 25 ms verbraucht und die restlichen 75 ms wartet, und zwar in jeder Periode — das zeigt sich als Latenz, während die CPU-Grafiken ruhig aussehen. Vor dem Verdacht auf fehlerhaften Code container_cpu_cfs_throttled_periods_total gegen container_cpu_cfs_periods_total prüfen. CPU-Limits dort behalten, wo sie gebraucht werden: bei der statischen CPU-Manager-Policy (Guaranteed QoS mit ganzzahligen CPUs), in einem Multi-Tenant-Cluster, in dem freie Kapazität nicht nutzbar sein darf, oder bei einem Pod, der die QoS-Klasse Guaranteed benötigt, was CPU-Limits gleich den Requests voraussetzt. Memory-Limits immer setzen.