Namensräume und cgroups in Linux: die eigentliche Grundlage von Containern

Informatec Digital » Ressourcen » Namensräume und cgroups in Linux: die eigentliche Grundlage von Containern

Wer mit Docker, Kubernetes oder einer anderen Containerplattform arbeitet, wird früher oder später mit den internen Abläufen des Systems konfrontiert. Hinter der scheinbaren Magie, Container in Sekundenschnelle zu starten, verbergen sich zwei Schlüsselkomponenten des Linux-Kernels: Namespaces und Cgroups. Dieses Duo ist für die Isolation und das fein abgestimmte Ressourcenmanagement verantwortlich . Ihr Verständnis ist entscheidend, um zwischen der bloßen Nutzung von Tools und der Entwicklung der Infrastruktur zu unterscheiden.

Im Verlauf dieses Artikels werden wir ruhig, aber ohne zu sehr ins Detail zu gehen, erklären, wie sie funktionieren. Namensräume (was ein Prozess sehen kann) und Cgroups (was ein Prozess verwenden kann)Wie Docker und Kubernetes diese nutzen; wie Sie sie auf niedriger Ebene mit Befehlen wie diesen anpassen können. unshare, ip netns oder direkt schreiben in /sys/fs/cgroupUnd welche Tricks sind nützlich für Leistung, Sicherheit und Fehlerbehebung in Produktionsumgebungen?

Was genau bewirkt ein Container unter Linux?

Wenn Sie etwas wie Folgendes ausführen docker runEs wird keine magische virtuelle Maschine erschaffen; Das Ergebnis ist ein Linux-Prozess (oder eine Gruppe von Prozessen) mit starker Isolation und begrenzten Ressourcen.Der „Trick“ basiert auf vier Kernmechanismen:

• NamensräumeSie steuern, was der Prozess sieht (Prozess-IDs, Netzwerk, Dateisystem, Hostname usw.).
• GruppenSie kontrollieren, wie viel der Prozess nutzen kann (CPU, RAM, E/A, PIDs…).
• Chroot / Rootfs isoliertSie geben dem Prozess ein eigenes Dateisystem.
• Normale Linux-ProzesseAm Ende kommt es alles auf die vom Kernel verwalteten Host-PIDs an.

Anders ausgedrückt: Ein Container ist einfach ein Prozess, der mit neuen Namensräumen innerhalb einer oder mehrerer Cgroups und einem benutzerdefinierten Dateisystem ausgeführt wird . Die restliche Verwaltung übernimmt das Tool (Docker, containerd, runc usw.) mit Automatisierung und benutzerfreundlichen APIs.

Linux-Namespaces: Isolierung dessen, was jeder Prozess sehen kann

Namensräume bilden eine Abstraktionsschicht des Kernels, die separate „Welten“ für Gruppen von Prozessen schafft . Ein Prozess sieht nur die Ressourcen innerhalb seines Namensraums; der Rest des Systems ist weiterhin vorhanden, aber für ihn unsichtbar.

Linux verfügt aktuell über mehrere Arten von Namensräumen, die jeweils auf einen bestimmten Teil des Systems fokussiert sind. In Kombination ermöglichen sie es, dass ein Container als eigenständiges Betriebssystem wahrgenommen wird, obwohl er sich den Kernel mit dem Hostsystem teilt.

Haupttypen von Namensräumen

Jeder Namespace-Typ isoliert eine andere Dimension. In einem professionellen Container ist es üblich, mehrere davon gleichzeitig zu verwenden. Die wichtigsten sind:

