containerd: der Laufzeit-Daemon, den die meisten Container-Nutzer nie sehen

Zusammenfassung

• containerd ist ein als CNCF-Projekt graduiertes Open-Source-Daemon, das unter Linux und Windows Image-Inhalte, Snapshots, Container-Metadaten und laufende Tasks für übergeordnete Plattformen verwaltet.
• Das Projekt entstand aus der Umstrukturierung der Laufzeitkomponenten von Docker, wechselte 2017 zur Cloud Native Computing Foundation und wurde zu einer gemeinsam genutzten Infrastrukturschicht statt zu einer vollständigen Container-Plattform.
• Kubernetes greift über das Container Runtime Interface auf containerd zu, während Netzwerk, Low-Level-Isolierung, Image-Vertrauen und Cluster-Planung getrennte Verantwortungsbereiche bleiben, die das Ergebnis weiterhin bestimmen.
• containerd 2.3 wurde am 30. April 2026 zur aktuellen LTS-Linie; nachfolgende Sicherheits- und Lebenszykluskorrekturen zeigen, dass Bereinigung, Abgleich und Patch-Bereitstellung zur Korrektheit einer Laufzeit gehören.

Ein nicht gelöster Mount ist ein Laufzeitfehler, selbst wenn der Prozess gestartet wurde

Am 10. Juli 2026 veröffentlichte containerd Version 2.3.3. Zu den Korrekturen gehörten Änderungen an der Validierung des Sandbox-Zustands, der Behandlung von NRI-Beendigungen und einem Fehlerpfad für fehlgeschlagene Hooks, durch den Mounts bestehen bleiben konnten. Nichts davon klingt so dramatisch wie das Ausbrechen aus einem Container.

Für einen Betreiber ist ein Mount, der hätte verschwinden müssen, aber bestehen blieb, dennoch ein echter Laufzeitfehler: Über eine ganze Knotenflotte hinweg können kleine Lecks Host-Ressourcen verbrauchen, die Bereinigung erschweren und eine ansonsten funktionierende Maschine in einen Zustand versetzen, in dem sie geleert oder neu aufgebaut werden muss.

Diese Veröffentlichung verdeutlicht, warum containerd wichtig ist. Die meisten Nutzer interagieren nicht direkt mit dem Daemon. Sie fordern Kubernetes auf, einen Pod zu starten, Docker, einen Container auszuführen, oder einen verwalteten Cloud-Dienst, einen Knoten bereitzustellen. containerd befindet sich unterhalb dieser Anforderungen und übersetzt sie in Zustandsübergänge, an denen Image-Inhalte, Dateisystem-Snapshots, Container-Datensätze, Laufzeit-Shims und aktive Prozesse beteiligt sind.

Die sichtbare Plattform kann sich durch eine Neuplanung der Arbeit erholen, doch die Laufzeit muss den Knoten weiterhin in einem Zustand hinterlassen, der nachvollzogen und erneut verwendet werden kann.

Das Starten eines Prozesses ist daher nur ein Teil der Korrektheit. Erstellung, Beobachtung, Löschung und Wiederherstellung sind gleichermaßen wichtig. Ein Task, der schnell startet, aber einen Mount, veralteten Netzwerkzustand, verwaisten Shim oder nicht abgeglichene Metadaten zurücklässt, ist betrieblich nicht korrekt. Der Fehler kann erst langsam sichtbar werden, nachdem Hunderte oder Tausende anderer Vorgänge erfolgreich abgeschlossen wurden.

Darin liegt die zentrale Spannung rund um containerd. Das Projekt war erfolgreich, weil es zu einer gemeinsamen Mittelschicht unter vielen Produkten wurde. Gerade diese Allgegenwart macht seine alltäglichen Lebenszyklusentscheidungen für große Flotten folgenreich, obwohl der Name containerd den Anwendungsteams möglicherweise nie angezeigt wird.

containerd wurde nützlich, indem es bewusst keine vollständige Plattform wurde

containerd ist ein eingebettetes Laufzeit-Daemon und kein vollständiges Container-Produkt. Es plant keine Workloads über einen Cluster hinweg, bietet kein Anwendungsdienstmodell und entscheidet nicht, wie ein Unternehmen Software entwickeln und bereitstellen sollte. Seine stabilen gRPC-Dienste stellen engere Funktionen bereit: Übertragung und Speicherung von Image-Inhalten, Pflege von Metadaten, Vorbereitung von Dateisystem-Snapshots, Erstellung von Container-Datensätzen und Verwaltung laufender Tasks.

Diese Grenze ist bewusst gewählt. Docker Engine kann darüber ein benutzerorientiertes Produkt aufbauen. Kubernetes kann containerd über das Container Runtime Interface als Knotenlaufzeit verwenden. Cloud-Anbieter können es in Knoten-Images integrieren. Linux-Distributionen können es mit eigenen Voreinstellungen und Rückportierungen ausliefern. Jedes übergeordnete System kann ein anderes Betriebsmodell bereitstellen, ohne dieselben grundlegenden Mechanismen für den Image- und Prozesslebenszyklus neu implementieren zu müssen.

Diese Unterscheidung erklärt auch, warumctr, der mit containerd ausgelieferte Befehl, leicht falsch verwendet werden kann. Das Projekt behandelt ihn als instabile Debugging- und Entwicklungsoberfläche und nicht als unterstützten, benutzerorientierten Vertrag. Ein Produktionsablauf, der unbemerkt von internenctr-Funktionen abhängt, kann jahrelang funktionieren und dann feststellen, dass er genau auf dem Teil des Projekts beruht, der bewusst veränderbar bleiben sollte.

