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

Die Containerisierungs-Landschaft, die sich ständig weiterentwickelt, hat Ende 2024 und im Laufe des Jahres 2025 eine Vielzahl praktischer und robuster Fortschritte 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 für 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 sich entwickelnde Container-Runtime-Landschaft: containerd 2.0 und darüber hinaus

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 an die Spitze gerückt und die Container Runtime Interface (CRI) als Standard-Interaktionsprotokoll zwischen dem kubelet und der zugrunde liegenden Runtime etabliert.

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 bei mutating admission webhooks, jedoch direkt auf Runtime-Ebene. Entwickler können NRI-Plugins nutzen, um bestimmte Runtime-Konfigurationen einzufügen oder benutzerdefinierte Ressourcenverwaltungsrichtlinien dynamisch anzuwenden, eine Fähigkeit, die zuvor ohne direkte Runtime-Modifikationen schwieriger zu implementieren war. Stellen Sie sich ein Szenario vor, in dem eine Organisation bestimmte CPU-Pinning- oder Speicherseitenallokationen für leistungskritische Workloads erzwingen muss; ein NRI-Plugin kann dies jetzt beim Containerstart vermitteln und so eine konsistente Anwendung über verschiedene Knotentypen hinweg gewährleisten, ohne den Kern-containerd-Daemon zu verändern.

Ein weiterer bemerkenswerter Fortschritt ist die Stabilisierung der Image Verifier Plugins. Während das CRI-Plugin in containerd 2.0 noch nicht vollständig in den neuen Transfer-Service für das Image-Pulling integriert ist und daher nicht sofort für Kubernetes-Workloads verfügbar ist, signalisiert seine Präsenz eine robuste Zukunft für die Image-Policy-Durchsetzung zur Pull-Zeit. Diese Plugins sind ausführbare Programme, die containerd aufrufen kann, um zu bestimmen, ob ein Image gezogen werden darf, und bieten einen entscheidenden Kontrollpunkt für die Sicherheit der Lieferkette. Sobald sie in die CRI integriert sind, können Kubernetes-Administratoren granulare Richtlinien definieren – beispielsweise nur Images zulassen, die von bestimmten Schlüsseln signiert sind oder über eine verifizierte Software Bill of Materials (SBOM) verfügen – direkt auf Knotenebene, bevor ein Container überhaupt versucht zu starten. Dies verlagert die Richtliniendurchsetzung nach links und verhindert, dass potenziell kompromittierte Images jemals auf einem Knoten landen.

Die containerd-Konfiguration wurde ebenfalls aktualisiert und ist auf v3 umgestellt. Das Migrieren bestehender Konfigurationen ist ein unkomplizierter Prozess mit containerd config migrate. Während die meisten Einstellungen kompatibel bleiben, müssen Benutzer, die den veralteten aufs-Snapshotter verwenden, zu einer modernen Alternative wechseln. Dies erzwingt eine notwendige Bereinigung und fördert performantere und gewartete Speicher-Backends.

Stärkung der Software-Lieferkette: Sigstores Aufstieg

Das Jahr 2025 markiert einen entscheidenden Wendepunkt bei der Signierung von Container-Images, wobei sich Sigstore als offener Standard für die Sicherheit der Software-Lieferkette etabliert hat. Docker erkannte die sich entwickelnde Landschaft und die begrenzte Akzeptanz seines Legacy Docker Content Trust (DCT) und begann im August 2025 formell mit der Ausmusterung von DCT (das auf Notary v1 basierte). Dieser Schritt erfordert zwar eine Migration für eine kleine Teilmenge von Benutzern, ebnet aber den Weg für einen einheitlicheren und robusteren Ansatz für die Image-Herkunft.

Sigstore adressiert den kritischen Bedarf an überprüfbarer Integrität der Lieferkette durch eine Reihe von Tools: Cosign zum Signieren und Verifizieren von OCI-Artefakten, Fulcio als kostenlose, öffentliche Root Certificate Authority, die kurzlebige Zertifikate ausstellt, und Rekor als Transparenzprotokoll für alle Signaturereignisse. Dieses Dreigestirn ermöglicht "keyless" Signing, ein bedeutender Paradigmenwechsel. Anstatt langfristige statische Schlüssel zu verwalten, verwenden Entwickler OIDC-Token von ihrem Identity Provider (z. B. GitHub, Google), um kurzlebige Signaturzertifikate von Fulcio zu erhalten. Cosign verwendet dann dieses Zertifikat, um das Image zu signieren, und die Signatur zusammen mit dem Zertifikat wird im unveränderlichen Rekor-Transparenzprotokoll aufgezeichnet.

Beispielsweise ist das Signieren eines Images mit Cosign bemerkenswert vereinfacht:

# Authenticate with your OIDC provider
# cosign will often pick this up automatically from environment variables.

# Sign an image (keyless)
cosign sign --yes <your-registry>/<your-image>:<tag>

