Lernpfad
Containerisierung und Virtualisierung mit Docker und Kubernetes
0 Min.
Docker und Kubernetes beherrschen
Lerne in einem interaktiven Lernpfad die Leistungsfähigkeit von Docker und Kubernetes kennen, um Anwendungen in modernen Umgebungen zu entwickeln und einzusetzen.
Podman: Die daemonlose Docker-Alternative
Podmanist die direkteste Herausforderung für den Architekturansatz von Docker.
Bild 1 – Podman-Startseite
Red Hat hat es speziell entwickelt, um das daemonbasierte Sicherheitsmodell von Docker zu unterstützen und gleichzeitig die Kompatibilität mit bestehenden Arbeitsabläufen zu gewährleisten.
>Wenn du einen tiefergehenden Vergleich zwischen Docker und Podman suchst, findest du in unserem Blogbeitrag heraus , welche Containerisierungsplattform für dich die richtige ist.
Architektonische Innovation
Der größte Unterschied zwischen Podman und Docker ist , dassder Daemon- komplettweggefallen ist. Anstatt Befehle über einen zentralen Dienst zu leiten, nutzt Podman ein Fork-Exec-Modell, bei dem jeder Container als direkter untergeordneter Prozess des Benutzers läuft, der ihn gestartet hat. Das heißt, es gibt keinen Hintergrunddienst, der ständig läuft, keinen einzigen Fehlerpunkt und keinen Daemon auf Root-Ebene, der deine Container verwaltet.
Diese Architektur lässt sich ganz einfach in den Standard-Dienstmanager von Linux, den „ systemd “, einbinden. Du kannst systemd-Unit-Dateien direkt aus Podman-Containern erstellen, damit deine Container beim Booten automatisch starten, bei Fehlern neu starten und in die Systemprotokollierung integriert werden. Das ist viel übersichtlicher als die separate Orchestrierungsebene von Docker.
Podman hält sich komplett an die OCI-Standards, sodass es die gleichen Container-Images wie Docker ohne Änderungen ausführt. Die Laufzeitumgebung nutzt die gleichen Technologien – Container-Engine ( runc ) für die Containerausführung und verschiedene Speichertreiber für die Imageverwaltung –, aber sie sind anders verpackt.
Verbesserte Sicherheit
Der rootless-Betrieb ist das herausragende Sicherheitsfeature von Podman. Wenn du Container mit Podman ausführst, laufen sie unter deinem Benutzerkonto und brauchen keine Root-Rechte. Das passiert durch die Zuordnung von Benutzernamenbereichen, bei der der Root-Benutzer des Containers deiner nicht privilegierten Benutzer-ID auf dem Host-System zugeordnet wird.
Dadurch wird der Angriffsvektor eliminiert, bei dem ein Container-Ausbruch das gesamte Host-System gefährden könnte. Selbst wenn ein Angreifer aus dem Container entkommt, ist er immer noch auf die Berechtigungen deines Benutzers beschränkt und hat keinen Root-Zugriff auf den Rechner.
Auf Red Hat Enterprise Linux- und Fedora-Systemen ist Podman eng mit SELinux (Security-Enhanced Linux) verbunden. SELinux hat strenge Zugriffskontrollen, die festlegen, worauf Container auf dem Host-System zugreifen können, selbst wenn sie gehackt werden. Das sorgt für mehrere Sicherheitsebenen – Benutzernamensräume verhindern, dass jemand mehr Rechte bekommt, als er sollte, und SELinux schützt vor unbefugtem Zugriff auf das Dateisystem.
In Unternehmen werden diese Funktionen oft mit zusätzlichen Tools für Sicherheitsscans und die Durchsetzung von Richtlinien kombiniert, um umfassende Verteidigungsstrategien zu schaffen.
Betriebliche Kompatibilität
Podman bleibt mit Docker über den Befehl „ podman “ kompatibel, der die gleichen Argumente wie „ docker “ versteht. Du kannst einen Alias (alias docker=podman) erstellen, dann funktionieren die meisten Skripte ohne Änderungen. Dadurch läuft die Migration von Docker viel reibungsloser als der Wechsel zu komplett anderen Toolchains.
Die Podman-Desktop-GUI „ “ ist eine Alternative zu Docker Desktop für Entwickler, die lieber mit grafischen Benutzeroberflächen arbeiten. Es umfasst Container-Management, Funktionen zur Image-Erstellung und Kubernetes-Integration für die lokale Entwicklung. Die Desktop-App kann sich mit Podman-Instanzen verbinden und hat ähnliche Funktionen wie das Dashboard von Docker Desktop.
Für Kubernetes-Workflows kann Podman Kubernetes-YAML-Manifeste aus laufenden Containern erstellen und unterstützt die Pod-Verwaltung – also das Ausführen mehrerer Container, die Netzwerk und Speicher gemeinsam nutzen, ähnlich wie Kubernetes-Pods.
Wichtige Kompromisse
Die Windows-Unterstützung ist immer noch die größte Einschränkung von Podman. Podman Machine macht Windows durch Virtualisierung kompatibel, aber es läuft nicht so reibungslos wie die WSL2-Integration von Docker Desktop. Windows-Entwickler könnten die Einrichtung etwas komplizierter finden.
Rootless-Netzwerke können die Leistung beeinträchtigen. Ohne Root-Rechte kann Podman keine Brückennetzwerke direkt erstellen, also nutzt es User-Mode-Netzwerke (slirp4netns), was zu einer höheren Latenz führt. Bei Entwicklungs-Workloads fällt das kaum auf, aber bei Netzwerk-Apps mit hohem Durchsatz kann es zu Leistungseinbußen kommen.
Docker Compose ist über podman-compose kompatibel, aber es sind nicht alle Funktionen verfügbar. Komplexe Compose-Dateien müssen vielleicht angepasst werden, und einige fortgeschrittene Netzwerkfunktionen werden im Rootless-Modus nicht unterstützt. Teams, die viel in Docker Compose-Workflows investiert haben, sollten vor der Migration gründlich testen.
Was ist der Unterschied zwischen Docker Compose und Kubernetes? Unser detaillierter Vergleich hat alles, was du wissen musst.
Kubernetes-Ökosystem-Laufzeiten: CRI-O und Containerd
Während Podman auf Docker-Kompatibilität setzt, konzentrieren sich CRI-O und containerd speziell auf Kubernetes-Produktionsumgebungen. Diese Laufzeiten entfernen unnötige Funktionen, um sie für koordinierte Workloads zu optimieren.
Jeder Entwickler sollte diese Unterschiede zwischen Docker und Kubernetes kennen.
CRI-O: Kubernetes-native Laufzeitumgebung
CRI-O wurde von Grund auf entwickelt, um die Container-Laufzeit-Schnittstelle (CRI) von Kubernetes zu implementieren.
Bild 2 – CRI-O-Startseite
Es enthält nur das, was Kubernetes braucht – keine Image-Erstellung, keine Volume-Verwaltung über die Anforderungen von Pods hinaus und keine eigenständige Container-Verwaltung. Dieser fokussierte Ansatz sorgt für weniger Speicherbedarf und schnellere Startzeiten im Vergleich zu Docker.
Die Ressourceneffizienz der Laufzeitumgebung kommt von ihrem minimalistischen Design. CRI-O hat keinen Daemon mit vielen APIs oder Hintergrunddiensten. Es startet Container, kümmert sich um ihren Lebenszyklus nach den Anweisungen von Kubernetes und macht sich dann einfach aus dem Staub. Das macht es super für Umgebungen mit wenig Ressourcen oder für große Installationen, wo jedes Megabyte Speicher wichtig ist.
CRI-O unterstützt jede OCI-kompatible Laufzeitumgebung als Low-Level-Executor. Standardmäßig ist „ runc “ eingestellt, aber du kannst das ohne Änderungen an deiner Kubernetes-Konfiguration durch Alternativen wie „ crun “ (in C geschrieben, für bessere Leistung) oder „ gVisor “ (für verbesserte Isolierung) ersetzen. Dank dieser Flexibilität kannst du bestimmte Sicherheits- oder Leistungsanforderungen auf Laufzeitebene optimieren.
Das Projekt hält sich strikt an die Release-Zyklen von Kubernetes, sodass neue Funktionen und Sicherheitsupdates immer mit deinen Cluster-Versionen kompatibel sind.
Containerd: Laufzeit für die Produktion
Containerd fing als die zugrunde liegende Laufzeitumgebung von Docker an, bevor es ein eigenständiges Projekt unter der Cloud Native Computing Foundation wurde.
Bild 3 – Containerd-Startseite
Docker nutzt intern immer noch containerd, aber du kannst es direkt starten, um die zusätzlichen Ebenen und den Overhead von Docker zu vermeiden.
Die Architektur dreht sich um eine Shim-API, die stabile Schnittstellen für die Container-Verwaltung bietet. Jeder Container kriegt seinen eigenen Shim-Prozess, der den Lebenszyklus des Containers selbstständig regelt. Wenn der Haupt-Containerd-Daemon neu startet, laufen die Container einfach weiter – echt wichtig für Produktions-Workloads, die keine Ausfallzeiten vertragen.
Dieses Design macht containerd super stabil für lang laufende Unternehmensanwendungen. Die Shim-Architektur macht auch Sachen wie Live-Migration und Updates ohne Ausfallzeiten möglich, bei denen du die Laufzeitumgebung upgraden kannst, ohne dass laufende Container davon betroffen sind.
Containerd hat eine eigene Bildverwaltung, Snapshots für effiziente Speicherung von Layern und Plugin-Systeme, um die Funktionen zu erweitern. Große Cloud-Anbieter wie AWS EKS, Google GKE und Azure AKS nutzen containerd als Standard-Laufzeitumgebung, weil die Architektur so gut für den Einsatz in der Produktion geeignet ist.
Leistungsmerkmale
Hier ist ein Vergleich der Laufzeiten für Kubernetes-Bereitstellungen in der Produktion:
Bild 4 – Leistungsmerkmale von Docker, CRI-O und Containerd
CRI-O ist super in Sachen Ressourceneffizienz und Startgeschwindigkeit, weil es so minimalistisch gebaut ist. Containerd bietet die beste Balance zwischen Funktionen und Stabilität für Unternehmensumgebungen. Docker hat die meisten Features, aber auch mehr Aufwand, den man in Kubernetes-Umgebungen nicht braucht.
Bei Kubernetes-Clustern für die Produktion machen sowohl CRI-O als auch containerd die Docker-Shim-Kompatibilitätsschicht überflüssig, was die Komplexität verringert und die Leistung im Vergleich zu Docker-basierten Setups verbessert.
Low-Level-Laufzeitumgebungen: runC und Youki
Während High-Level-Laufzeitumgebungen wie Podman und containerd sich um die Verwaltung von Images und APIs kümmern, konzentrieren sich Low-Level-Laufzeitumgebungen nur auf die Ausführung von Containern. Diese Tools sind die Basis für die meisten Containerisierungsplattformen.
runC: OCI-Referenzimplementierung
runC ist die Referenzimplementierung der OCI-Laufzeitspezifikation für „ “ – also das Standardbeispiel dafür, wie Container eigentlich laufen sollten. Die meisten Container-Plattformen nutzen runC als Ausführungs-Engine, zum Beispiel Docker, containerd, CRI-O und Podman. Wenn du einen Container mit einem dieser Tools startest, kümmert sich runC wahrscheinlich um die eigentliche Erstellung und Isolierung des Prozesses.
Die Laufzeitumgebung macht die grundlegenden Container-Primitive klar: Linux-Namespaces für die Isolierung erstellen, cgroups für Ressourcenbeschränkungen einrichten und Sicherheitskontexte konfigurieren. Es ist in Go geschrieben und so gemacht, dass es einfach, zuverlässig und spezifikationskonform ist, statt mit vielen Funktionen vollgestopft zu sein.
runC ist super für eingebettete Systeme und benutzerdefinierte Container-Stacks, wo du vorhersehbares Verhalten und möglichst wenig Abhängigkeiten brauchst. Da es nur die Ausführung von Containern übernimmt, kannst du darauf spezialisierte Container-Plattformen aufbauen, ohne unnötige Komplexität zu erben. IoT-Geräte, Edge-Computing-Plattformen und maßgeschneiderte Orchestrierungssysteme nutzen oft direkt runC, anstatt höhere Laufzeitumgebungen.
Das Tool ist ein Befehlszeilenprogramm, das OCI-Bundle-Spezifikationen liest und entsprechend Container erstellt. Das macht es super, um es in bestehende Systeme zu integrieren oder eigene Container-Management-Tools zu entwickeln.
Youki: Rust-basierte Leistung
Youki implementiert „“ neu und setzt damit die OCI-Laufzeitspezifikation in Rust um, wobei der Fokus auf Speichersicherheit und Leistung liegt. Die Rust-Implementierung beseitigt ganze Klassen von Sicherheitslücken, die C- und Go-Laufzeiten beeinträchtigen können, und verbessert gleichzeitig die Startzeiten von Containern durch eine bessere Speicherverwaltung und reduzierten Overhead.
Benchmarks zeigen, dass Youki Container in vielen Fällen schneller startet als runC, wobei die genaue Verbesserung je nach Arbeitslast variiert. Diese Verbesserung kommt von Rusts kostenlosen Abstraktionen und effizienteren Speicherzuweisungsmustern. Bei Anwendungen, die viele kurzlebige Container erstellen und löschen, können diese Verbesserungen der Startzeit echt wichtig sein.
Youki ist voll kompatibel mit der OCI-Laufzeitspezifikation, sodass es in den meisten Container-Plattformen einfach anstelle von runC eingesetzt werden kann. Docker Engine, containerd und andere High-Level-Laufzeitumgebungen können Youki ohne Änderungen an ihrer Konfiguration oder ihren APIs nutzen.
Die Laufzeitvorteile kommen bei performancekritischen Workloads wie serverlosen Funktionen, CI/CD-Pipelines mit vielen Container-Builds und Microservices-Architekturen mit häufigen Skalierungsereignissen zum Tragen. Die schnelleren Startzeiten bedeuten in diesen Fällen direkt weniger Wartezeit beim Kaltstart und eine bessere Nutzung der Ressourcen.
Youki hat auch coole Features wie cgroup v2-Optimierung und verbesserte Rootless-Container-Unterstützung, die das Typsystem von Rust nutzen, um Konfigurationsfehler beim Kompilieren zu vermeiden.
Systemcontainer: LXC/LXD im Vergleich zu Anwendungscontainern
Nicht bei jeder Containerisierung geht's nur um einzelne Anwendungen – manchmal musst du ganze Betriebssysteme in Containern laufen lassen. LXC und LXD bieten Containerisierung auf Systemebene, die sich total von dem anwendungsorientierten Ansatz von Docker unterscheidet.
LXC: Virtualisierung auf Betriebssystemebene
LXC (Linux Containers)macht Container, die sich wie komplette Linux-Systeme verhalten und nicht wie isolierte Anwendungsprozesse.
Bild 5 – LXC-Startseite
Jeder LXC-Container hat sein eigenes Init-System, kann mehrere Dienste hosten und bietet eine komplette Benutzerumgebung, die man kaum von einer virtuellen Maschine unterscheiden kann.
Dieser Ansatz eignet sich besonders für ältere Workloads, die nicht für die Containerisierung konzipiert wurden. Programme, die auf /etc schreiben, Systemdienste ausführen oder mit der ganzen Dateisystemhierarchie interagieren sollen, funktionieren in LXC-Containern ohne Probleme. Du kannst ganze Serverkonfigurationen in LXC verschieben, ohne Anwendungen für Microservices-Architekturen umbauen zu müssen.
LXC-Container nutzen den Host-Kernel, sind aber besser isoliert als Anwendungscontainer. Jeder Container kriegt seinen eigenen Netzwerkstack, Prozessbaum und Dateisystem-Namespace, was eine VM-ähnliche Isolation ohne den Aufwand von Hardware-Virtualisierung schafft.
LXD, jetzt „“ von Canonical, erweitert LXC um eine leistungsstarke Verwaltungsebene. LXD bietet REST-APIs, Bildverwaltung und coole Funktionen wie Live-Migration zwischen Hosts. Du kannst laufende Container ohne Ausfallzeiten zwischen physischen Maschinen verschieben, ähnlich wie bei VMware vMotion, nur eben mit Containern.
Dank Hardware-Passthrough-Funktionen können LXD-Container direkt auf GPUs, USB-Geräte und andere Hardware zugreifen. Dadurch eignet es sich für Workloads, die speziellen Hardwarezugriff brauchen, während die Vorteile von Containern wie Dichte und schnelle Bereitstellung erhalten bleiben.
LXD unterstützt auch Clustering, sodass du mehrere Hosts als eine logische Einheit mit automatischer Platzierung und Failover-Funktionen verwalten kannst.
Vergleichende Analyse
Hier siehst du, wie Systemcontainer und Anwendungscontainer in den wichtigsten Punkten verglichen werden:
Bild 6 – Docker vs. LXC vs. Virtuelle Maschinen – Übersicht über die wichtigsten Eigenschaften
Systemcontainer füllen die Lücke zwischen leichten Anwendungscontainern und schweren virtuellen Maschinen. Sie sind ideal, wenn du VM-ähnliche Funktionen mit der Effizienz von Containern brauchst oder wenn du ältere Anwendungen migrierst, die sich nicht einfach in Microservices aufteilen lassen.
Die Entscheidung zwischen System- und Anwendungscontainern hängt eher von deinen Arbeitslasten und Betriebsanforderungen ab als von der technischen Überlegenheit – sie lösen einfach unterschiedliche Probleme im Containerisierungsbereich.
Sicherheitsarchitekturen in modernen Laufzeitumgebungen
Sicherheit ist in modernen Container-Laufzeitumgebungen nicht mehr nur ein nachträglicher Gedanke, sondern ein zentraler Teil des Designs. Heutzutage setzen Plattformen auf umfassende Sicherheitsstrategien, die davon ausgehen, dass Container angegriffen werden, und versuchen, den Schaden so gering wie möglich zu halten.
Betrieb ohne Wurzel
Rootless-Container beseitigen das größte Sicherheitsrisiko bei herkömmlichen Docker-Bereitstellungen – den Root-Daemon. Podman hat diesen Ansatz als Erster umgesetzt, indem Container komplett mit Benutzerrechten laufen und Linux-Benutzernamensräume nutzen, um den Root-Benutzer des Containers einer nicht privilegierten Benutzer-ID auf dem Host-System zuzuordnen.
Die Umsetzung nutzt untergeordnete Benutzer- und Gruppen-ID-Bereiche (/etc/subuid und /etc/subgid), die es Benutzern ohne Sonderrechte ermöglichen, isolierte Namensräume zu erstellen. Wenn ein Container-Prozess denkt, dass er als Root (UID 0) läuft, ordnet der Kernel das deiner echten Benutzer-ID (z. B. UID 1000) auf dem Host zu. Selbst wenn ein Angreifer aus dem Container entkommt, kann er nicht über die Berechtigungen deines Benutzers hinausgehen.
Containerd hat ähnliche Rootless-Funktionen über seinen Rootless-Modus eingebaut, der die gleichen Techniken zur Zuordnung von Benutzernamenräumen nutzt. Die Laufzeitumgebung kann Container starten, Images verwalten und Netzwerke handhaben, ohne Root-Rechte auf dem Host-System zu brauchen.
Kubernetes unterstützt jetzt den rootless-Betrieb direkt überdas Kubernetes-in-Rootless-Docker (KIND) -Projektct und die Integration von rootless containerd. Das heißt, dass ganze Kubernetes-Cluster ohne Root-Rechte laufen können, was die Angriffsfläche für Multi-Tenant-Umgebungen und Edge-Bereitstellungen, wo herkömmliche Sicherheitsmodelle nicht funktionieren, deutlich verringert.
Die Auswirkungen auf die Sicherheit gehen über die Verhinderung von Privilegienausweitungen hinaus. Rootless-Container können sich nicht an privilegierte Ports (unter 1024) binden, nicht auf die meisten Dateisysteme „ /proc “ und „ /sys “ zugreifen und keine Vorgänge ausführen, die Kernel-Funktionen brauchen. Dadurch entstehen natürliche Grenzen, die potenzielle Sicherheitslücken eindämmen.
Seccomp/BPF-Integration
Moderne Laufzeitumgebungen haben eBPF (extended Berkeley Packet Filter) eingebaut, um Sicherheitsrichtlinien in Echtzeit durchzusetzen, was über normale Zugriffskontrollen hinausgeht. eBPF-Programme laufen im Kernel-Bereich und können Systemaufrufe in Echtzeit überwachen, filtern oder ändern, was eine ganz neue Transparenz und Kontrolle über das Container-Verhalten ermöglicht.
Seccomp-Profile (Secure Computing) nutzen BPF, um Systemaufrufe auf Kernel-Ebene zu filtern. Anstatt Containern Zugriff auf alle über 300 Linux-Systemaufrufe zu geben, legen seccomp-Profile genau fest, welche Aufrufe erlaubt sind. Das Standard-Seccomp-Profil von Docker hält potenziell gefährliche Systemaufrufe ab, und mit benutzerdefinierten Profilen kann man die Sicherheit je nach den Anforderungen der Anwendung noch weiter erhöhen.
Die erweiterte eBPF-Integration macht die Verhaltensüberwachung in Echtzeit möglich. Tools wie Falco nutzen eBPF-Programme, um komisches Container-Verhalten zu erkennen – zum Beispiel ungewöhnliche Netzwerkverbindungen, unerwartete Dateizugriffsmuster oder Versuche, gesperrte Systemaufrufe zu nutzen. Diese Erkennungen passieren in Echtzeit und mit minimalem Performance-Overhead, weil die Überwachung im Kernel-Space stattfindet.
Die Durchsetzung von Netzwerkrichtlinien über eBPF ermöglicht eine detaillierte Kontrolle des Datenverkehrs auf Paketebene. Cilium, ein beliebtes Kubernetes CNI, nutzt eBPF, um Netzwerkrichtlinien umzusetzen, die den Datenverkehr nicht nur anhand von IP-Adressen und Ports, sondern auch anhand von Protokollen der Anwendungsschicht filtern können. Das heißt, du kannst direkt im Kernel Regeln wie „HTTP-GET-Anfragen an /api/v1/users zulassen, aber POST-Anfragen blockieren” festlegen.
Die eBPF-basierte Sicherheit macht auch eine containerbewusste Überwachung möglich, die die Beziehungen zwischen Prozessen, Containern und Kubernetes-Pods versteht. Herkömmliche Überwachungstools sehen einzelne Prozesse, aber eBPF-Programme können Systemaufrufe mit Container-Metadaten verknüpfen, um kontextbezogene Sicherheitsinformationen zu liefern.
Diese Funktionen machen Sicherheit nicht mehr nur zu einem reaktiven Patch-Prozess, sondern zu einer proaktiven Durchsetzung von Richtlinien, bei der verdächtiges Verhalten automatisch blockiert wird, bevor es Schaden anrichten kann.
Strategien zur Leistungsoptimierung
Die Container-Performance ist super wichtig, wenn du Hunderte oder Tausende von Containern in deiner Infrastruktur laufen hast. Schauen wir uns mal Strategien an, die den Ressourcenaufwand und die Startverzögerung minimieren.
Kaltstartreduzierung
Die Kaltstartzeit – also die Zeit zwischen der Anforderung eines Containers und seiner Verfügbarkeit für den Datenverkehr – hat einen direkten Einfluss auf die Benutzererfahrung und die Ressourceneffizienz. Es gibt jetzt Techniken, um diese Verzögerungen in verschiedenen Laufzeitarchitekturen zu minimieren.
Vorgeladene Images sparen Download-Zeit, weil oft genutzte Container-Images auf den Knoten zwischengespeichert werden. Kubernetes DaemonSets können wichtige Images vorab abrufen, während Registries wie Harbor die Replikation von Images an Edge-Standorte unterstützen. Mit dieser Technik kannst du die Kaltstartzeit für zwischengespeicherte Bilder von Sekunden auf Millisekunden verkürzen.
Die Optimierung der Bildebenen, reduziert die Menge der Daten, die übertragen und extrahiert werden müssen. Mehrstufige Builds sorgen für kleinere Endbilder, während Tools wie „dive“ dabei helfen, unnötige Ebenen zu erkennen. Distroless-Images von Google machen Paketmanager und Shells überflüssig und verkleinern die Image-Größen oft erheblich.
Lazy Loading mit Projekten wie Stargz ermöglicht es, dass „ “-Container starten können, bevor das ganze Image runtergeladen ist. Die Laufzeitumgebung holt nur die Dateien, die für den ersten Start gebraucht werden, und lädt weitere Ebenen bei Bedarf runter. Dadurch kann die Kaltstartzeit bei großen Bildern von mehreren Sekunden auf unter 1 Sekunde reduziert werden.
Die Laufzeitoptimierung „ “ hängt von der Implementierung ab. Youkis Rust-Implementierung läuft dank besserer Speicherverwaltung schneller als runC. Crun, geschrieben in C, schafft ähnliche Verbesserungen, indem es den Overhead der Garbage Collection von Go bei der Erstellung von Containern vermeidet.
Die Snapshot-Freigabe-, die in containerd eingebaut ist, ermöglicht es mehreren Containern, schreibgeschützte Dateisystem-Snapshots zu teilen, was sowohl Speicherplatz als auch Arbeitsspeicher spart. Wenn du mehrere Container aus demselben Image startest, musst du nur die beschreibbaren Layer separat zuweisen.
Optimierung des Init-Prozesses kann die Startzeit verkürzen, indem man leichte Init-Systeme wie tini nutzt oder die Startsequenzen von Anwendungen so plant, dass die Initialisierungsarbeit auf ein Minimum reduziert wird.
Speichereffizienz
Der Speicherbedarf ist bei verschiedenen Container-Laufzeiten unterschiedlich, was vor allem in Umgebungen mit wenig Ressourcen oder bei vielen Bereitstellungen wichtig ist.
Der Overhead der Laufzeit-Baseline unterscheiden sich erheblich:
- Docker-Engine-: Benötigt Daemon-Overhead plus Overhead pro Container
- Podman: Kein Daemon-Overhead dank einer daemonlosen Architektur, minimaler Overhead pro Container
- Containerd-: Mittlerer Daemon-Overhead plus minimaler Overhead pro Container
- CRI-O: Geringer Daemon-Overhead plus minimaler Overhead pro Container
Die Deduplizierung von Image-Layern spart Speicherplatz, wenn mehrere Container aus ähnlichen Images laufen. Container-Laufzeiten nutzen Copy-on-Write-Dateisysteme, bei denen gemeinsam genutzte Ebenen nur einmal über alle Container hinweg Speicher belegen. Ein Cluster, auf dem viele Container aus ähnlichen Basis-Images laufen, kann durch Deduplizierung echt viel Speicherplatz sparen.
Die Optimierung der Speicherzuordnung in modernen Laufzeitumgebungen reduziert den Speicherbedarf. Tools wie crun führen ausführbare Dateien direkt vom Speicher aus, anstatt sie in den Arbeitsspeicher zu laden, wodurch der Speicherbedarf für Container mit großen Binärdateien reduziert wird.
Die Speicherabrechnung für Cgroups ( ) gibt dir die Möglichkeit, die Speichergrenzen von Containern genau zu kontrollieren, aber verschiedene Laufzeiten gehen unterschiedlich mit Speicherbelastungen um. Einige Laufzeitumgebungen holen unter Druck besser Speicher zurück, während andere genauere Berichte zur Speicherauslastung für automatische Skalierungsentscheidungen liefern.
Der Rootless-Memory-Overhead-, tauscht ein bisschen Effizienz gegen mehr Sicherheit ein. Rootless-Container brauchen zusätzliche Prozesse für die Verwaltung von Benutzernamenräumen und die Vernetzung, was im Vergleich zum Betrieb mit Root-Zugriff normalerweise mehr Aufwand bedeutet.
Die Entscheidung für eine Laufzeitumgebung hängt oft davon ab, wie man Speicherplatz und Funktionen gegeneinander abwägt. CRI-O hat wenig Overhead für Kubernetes-Workloads, während Podman ein bisschen Effizienz für mehr Sicherheit und Kompatibilität eintauscht.
Integration des Entwicklungs-Workflows
Die beste Container-Laufzeitumgebung ist nutzlos, wenn sie nicht zu deinem Entwicklungs-Workflow passt. Docker-Alternativen haben Tools entwickelt, die in bestimmten Szenarien oft besser sind als Docker.
Lokale Kubernetes-Umgebungen
Die lokale Kubernetes-Entwicklung hat sich von Minikubes virtueller Maschine zu effizienteren Lösungen entwickelt, die direkt in Container-Laufzeiten integriert sind. Die Wahl der lokalen Umgebung hat einen großen Einfluss auf die Entwicklungsgeschwindigkeit und den Ressourcenverbrauch.
Kind (Kubernetes in Docker) baut Kubernetes-Cluster mit Containern statt mit virtuellen Maschinen auf. Die Einrichtung dauert normalerweise 1–2 Minuten und braucht nicht viel Speicherplatz pro Knoten. Kind funktioniert mit jeder Docker-kompatiblen Laufzeitumgebung, sodass du es mit Podman (kind create cluster --runtime podman) für die rootless Kubernetes-Entwicklung nutzen kannst.
K3s ist eine schlanke Option, die eine komplette Kubernetes-Distribution mit minimalem Speicherbedarf laufen lässt. Es ist schnell einsatzbereit und hat integrierten Speicher, Netzwerkfunktionen und Ingress-Controller. K3s funktioniert super mit containerd und kann auf Entwicklungsrechnern mit wenig Ressourcen laufen.
MicroK8s von Canonical ist ein guter Kompromiss mit nicht so viel Speicherbedarf und modularen Add-ons. Es lässt sich gut mit containerd integrieren und bietet produktionsähnliche Funktionen ohne den Aufwand einer virtuellen Maschine. Die Startzeit ist für einen kompletten Cluster okay.
Rancher Desktop bringt K3s mit Containerd- oder Dockerd-Backends zusammen und bietet so eine Docker Desktop-Alternative, die weniger Ressourcen braucht. Es hat eine eingebaute Bildscanner-Funktion und ist mit dem Kubernetes-Dashboard verbunden.
Podman-Pods bieten eine coole Alternative – du kannst Multi-Container-Anwendungen mit dem Pod-Konzept von Podman entwickeln, das das Verhalten von Kubernetes-Pods nachahmt. Mit „ podman generate kube “ kannst du Kubernetes-YAML direkt aus laufenden Pods machen und so einen nahtlosen Weg von der lokalen Entwicklung bis zur Cluster-Bereitstellung schaffen.
Optimierung der CI/CD-Pipeline
Herkömmliche Docker-basierte CI/CD-Pipelines stoßen in containerisierten Umgebungen an Grenzen, wo die Ausführung von Docker-in-Docker Sicherheits- und Leistungsprobleme mit sich bringt. Moderne Alternativen bieten bessere Möglichkeiten, Container-Images in CI-Systemen zu erstellen und zu pushen.
Buildah-Excel-t in CI-Umgebungen super, weil es keinen Daemon oder Root-Rechte braucht. Du kannst OCI-konforme Images mit Shell-Skripten erstellen, die besser überprüft werden können als Dockerfiles. Der Skriptansatz von Buildah ermöglicht die dynamische Bildkonstruktion auf Basis von CI-Variablen und eignet sich daher super für komplexe Build-Prozesse, die bedingte Logik brauchen.
Bild 7 – Startseite von Buildah
Zum Vergleich: Traditionelle Dockerfiles verwenden deklarative Anweisungen:
FROM alpine:latest
RUN apk add --no-cache nodejs npm
COPY package.json /app/
WORKDIR /appBuildah nutzt imperative Shell-Befehle, die Variablen und bedingte Logik enthalten können:
# Buildah scripting approach with CI integration
buildah from alpine:latest
buildah run $container apk add --no-cache nodejs npm
buildah copy $container package.json /app/
buildah config --workingdir /app $container
buildah commit $container myapp:${CI_COMMIT_SHA}Dank dieser Flexibilität bei der Skripterstellung kannst du Basisimages dynamisch auswählen, Pakete basierend auf Branch-Namen installieren oder Build-Schritte anhand von CI-Umgebungsvariablen anpassen – Funktionen, die in herkömmlichen Dockerfiles komplexe Workarounds erfordern.
Kaniko löst das Problem „“ und „Docker-in-Docker“, indem es Images komplett im Userspace innerhalb eines Containers erstellt. Es läuft in Kubernetes-Pods, ohne dass du privilegierten Zugriff oder einen Docker-Daemon brauchst. Kaniko ist super in GitLab CI und Jenkins X Pipelines, wo Sicherheitsrichtlinien privilegierte Container nicht zulassen.
Das Tool holt Basisbilder raus, macht die Anweisungen aus der Dockerfile-Datei isoliert und schickt die Ergebnisse direkt in die Registries. Die Build-Zeiten sind ähnlich wie bei Docker, aber die Sicherheit in orchestrierten Umgebungen ist viel besser.
Nerdctl macht die Docker-CLI-Kompatibilität von „ “ für containerd verfügbar, was es zu einem super Ersatz für Docker in CI-Systemen macht. Es unterstützt die gleichen Befehle zum Erstellen, Pushen und Pullen wie Docker, nutzt aber containerd als Backend. Dadurch wird der Docker-Daemon entfernt, während die gewohnten Arbeitsabläufe beibehalten werden.
Nerdctl hat coole Features wie Lazy Pulling und verschlüsselte Images, die die CI-Performance verbessern können. Für Teams, die containerd in der Produktion nutzen, sorgt nerdctl für Konsistenz zwischen CI- und Laufzeitumgebungen.
Leistungsvergleich in CI-Pipelines:
- Docker-: Vollständiger Daemon erforderlich, mögliche Sicherheitsprobleme mit privilegierten Containern
- Buildah: Kein Daemon, rootless-fähig, andere Syntax als Dockerfiles
- Kaniko: Containerbasiert, von Grund auf sicher, braucht eine Kubernetes-Umgebung
- Nerdctl: Containerd-Backend, gut für Containerd-basierte Bereitstellungen
Die Entscheidung hängt von deinen Sicherheitsanforderungen, der vorhandenen Infrastruktur und den Leistungsanforderungen ab. Kaniko funktioniert am besten in Kubernetes-Umgebungen, wo Sicherheit wichtig ist, während Buildah super ist, wenn du komplexe Build-Logik brauchst, die sich in Dockerfiles schwer ausdrücken lässt.
Überlegungen zur Bereitstellung in Unternehmen
Für Container-Implementierungen in Unternehmen reicht es nicht, nur die richtige Laufzeitumgebung zu wählen – du brauchst Plattformen, die Compliance, Governance und Multi-Cluster-Betrieb in großem Maßstab abdecken. Die von Ihnen gewählten Container-Alternativen müssen sich in die Unternehmensmanagement-Tools integrieren lassen und die gesetzlichen Anforderungen erfüllen.
Verwaltung mehrerer Cluster
Um Container über mehrere Cluster, Clouds und Edge-Standorte hinweg zu verwalten, braucht man echt gute Orchestrierungsplattformen, die mehr können als nur das, was Kubernetes so bietet. Unternehmenslösungen bieten zentralisierte Verwaltung, Durchsetzung von Richtlinien und einheitliche Abläufe in verschiedenen Umgebungen.
Red Hat OpenShift macht Kubernetes zu einer super flexiblen Cloud-Plattform mit einer Auswahl an Container-Laufzeitumgebungen für Unternehmen. OpenShift nutzt standardmäßig CRI-O, weil es im Vergleich zu Docker-basierten Bereitstellungen sicherer ist und die Ressourcen besser nutzt. Die Plattform hat integrierte Bildscans, Richtlinien und Entwickler-Workflows, die immer funktionieren, egal ob du AWS, Azure oder deine eigene Infrastruktur nutzt.
Bild 8 – Startseite von Red Hat OpenShift
Das Multi-Cluster-Management von OpenShift sorgt für einheitliche Laufzeitbedingungen in allen Umgebungen. Du kannst festlegen, dass alle Cluster CRI-O mit bestimmten Sicherheitsrichtlinien verwenden, um ein einheitliches Verhalten zu gewährleisten, egal ob die Container in Entwicklungs-, Staging- oder Produktionsumgebungen laufen.
Rancher bietet mit „“ eine einheitliche Oberfläche für die Verwaltung von Kubernetes-Clustern, egal welche Container-Laufzeitumgebung dahintersteckt. Rancher unterstützt Cluster, auf denen Docker, Containerd oder CRI-O läuft, sodass du Laufzeiten nach und nach migrieren kannst, ohne den Betrieb zu stören. Die Plattform bietet zentrale Überwachung, Datensicherung und Sicherheitsscans für alle verwalteten Cluster.
Bild 9 – Startseite von Rancher
Der Ansatz von Rancher ist super, wenn du gemischte Umgebungen hast – manche Cluster nutzen vielleicht containerd wegen der Performance, während andere CRI-O wegen der Sicherheit verwenden. Die Managementebene macht diese Unterschiede unsichtbar und stellt gleichzeitig einheitliche Tools für den Betrieb bereit.
Die Mirantis Kubernetes Engine ist voll auf Docker-Umgebungen in Unternehmen ausgerichtet, kann aber auch auf containerd-basierte Bereitstellungen umgestellt werden. Die Plattform bietet Unternehmenssupport, Sicherheitsoptimierung und Compliance-Tools, die mit verschiedenen Container-Laufzeitumgebungen funktionieren.
Bild 10 – Startseite von Mirantis
Diese Plattformen machen Schluss mit dem ganzen Aufwand, der entsteht, wenn man verschiedene Container-Laufzeiten in der Infrastruktur betreibt, und sorgen gleichzeitig für zentrale Verwaltung und Sicherheitsrichtlinien.
Einhaltung von Vorschriften
In Unternehmen muss man oft Vorschriften wie FIPS 140-2, SOC 2 oder DSGVO einhalten, was sich direkt auf die Auswahl und Konfiguration der Container-Laufzeitumgebung auswirkt. Bei der Compliance geht's nicht nur um die Laufzeit selbst, sondern auch um Image-Registries, Sicherheitsscans und Audit-Protokollierung.
Die FIPS-Validierung ( ) erfordert kryptografische Module, die die Sicherheitsstandards der Regierung erfüllen. Nicht alle Container-Laufzeiten unterstützen FIPS-validierte Krypto-Bibliotheken. Red Hat Enterprise Linux bietet FIPS-konforme Versionen von CRI-O und Podman, während Standard-Docker-Installationen oft noch ein bisschen mehr Konfiguration brauchen, um FIPS-konform zu sein.
Die FIPS-Konformität betrifft die Bildsignatur, die TLS-Kommunikation und die verschlüsselte Speicherung. Container-Plattformen müssen FIPS-validierte kryptografische Bibliotheken für alle Sicherheitsvorgänge verwenden, vom Abrufen von Images bis zum Aufbau von Netzwerkverbindungen zwischen Containern.
Die DSGVO-Compliance- en beeinflussen, wie Containerplattformen mit personenbezogenen Daten in Protokollen, Metriken und Bildmetadaten umgehen. Container-Registries für Unternehmen wie Harbor, Quay und AWS ECR bieten Funktionen wie Kontrollen der Datenresidenz, Audit-Protokollierung und automatisierte Richtlinien zur Datenaufbewahrung.
Container-Laufzeiten müssen Compliance-Funktionen unterstützen, wie zum Beispiel:
- Auditprotokollierung die alle Container-Vorgänge für Compliance-Berichte erfasst
- Bildherkunft verfolgen um die Quelle und den Erstellungsprozess von Container-Images zu zeigen
- Verschlüsselung im Ruhezustand für Container-Images und Laufzeitdaten
- Durchsetzung von Netzwerkrichtlinien um den Datenfluss zwischen Containern und externen Systemen zu kontrollieren
Die SOC 2-Compliance-, verlangt nach nachweisbaren Sicherheitskontrollen in den Bereichen Zugriffsmanagement, Systemüberwachung und Datenschutz. Container-Plattformen müssen mit Identitätsanbietern von Unternehmen zusammenarbeiten, detaillierte Prüfpfade bieten und automatisierte Sicherheitsrichtlinien unterstützen.
Moderne Container-Laufzeitumgebungen wie CRI-O und containerd bieten eine bessere Compliance-Basis als Docker, weil sie genauere Sicherheitskontrollen, bessere Audit-Protokollierung und eine klarere Trennung zwischen Laufzeitkomponenten und Verwaltungsschnittstellen bieten.
Die Einhaltung der Vorschriften gilt auch für die Sicherheit der Lieferkette – es muss sichergestellt werden, dass Container-Images aus vertrauenswürdigen Quellen stammen und nicht manipuliert wurden. Tools wie Sigstore und in-toto bieten eine kryptografische Überprüfung der Herkunft von Container-Images, während Zulassungscontroller sicherstellen können, dass nur signierte und gescannte Images in Produktionsclustern ausgeführt werden.
Neue Trends in der Containerisierung
Die Containerisierung entwickelt sich immer weiter, weg von den klassischen Linux-Containern, hin zu neuen Ausführungsmodellen und neuen Möglichkeiten, alles im Blick zu behalten. Diese neuen Technologien versprechen, grundlegende Einschränkungen der aktuellen Containerarchitekturen zu lösen.
WebAssembly-Integration
WebAssembly (WASM) entwickelt sich zu einer coolen Alternative zu herkömmlichen OCI-Containern für bestimmte Workloads. Anders als Container, die den ganzen Benutzerbereich eines Betriebssystems verpacken, bietet WebAssembly eine leichte, sandboxbasierte Ausführungsumgebung, die auf verschiedenen Architekturen fast so schnell wie nativ läuft.
WASM-Module starten viel schneller als herkömmliche Container und sind damit super für serverlose Funktionen und Edge-Computing, wo die Kaltstartzeit direkt die Benutzererfahrung beeinflusst. Ein WebAssembly-Modul kann viel mehr Anfragen abwickeln als ein Container mit längeren Startzeiten.
Das Sicherheitsmodell ist ganz anders als bei Containern. WebAssembly bietet kapazitätsbasierte Sicherheit, bei der Module nur auf Ressourcen zugreifen können, die ihnen ausdrücklich zugeteilt wurden. Es gibt keine gemeinsame Kernel-Oberfläche wie bei herkömmlichen Containern – WASM-Module laufen in einer Sandbox-Umgebung, die viele Arten von Sicherheitslücken verhindert.
Container-Laufzeiten fangen an, WebAssembly-Workloads direkt zu unterstützen. Wasmtime verbindet „ “ mit „containerd“ als Laufzeit-Shim, sodass du WASM-Module mit Standard-Kubernetes-YAML bereitstellen kannst. Das heißt, du kannst traditionelle Container und WebAssembly-Workloads je nach Performance- und Sicherheitsanforderungen im selben Cluster mischen.
Der Nachteil ist, dass das Ökosystem noch nicht so ausgereift ist. WebAssembly hat im Vergleich zu Containern nur eingeschränkte Sprachunterstützung – Rust, C/C++ und AssemblyScript funktionieren gut, während Sprachen wie Python und Java zusätzliche Laufzeit-Layer brauchen, die die Performance-Vorteile verringern.
WASM ist super für Rechenaufgaben, serverlose Funktionen und Edge-Computing, aber noch nicht so weit, Container für komplexe Anwendungen zu ersetzen, die eine umfassende Betriebssystemintegration brauchen.
eBPF-fähige Beobachtbarkeit
eBPF (extended Berkeley Packet Filter) macht die Überwachung von Containern total cool, indem es Einblicke auf Kernel-Ebene gibt, ohne dass man an Apps rumschrauben oder Sidecar-Container einsetzen muss. Anders als bei der herkömmlichen Überwachung, die auf von Anwendungen exportierten Metriken basiert, beobachten eBPF-Programme Systemaufrufe, Netzwerkverkehr und Kernel-Ereignisse in Echtzeit.
Container-bewusste Überwachung über eBPF verbindet Low-Level-Systemereignisse mit höherwertigen Container- und Kubernetes-Metadaten. Mit Tools wie Pixie und Cilium Hubble kannstdu genau sehen, welche HTTP-Anfragen zwischen bestimmten Pods laufen, einschließlich der Latenzzeiten, der Nutzdatenprüfung und der Fehlerraten – und das alles, ohne deine Anwendungen zu verändern.
Dieser Ansatz bietet einen super Einblick in die Kommunikationsmuster von Microservices. Du kannst Servicekarten automatisch erstellen, indem du die tatsächlichen Netzwerkflüsse beobachtest, anstatt dich auf statische Konfigurationen zu verlassen. Wenn ein Dienst anfängt, mit einer neuen Abhängigkeit zu reden, merken die eBPF-basierten Tools das sofort und aktualisieren die Dienst-Topologie in Echtzeit.
Leistungsprofilierungs- en über eBPF zeigen, wo es auf Container-Ebene Probleme gibt. Du musst nicht mehr raten, warum ein Pod langsam ist, sondern kannst genau sehen, welche Systemaufrufe Zeit brauchen, auf welche Dateien zugegriffen wird und wie sich die Netzwerklatenz auf die App-Performance auswirkt. Diese Daten werden ständig gesammelt, ohne dass es viel Platz braucht, normalerweise weniger als 1 % der CPU-Leistung.
Sicherheitsüberwachungs s profitieren von der Fähigkeit von eBPF, ungewöhnliche Verhaltensmuster zu erkennen. Anstatt Protokolle nach einem Vorfall zu checken, können eBPF-Programme verdächtige Systemaufrufe, unerwartete Netzwerkverbindungen oder Dateizugriffsmuster erkennen, sobald sie passieren. Das macht es möglich, Bedrohungen in Echtzeit zu erkennen, die die Container-Grenzen und die Identität der Kubernetes-Workloads kennen.
Die Integration zwischen eBPF und Container-Laufzeiten wird immer besser. Cilium bietet eBPF-basiertes Networking für Kubernetes, das schneller und besser zu beobachten ist als herkömmliche CNI-Plugins. Falco nutzt eBPF für die Überwachung der Laufzeitsicherheit, das den Container-Kontext von Haus aus versteht.
Dieser Trend zur Beobachtbarkeit auf Kernel-Ebene ist ein echter Wandel von der Black-Box-Überwachung hin zu vollständiger Systemtransparenz. Dadurch werden Containerumgebungen standardmäßig besser debugbar und sicherer.
Zusammenfassung der Docker-Alternativen
Bei der richtigen Docker-Alternative geht's nicht darum, einfach einen Ersatz zu finden, sondern die Tools an die speziellen Anforderungen in deinen Entwicklungs- und Produktionsumgebungen anzupassen. Das Containerisierungs-Ökosystem ist zu einer Sammlung von Lösungen gereift, die in verschiedenen Szenarien echt gut funktionieren.
Für Entwickler bietet Podman dank seiner Kompatibilität mit der Docker-CLI einen super reibungslosen Migrationspfad und sorgt durch rootless Betrieb für erstklassige Sicherheit. Wenn du viel in Docker Desktop-Workflows investiert hast, bietet Rancher Desktop mit containerd ähnliche Funktionen bei besserer Ressourceneffizienz. Teams, die komplexe CI/CD-Pipelines aufbauen, profitieren von der Flexibilität der Skripte von Buildah oder dem sicheren, daemonfreien Ansatz von Kaniko.
Im Produktionsmaßstab bieten „ “, „containerd“ und „CRI-O“ eine bessere Leistung und Ressourceneffizienz als die Docker Engine. Containerd ist super für Unternehmensumgebungen, die Stabilität und viele Funktionen brauchen, während CRI-O die effizienteste Option für Kubernetes-fokussierte Bereitstellungen ist. Für Edge-Computing oder eingebettete Systeme bieten leichte Laufzeitumgebungen wie runC oder Youki den minimalen Overhead, der für ressourcenbeschränkte Umgebungen nötig ist.
Sicherheitsbewusste Unternehmen sollten rootless Runtimes wie Podman oder rootless containerd bevorzugen. Die Kombination aus Isolierung des Benutzer-Namespace, eBPF-basierter Überwachung und reduzierter Angriffsfläche bietet einen umfassenden Schutz, den herkömmliche Docker-Bereitstellungen nicht bieten können. Für regulierte Branchen solltest du sicherstellen, dass die von dir gewählte Laufzeitumgebung FIPS-konform ist und sich in die Audit-Protokollierungssysteme deines Unternehmens einbinden lässt.
In der Praxis funktioniert ein hybrider Ansatz oft am besten. Nutze Podman für die lokale Entwicklung, um von Rootless-Sicherheit und Docker-Kompatibilität zu profitieren. Stell Produktions-Workloads auf Containerd oder CRI-O bereit, um die Kubernetes-Integration und -Performance zu optimieren. Speicher spezielle Tools wie Buildah für CI/CD-Pipelines, wo Sicherheit und Flexibilität wichtiger sind als Kompatibilität.
>Suchst du Ideen für Docker- und Containerisierungsprojekte? Mit diesen 10 kannst du loslegen.
Für die Zukunft sind WebAssembly und eBPF die nächste Stufe in der Containerisierungs. Die schnellen Startzeiten und die starken Sicherheitsgarantien von WebAssembly werden wahrscheinlich bei serverlosen und Edge-Computing-Workloads die Oberhand gewinnen. Die Beobachtbarkeit auf Kernel-Ebene von eBPF verändert bereits jetzt, wie wir containerisierte Anwendungen überwachen und sichern. Diese Technologien werden herkömmliche Container nicht komplett ersetzen, aber sie werden neue Kategorien von Workloads schaffen, für die die aktuellen Container-Einschränkungen nicht gelten.
Der Schlüssel liegt darin, flexibel zu bleiben, während diese Technologien ausgereift werden, und zu verstehen, dass die beste Containerisierungsstrategie mehrere Tools kombiniert, anstatt sich auf eine einzige Lösung zu verlassen.
Wenn du mehr über Docker, Containerisierung, Virtualisierung und Kubernetes erfahren möchtest, sind diese Kurse der perfekte nächste Schritt:
Docker und Kubernetes beherrschen
Lerne in einem interaktiven Lernpfad die Leistungsfähigkeit von Docker und Kubernetes kennen, um Anwendungen in modernen Umgebungen zu entwickeln und einzusetzen.
Themen