Die stabile Grenze ist daher mehr als eine API-Entscheidung. Sie ist eine Governance-Entscheidung. Das Projekt verspricht Kompatibilität für dokumentierte Dienste und bewahrt sich zugleich die Möglichkeit, die dahinterliegenden Implementierungen zu ersetzen. Dadurch ist containerd nur dann eine nützliche gemeinsame Schicht, wenn nachgelagerte Produkte dieselbe Grenze respektieren.

Docker extrahierte einen gemeinsamen Laufzeitkern und schuf eine von anderen Produkten nutzbare Infrastruktur

containerd entstand innerhalb von Docker. Das frühe Docker vereinte Image-Verteilung, Build-Funktionen, APIs, Netzwerk und Prozesslebenszyklus in einem Produkt. Mit dem Wachstum der Plattform wurden die Laufzeitaufgaben getrennt, damit sich die dauerhaften Mechanismen zur Vorbereitung und Überwachung von Containern unabhängig von der übrigen Produktoberfläche von Docker weiterentwickeln konnten.

Die öffentliche Veröffentlichungshistorie beginnt mit einer 0.0-Linie vom 4. Dezember 2015. Im März 2017 übergab Docker containerd an die Cloud Native Computing Foundation. Version 1.0 folgte am 5. Dezember 2017 und etablierte stabile gRPC-APIs sowie einen produktionsorientierten Vertrag für die Einbettung. CNCF gab am 28. Februar 2019 die Graduierung des Projekts bekannt.

Der institutionelle Wechsel war wichtig, weil Docker sowohl der ursprüngliche Entwickler als auch ein kommerzielles Plattformunternehmen war. Eine Laufzeit, die von konkurrierenden Cloud-Anbietern, Linux-Distributoren und Kubernetes-Anbietern genutzt wird, ist leichter als Abhängigkeit zu akzeptieren, wenn ihre vorgelagerte Governance nicht allein einem Produktanbieter gehört. Die Apache License 2.0 ermöglicht zudem eine breite kommerzielle und quelloffene Nutzung, ohne dass jeder Anwender dasselbe Geschäftsmodell übernehmen muss.

Die Aufnahme durch die Stiftung löschte weder die Geschichte von Docker noch den Einfluss der Unternehmen aus, bei denen Maintainer beschäftigt sind. Sie veränderte den formalen Weg, über den der gemeinsam genutzte Code gesteuert werden konnte. containerd wurde zu einer Infrastruktur, die Docker weiterhin verwendete, statt eine interne Komponente zu bleiben, die andere zu den Bedingungen von Docker akzeptieren mussten.

Das technische Ergebnis war ebenso wichtig. Übergeordnete Plattformen erhielten eine dauerhafte Schicht zwischen Orchestrierung und Low-Level-Laufzeiten wie runc. Statt dass jedes Produkt einen eigenen Image-Speicher, Snapshot-Lebenszyklus und ein eigenes Modell zur Prozessüberwachung entwickelte, konnten mehrere Produkte dieselben Mechanismen nutzen und in anderen Bereichen konkurrieren.

Images, Container und Tasks bezeichnen bewusst unterschiedliche Dinge

Das Container-Vokabular ist verwirrend, weil benutzerorientierte Werkzeuge häufig mehrere Entitäten unter einem einzigen Begriff zusammenfassen. containerd tut dies nicht. Ein Image bezeichnet Inhalte und Metadaten. Ein Container-Datensatz speichert die vorgesehene Laufzeitkonfiguration und Labels. Ein Task repräsentiert die aktive Prozessgruppe, die aus dieser Definition erstellt wurde. Jede dieser Entitäten kann einem anderen Zeitplan folgen.

Ein Container-Datensatz kann bestehen bleiben, nachdem ein Task beendet wurde. Ein Image kann erhalten bleiben, nachdem alle Container gelöscht wurden, die es verwendet haben. Ein Task kann ausfallen, während die Metadaten, die seinen Container beschreiben, weiterhin vorhanden sind. Diese Trennung ist für Neustart, Untersuchung und Wiederherstellung nützlich, weil der Daemon die Lebensdauer eines Prozesses nicht mit der Lebensdauer sämtlicher zugehöriger Entitäten gleichsetzen muss.

Sie schafft jedoch auch eine betriebliche Verpflichtung. Das Löschen einer Entität beweist nicht automatisch, dass jedes zugehörige Dateisystem, Blob, Shim oder jede Netzwerkressource zurückgewonnen wurde. Eine Überwachung, die Container zählt, ohne Tasks zu verstehen, kann einen irreführenden Zustand melden. Bereinigungscode, der davon ausgeht, dass eine Löschung alle übrigen nach sich zieht, kann Ressourcen zurücklassen.

Das Entitätsmodell ist daher kein Implementierungsdetail. Es ist die Antwort der Laufzeit auf ein grundlegendes Problem: Gewünschte Konfiguration, gespeicherte Inhalte und aktive Ausführung sind unterschiedliche Formen von Zustand. Ein System, das eine zuverlässige Wiederherstellung anstrebt, muss erkennen können, welche davon ausgefallen ist.

Diese Unterscheidung wird nach einem Teilfehler besonders wichtig. Wenn ein Neustart des Daemons, ein Ressourcenengpass am Knoten oder ein Hook-Fehler einen Vorgang auf halbem Weg unterbricht, benötigt der Wiederherstellungspfad genügend dauerhafte Informationen, um zu entscheiden, was bereits geschehen ist und was noch entfernt oder neu erstellt werden muss.

Inhaltsadressierung beweist, welche Bytes eingetroffen sind, nicht ob ihnen vertraut werden sollte

Container-Images sind Graphen unveränderlicher Inhalte. containerd speichert Blobs anhand kryptografischer Digests, wodurch identische Inhalte wiederverwendet und über ihre Byte-Identität überprüft werden können. Image-Datensätze verknüpfen Namen und Manifeste mit diesen Inhalten, während Übertragungsdienste Registry-Referenzen auflösen und die erforderlichen Blobs in den lokalen Speicher übertragen.