# Verify an image
cosign verify <your-registry>/<your-image>:<tag>

Die --yes-Flag in cosign sign umgeht interaktive Eingabeaufforderungen, was für CI/CD-Pipelines entscheidend ist. Der Verifizierungsschritt, cosign verify, fragt Rekor ab, um die Authentizität und Integrität der Signatur zu gewährleisten und sie mit einer überprüfbaren Identität zu verknüpfen. Dies bietet eine starke, überprüfbare Herkunft ohne den betrieblichen Aufwand einer herkömmlichen PKI.

Turbocharging Builds mit Buildx und BuildKit

Docker's Buildx, unterstützt durch das BuildKit-Backend, hat sich zu einem unverzichtbaren Tool für jeden ernsthaften Container-Entwicklungsworkflow entwickelt, insbesondere für Multi-Plattform-Image-Builds und Caching-Strategien. Der traditionelle docker build-Befehl mag zwar funktionsfähig sein, leidet aber oft unter Leistungsengpässen und begrenzter Unterstützung für Cross-Architekturen. BuildKit rearchitekturiert den Build-Prozess grundlegend mithilfe eines gerichteten azyklischen Graphen (DAG) für Build-Operationen, der eine parallele Ausführung unabhängiger Schritte und überlegene Caching-Mechanismen ermöglicht.

Das herausragende Feature, Multi-Plattform-Builds, ist nicht mehr eine Nischenfähigkeit, sondern eine praktische Notwendigkeit in einer Welt, die sich schnell in amd64, arm64 und sogar arm/v7-Architekturen diversifiziert. Buildx ermöglicht es mit einem einzigen docker buildx build-Befehl, eine Manifestliste zu erstellen, die Images für mehrere Zielplattformen enthält, wodurch die Notwendigkeit separater Build-Umgebungen entfällt.

Betrachten Sie diese Dockerfile:

# Dockerfile
FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app/my-app ./cmd/server

FROM --platform=$BUILDPLATFORM alpine:3.18
COPY --from=builder /app/my-app /usr/local/bin/my-app
CMD ["/usr/local/bin/my-app"]

Um für linux/amd64 und linux/arm64 zu bauen und in ein Registry zu pushen:

docker buildx create --name multiarch-builder --use
docker buildx inspect --bootstrap
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myregistry/my-app:latest \
  --push .

In Bezug auf die Leistung ist das Caching von BuildKit überlegen. Über das lokale Layer-Caching hinaus unterstützt Buildx das Registry-Caching, bei dem zuvor in ein Registry gepushte Build-Layer für nachfolgende Builds genutzt werden können, was die Build-Zeiten für häufig aktualisierte Projekte deutlich reduziert. Dies ist besonders in CI/CD-Pipelines wirkungsvoll, in denen Build-Umgebungen oft flüchtig sind.

eBPF: Neudefinition von Kubernetes-Netzwerken und Beobachtbarkeit

Die Integration von eBPF (extended Berkeley Packet Filter) in Kubernetes-Netzwerk- und Beobachtbarkeits-Stacks hat sich Ende 2024 und 2025 von experimenteller Neugier zu einer grundlegenden Technologie entwickelt. eBPF ermöglicht es gesandboxed Programmen, direkt innerhalb des Linux-Kernels ausgeführt zu werden, ausgelöst durch verschiedene Ereignisse, und bietet eine beispiellose Leistung und Flexibilität ohne den Overhead traditioneller Kernel-to-User-Space-Kontextwechsel.

Für Netzwerke bieten eBPF-basierte Container Network Interface (CNI)-Plugins wie Cilium und Calico aktive Ersatzlösungen oder ü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.

Über die Leistung hinaus verbessert eBPF die Beobachtbarkeit 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. Tools wie Cilium Hubble nutzen eBPF, um Netzwerkflüsse in Kubernetes zu überwachen und bieten tiefe Einblicke in die Service-to-Service-Kommunikation, einschließlich Latenz, übertragenen Bytes und Richtliniendurchsetzungsentscheidungen.

WebAssembly: Ein neues Paradigma für Cloud-Native-Workloads

WebAssembly (Wasm), ursprünglich für den Browser konzipiert, hat unbestreitbar die Kluft in Server-Side- und Cloud-Native-Umgebungen überwunden und stellt 2025 eine überzeugende Alternative zu traditionellen Containern für bestimmte Anwendungsfälle dar. Seine Kernvorteile – blitzschnelle Startzeiten, winziger Footprint und starke Sandbox-Sicherheit – machen es besonders attraktiv für Serverless-Funktionen und Edge Computing. Wie wir in der Entwicklung von Node.js, Deno, Bun in 2025 sehen, diversifiziert sich die Runtime-Landschaft, um diesen Leistungsanforderungen gerecht zu werden.

