cgroups (Control Groups)

Als Docker-Nutzer siehst du cgroups ständig: docker run --cpus="1.5" --memory="512m" nginx Das übersetzt Docker im Hintergrund in cgroup-Regeln.

1. Es erstellt einen cgroup Ordner: /sys/fs/cgroup/cpu/docker/<container-id>.
2. Es schreibt 150000 in cpu.cfs_quota_us.
3. Es schreibt 536870912 in memory.limit_in_bytes.

Du kannst es prüfen mit docker stats. Das Tool liest einfach die cgroup-Metriken aus.

Praxisroutine

In der Praxis lernst du cgroups (Control Groups), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. v1 vs. v2

Es gibt zwei Versionen der cgroup API.

• cgroup v1: Hierarchisch chaotisch. Jede Ressource (cpu, memory) hatte eigene Ordnerstrukturen. Schwer zu koordinieren.
• cgroup v2 (Unified Hierarchy): Der neue Standard (in modernen Distros und K8s). Alles ist in einem Baum. Ermöglicht bessere Features wie "Resource Pressure Stall Information" (PSI) und sichereres Rootless Docker.

2. OOM Killer (Out of Memory)

Was passiert, wenn die cgroup voll ist? Wenn ein Prozess das Limit (Hard Limit) erreicht, greift der OOM Killer innerhalb der cgroup ein. Er tötet den Prozess mit dem höchsten Verbrauch. Exit Code 137 (128 + 9 SIGKILL) in Docker ist das klassische Zeichen: "Der Cgroup-Türsteher hat zugeschlagen". Der Rest des Systems (Host) bleibt unberührt.

3. CPU Shares vs. CPU Quota

• CPU Quota (Hard Limit): "Du bekommst exakt 0.5 CPUs". Wenn Limit erreicht ist, wird der Prozess vom Scheduler "gedrosselt" (Throttling). Er pausiert für den Rest der Periode (100ms). Führt zu Latenz-Spikes!
• CPU Shares (Soft Limit): "Du bekommst Priorität 1024". Wenn die CPU leer ist, darfst du 100% nehmen. Wenn Stau ist, kriegst du deinen Anteil. Besser für Auslastung, aber weniger vorhersehbar.

1. CPU CFS Quota vs. CPU Shares (Hard vs. Soft)

Wie verteilt Kubernetes die Rechenkraft auf Pods? Wird unter resources: requests CPU gefordert, setzt cgroups die cpu.shares. Das ist eine rein relative Zahl (z.B. 1024 vs 512). Alle Container nutzen 100% der Hardware. Nur falls Ressourcenknappheit entsteht, priorisiert der Kernel den 1024-Prozess mit gnadenlos doppelter CPU-Länge (Soft-Limit). Nutzt man resources: limits, feuert cgroups die scharfe Waffe: CFS Quota (Completely Fair Scheduler). In einem Fenster von zumeist 100ms kriegt der Container $X$ Mikrosekunden Rechenzeit. Ist der Burst innerhalb von 20ms aufgebraucht, "throttelt" der Kernel den Prozess brutal für die restlichen 80ms (Freeze). Selbst wenn das Rechenzentrum leer steht, blockiert cgroups künstlich und induziert furchtbare 99th-Percentile Latenz-Aussetzer bei Java-Gartner-Knoten.

2. EBPF und OOM-Debugging

Früher war der "OOM Killer" ein Phantom der Blackbox. Wenn ein Java-Heap den Root-CGroup des Docker-Containers überlief, stürzte alles mit SIGKILL und Exit Code 137 ab, oft gänzlich ohne Log. Mit modernen eBPF (Extended Berkeley Packet Filter) Hooks schaut die Cloud-Welt tief ins cgroup-Subsystem. Tools greifen sich im Kernel-Space sofort Pointers ab, sobald die Funktion mem_cgroup_out_of_memory triggert. Sie exportieren den exakten Call-Stack, den Call-Graph-RSS-Graphen sowie Block-I/O Engpässe des Userspace, noch drei Millisekunden bevor der Container endgültig verdampft, ins Elasticsearch-Dashboard.

3. Namespace/Cgroup v2 unified hierarchy

Cgroups v1 war evolutionärer Bastelcode. Ein Prozess lag bei Memory in einem anderen Hierarchiebaum als bei CPU, was es extrem anfällig für "Race Conditions" bei Start/Stop-Orchestrierungen machte. Cgroups v2 (Standard seit Kubernetes 1.25+ und dem systemd Umbruch) verschmilzt das Konzept. Ein Task gehört zu genau einer Node in einem einzigen, zentralen cgroup-V2-Baum, durch alle Controller tiefgeschachtelt hinweg. Dadurch erst wurde es möglich zu beobachten, dass exzessive Speicher-Auslagerung (Swap) in Wahrheit ein I/O-Bandbreitenproblem zur Platte darstellt. Mit V2 kann der Controller endlich Memory-Druck und Disk-Latencies als kombiniertes Limit regeln ("Pressure Stall Information").