Dieses Modell reduziert Duplikate und schafft eine stabile Möglichkeit festzustellen, welche Bytes ein Knoten erhalten hat. Es belegt nicht, wer sie veröffentlicht hat, ob dem Herausgeber vertraut werden sollte, ob eine Signatur akzeptabel ist oder ob die Software eine bekannte Schwachstelle enthält. Ein bösartiges Image kann einen vollkommen gültigen Digest besitzen. Ein veränderliches Tag kann im Lauf der Zeit auf unterschiedliche Inhalte verweisen, obwohl jeder einzelne Blob weiterhin korrekt adressiert ist.

Diese Unterscheidung ist wichtig, weil containerd häufig Teil eines umfassenderen Lieferkettensystems ist. Registry-Authentifizierung, Signaturrichtlinien, Softwarestücklisten, Attestierungen, Schwachstellenscans und Zulassungsrichtlinien werden von anderen Komponenten oder nachgelagerten Produkten übernommen. Die Laufzeit kann die Integrität von Inhalten bewahren, ohne zu einem vollständigen Vertrauensrahmen zu werden.

Für Betreiber ist die praktische Regel einfach: Image-Identität und Image-Vertrauen sind unterschiedliche Kontrollen. Bei der Analyse eines Vorfalls sollten sowohl der ausgeführte Digest als auch die Richtlinie dokumentiert werden, die seine Ausführung zugelassen hat. Einen Digest-adressierten Speicher als Sicherheitssystem zu bezeichnen, führt zwei getrennte Fragen unzulässig zusammen.

Dieselbe Trennung erleichtert die Portabilität. Ein stabiles Inhaltsmodell ermöglicht verschiedenen übergeordneten Plattformen die Arbeit mit denselben lokalen Daten. Unterschiede bei Registry-Zugangsdaten, Vertrauensrichtlinien und Plattformauswahl können jedoch weiterhin dazu führen, dass ein Image in einer Flotte nutzbar und in einer anderen blockiert ist.

Snapshotter verwandeln unveränderliche Images in nutzbare Dateisysteme

Ein Image kann gespeichert sein, ohne bereits ausführbar zu sein. Ein laufender Container benötigt eine Dateisystemansicht, die Image-Schichten mit einem beschreibbaren Zustand verbindet. containerd delegiert diese Arbeit an Snapshotter-Plugins.

Die Snapshotter-Schnittstelle trennt die Inhaltsverteilung von der Dateisystemimplementierung. Ein Snapshotter kann aktive, schreibgeschützte oder bestätigte Snapshots vorbereiten, sie zum Entpacken oder Ausführen einhängen und später entfernen. Zu den gängigen Implementierungen gehören Overlay-basierte und native Ansätze. Spezialisierte und entfernte Snapshotter können zudem beeinflussen, wie viele Daten vor dem Start eines Workloads abgerufen werden.

Der Vorteil liegt in der Modularität. Das Kerndaemon muss nicht für jede Dateisystemstrategie neu geschrieben werden. Cloud-Anbieter, Speicheranbieter und Edge-Plattformen können Startzeit, Festplattennutzung oder entfernten Zugriff hinter einer gemeinsamen Dienstgrenze optimieren.

Der Nachteil besteht darin, dass das Verhalten von Snapshottern nicht einheitlich ist. Garbage Collection, Mount-Semantik, Quotenverhalten, Startlatenz und Wiederherstellung hängen von der Implementierung ab. Ein Benchmark, der einen schnellen Kaltstart „containerd“ zuschreibt, ohne Image-Pfad, Registry, Datenträger und Snapshotter zu nennen, ist daher unvollständig.

Die in Version 2.3.3 behobene Mount-Leckage erinnert von der Fehlerseite her an denselben Punkt. Speicherzustände müssen sauber zurückgenommen werden, wenn Hooks oder Lebenszyklusschritte fehlschlagen. Bleibt ein Snapshot oder Mount fälschlich referenziert, können Inhalte auf dem Datenträger verbleiben, nachdem die übergeordnete Plattform den Workload bereits als entfernt betrachtet. Im Flottenmaßstab wird das Bereinigungsverhalten zu einer Kapazitätsfrage.

Entfernte Snapshotter und Snapshotter mit verzögertem Abruf verschärfen diesen Zielkonflikt. Sie können die Startverzögerung oder den lokalen Speicherverbrauch reduzieren, indem sie größere Teile des Image-Pfads bei Bedarf verfügbar machen. Zugleich machen sie die Verfügbarkeit einer Registry oder eines entfernten Speichers in einer Weise zum Bestandteil der Ausführung, die bei einem vollständig lokalen Image nicht besteht. Die Abstraktion bleibt stabil, während sich das darunterliegende Fehlermodell verändert.

Runtime-v2-Shims lassen einen Task das Daemon überleben, das ihn erstellt hat

containerd führt einen Linux-Containerprozess normalerweise nicht selbst aus. Es verwendet einen Laufzeit-Shim zur Kommunikation mit einer Low-Level-Laufzeit wie runc, die anhand der Betriebssystemmechanismen des Hosts die abschließende Erstellung und Ausführung übernimmt.

Im Runtime-v2-Modell erhält jeder Task oder jede Sandbox eine vermittelnde Komponente, die unabhängig vom langlebigen containerd-Daemon weiterlaufen kann. Wird das Daemon neu gestartet, müssen aktive Workloads nicht zwangsläufig mit ihm beendet werden. containerd kann sich erneut mit den Shims verbinden und die Überwachung anhand des erhaltenen Zustands wiederherstellen.