Wasm-Module starten typischerweise in Millisekunden, ein deutlicher Kontrast zu den Sekunden, die traditionelle Container-Cold-Starts oft benötigen. Die Integration von Wasm in Kubernetes wird hauptsächlich durch CRI-kompatible Runtimes und Shims erreicht. Projekte wie runwasi bieten ein containerd-Shim, das es Kubernetes ermöglicht, Wasm-Module neben traditionellen Linux-Containern zu planen.

Zum Beispiel, um eine Wasm-Anwendung mit crun auszuführen:

# runtimeclass.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasm-crun
handler: crun
---
# wasm-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: wasm-demo
  annotations:
    module.wasm.image/variant: compat
spec:
  runtimeClassName: wasm-crun
  containers:
  - name: my-wasm-app
    image: docker.io/myuser/my-wasm-app:latest
    command: ["/my-wasm-app"]

Kubernetes API Evolution: Vorreiter bei Deprecations

Kubernetes verfeinert seine API-Oberfläche kontinuierlich, um neue Funktionen einzuführen und veraltete Funktionen zu entfernen. Ende 2024 und 2025 bleibt die Wachsamkeit gegenüber API-Deprecations und -Entfernungen eine kritische operative Aufgabe. Das Kubernetes-Projekt hält sich an eine klar definierte Deprecation-Richtlinie für Alpha-, Beta- und GA-APIs.

Die Auswirkungen sind klar: Entwickler müssen Deprecation-Warnungen aktiv überwachen. Seit Kubernetes v1.19 gibt jede Anfrage an eine veraltete REST-API eine Warnung zurück. Automatisierte Tools und CI/CD-Pipeline-Checks sind unerlässlich, um Ressourcen zu identifizieren, die veraltete APIs verwenden.

# Example: Find deployments using deprecated extensions/v1beta1 API
kubectl get deployments.v1.apps -A -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,APIVERSION:.apiVersion" | grep "extensions/v1beta1"

Proaktive Migrationsplanung, lange vor einem Upgrade-Fenster, ist der einzige robuste Ansatz, um die Clusterstabilität zu gewährleisten. Die Veröffentlichung von Kubernetes v1.34 (August 2025) und v1.31 (Juli 2024) enthielten beide Deprecations und Entfernungen, die Aufmerksamkeit erforderten.

Erweiterte Container-Sicherheitspremitive: Über Image-Scanning hinaus

Während die Schwachstellensuche weiterhin eine grundlegende Best Practice ist, konzentrieren sich aktuelle Entwicklungen auf die Stärkung von Sicherheitspremitiven auf Runtime-Ebene. Ein bedeutender Fortschritt in containerd 2.0 ist die verbesserte Unterstützung für User Namespaces. Diese Funktion ermöglicht es Containern, innerhalb des Containers als root ausgeführt zu werden, aber auf dem Hostsystem auf eine unprivilegierte User ID (UID) abgebildet zu werden, was den Explosionsradius eines Container-Escapes drastisch reduziert.

Über User Namespaces hinaus hat die Betonung auf immutable Infrastructure und Runtime-Monitoring zugenommen. Runtime-Sicherheitslösungen, die oft eBPF nutzen, bieten eine entscheidende Sichtbarkeit in das Containerverhalten, erkennen Anomalien und Richtlinienverletzungen in Echtzeit. Darüber hinaus erstreckt sich der Push für Least Privilege auf die Container-Capabilities. Entwickler werden ermutigt, unnötige Linux-Capabilities (z. B. CAP_NET_ADMIN) zu entfernen und nach Möglichkeit schreibgeschützte Dateisysteme zu erzwingen.

Entwicklererfahrung und Tooling-Verbesserungen

Die kontinuierliche Verfeinerung von Entwickler-Tools, insbesondere rund um Docker Desktop und lokale Kubernetes-Umgebungen, war ein ständiges Thema im Jahr 2025. Diese Verbesserungen konzentrieren sich auf die Verbesserung der Sicherheit und die Vereinfachung komplexer Workflows für die Millionen von Entwicklern, die sich auf diese Plattformen verlassen.

Docker Desktop hat einen stetigen Strom von Sicherheitspatches erhalten, die kritische Schwachstellen beheben (z. B. CVE-2025-9074). Für die lokale Kubernetes-Entwicklung entwickeln sich Tools wie kind und minikube weiter und bieten eine schnellere Clusterbereitstellung. Die Integration von BuildKit und Buildx in lokale Umgebungen hat die Effizienz des Image-Buildings deutlich verbessert, insbesondere für diejenigen, die mit Multi-Architektur-Zielen arbeiten.

Im Wesentlichen ist die Entwicklererfahrung sicherer geworden, mit einem Schwerpunkt auf robusten Build-Prozessen und kontinuierlicher Sicherheitspatching. Die Tools machen bestehende Workflows praktischer, sicherer und effizienter, was für erfahrene Entwickler oft die wertvollste Art von Fortschritt ist.