Sobald Docker nicht mehr das ist, was auf einem Knoten Container ausführt, funktionieren docker ps und docker logs dort nicht mehr. Drei Werkzeuge füllen diese Lücke, gebaut von zwei verschiedenen Communities für zwei verschiedene Zwecke. Das falsche zu verwenden ist die häufigste Quelle für Verwirrung bei der Fehlersuche direkt auf einem Knoten.

Die drei Werkzeuge im Überblick

Werkzeug	Gebaut von	Spricht mit	Zweck	Docker-ähnlich?
ctr	containerd-Projekt	containerd direkt	containerd selbst debuggen	Nein, minimal und low-level
nerdctl	containerd-Projekt	containerd direkt	Allgemeine Container-Verwaltung	Ja, spiegelt docker eng
crictl	Kubernetes-Projekt	jede CRI-kompatible Runtime	Die Runtime aus Kubernetes-Sicht debuggen	Teilweise, Pod-bewusst

ctr: mitgeliefert, minimal, nur zum Debuggen

ctr wird mit containerd selbst ausgeliefert und ist damit überall verfügbar, wo containerd ist. Es ist aber ausdrücklich ein Debugging-Werkzeug mit bewusst kleinem Funktionsumfang und nicht für die tägliche Container-Verwaltung gedacht:

ctr images pull docker.io/library/redis:7
ctr run docker.io/library/redis:7 my-redis
ctr containers list

Das containerd-Projekt selbst rät davon ab, ctr für mehr als das Debuggen und Untersuchen des eigenen Zustands von containerd zu verwenden. Wenn du versuchst, damit Deployments zu skripten, ist das ein Zeichen, stattdessen zu nerdctl zu greifen.

nerdctl: der Docker-ähnliche Alltagsbegleiter

nerdctl ist eine eigene CLI, ebenfalls vom containerd-Projekt, die so gestaltet ist, dass sie der docker-CLI so nahe kommt, dass die meisten docker-Befehle funktionieren, wenn man den Namen des Programms ersetzt:

nerdctl run -d -p 8080:80 nginx:1.25
nerdctl ps
nerdctl logs my-container
nerdctl build -t myapp:latest .

Über die Parität mit vertrauten Docker-Workflows hinaus bietet nerdctl containerd-native Fähigkeiten, die Docker nicht hat: verschlüsselte Images, Lazy Pulling, P2P-Image-Verteilung, Image-Signierung und -Verifizierung sowie direkte Interaktion mit Kubernetes-Namespaces in containerds eigenem Datenmodell. Für allgemeine Container-Arbeit auf einer Maschine mit installiertem containerd, aber ohne Docker, ist nerdctl das Werkzeug der Wahl.

crictl: aus Sicht von Kubernetes

crictl wird vom Kubernetes-Projekt selbst gepflegt, nicht von containerd, und spricht CRI – dieselbe Schnittstelle, die der kubelet nutzt – statt containerds nativer API. Das heißt, es funktioniert identisch mit containerd, CRI-O oder jeder anderen CRI-konformen Runtime, und es versteht Kubernetes-Konzepte, die ctr und nerdctl nicht kennen, vor allem Pods und nicht nur Container:

crictl images
crictl ps
crictl pods
crictl exec -it CONTAINER_ID sh
crictl logs CONTAINER_ID

Beachte crictl pods: Weder ctr noch nerdctl, noch Docker davor hatten ein natives Konzept eines Pods, einer Gruppe von Containern, die Netzwerk und Speicher teilen. Das ist Kubernetes-spezifisch, und crictl ist das Werkzeug, das gebaut wurde, um direkt darüber nachzudenken.

crictl ist wie ctr für Inspektion und Debugging gedacht und nicht, um Workloads zu erstellen. Wenn du damit einen Container startest, von dem Kubernetes nichts weiß, hat der kubelet keinen Eintrag dazu und löscht ihn, sobald er ihn bemerkt, denn aus Kubernetes-Sicht ist ein unerwarteter Container auf einem Knoten eine zu korrigierende Abweichung und kein zu erhaltender Workload.

Mit welchem Endpoint crictl spricht

Da crictl runtime-übergreifend funktioniert, muss es wissen, mit welcher es sich verbinden soll. Ohne Konfiguration probiert es eine feste Liste von Standard-Sockets der Reihe nach durch (historisch den von dockershim, dann den von containerd, dann den von CRI-O, dann weitere). Auf einem modernen Knoten spielt diese Mehrdeutigkeit selten eine Rolle, weil nur eine Runtime installiert ist. Auf einem Knoten mit mehr als einer oder bei der Fehlersuche an einem Socket-Pfad setze ihn jedoch explizit:

crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps
# oder
export CONTAINER_RUNTIME_ENDPOINT=unix:///run/containerd/containerd.sock

Zwischen ihnen wählen

• Untersuchen oder Fehlersuche an dem, was Kubernetes selbst sieht, also das, was kubectl describe pod meldet, mit dem abzugleichen, was tatsächlich auf dem Knoten läuft: nimm crictl.
• Allgemeine Container-Arbeit auf einem Knoten oder in der lokalen Entwicklung, etwa schnell etwas ausführen, ein Image bauen, Logs prüfen: nimm nerdctl.
• Debuggen von containerds eigenem internem Zustand, etwas Spezifisches für containerd statt der runtime-agnostischen CRI-Sicht: greife zu ctr und rechne damit, containerds eigene Dokumentation daneben offen zu haben.