Dès que Docker n’est plus ce qui exécute les conteneurs sur un nœud, docker ps et docker logs cessent d’y fonctionner. Trois outils comblent ce vide, conçus par deux communautés différentes pour deux usages différents. Choisir le mauvais est la source de confusion la plus fréquente quand on dépanne directement un nœud.

Les trois outils en un coup d’œil

Outil	Conçu par	Dialogue avec	Rôle	Proche de Docker ?
ctr	projet containerd	containerd directement	Déboguer containerd lui-même	Non, minimal et bas niveau
nerdctl	projet containerd	containerd directement	Gestion générale des conteneurs	Oui, reproduit fidèlement docker
crictl	projet Kubernetes	tout runtime compatible CRI	Déboguer le runtime du point de vue de Kubernetes	Partiellement, conscient des Pods

ctr : fourni d’office, minimal, réservé au débogage

ctr est livré avec containerd lui-même, ce qui le rend toujours disponible là où containerd l’est, mais c’est explicitement un outil de débogage au jeu de fonctionnalités volontairement réduit, pas un outil de gestion quotidienne des conteneurs :

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

Le projet containerd lui-même déconseille d’utiliser ctr pour autre chose que le débogage et l’inspection de l’état interne de containerd. Si vous vous surprenez à vouloir scripter des déploiements avec, c’est le signe qu’il faut se tourner vers nerdctl.

nerdctl : l’outil quotidien à la Docker

nerdctl est une CLI distincte, également issue du projet containerd, conçue pour ressembler à la CLI docker et se comporter comme elle, au point que la plupart des commandes docker fonctionnent en remplaçant simplement le nom du binaire :

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

Au-delà de la parité avec les workflows Docker familiers, nerdctl expose des capacités natives de containerd que Docker n’a pas : images chiffrées, lazy pulling, distribution d’images en P2P, signature et vérification d’images, et interaction directe avec les namespaces Kubernetes dans le modèle de données propre à containerd. Pour du travail général sur une machine où containerd est installé mais pas Docker, nerdctl est l’outil à privilégier.

crictl : du point de vue de Kubernetes

crictl est maintenu par le projet Kubernetes lui-même, et non par containerd, et il parle CRI, la même interface que celle utilisée par le kubelet, plutôt que l’API native de containerd. Cela signifie qu’il fonctionne de façon identique avec containerd, CRI-O ou tout autre runtime conforme à CRI, et qu’il comprend des concepts Kubernetes que ctr et nerdctl ignorent, surtout les Pods, et pas seulement les conteneurs :

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

Remarquez crictl pods : ni ctr, ni nerdctl, ni Docker avant eux, n’avaient de concept natif de Pod, c’est-à-dire un groupe de conteneurs partageant réseau et stockage. C’est propre à Kubernetes, et crictl est l’outil conçu pour raisonner directement dessus.

Comme ctr, crictl est destiné à l’inspection et au débogage plutôt qu’à la création de workloads. Si vous l’utilisez pour démarrer un conteneur que Kubernetes ne connaît pas, le kubelet n’en a aucune trace et le supprimera dès qu’il le remarquera, puisque du point de vue de Kubernetes, un conteneur inattendu sur un nœud est une dérive à corriger, pas un workload à préserver.

Vers quel endpoint crictl dialogue

Comme crictl fonctionne avec plusieurs runtimes, il doit savoir auquel se connecter. Sans configuration, il essaie dans l’ordre une liste fixe de sockets par défaut (historiquement celui de dockershim, puis celui de containerd, puis celui de CRI-O, puis d’autres). Sur un nœud moderne, cette ambiguïté pose rarement problème car un seul runtime est installé, mais sur un nœud qui en a plusieurs, ou pour dépanner un problème de chemin de socket, indiquez-le explicitement :

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

Choisir entre eux

• Inspecter ou dépanner ce que Kubernetes voit lui-même, c’est-à-dire confronter ce que rapporte kubectl describe pod à ce qui tourne réellement sur le nœud : utilisez crictl.
• Travail général sur un nœud ou en développement local, comme lancer rapidement quelque chose, construire une image ou consulter des logs : utilisez nerdctl.
• Déboguer l’état interne de containerd, quelque chose de spécifique à containerd plutôt qu’à la vue CRI indépendante du runtime : tournez-vous vers ctr, et prévoyez d’avoir la documentation de containerd ouverte à côté.