Das ist eine bedeutsame Resilienzeigenschaft. Ein Laufzeit-Daemon kann gepatcht oder neu gestartet werden, ohne dass dadurch automatisch jeder Workload auf einem Knoten ausfällt. Das Modell ermöglicht außerdem, mehrere Low-Level-Laufzeiten hinter einer übergeordneten API parallel zu betreiben, einschließlich abgeschirmter Laufzeiten, die die Isolationsgrenze verändern.

Diese Garantie hat Grenzen. Ein ausgefallener oder verwaister Shim, beschädigter lokaler Zustand, ein Fehler in der Low-Level-Laufzeit oder ein Ausfall des Host-Kernels kann weiterhin zum Verlust der Überwachung oder des Workloads selbst führen. Ein Neustart des Knotens unterscheidet sich vom Neustart eines Daemons. Eine Beschädigung des Datenträgers unterscheidet sich von einem ordnungsgemäßen Prozessneustart. Die Architektur unterstützt Kontinuität bei einer bestimmten Fehlerklasse; sie macht die Ausführung nicht von der Maschine unabhängig.

Dieses geschichtete Laufzeitmodell erklärt, warum der Begriff „Container-Laufzeit“ mehrdeutig sein kann. containerd ist ein langlebiger Lebenszyklus- und Zustandsdienst. runc und alternative Low-Level-Laufzeiten erstellen Prozesse. Kata Containers oder gVisor können das darunterliegende Isolationsmodell verändern, während containerd als Vermittler darüber bestehen bleibt. Eine präzise Zuordnung von Vorfällen beginnt mit der Benennung der Schicht, die tatsächlich ausgefallen ist.

Kubernetes hängt von containerd ab, ohne ihm den Cluster zu überlassen

Kubernetes greift über das Container Runtime Interface auf containerd zu. Das eingebettete CRI-Plugin implementiert die von kubelet erwarteten Laufzeit- und Image-Dienste, bildet Pod-Sandboxes und Container auf containerd-Entitäten ab und koordiniert sie mit der konfigurierten Laufzeit und dem Netzwerkpfad.

Dadurch wurde containerd zu einer direkten Abhängigkeit auf vielen Kubernetes-Knoten, ohne selbst zu Kubernetes zu werden. Der Scheduler entscheidet weiterhin, wo ein Pod ausgeführt werden soll. Controller gleichen weiterhin den gewünschten Anwendungszustand ab. kubelet verwaltet weiterhin die Absicht auf Knotenebene. Clusternetzwerk und Richtlinien hängen von CNI-Implementierungen und anderen Komponenten ab. Host-Kernel und Low-Level-Laufzeit stellen weiterhin die Mechanismen zur Prozessisolierung bereit.

Diese Grenze ist bei einem Fehler wichtig. Ein Pod, der nicht startet, kann durch die kubelet-Konfiguration, CRI-Kompatibilität, ein fehlendes Image, einen Snapshotter-Fehler, die CNI-Einrichtung, einen Shim, runc oder den Kernel blockiert werden. Den Vorgang schlicht als „containerd-Fehler“ zu melden, kann die tatsächlich fehlgeschlagene Übergabe verschleiern. Jedes Laufzeitproblem als „Kubernetes“ zu bezeichnen, ist ebenso ungenau.

Kompatibilität hat außerdem eine Versionsdimension. Kubernetes-Distributionen qualifizieren bestimmte Kombinationen aus containerd, CRI und Konfiguration. Verwaltete Dienste können nachgelagerte Patches oder verzögerte Versionen verwenden. Eine vorgelagerte Veröffentlichung kann korrekt sein, während ein Cloud-Knoten-Image auf einem älteren Build verbleibt. Ein Cloud-Anbieter kann eine Sicherheitskorrektur rückportieren, ohne die Version so zu ändern, wie es ein direkter Nutzer der vorgelagerten Version erwarten würde.

Deshalb ist die maßgebliche Entität die Stückliste des Knotens und nicht allein der Projektname: containerd, Low-Level-Laufzeit, CNI-Binärdateien, Snapshotter, Kernel, Konfiguration und nachgelagerte Patches. Dieser Stack startet und entfernt den Pod tatsächlich.

CNI und NRI halten containerd schlank, indem sie mehr Verantwortung in den Knoten-Stack verlagern

Die Architektur von containerd stützt sich stark auf die Zusammensetzung verschiedener Komponenten. Der CRI-Pfad kann externe Plugins des Container Network Interface aufrufen, um Sandbox-Netzwerke zu erstellen und zu entfernen. Plugins des Node Resource Interface können Lebenszyklusereignisse beobachten und zulässige Ressourcen- oder Laufzeiteinstellungen anpassen. Snapshotter- und Laufzeit-Plugins ersetzen Speicher- und Ausführungskomponenten, ohne die Kern-API neu zu schreiben.

So bleibt das Daemon klein genug, um wiederverwendbar zu sein. Netzwerkspezialisten können CNI-Implementierungen weiterentwickeln. Hardwareanbieter können NRI oder verwandte Mechanismen einsetzen, statt einen privaten Fork zu pflegen. Speicherentwickler können entfernte Snapshotter hinzufügen. Sandbox-Projekte können alternative Laufzeiten integrieren.

Jede Erweiterung schafft jedoch auch eine weitere Fehler- und Vertrauensabhängigkeit. Ein fehlgeschlagener CNI-ADD- oder CNI-DEL-Vorgang kann Adressen, Schnittstellen oder Namespaces zurücklassen. Ein fehlerhaftes NRI-Plugin kann Lebenszyklusvorgänge blockieren oder Zuweisungen auf einem Knoten verändern. Ein Snapshotter eines Drittanbieters kann Mounts zurücklassen oder die Garbage Collection fehlerhaft handhaben. Ein Laufzeit-Plugin kann mit einem Kernel korrekt funktionieren und mit einem anderen ausfallen.

