cgroups (Control Groups) sind ein Mechanismus des Linux-Kernels, um Ressourcen wie CPU, Arbeitsspeicher und I/O zu begrenzen und zu messen. Kubernetes nutzt sie für jede Ebene der Isolation: Requests und Limits aus dem Pod-Manifest werden in cgroup-Werte übersetzt.
cgroup v2 ist der Standard
Kubernetes setzt inzwischen auf cgroup v2; cgroup v1 gilt als veraltet. Der Kubelet startet auf cgroup-v1-Knoten nicht mehr standardmäßig. Wichtig ist der cgroup-Treiber: Er muss zwischen Kubelet und Container-Runtime übereinstimmen – empfohlen ist systemd, alternativ cgroupfs.
Vom Limit zur cgroup
Ein Container mit resources.limits.cpu und resources.limits.memory bekommt in cgroup v2 entsprechend cpu.max und memory.max gesetzt. Überschreitet ein Container sein Memory-Limit, beendet der Kernel ihn per OOM-Kill; beim CPU-Limit greift stattdessen Throttling. Requests steuern die Zuteilung des Schedulers und die Priorisierung unter Druck.
Die Hierarchie
Der Kubelet legt pro Pod eine Pod-cgroup an; die Container-Runtime ordnet darunter die Container-cgroups ein. Die QoS-Klassen bilden eigene Untergruppen (Guaranteed, Burstable, BestEffort), damit Kubernetes bei Knappheit in der richtigen Reihenfolge beendet. Auch ResourceQuota und LimitRange wirken über Requests und Limits in dieses System hinein.
Warum cgroups so zentral sind
Kubernetes misst den tatsächlichen Verbrauch über die cgroup-Statistiken (etwa via cAdvisor). Darauf baut die Eviction API auf: Signale wie memory.available sind cgroup-basiert. Sandbox-Runtimes wie gVisor oder Firecracker kapseln ihre Isolation zusätzlich in cgroups und Namespaces, genau wie klassische Container (LXC, runc).
Der Descheduler nutzt dieselben cgroup-Messwerte, um ungleiche Auslastung zwischen Knoten zu erkennen und Pods umzuverteilen.
Verwandte Grundlagen: Kubelet, Container-Runtime, Eviction API.