Containerisierung 2025: Warum containerd 2.0 und eBPF alles verändern

Die Containerisierungslandschaft ist seit jeher dynamisch und hat Ende 2024 und im Laufe des Jahres 2025 eine Flut an praktischen, soliden Fortschritten erlebt. Als erfahrene Entwickler sind wir über den "Hype-Zyklus" hinaus und in den Praxistest übergegangen, um Funktionen zu bewerten, die greifbare operative Vorteile bieten und reale Einschränkungen berücksichtigen. Das vergangene Jahr hat mehrere Trends gefestigt: ein unerbittlicher Drang nach verbesserter Sicherheit über die gesamte Lieferkette hinweg, grundlegende Verbesserungen der Laufzeiteffizienz, ein bedeutender Sprung in der Benutzerfreundlichkeit beim Erstellen von Multi-Architektur-Deployments und das Aufkommen von WebAssembly als glaubwürdige, wenn auch noch in den Kinderschuhen steckende, Alternative für bestimmte Workloads. Hier ist eine detaillierte Analyse der Entwicklungen, die wirklich wichtig sind.

Die neue Grundlage: containerd 2.0 und eBPF

containerd 2.0: Die CRI-Grundlage neu gehärtet

Die Grundlage unserer containerisierten Welt, die Container-Runtime, hat erhebliche Fortschritte gemacht, insbesondere mit der Veröffentlichung von containerd 2.0 Ende 2024. Dies ist nicht nur ein inkrementelles Update; es ist eine strategische Stabilisierung und Verbesserung der Kernfunktionen sieben Jahre nach der Veröffentlichung von Version 1.0. Der Wegfall von dockershim in Kubernetes v1.24 hat containerd und CRI-O in den Vordergrund gerückt, ähnlich wie moderne CLI-Tools die Entwicklererfahrung im Jahr 2025 neu definieren.

containerd 2.0 bringt mehrere wichtige Funktionen in den stabilen Kanal, die genaue Aufmerksamkeit verdienen. Die Node Resource Interface (NRI) ist jetzt standardmäßig aktiviert und bietet einen leistungsstarken Erweiterungsmechanismus zur Anpassung von Low-Level-Containerkonfigurationen. Dies ermöglicht eine feinere Kontrolle über die Ressourcenallokation und die Durchsetzung von Richtlinien, ähnlich wie mutating admission webhooks, jedoch direkt auf Laufzeitebene. Entwickler können NRI-Plugins nutzen, um spezifische Laufzeitkonfigurationen einzufügen oder benutzerdefinierte Ressourcenverwaltungsrichtlinien dynamisch anzuwenden, eine Fähigkeit, die zuvor ohne direkte Laufzeitmodifikationen schwieriger zu implementieren war.

Darüber hinaus unterstützt containerd 2.0 jetzt Image Verifier Plugins. Dies ist wirklich beeindruckend, da es die Durchsetzung von Richtlinien für Images zum Zeitpunkt des Image-Pulls ermöglicht. Denken Sie darüber nach: Anstatt Images nur während der CI/CD oder bei der Bereitstellung zu scannen, kann containerd nun ein externes Plugin (das eine beliebige ausführbare Datei oder ein Skript sein kann) aufrufen, um die Integrität oder Compliance eines Images zu validieren, bevor es vollständig heruntergeladen und ausgeführt wird. Dies integriert sich direkt in den transfer service (stabilisiert in 2.0), obwohl zu beachten ist, dass das CRI-Plugin noch nicht vollständig integriert ist, sodass die unmittelbare Auswirkung auf Kubernetes-Deployments möglicherweise begrenzt ist, bis dies erfolgt. Für direkte containerd-Benutzer ist dies jedoch ein robuster Schritt nach vorn für die Sicherheit der Lieferkette an der Laufzeitgrenze. In Bezug auf die Sicherheit enthält containerd v2.2.0 auch Fixes für kritische Schwachstellen wie CVE-2024-25621 und CVE-2025-64329, zusammen mit runc v1.3.3, das CVE-2025-31133, CVE-2025-52565 und CVE-2025-52881 behebt, was einen kontinuierlichen Aufwand zur Härtung der Kernkomponenten zeigt.

eBPFs Aufstieg: Kernel-Level-Kontrolle für Netzwerk & Observability