Die Reife des Kernprojekts überträgt sich nicht automatisch auf den Erweiterungsgraphen. Eine unterstützte containerd-Version zertifiziert nicht jedes damit kombinierte Plugin, jede Laufzeit oder jede Konfiguration. Betreiber müssen Herkunft, Version, Signierung, Supportweg und Rücksetzplan jeder privilegierten Erweiterung kennen, die in den Knotenlebenszyklus aufgenommen wird.

Der Plugin-Graph ist somit sowohl der wichtigste Portabilitätsmechanismus von containerd als auch eine seiner größten Quellen für Kompositionsrisiken. Das Projekt reduziert den Bedarf an Forks, indem es Erweiterungspunkte schafft. Der Preis besteht darin, dass die Produktionszuverlässigkeit über diese Erweiterungen hinweg bewertet werden muss und nicht aus dem Ruf des Kerndaemons abgeleitet werden kann.

Namespaces organisieren Clients innerhalb eines Daemons; sie schaffen keine neue Host-Grenze

Namespaces von containerd ermöglichen verschiedenen Clients, Ressourcen innerhalb eines Daemons zu gruppieren und zu adressieren. Docker, CRI und andere einbettende Systeme können ihre Images, Container, Snapshots und Tasks logisch voneinander trennen, statt sie in einem einzigen flachen Entitätsraum kollidieren zu lassen.

Das ist eine sinnvolle Trennung für mehrere Clients. Es entspricht nicht der Isolation zweier Mandanten auf getrennten Maschinen. Das Daemon bleibt ein privilegierter Prozess, der administrative Socket bleibt eine Schnittstelle mit weitreichenden Folgen und gewöhnliche Container-Workloads hängen weiterhin von der Isolierung durch den Host-Kernel ab, sofern keine stärkere Sandbox eingesetzt wird.

Ein Client mit ausreichendem Zugriff auf das Daemon kann möglicherweise entsprechend seinen Berechtigungen und dem Verhalten der Plugins Namespaces übergreifend auflisten oder Aktionen darin ausführen. Diese Grenze ist daher ein Mechanismus zur Eingrenzung der API und kein Ersatz für Unix-Berechtigungen, Socket-Schutz, Kernel-Namespaces, cgroups, verbindliche Zugriffskontrollen oder durch virtuelle Maschinen gestützte Isolation.

Diese Unterscheidung ist wirtschaftlich ebenso wichtig wie technisch. Eine Plattform kann logische Trennung bewerben und dennoch mehrere Kunden auf einer gemeinsamen privilegierten Laufzeit und einem gemeinsamen Host-Kernel platzieren. Der Sicherheitsnachweis muss auf der Host- und Sandbox-Schicht geführt werden und darf nicht aus dem Vorhandensein einer containerd-Namespace-Zeichenfolge abgeleitet werden.

Das Projekt profitiert davon, wenn diese Grenze ausdrücklich sichtbar bleibt. Es kann ein klares Organisationsmodell bereitstellen, ohne vorzugeben, die weiter unten im Stack angesiedelte Mandantenisolierung zu lösen.

Der Daemon-Socket gehört in dasselbe Bedrohungsmodell wie die Host-Administration

containerd ist befugt, Prozesse, Mounts und Namespaces zu erstellen und Laufzeitspezifikationen mit weitreichenden Folgen an niedrigere Schichten zu übergeben. Auf vielen Systemen kann die Kontrolle über das Daemon oder seinen Socket einer Kontrolle über den Host gleichkommen.

Damit werden Socket-Zugriff, entfernte Erreichbarkeit, Authentifizierung, Auditierung und Plugin-Berechtigungen zu primären Sicherheitskontrollen. Wird das Daemon als verborgenes Implementierungsdetail behandelt, können Teams zwar die Kubernetes-API schützen, aber der lokalen Knotenschnittstelle weniger Aufmerksamkeit schenken, die tatsächlich privilegierte Prozesse erstellt.

Dieselbe Vorsicht gilt für die Laufzeitkonfiguration. Ein Container kann Fähigkeiten, Geräte, Namespaces und Mounts anfordern, die sein Verhältnis zum Host verändern. containerd übergibt diese Spezifikationen an eine Low-Level-Laufzeit und Kernel-Mechanismen. Die Laufzeitschicht kann konfigurierte Beschränkungen durchsetzen; sie kann weder eine Kernel-Schwachstelle beseitigen noch eine unsichere privilegierte Spezifikation allein durch die Verwendung einer Standard-API sicher machen.

Die Zuordnung von Sicherheitsproblemen erfordert daher mehrere Schichten. Eine Schwachstelle in der API-Verarbeitung von containerd unterscheidet sich von einem Ausbruch aus runc, einem Kernel-Fehler, einem unsicheren CNI-Plugin oder einem überprivilegierten Kubernetes-Workload. Eine vorgelagerte containerd-Korrektur belegt nicht, dass jeder nachgelagerte Knoten geschützt ist. Ebenso macht eine sichere containerd-Version einen verwundbaren Kernel nicht sicher.

Version 2.3.2, veröffentlicht am 18. Juni 2026, enthielt neben weiteren Laufzeitkorrekturen Patches für fünf aufgeführte containerd-CVEs. Die richtige betriebliche Frage lautet nicht, ob die neueste Version „sicher“ ist. Entscheidend ist, welcher Sicherheitshinweis die eingesetzte Konfiguration betrifft, welcher Build die Korrektur enthält und wann dieser Build tatsächlich die laufenden Knoten erreicht hat.