• PID-Namensraum: isoliert den Prozessidentifikatorraum. Innerhalb des Containers ist der Hauptprozess üblicherweise PID 1.Auch wenn der Host eine andere Nummer hat. Prozesse aus verschiedenen Namensräumen können dieselbe Prozess-ID (PID) haben, ohne sich gegenseitig zu stören, und sie können keine Signale austauschen, es sei denn, der Host erlaubt dies explizit.
• Netzwerk (NET) Namespace: Erzeugt einen unabhängigen Netzwerk-Stack mit eigenen Schnittstellen, Routen, Firewall-Regeln, Sockets usw. Jeder Container verfügt über seine eigene Loopback-Schnittstelle, seine eigenen IP-Adressen und sein eigenes Routing.Auf diese Weise können Sie dieselbe IP-Adresse in verschiedenen Namensräumen konfliktfrei wiederverwenden und isolierte iptables-Regeln anwenden.
• Mount (MNT) Namespace: trennt die Sicht von den Befestigungspunkten. Prozesse sehen nur die Dateihierarchie ihres Namensraums.Auch wenn darunter Bind-Mounts, gemeinsam genutzte Volumes, Overlays usw. vorhanden sind. Dadurch kann ein Container scheinbar sein eigenes "/" haben, ohne das eigentliche Stammverzeichnis des Hosts zu berühren.
• UTS-Namensraum: Steuert den Hostnamen und die NIS-Domäne. Innerhalb eines UTS-Namensraums Sie können den Hostnamen ändern, ohne das Hostsystem zu beeinträchtigen.Sehr nützlich zur Unterscheidung von Containern oder zur Simulation von Knoten in Testumgebungen.
• IPC-Namensraum: isoliert System V-Nachrichtenwarteschlangen, Semaphore und gemeinsam genutzten Speicher. Verhindern, dass unterschiedliche Containerprozesse die IPC beeinträchtigen. aufgrund eines Unfalls oder mangelhafter Konstruktion.
• Benutzer-NamespaceVermutlich die heikelste. Sie erlaubt Interne Namespace-UIDs und GIDs anderen Host-IDs zuordnenDadurch kann das „Root“-Rechtekonto innerhalb des Containers einem Benutzer ohne Administratorrechte auf dem Host zugeordnet werden, wodurch das Risiko einer Rechteausweitung erheblich reduziert und die Sicherheit verbessert wird. Containersicherheit.
• Cgroup-Namensraum: bietet eine virtualisierte Ansicht von /proc/self/cgroup und die cgroups-Hierarchie. Innerhalb des Containers sind nur seine eigenen Gruppen sichtbar.Dadurch wird die eigentliche Struktur des Wirtsorganismus verschleiert und die Isolation verstärkt.
• Zeit-Namensraum: ermöglicht das Anbieten unterschiedliche Zeitwahrnehmungen (Uhren wie CLOCK_MONOTONIC oder CLOCK_BOOTTIME) für verschiedene Prozessgruppen. Es eignet sich für Testszenarien oder sehr feine Isolation.

Alle diese Namensräume sind verfügbar in /proc/<pid>/ns/und kann mit Werkzeugen wie beispielsweise erstellt oder kombiniert werden unshare y nsenterWenn der letzte Prozess, der zu einem Namensraum gehört, beendet wird, wird dieser Namensraum automatisch zerstört.

Experimentieren mit Namensräumen über die Kommandozeile

Der Befehl unshare Es gehört zu den Grundvoraussetzungen für Experimente: erstellt einen untergeordneten Prozess mit einem oder mehreren neuen NamensräumenZum Beispiel zum Testen eines isolierten PID-Namensraums:

unshare --pid --fork --mount-proc bash
ps aux
echo $$

Intern werden Ihnen nur die Prozesse dieses Namespace angezeigt, und Ihre Shell erscheint dort als Prozess-ID 1, obwohl der Host weiterhin alle seine üblichen Prozesse ausführt. Es handelt sich im Grunde um das Grundgerüst dessen, was eine OCI-Laufzeitumgebung beim Start eines Containers ausführt.

Netzwerk-Namespaces im Detail

Der Netzwerkaspekt ist einer der vielseitigsten. Beim Erstellen eines .NET-Namespace mit ip netns addSie erhalten einen leeren Stack, mit Ausnahme des Loopback-Stacks. Von dort aus können Sie Folgendes tun:

• Verbinden Sie diesen Namespace mit dem Host mit einem Paar veth (zwei virtuelle Schnittstellen, die durch ein logisches Kabel verbunden sind).
• Brücken bauen Typ br0 und mehrere Namensräume mit dieser Brücke zu verbinden, sodass sie sich über private IPs gegenseitig erreichen können.
• NAT und Weiterleitung um diesen "selbst erstellten Containern" mit iptables Internetzugang zu gewähren und /proc/sys/net/ipv4/ip_forward.

Genau, auf einer sehr niedrigen Ebene macht Docker genau das mit der Brücke. docker0 und deren Standardnetzwerke: Es richtet Netzwerk-Namespaces, veth-Peers, Bridges und NAT-Regeln ein. damit die Container miteinander kommunizieren und nach draußen gelangen können.