Ich habe darauf gewartet, dass eBPF in der Container-Ökosystem wirklich Fuß fasst, und spätes 2024 bis 2025 hat dies geliefert. Die Integration von eBPF (extended Berkeley Packet Filter) in Kubernetes-Netzwerk- und Observability-Stacks hat sich von einer experimentellen Neugier zu einer grundlegenden Technologie entwickelt. eBPF ermöglicht das Ausführen von sandboxed Programmen direkt innerhalb des Linux-Kernels, die durch verschiedene Ereignisse ausgelöst werden und eine beispiellose Leistung und Flexibilität ohne den Overhead traditioneller Kernel-to-User-Space-Kontextwechsel bieten.

Für das Networking ersetzen eBPF-basierte Container Network Interface (CNI)-Plugins wie Cilium und Calico aktiv oder bieten überlegene Alternativen zu iptables-basierten Ansätzen. Der Kernvorteil liegt in der effizienten Paketverarbeitung. Anstatt komplexe iptables-Ketten für jedes Paket zu durchlaufen, können eBPF-Programme Routing- und Richtlinienentscheidungen direkt an einem früheren Punkt im Netzwerk-Stack des Kernels treffen. Dies reduziert den CPU-Overhead und die Latenz drastisch, insbesondere in großen Kubernetes-Clustern. Projekte wie Cilium haben das Container-Networking weiterentwickelt, indem sie iptables durch effiziente eBPF-Datapaths ersetzt haben, und sein graduierter Status mit der CNCF und die Einbeziehung in Projekte wie OpenTelemetry machen es zu einem De-facto-Standard für die Handhabung von Netzwerkrichtlinien.

Über die Leistung hinaus verbessert eBPF die Observability erheblich. Durch das Anhängen von eBPF-Programmen an Systemaufrufe, Netzwerkereignisse und Prozessaktivitäten können Entwickler detaillierte Telemetriedaten direkt aus dem Kernel in Echtzeit erfassen. Dies bietet eine granulare Sichtbarkeit in das Containerverhalten, die Netzwerkflüsse und die Systemaufrufe, ohne intrusive Sidecar-Proxys oder Anwendungs-Instrumentation zu erfordern. Beispielsweise kann ein eBPF-Programm alle Netzwerkverbindungen überwachen, die von einem bestimmten Container initiiert werden, ungewöhnliche Dateizugriffsmuster erkennen oder Systemaufrufe verfolgen und so ein leistungsstarkes Werkzeug sowohl für die Leistungsdebuggung als auch für die Echtzeit-Erkennung von Sicherheitsbedrohungen bieten.

Modernisierung des Build- und Dev-Workflows

BuildKit 2.0 & Docker Build Cloud: Intelligenter, schneller, sicherer Build

Wenn Sie docker build immer noch als Blackbox betrachten, verpassen Sie etwas. BuildKit ist seit Version 23.0 der Standard-Builder in Docker Engine, und BuildKit 2.0 zusammen mit der Docker Build Cloud stellt einen bedeutenden Fortschritt in der Art und Weise dar, wie wir Container-Images erstellen. BuildKit 2.0 geht es nicht nur um Geschwindigkeit; es ist ein Paradigmenwechsel hin zu sichereren, portableren und intelligenter optimierten Build-Pipelines.

Eines der herausragenden Features in BuildKit 2.0 ist Federated Caching. Registry-basiertes Caching (--cache-from) war schon immer etwas langsam und netzwerkintensiv. Federated Caching führt jedoch einen Peer-to-Peer-Caching-Mechanismus ein, der es Ihren Build-Agenten ermöglicht, einen verteilten Cache-Cluster zu bilden. Wenn ein Agent eine Ebene erstellt, kann sie sofort für andere im selben Netzwerk verfügbar sein, ohne einen Roundtrip zu einem Remote-Registry. Dies verkürzt die Build-Zeiten für Teams drastisch, insbesondere in Microservice-Architekturen, in denen Basis-Images häufig neu erstellt werden, und verwandelt eine Kaffeepause in eine schnelle Aktualisierung.