Ereignisse und Garbage Collection machen den Abgleich zu einer fortlaufenden Aufgabe

Eine langlebige Laufzeit muss genügend Zustand speichern, um unterbrochene Vorgänge wiederherzustellen, und zugleich nicht mehr benötigte Ressourcen zurückgewinnen. Die Metadaten-, Ereignis- und Garbage-Collection-Mechanismen von containerd unterstützen diese Arbeit.

Ereignisse ermöglichen Orchestratoren und Überwachungssystemen, auf Änderungen des Lebenszyklus und der Inhalte zu reagieren, ohne jede Entität fortlaufend abzufragen. Sie sind für Abgleich und Beobachtbarkeit nützlich, sollten von Verbrauchern jedoch nicht als perfekt geordnete, dauerhaft beständige Datenbank behandelt werden. Die Wiederverbindungslogik muss weiterhin den aktuellen Zustand abfragen und mit fehlenden oder in anderer Reihenfolge beobachteten Ereignissen umgehen können.

Leases, Labels und Metadatenreferenzen tragen dazu bei, weiterhin verwendete Inhalte und Snapshots zu schützen, während nicht mehr erreichbare Ressourcen gesammelt werden können. Der Mechanismus begrenzt das Datenwachstum in Image-intensiven Flotten. Er kann jedoch in beide Richtungen fehlschlagen: Nicht freigegebene Referenzen bewahren Daten unbegrenzt auf, während fehlerhafte Referenzen Inhalte einer vorzeitigen Bereinigung aussetzen können.

Speicherplatzdruck ist daher ein Laufzeitproblem, selbst wenn Arbeitsspeicher und CPU der Anwendungen unauffällig erscheinen. Image-Abrufe, entpackte Schichten, beschreibbare Snapshots und veraltete Zustände konkurrieren um den Host-Speicher. Ein Knoten, der Images nicht abrufen, entpacken oder bereinigen kann, kann für den Scheduler lange vor einem Ausfall des Hosts nicht mehr verfügbar sein.

Dies ist ein weiterer Grund, containerd anhand von Dienstzielen auf Knotenebene zu betreiben, die auch Löschung und Wiederherstellung umfassen. Die Plattform muss nicht nur wissen, wie schnell ein Pod startet, sondern auch, ob fehlgeschlagene Vorgänge die Maschine in einem Zustand hinterlassen, der eine sichere Wiederverwendung erlaubt.

Die LTS-Linie 2.3 macht Release-Engineering zu einem Betriebsvertrag

Die Veröffentlichungsrichtlinie von containerd wurde mit dem Übergang des Projekts in die 2.x-Ära eindeutiger. Die Linie 1.6 begann am 15. Februar 2022. Die LTS-Linie 1.7 folgte am 10. März 2023. Version 2.0 erschien am 5. November 2024; die Versionen 2.1 und 2.2 setzten den Übergang im Jahr 2025 fort.

Am 30. April 2026 veröffentlichte das Projekt containerd 2.3 und erklärte diese Version zur aktuellen Linie mit langfristigem Support, der bis zum 30. April 2028 geplant ist. Das Projekt wechselte außerdem zu einem viermonatigen Rhythmus für Nebenversionen und veröffentlichte Plattformstufen, Erwartungen an die API-Stabilität und unterstützte Upgrade-Pfade.

Das ist Infrastrukturpolitik und keine bloße Verwaltung des Repositorys. Cloud-Anbieter und Kubernetes-Distributionen müssen wissen, wie lange ein Zweig Korrekturen erhält, welche Upgrade-Abfolgen voraussichtlich funktionieren und welche Plattformen das Projekt fortlaufend testen kann. Der LTS-Status ermöglicht Betreibern, die Wartung von Knoten-Images an einem erklärten Zeithorizont auszurichten, statt den Support aus der Commit-Aktivität abzuleiten.

Der Vertrag ist bewusst begrenzt. Stabile Garantien gelten für dokumentierte APIs und unterstützte Plattformen.ctrliegt außerhalb dieses Versprechens. Drittanbieter-Plugins sind nicht automatisch abgedeckt. Nachgelagerte Distributionen können Veröffentlichungen rückportieren, verzögern oder verändern. Der Supportzeitraum eines Projekts sagt einem Unternehmen nicht, wann sein verwalteter Cloud-Anbieter ein verwundbares Knoten-Image ersetzen wird.

Zum Recherche-Stichtag des Artikels am 6. August 2026 war 2.3.3 die neueste verifizierte stabile Version, nach dem sicherheitsrelevanten Patch 2.3.2 im Juni. Version 2.4 war vorläufig für den 26. August 2026 vorgesehen. Dieses Datum war eine Planung und keine abgeschlossene Veröffentlichung und sollte vor der Publikation aktualisiert werden, falls der Artikel über den Stichtag hinaus verschoben wird.

Das Veröffentlichungsmodell erleichtert die Steuerung einer verborgenen Abhängigkeit. Sein Erfolg wird an der Qualität der Rückportierungen, dem Zustand des Zweigs 2.3 bis 2028 und der Zeit erkennbar sein, die nachgelagerte Flotten für die Übernahme wichtiger Korrekturen benötigen.

Plattformstufen zeigen, wo Portabilität von dauerhaft verfügbaren Testkapazitäten abhängt

containerd unterstützt mehr als eine Betriebsumgebung. Support ist jedoch keine abstrakte Behauptung, dass sich jede Architektur gleich verhält. Zum Recherche-Stichtag gehörtenlinux/amd64,linux/arm64undwindows/amd64zu den Plattformen der Stufe 1.