Mount- und Benutzer-Namespaces für Root-Dateisystem und Sicherheit

Mit `mount namespace` können Sie experimentieren, indem Sie ein Container-Dateisystem erstellen, ohne Docker zu verwenden. Das typische Vorgehen ist:

• Zusammenstellen oder Vorbereiten eines minimales Root-Dateisystem (zum Beispiel ein Alpine minirootfs, heruntergeladen von wget und in ein Verzeichnis extrahiert).
• Erstellen Sie einen Mount-Namespace und führen Sie Folgendes aus: pivot_root o chroot in dieses Verzeichnis.
• Montar /proc, /sys und andere Pseudo-Systeme innerhalb der neuen Wurzel.

Damit sieht Ihre Shell nur noch dieses Dateisystem, aber Sie bleiben ein normaler Hostprozess mit Ihrer echten Prozess-ID (PID) und sind vom Administrator steuerbar.Wenn Sie auch einen Benutzer-Namespace verwenden mit --map-root-userEs kann ein "Root" geben, das außerhalb eines Benutzers ohne Berechtigungen liegt.

Cgroups: Wie viele Ressourcen jeder Prozess ausgeben kann

Während Namensräume festlegen, welche Ressourcen ein Prozess sehen kann, begrenzen Cgroups die Anzahl der Systemressourcen, die eine Gruppe von Prozessen verbrauchen kann . Sie wurden mit Kernel 2.6.24 eingeführt und sind heute auf jeder modernen Containerplattform unerlässlich.