Ebenso aufregend ist die Einführung von Native WASM Build Steps. Komplexe RUN-Befehle mit curl, tar und sed sind berüchtigt dafür, fehleranfällige und unsichere Builds zu erzeugen. BuildKit 2.0 geht dies an, indem es die Verwendung von WebAssembly (WASM)-Modulen als native Build-Schritte ermöglicht. Anstatt Shell-Befehle zu verketten, können Sie eine vorkompilierte, sandboxed WASM-Binärdatei verwenden, um Aufgaben wie das Abrufen von Assets, die Code-Generierung oder das Linting auszuführen. Dies bietet sandboxed Ausführung und verbesserte Portabilität und macht Ihre Builds zuverlässiger und sicherer. Darüber hinaus integriert BuildKit 2.0 tiefgreifend moderne Sicherheitspraktiken und generiert automatisch SLSA-Attestierungen und signiert Images mit Sigstore/Cosign als nativen Teil des Build-Prozesses.

Ergänzend zu BuildKit 2.0 zielt Docker Build Cloud, das im Januar 2024 eingeführt wurde, darauf ab, Builds zu beschleunigen, indem sie in die Cloud ausgelagert werden. Dieser Service nutzt Cloud-Rechenleistung und Cache, um Build-Zeiten bis zu 39-mal schneller als lokale Builds zu erreichen. Er bietet native Unterstützung für Multi-Architektur-Builds (AMD64, ARM64) und eliminiert die Notwendigkeit langsamer Emulationen oder der Wartung mehrerer nativer Builder. Der Befehl docker buildx build --platform linux/amd64,linux/arm64 -t myregistry/my-app:latest --push . macht das Erstellen für mehrere Architekturen nahtlos.

Docker Compose v5: Verbesserung der lokalen Entwicklungsworkflows

Docker Compose war schon immer der Arbeitspferd für die lokale Multi-Container-Entwicklung, aber die jüngste Entwicklung, die in Compose v5 im Dezember 2025 gipfelte, hat es zu einem noch leistungsstärkeren und integrierteren Tool gemacht. Die bedeutendste strukturelle Änderung war die vollständige Integration von docker compose (die Go-basierte Implementierung) direkt in die Docker CLI, wodurch die ältere Python-basierte docker-compose (mit Bindestrich) offiziell veraltet wurde.

Eines der Features, auf das ich gewartet habe, ist docker compose watch. Dieser Befehl verfolgt Dateien und aktualisiert laufende Container automatisch, sobald eine Datei gespeichert wird, wodurch die Notwendigkeit manueller docker compose up- oder restart-Zyklen entfällt. Für einen Webanwendungsentwickler bedeutet dies eine enge Feedbackschleife: Schreiben-Speichern-Anzeigen geschieht in Sekunden, perfekt zum Iterieren an API-Endpunkten oder Live-Frontend-Vorschauen. Sie können dies mit einem einfachen Label in Ihrer compose.yml aktivieren:

services:
  web:
    build: .
    ports:
      - "80:80"
    labels:
      com.docker.compose.watch: "true" # Aktiviert den Watch-Modus für diesen Service

Weitere bemerkenswerte CLI-Verbesserungen umfassen docker compose attach zum Debuggen, docker compose stats zur Live-Ressourcenauslastungsüberwachung und docker compose cp zum einfachen Kopieren von Dateien zwischen dem Host und einem Service-Container. Das Feld version in docker-compose.yml ist jetzt vollständig veraltet; moderne Compose-Dateien sollten es weglassen und direkt mit dem Block services: beginnen. Compose v5 führt auch ein neues offizielles Go SDK ein, das eine umfassende API zur direkten Integration der Compose-Funktionalität in Anwendungen bietet.

KI/ML und die Weiterentwicklung von Docker Desktop

Docker Desktops KI/ML-Pivot: Über reine Containerisierung hinaus

Docker Desktop entwickelt sich weiter als umfassende Entwickler-Workstation, und seine Funktionen im Jahr 2025 zeigen einen deutlichen Pivot hin zur Unterstützung von KI/ML-Entwicklungsworkflows. Über seine Kernfunktion hinaus, eine lokale Docker Engine und einen Kubernetes-Cluster bereitzustellen, integriert Docker Desktop jetzt Tools, die direkt auf die Schwachstellen von KI-Entwicklern eingehen.