Eine Plattformstufe spiegelt gepflegte Funktionstests und die Kapazitäten des Projekts wider. Windows-Container verwenden andere Host-Mechanismen und Laufzeitpfade als Linux. Dateisystemsemantik, Prozessisolierung und CI-Abdeckung unterscheiden sich. Eine in der gemeinsamen API vorhandene Funktion kann daher je nach Plattformfamilie einen anderen Reifegrad oder ein anderes Fehlerverhalten aufweisen.

Die Richtlinie zu Plattformstufen ist teilweise ein technisches und teilweise ein ressourcenbezogenes Dokument. Eine Plattform kann nur dann erstklassig bleiben, wenn Maintainer über zuverlässige Runner, Hardware, Tests und Personen verfügen, die reagieren können, wenn diese Tests fehlschlagen. Portabilität hängt von einer dauerhaft verfügbaren Infrastruktur hinter der Kompatibilitätszusage ab.

Für Käufer hat das zwei Folgen. Erstens sollte eine Projektfunktion anhand der genauen unterstützten Kombination aus Plattform und Laufzeit bewertet werden. Zweitens ist die Herauf- oder Herabstufung einer Plattform wesentlich, weil sie eine Veränderung der Fähigkeit des Projekts signalisiert, den Zweig zu gewährleisten, und nicht nur eine redaktionelle Änderung der Dokumentation.

Dasselbe Prinzip gilt für spezialisierte Hardwareintegrationen. Ein Daemon kann einen allgemeinen Erweiterungspunkt bereitstellen, während die Produktionsqualität eines bestimmten GPU-, Speicher- oder Netzwerkpfads von Code und Tests abhängt, die an anderer Stelle gepflegt werden.

CNCF schuf ein neutrales vorgelagertes Projekt, doch das eingesetzte containerd hat weiterhin viele Verantwortliche

containerd wird als CNCF-Projekt über Maintainer, Committer, Release-Verantwortliche, Governance-Dokumente und einen Sicherheitsprozess geführt. Das Projekt besitzt keinen herkömmlichen Verwaltungsrat, keine Aktionäre und kein Führungsteam. Autorität ergibt sich aus Projektrollen und Beitragsprozessen statt aus Eigentumsanteilen.

Dieses Modell macht die Laufzeit für konkurrierende Unternehmen nutzbar. Ein Cloud-Anbieter muss containerd nicht von einem anderen Cloud-Anbieter erwerben. Eine Linux-Distribution kann es paketieren. Docker kann es einbetten. Kubernetes-Anbieter können es qualifizieren. Maintainer, die bei verschiedenen Organisationen beschäftigt sind, können am selben vorgelagerten Code arbeiten.

Neutrale Governance bedeutet nicht, dass der Einfluss von Arbeitgebern verschwindet. Die Entwicklungskapazität stammt größtenteils von Personen, die von Anbietern bezahlt werden oder über Institutionen beitragen, die von der Laufzeit profitieren. CI, Release-Verantwortung und Sicherheitsarbeit benötigen Zeit und Infrastruktur. Die öffentlichen Governance-Unterlagen zeigen formelle Rollen, können aber den informellen Einfluss auf die Roadmap oder private kommerzielle Prioritäten nicht vollständig messen.

Die Kontrolle über Bereitstellungen ist noch stärker verteilt. Vorgelagerte Maintainer entscheiden, was in eine offizielle Veröffentlichung gelangt. Linux-Distributionen entscheiden, was sie paketieren und rückportieren. Cloud-Anbieter entscheiden, welcher Build in ein Knoten-Image gelangt und wann dieses Image die Kunden erreicht. Cluster-Betreiber entscheiden, wann laufende Knoten geleert und ersetzt werden. Dasselbe Projekt kann daher gleichzeitig in mehreren wesentlich unterschiedlichen Produktions-Builds existieren.

Diese geschichtete Kontrolle ist für die Berichterstattung über Vorfälle zentral. Das Datum einer vorgelagerten Veröffentlichung ist kein Datum für den marktweiten Abschluss der Fehlerbehebung. Ein Cloud-Sicherheitshinweis kann eine korrigierte Flotte beschreiben, obwohl die öffentliche Versionsnummer von der vorgelagerten Version abweicht. Eine verlässliche Antwort erfordert die Nachverfolgung des genauen Builds und seines Bereitstellungswegs.

containerd schafft wirtschaftlichen Wert ohne eine gewöhnliche Umsatzposition

containerd ist kein eigenständiges Produktunternehmen mit veröffentlichter Gewinn-und-Verlust-Rechnung. In den bereitgestellten Belegen gibt es keine Umsatzangabe für containerd, keine Unternehmensbewertung und keine geprüfte Zahl von Installationen. CNCF beherbergt das Projekt, Arbeitgeber finanzieren einen großen Teil der Entwicklung durch die Arbeitszeit ihrer Beschäftigten und nachgelagerte Unternehmen verdienen Geld mit Produkten und Diensten, die die Laufzeit einbetten.

Sein wirtschaftlicher Wert zeigt sich vor allem in vermiedener Doppelarbeit. Docker, Kubernetes-Anbieter, Clouds und Distributionen können Mechanismen für Images und Lebenszyklen gemeinsam nutzen, statt jeweils ein vollständig separates Daemon zu finanzieren. Eine Fehlerkorrektur kann mehrere Produkte erreichen. Eine stabile API kann die Kosten für die mehrjährige Pflege von Integrationen senken.

Die Struktur als öffentliches Gut wirft zugleich eine Nachhaltigkeitsfrage auf. Viele Unternehmen können von containerd abhängen, ohne entsprechend dieser Abhängigkeit Entwicklungsarbeit beizutragen. LTS-Zweige benötigen Release-Verantwortliche, CI, Rückportierungsarbeit und Sicherheitsreaktionen, lange nachdem die Aufmerksamkeit für eine neue Veröffentlichung weitergezogen ist. Plattformspezifische Tests erfordern Hardware und Maintainer. Die Einbettung macht das Projekt wertvoll, während sein direktes Budget schwer sichtbar bleibt.

