Containerd : le runtime de conteneurs sous le capot de Kubernetes

Depuis le déploiement massif de Kubernetes en production, containerd s'est imposé comme le runtime de conteneurs par défaut. Mais pourquoi ? Parce qu'il offre ce que Docker ne peut pas : une architecture légère, modulaire, et taillée spécifiquement pour les environnements d'orchestration moderne.

Si vous administrez une infrastructure de conteneurs chez vous ou chez un client, vous rencontrez certainement containerd sans le savoir. Kubernetes 1.24 a supprimé le support natif de Docker (dockershim) en mai 2022. Depuis, containerd règne sans partage sur les clusters de production.

Cet article vous plonge dans les entrailles de containerd : son histoire, son architecture, ses outils, et comment le configurer pour Kubernetes.

1. De Docker à containerd, L'histoire d'une extraction
2. Architecture et plugins, Comprendre le design modulaire
3. Les CLI : ctr et nerdctl, Interagir avec les conteneurs
4. Configuration pour Kubernetes, Le fichier config.toml
5. Comparaison : containerd vs CRI-O vs Docker
6. Perspectives et ressources

Avant 2017, Docker était une boîte noire monolithique. Moby Project a ouvert les portes, mais c'est l'extraction de containerd qui a révolutionné l'écosystème.

L'extraction de Docker (2017)

Docker Inc. a reconnu une vérité inconfortable : les équipes d'infrastructure ne voulaient pas de l'ensemble Docker, juste du runtime. Les fonctionnalités daemon, API, build, networking, tout ça, c'était du bruit pour Kubernetes.

En février 2019, containerd atteint le statut CNCF Graduated. C'était officiel : containerd était l'avenir du runtime de conteneurs.

Pourquoi cette extraction ?

• Légèreté : 65 MB au lieu de 200+ MB pour Docker
• Stabilité : une responsabilité unique = moins de bugs
• Contrôle : pas de dépendances sur les décisions de Docker Inc.
• Flexibilité : architecture plugin pour les runtimes alternatifs

Containerd repose sur une architecture plugin-first. Chaque fonction critique est un plugin.

Les trois piliers

# /etc/containerd/config.toml
[grpc]
  address = "/run/containerd/containerd.sock"

[plugins]
  # Plugin snapshotter (gestion des couches de conteneurs)
  [plugins."io.containerd.snapshotter.v1.overlayfs"]
    root_path = "/var/lib/containerd/snapshots"

  # Plugin content store (blob storage)
  [plugins."io.containerd.content.v1.content"]
    root = "/var/lib/containerd/content"

  # Plugin CRI (Container Runtime Interface)
  [plugins."io.containerd.grpc.v1.cri"]
    sandbox_image = "registry.k8s.io/pause:3.8"

Snapshotter : gère les couches du système de fichiers (overlayfs par défaut, mais supporte btrfs, zfs).

Content store : stockage immutable des images (blobs, digests SHA256).

CRI plugin : l'interface standard pour Kubernetes (Pod, Container, Image services).

OCI compliance

Containerd respecte la Open Container Initiative (OCI). Le runtime par défaut est runc, mais vous pouvez injecter crun (C), kata (lightweight VMs), ou gVisor (sandbox).

Deux interfaces existent.

ctr : bas niveau, brut

# Lister les images
ctr images ls

# Tirer une image
ctr images pull docker.io/library/alpine:latest

# Créer et lancer un conteneur (plus complexe)
ctr run --rm docker.io/library/alpine echo "Hello"

ctr est complet mais verbeux. Pensez-y comme du strace pour conteneurs.

nerdctl : Docker-compatible

# Interface Docker, mais avec containerd
nerdctl ps
nerdctl images
nerdctl run -it alpine /bin/sh
nerdctl build -t myapp .
nerdctl push docker.io/myrepo/myapp

nerdctl est ce que vous voulez vraiment. C'est Docker sans Docker, 99 % compatible.

Kubernetes parle à containerd via le plugin CRI. Voici une config typique :

version = 2

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.9"
  [plugins."io.containerd.grpc.v1.cri".containerd]
    snapshotter = "overlayfs"
    default_runtime_name = "runc"

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      privileged_without_host_devices = false

[plugins."io.containerd.grpc.v1.cri".cni]
  bin_dir = "/opt/cni/bin"
  conf_dir = "/etc/cni/net.d"

Démarrer et vérifier :

# Redémarrer après édition
sudo systemctl restart containerd

# Vérifier que CRI fonctionne
crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps

Verdict : containerd pour 95 % des cas. CRI-O si vous cherchez quelque chose de super léger et dédié à Kubernetes.

• Kubernetes Introduction, Comprendre l'orchestration au-delà du runtime
• Hardening Docker, Sécuriser vos conteneurs en production
• Podman 2026, L'alternative daemonless à containerd

• containerd.io
• GitHub: containerd/containerd
• nerdctl GitHub
• OCI Runtime Specification
• Kubernetes CRI Documentation

Containerd a maturé en devenant le runtime par défaut de Kubernetes, et c'est mérité. Son architecture modulaire, sa légèreté et son respect des standards OCI en font la brique de base de tout cluster moderne.

Chez SHPV, nos infrastructures de conteneurs reposent sur cette fondation éprouvée. Que vous déployiez une application en Kubernetes ou que vous orchestriez des conteneurs directement, comprendre containerd (ses plugins, sa configuration, ses outils) c'est comprendre comment vos applications tournent en production.

La prochaine fois que vous verrez un Pod Kubernetes au travail, vous saurez que c'est containerd, en coulisses, qui fait toute la plomberie.