Das Feature Model Runner beispielsweise zielt darauf ab, die lokale LLM-Ausführung zu vereinfachen. Das Ausführen von KI-Modellen lokal beinhaltet oft das Jonglieren mit Python-Umgebungen, CUDA-Installationen, spezifischen Modellformaten und komplexen Abhängigkeiten. Docker's Model Runner abstrahiert viel dieser Komplexität und ermöglicht Entwicklern, Modelle mit einem einfachen docker model pull ai/llama3.2:1B-Q8_0-Befehl (ab Docker Desktop 4.40+) herunterzuladen und auszuführen. Dies ist wirklich beeindruckend, da es die Einstiegshürde für das Experimentieren mit großen Sprachmodellen und anderen KI-Anwendungen senkt und eine konsistente, containerisierte Umgebung für die Modellausführung bietet.

Für Workloads, die die lokalen Maschinenressourcen übersteigen, bietet Docker Offload eine nahtlose Möglichkeit, Modelle und Container auf Cloud-GPUs auszuführen. Dies befreit Entwickler von Infrastrukturbeschränkungen, indem rechenintensive Aufgaben, wie z. B. große Sprachmodelle und Multi-Agent-Orchestrierung, an leistungsstarke Cloud-Umgebungen ausgelagert werden. Darüber hinaus runden das MCP Toolkit (für die Entwicklung von KI-Agenten) und Docker Debug (für verbesserte Fehlerbehebung mit schlanken Debug-Containern) Docker Desktops erweiterte Fähigkeiten ab und machen es zu einem vielseitigeren Tool für moderne, ressourcenintensive Entwicklung.

Härtung der Lieferkette und Datenschutz

Erweiterte Imagesicherheit & gehärtete Images

Die zunehmende Abhängigkeit von Open-Source-Komponenten bedeutet, dass Container-Images ein primärer Kontrollpunkt für die Sicherheit der Softwarelieferkette sind, und Docker hat seine Bemühungen in den Jahren 2024-2025 deutlich verstärkt. Über 90 % der modernen Anwendungen sind auf Open Source angewiesen, und Container-Images können Hunderte von Abhängigkeiten enthalten, was die Image-Schicht zu einer der größten und am wenigsten sichtbaren Angriffsflächen macht.

Docker Scout (früher Docker Scan) ist jetzt ein zentraler Bestandteil dieser Strategie und bietet eine kontinuierliche Schwachstellenanalyse für unbegrenzte Scout-fähige Repositories innerhalb der Docker Team- und Business-Pläne. Es bietet Echtzeit-Einblicke in das Image-Risiko und empfohlene Abhilfemaßnahmen und lässt sich nahtlos in die Docker CLI und CI/CD-Pipelines integrieren. Dieser "Shift-Left"-Ansatz ist entscheidend, da er Entwicklern ermöglicht, Schwachstellen frühzeitig im Entwicklungszyklus zu erkennen und zu beheben, wodurch verhindert wird, dass unsichere Images die Produktion erreichen.

Eine besonders wirkungsvolle Entwicklung ist die Entscheidung von Docker, Docker Hardened Images kostenlos für jedermann zur Verfügung zu stellen. Diese Images bieten eine sichere Standardbasis und reduzieren die Reibung zwischen Entwicklungsgeschwindigkeit und Sicherheit. Sie verfügen über eine erweiterte Lebenszyklusunterstützung, die Unternehmen hilft, konform zu bleiben und Risiken durch End-of-Life zu mindern. Dieser Schritt signalisiert Dockers Engagement, einen neuen Standard für das gesamte Container-Ökosystem zu setzen und Sicherheit zu einer Basiserwartung anstatt zu einem Premium-Feature zu machen.

Confidential Containers: Vertrauen in nicht vertrauenswürdige Umgebungen schaffen

Für hochsensible Workloads hat sich das Konzept der Confidential Containers (CoCo) deutlich weiterentwickelt und bewegt sich von Nischenforschung zu praktischen Implementierungen. CoCo ist ein CNCF-Sandbox-Projekt, das darauf abzielt, vertrauliches Cloud-Computing zu ermöglichen, indem es Trusted Execution Environments (TEEs) nutzt, um Container und Daten zu schützen. Dies ist ein Game-Changer für den Datenschutz, insbesondere in regulierten Branchen oder bei der Verarbeitung personenbezogener Daten (PII).