Die LTS-Zusage für 2.3 hat daher auch ohne veröffentlichtes Budget eine finanzielle Dimension. Ein zweijähriger Zweig erfordert kontinuierliche Arbeit. Der Zustand dieser Zusage sollte anhand der Release-Verantwortung, Patch-Frequenz, Testabdeckung und Vielfalt der Mitwirkenden beurteilt werden und nicht anhand einer erfundenen Umsatzschätzung.

Eine vollständige Erhebung der Bereitstellungen ist ebenfalls nicht verfügbar. Die breite Nutzung in Docker, Kubernetes und Cloud-Produkten ist aufgrund der Rolle des Projekts erkennbar, unterstützt aber keine präzise Aussage zum Marktanteil. Die belastbarste Beschreibung lautet, dass containerd weit verbreitet eingebettet und folgenreich ist, nicht dass es einen bekannten Anteil aller Container weltweit ausführt.

Alternativen konkurrieren erst dann mit containerd, wenn die jeweilige Grenze benannt wird

Vergleiche von Container-Laufzeiten vermischen häufig Produkte, die auf unterschiedlichen Schichten arbeiten. CRI-O ist eine direkte Alternative in Kubernetes-orientierten CRI-Bereitstellungen. Docker Engine ist eine breitere benutzerorientierte Plattform, die containerd einbettet, statt jede Schicht mit demselben Funktionsumfang zu ersetzen. Podman und der libpod-Stack verwenden ein anderes Benutzer- und Daemon-Modell. runc ist eine Low-Level-OCI-Laufzeit, die üblicherweise unter containerd angesiedelt ist, statt mit ihm zu konkurrieren.

Kata Containers und gVisor verändern das Isolationsmodell unterhalb des Lebenszyklusvermittlers. Sie können über Laufzeitintegrationen ausgeführt werden, während containerd weiterhin übergeordnete Image- und Task-Dienste übernimmt. Kubernetes selbst ist ein Orchestrator oberhalb der Knotenlaufzeit. Die Open Container Initiative definiert Spezifikationen, die der Stack verwendet, statt Container zu betreiben.

Diese Unterschiede sind wichtig, weil der Austausch einer Komponente nicht jede Abhängigkeit beseitigt. Der Wechsel von containerd zu einer anderen CRI-Laufzeit betrifft Knoten-Images, Kompatibilitätstests, Snapshot-Speicher, Laufzeitkonfiguration und Betriebswerkzeuge. Der Wechsel von runc zu einer durch virtuelle Maschinen gestützten Sandbox verändert eine andere Grenze. Auch nach dem Austausch von Docker Engine kann containerd Bestandteil der resultierenden Architektur bleiben.

Der nützlichste Vergleich ist daher funktional. Welche Schicht wird ersetzt? Welcher Zustand muss verschoben werden? Welche Betriebswerkzeuge setzen die alte API oder das alte Entitätsmodell voraus? Welche Fehlermodi ändern sich? Ein allgemeiner „Laufzeitmarkt“ verschleiert mehr, als er erklärt.

Der Vorteil von containerd besteht nicht darin, dass keine Alternative existiert. Er liegt darin, dass viele Produkte Integrationscode, Betriebswissen und Tests rund um seine stabile Mittelschicht aufgebaut haben. Dieses etablierte Wissen schafft Wechselkosten, obwohl die Softwarelizenz selbst keine rechtliche Bindung erzeugt.

Der eigentliche Portabilitätstest beginnt, wenn ein Vorgang auf halbem Weg stoppt

Das Design von containerd beruht auf einer sinnvollen Aufgabentrennung. Das Daemon verwaltet dauerhafte Laufzeitzustände und Dienste. Snapshotter bereiten Dateisysteme vor. Shims vermitteln aktive Tasks. Low-Level-Laufzeiten erstellen Prozesse. CNI konfiguriert das Netzwerk. Kubernetes oder ein anderes übergeordnetes System entscheidet, was ausgeführt werden soll. Der Kernel stellt die eigentlichen Isolationsmechanismen bereit.

Diese Aufteilung lässt das Projekt klein genug bleiben, um wiederverwendet zu werden. Sie bedeutet zugleich, dass keine einzelne Komponente das Gesamtergebnis garantieren kann. Ein Container kann ausfallen, weil das Image nicht aufgelöst werden konnte, der Snapshotter nicht einhängen konnte, CNI die Bereinigung nicht abschließen konnte, der Shim verschwunden ist, die Laufzeit die Spezifikation abgelehnt hat oder der Kernel den Vorgang verweigerte.

Eine ausgereifte Knotenlaufzeit muss Fehler daher verständlich machen. Betreiber müssen wissen, welcher Zustand sich vor dem Abbruch des Vorgangs verändert hat, welche Ressourcen verbleiben, ob ein erneuter Versuch sicher ist und ob der Knoten ohne Neuaufbau wieder in Betrieb genommen werden kann. Fehlerbehandlung, Task-Zustand, Ereignisse, Bereinigung und Wiederherstellung sind ebenso wichtig wie der erfolgreiche Standardablauf.

So lässt sich die langfristige Leistung von containerd am besten verstehen. Das Projekt ermöglichte eine gemeinsame Mittelschicht, ohne diese Schicht in eine vollständige Container-Plattform zu verwandeln. Es wird wertvoll bleiben, wenn die gemeinsamen Mechanismen stabil genug zum Einbetten, transparent genug zur Fehleranalyse und austauschbar genug bleiben, damit ihre Allgegenwart nicht zum Grund wird, verborgene betriebliche Altlasten hinzunehmen.