Auf konzeptioneller Ebene ist eine C-Gruppe ein Verzeichnis innerhalb /sys/fs/cgroup mit Dateien, die Grenzwerte, Prioritäten und Metriken beschreiben.Wenn Sie eine PID zur entsprechenden Datei hinzufügen (zum Beispiel, cgroup.procsDieser Prozess unterliegt diesen Regeln.

Ressourcencontroller in cgroups

Cgroups bestehen aus Controllern (Subsystemen), die auf bestimmte Ressourcen zugreifen. Zu den am häufigsten verwendeten gehören:

• CPU: Steuert die zugewiesene CPU-Zeit. Mit Aktien definiert relative Priorität; mit Quoten feste Grenzwerte (z. B. 50 ms CPU-Timeout pro 100 ms Periode); mit CPU-Sets Sie weisen Prozesse bestimmten Kernen zu.
• Memory: Beschränkt RAM und Auslagerungsspeicher. Ermöglicht Harte und weiche Grenzwerte, OOM-Killer-Einstellungen, Statistiken und SpeicherdruckSehr nützlich, um zu verhindern, dass ein Dienst den gesamten Server belegt.
• Block I/O (blkio / io): Beschränkt Bandbreite und IOPS pro Gerät. Sie können Proportionale Gewichtung zuweisen oder genaue Grenzwerte in Bytes/s Operationen/s festlegen..
• NetzwerkEs gibt Mechanismen zur Begrenzung von Bandbreite und Paketen, allerdings ist die Unterstützung dafür weniger ausgereift und wird üblicherweise mit tc und QoS kombiniert.
• PIDs: markieren Sie die maximale Anzahl von Prozessen/Threads Dadurch kann eine Gruppe erstellt werden, wodurch Fork-Bomben oder Codefehler, die Threads auslösen, vermieden werden.

Die praktische Idee ist sehr einfach: Sie platzieren Ihre Anwendung in einer Cgroup und legen die maximale CPU-Auslastung, den Arbeitsspeicher, die E/A-Leistung und die Anzahl der Prozess-IDs fest . Der Kernel kümmert sich dann um die Einhaltung der Regeln.

cgroups v1 vs cgroups v2

Im Produktivbetrieb findet man zwei Varianten von cgroups, und es ist wichtig, sich darüber im Klaren zu sein, in welchem ​​Bereich man sich gerade befindet:

• cgroup v1Jeder Controller verfügt über seine eigene, unabhängige Hierarchie. Es gibt Routen wie beispielsweise /sys/fs/cgroup/cpu/..., /sys/fs/cgroup/memory/..., usw. Es ist flexibel, aber in großem Maßstab kompliziert zu handhaben.Viele klassische Distributionen und Plattformen nutzen es aus Gründen der Kompatibilität immer noch oder unterstützen es.
• cgroup v2: gruppiert alles unter einem einheitliche Hierarchie en /sys/fs/cgroupDie Grenzwerte werden über Dateien wie beispielsweise … konfiguriert. cpu.max, memory.max, io.max und dergleichen. Es vereinfacht die Verwaltung und verbessert die Feinabstimmung der Ressourcen.Moderne Distributionen verwenden standardmäßig Version 2, manchmal auch im Hybridmodus.

En /proc/cgroups Sie können sehen, welche Controller aktiviert sind, wie viele aktive Cgroups vorhanden sind und ob Sie Version 1 oder 2 verwenden (in Version 2 sehen Sie eine einheitliche Hierarchie mit der ID 0). Der Befehl mount | grep cgroup Es zeigt Ihnen auch den Typ des Dateisystems an (cgroup2fs impliziert v2, tmpfs (verweist üblicherweise auf v1).

Manuelle Erstellung von Cgroups und typische Grenzwerte

Um die Funktionsweise von Docker im Detail zu verstehen, empfiehlt es sich, Cgroups manuell zu erstellen. Das allgemeine Vorgehen ist wie folgt:

• Erstelle ein cgroup-Verzeichnis.
• Limit-/Prioritätsdateien konfigurieren (CPU, Speicher, E/A, PIDs…).
• Fügen Sie PIDs zu cgroup hinzu, indem Sie Folgendes eingeben: cgroup.procs o tasks (in Version 1).

In cgroups v2 könnte man beispielsweise für CPU und Arbeitsspeicher Folgendes haben:

mkdir /sys/fs/cgroup/test_app
echo "+cpu +memory +io +pids" > /sys/fs/cgroup/cgroup.subtree_control
echo "50000 100000" > /sys/fs/cgroup/test_app/cpu.max
echo "512M" > /sys/fs/cgroup/test_app/memory.max
echo $$ > /sys/fs/cgroup/test_app/cgroup.procs

Damit ist das aktuelle Verfahren beschränkt auf 50 % eines Kerns und 512 MB RAMWenn Sie etwas Intensives beginnen (ein dd Wenn Sie beispielsweise auf /dev/null zugreifen, werden Sie sehen, dass das System nicht durcheinander gerät. In cgroups v1 ist das Schema ähnlich, jedoch mit Dateien wie cpu.shares, cpu.cfs_quota_us, memory.limit_in_bytesusw., jedes in seiner eigenen Hierarchie.

Wie Docker, Kubernetes und der Kernel-Stack

Über den Namespaces und Cgroups befinden sich mehrere Softwareebenen, die die Verantwortung hin und her schieben, bis sie den Kernel erreichen. Selbst wenn sich der Name des Tools ändert, ist das Endergebnis immer dasselbe: Kernel-Aufrufe zum Erstellen von Namespaces, Konfigurieren von Cgroups und Einbinden von Dateisystemen.

Der typische Containerstapel sieht heutzutage in etwa so aus:

• OrchestrierungsebeneKubernetes, Docker Swarm, Nomad… Sie kümmern sich um den Lebenszyklus von Pods/Diensten, die Planung, Skalierung und den Support. Microservices-Architekturen.
• Container-Laufzeitumgebung auf hoher EbeneDocker Engine, containerd, CRI-O. Sie nehmen die Anweisungen des Dirigenten entgegen und setzen sie in konkrete Handlungen um. (Images herunterladen, Container erstellen, Snapshots verwalten usw.).
• OCI-Laufzeitumgebung auf niedriger EbeneRunc, crun und ähnliche Tools implementieren die OCI-Spezifikation und sind direkt für deren Implementierung verantwortlich. sie nennen clone(), unshare(), mount() und Unternehmen um den Behälter zu materialisieren.
• Linux KernelEs stellt Namensräume, Cgroups, OverlayFS und alle anderen Grundelemente bereit. Hier geschieht die eigentliche „Magie“.

Wenn du einen wirfst docker runDer Pfad verläuft wie folgt: CLI-Client → dockerd → containerd → runc → Kernelaufrufe. Entlang dieses Pfades werden Namespaces erstellt, Cgroups zugewiesen, das Root-Dateisystem mit OverlayFS und Volumes eingebunden und die Netzwerkschnittstellen sowie die Bridge verbunden. Was Sie als „Container“ sehen, ist für den Kernel eine Handvoll Prozesse mit bestimmten Flags und speziellen Pfaden..

Anforderungen und vorherige Prüfungen im System

Bevor Sie anfangen, mit Namespaces und Cgroups auf einem Server herumzuexperimentieren, sollten Sie sicherstellen, dass die Hardware und der Kernel vernünftige Mindestanforderungen erfüllen , insbesondere wenn Sie planen, etwas Ähnliches wie eine Produktionsumgebung einzurichten.

Als Richtwert werden üblicherweise mindestens 2 logische CPUs, 4 GB RAM (besser 8 GB oder mehr) , etwa 20 GB freier Festplattenspeicher und ein Kernel 3.10 oder höher (idealerweise 4.x oder 5.x, um alle Vorteile von cgroups v2 und moderne Funktionen nutzen zu können) empfohlen.

Um zu überprüfen, ob der Kernel Namespaces und Cgroups unterstützt, prüfen Sie einfach die Konfigurationsdatei der verwendeten Version:

grep -E "CONFIG_.*_NS" /boot/config-$(uname -r)
grep -E "CONFIG_CGROUP" /boot/config-$(uname -r)

Optionen wie diese sollten dort erscheinen. CONFIG_NAMESPACES, CONFIG_PID_NS, CONFIG_NET_NS, CONFIG_CGROUPS, CONFIG_MEMCG, CONFIG_CGROUP_SCHED markiert als =yOhne das wirst du nicht viel Spielzeit bekommen.

Ein weiteres praktisches Detail ist, ob das System dies zulässt. Benutzer-Namespaces erstellen, ohne Root-Rechte zu habenDies ist sehr nützlich für Tests und einige Tools. Es wird mit sysctl gesteuert. kernel.unprivileged_userns_cloneWenn der Wert bei 0 steht, müssen Sie es aktivieren (oder überall Ihren Schweiß einsetzen).

Erkundung von cgroups und Namensräumen auf „echten“ Maschinen

Eine recht einfache Möglichkeit, diese Konzepte zu verinnerlichen, besteht darin, sich anzusehen, wie das System selbst und Ihre Container sie verwenden . Einige hilfreiche Hinweise:

• ls /proc/self/ns/ Es zeigt Ihnen die Namensräume an, zu denen Ihre aktuelle Shell gehört (cgroup, ipc, mnt, net, pid, user, uts…).
• systemd-cgtop Es zeigt die CPU-, Speicher- und E/A-Auslastung nach Cgroup an, sehr ähnlich wie top aber gruppiert nach Diensten und Containern.
• En /sys/fs/cgroup Die von Docker oder Podman für jeden Container erstellten Cgroups lassen sich in der Regel anhand der Container-ID im Pfad finden. cgroup.procs Liste die zugehörigen PIDs auf.
• /proc/<pid>/cgroup Es zeigt Ihnen, welchen Cgroups ein bestimmter Prozess zugeordnet ist – perfekt, um eine problematische Anwendung aufzuspüren.

Sie werden feststellen, dass Container lediglich ein weiterer Zweig der cgroups-Hierarchie sind, mit eigenen CPU-, Speicher-, blkio- und anderen Beschränkungen, genau wie Sie sie auch manuell erstellen könnten . Der Vorteil von Docker liegt darin, dass dies automatisch und mit einer benutzerfreundlichen API geschieht.

Leistungs-, NUMA- und Affinitätsstrategien

Bei hoher Last (große Datenbanken, intensive Verarbeitung, Streaming usw.) reicht das einfache „Starten von Containern“ nicht aus. Die Art und Weise, wie Sie CPU und Arbeitsspeicher den einzelnen Diensten zuweisen, hat einen erheblichen Einfluss auf die Leistung.

Mit dem cpuset- Treiber können Sie Prozesse oder Dienste bestimmten Gruppen von CPUs und NUMA-Knoten zuweisen. Es ist ganz einfach:

mkdir /sys/fs/cgroup/cpuset/dedicated_cpus
echo "4-7" > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.cpus
echo "0" > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.mems
echo 1 > /sys/fs/cgroup/cpuset/dedicated_cpus/cpuset.cpu_exclusive

Dadurch können Sie eine Gruppe von Kernen für einen bestimmten Dienst reservieren und verhindern, dass der Rest des Systems diesen beeinträchtigt. Dies reduziert Störungen, Thread-Migrationen und Latenzprobleme , die häufig auftreten, wenn alle Systeme um dieselben CPUs konkurrieren.

Auf Speicherebene trägt die Kombination von numactl mit cgroups (oder die direkte Verwendung der NUMA-Einstellungen des Speichercontrollers, sofern verfügbar) dazu bei, Daten auf dem physischen Knoten zu halten, der den Kernen, die sie verwenden, am nächsten liegt. Dies macht sich in latenzempfindlichen Anwendungen bemerkbar.

Überwachung und Beobachtbarkeit von Cgroups und Namensräumen

Das Festlegen von Ressourcenlimits ist in Ordnung, aber Wer nicht misst, was passiert, könnte sich selbst schaden, ohne es überhaupt zu merken.cgroup v2 selbst bietet eine ganze Reihe nützlicher Metriken in den Protokollen. *.stat, *.events y *.pressure.

Einige praktische Beispiele:

• cpu.stat Es zeigt an, wie viel CPU-Zeit die Gruppe verbraucht hat, wie oft die Leistung gedrosselt wurde usw.
• memory.current y memory.max Sie zeigen den aktuellen Verbrauch und das konfigurierte Limit an.
• memory.events Es erfasst OOMs, erreichte Soft Limits und andere kritische Werte.
• io.stat Zählt Lese-/Schreibvorgänge pro Gerät auf.

Für einen schnellen Überblick, systemd-cgtop Es ist sehr praktisch, und wenn Sie etwas Industrielleres benötigen, gibt es Werkzeuge wie Berater Sie exportieren Docker/containerd-Cgroup-Metriken nach Prometheus, sodass Sie ohne großen Aufwand vollständige Dashboards in Grafana erstellen können – ideal für … erweiterter Systemmonitor.

Beim Debuggen von Namensraumproblemen sind einfache Skripte, die den Namensraum durchlaufen, hilfreich. /proc/<pid>/ns/ und vergleichen Sie die Hilfe der symbolischen Verknüpfungen um zu wissen, welche Prozesse genau denselben Namensraum verwenden.oder um einen „verlorenen“ Netzwerk-Namensraum aufzuspüren, der sich festgefahren hat.

Verwendung von systemd als cgroup-Manager

In den meisten modernen Distributionen verwendet systemd zur Verwaltung von Diensten, Slices und Scopes in hohem Maße cgroups . Wenn Sie eine Unit mit Ressourcengrenzen definieren, erstellt systemd eine cgroup für diesen Dienst und konfiguriert dessen Handler.

Ein Dienst, der mit Anweisungen wie den folgenden deklariert wurde:

CPUQuota=50%
CPUWeight=500
MemoryMax=512M
IOReadBandwidthMax=/dev/sda 10M

Dies führt zu Cgroup-Limits für CPU, Speicher und E/A des Prozesses dieser Einheit. Dadurch lässt sich die klassische Dienstverwaltung an das Containermodell anpassen, wobei dasselbe zugrundeliegende Kernel-Subsystem verwendet wird. Weitere Informationen zu systemd und seinen Anforderungen finden Sie unter systemd changes.

Für Teams, die traditionelle Dienste mit Containern mischen (sehr verbreitet), ist die Verwendung von systemd zur Festlegung von Grenzwerten für kritische Daemons eine elegante Möglichkeit, zu verhindern, dass Ressourcen von den Pods in der containerisierten Umgebung beendet werden.

In Umgebungen mit vielfältigen Workloads – von Datenbanken über Monitoring-Agenten bis hin zu benutzerdefinierten Anwendungen – ermöglicht die Beherrschung von Namespaces und Cgroups die Definition strenger Isolationsrichtlinien, die Anpassung der Dienstqualität und die Sicherstellung einer präzisen Zuweisung von CPU und Arbeitsspeicher für jede Komponente . Das Verständnis, wie Docker, Kubernetes und systemd diese Kernel-Funktionen nutzen, versetzt Sie in die Lage, sicherere Multi-Tenant-Infrastrukturen zu entwerfen, komplexe Probleme (von Speichermangel bis hin zu E/A-Engpässen) zu beheben und Ihre Hardware optimal zu nutzen, ohne Kompromisse bei der Stabilität einzugehen.