Die Kernidee besteht darin, sichere Enklaven innerhalb eines Prozessors zu erstellen, die die verarbeiteten Daten vor der Umgebung schützen, einschließlich der CPU, des Hypervisors und sogar der Cloud-Administratoren. Technologien wie Intel SGX, Intel TDX und AMD SEV bilden die Hardwarebasis und verschlüsseln den Container-Speicher, wodurch verhindert wird, dass Daten im Speicher im Klartext vorliegen. Dieser "Blackbox"-Ansatz stellt sicher, dass sensible Workflows vor unbefugtem Zugriff geschützt sind.

Das Ziel des CoCo-Projekts ist es, vertrauliches Computing auf Containerebene zu standardisieren und seine Nutzung in Kubernetes zu vereinfachen. Dies bedeutet, dass Kubernetes-Benutzer vertrauliche Container-Workloads mit vertrauten Workflows und Tools bereitstellen können, ohne über umfassende Kenntnisse der zugrunde liegenden vertraulichen Computing-Technologien verfügen zu müssen. Obwohl es für einige Cloud-Anbieter noch in der Vorschau ist und einen inhärenten Leistungsaufwand aufgrund der zusätzlichen Isolation mit sich bringt, ist die Möglichkeit, ein neues Maß an Datenvertraulichkeit und -integrität zu erreichen, indem verhindert wird, dass Daten im Speicher lesbar sind, ein leistungsstarker Fortschritt.

Die Realität von Wasm und der Weg nach vorn

Die Nuance von Wasm: Eine Geschichte von zwei Implementierungen

WebAssembly (Wasm) im Container-Ökosystem stellt eine interessante Dualität dar. Einerseits ist BuildKit 2.0s Einführung von Native WASM Build Steps eine überzeugende Entwicklung zur Verbesserung der Build-Sicherheit und -Portabilität. Hier werden WASM-Module innerhalb des Build-Prozesses verwendet, um bestimmte Aufgaben auszuführen und eine sandboxed und effiziente Alternative zu herkömmlichen Shell-Skripten zu bieten. Dies ist ein praktischer und solider Fortschritt, der reale Probleme der Build-Zuverlässigkeit und -Sicherheit angeht.

Die Geschichte für Wasm als direkte Container-Runtime innerhalb von Docker Desktop scheint sich jedoch anders zu entwickeln. Die Docker Desktop 4.55.0 Release Notes vom Dezember 2025 geben explizit an, dass Wasm-Workloads in einer zukünftigen Docker Desktop-Version veraltet und entfernt werden. Dies ist eine entscheidende Realitätsprüfung. Während runwasi als nicht-kerniges containerd-Projekt für einen WASM-Shim existiert, deutet Dockers Entscheidung für Desktop darauf hin, dass die direkte Wasm-Runtime-Ausführung möglicherweise nicht die erwartete Akzeptanz oder technische Durchführbarkeit für allgemeine Entwickler-Workflows innerhalb ihres Desktop-Produkts erfüllt hat.

Fazit: Der Weg nach vorn

Was für ein Jahr das war! Die Fortschritte bei Docker, containerd und Kubernetes Ende 2024 und im Laufe des Jahres 2025 sind schlichtweg beeindruckend. Wir haben gesehen, wie sich containerd 2.0 als robuste, erweiterbare Grundlage für Container-Runtimes etabliert hat und leistungsstarke neue Hooks wie NRI und Image-Verifier-Plugins bietet. Der Aufstieg von eBPF hat grundlegend verändert, wie wir über Container-Networking, Observability und Sicherheit denken, und die Effizienz auf Kernel-Ebene und die Sichtbarkeit in den Mainstream gebracht.

Für Entwickler zeigen Docker Compose v5 und Docker Desktops neue KI/ML-orientierte Funktionen wie Model Runner und Docker Offload ein Engagement für die Rationalisierung von Workflows über das reine Container-Management hinaus und die Akzeptanz neuer Trends. Und vielleicht am wichtigsten ist, dass der unerbittliche Fokus auf die Sicherheit der Lieferkette, der sich in Docker Scouts kontinuierlicher Analyse und der Verfügbarkeit von kostenlosen Docker Hardened Images zeigt, einen höheren Standard für das Vertrauen in unsere Softwareartefakte setzt. Während einige Funktionen, wie die direkte Wasm-Ausführung in Docker Desktop, neu bewertet werden, ist die allgemeine Richtung klar: Container werden sicherer, leistungsfähiger und stärker in die fortschrittlichen Entwicklungsparadigmen von heute und morgen integriert.