CRICTL : Gérer les conteneurs avec les runtimes CRI

crictl est l’outil CLI officiel pour interagir avec les runtimes de conteneurs compatibles CRI (Container Runtime Interface) comme containerd ou CRI-O. Si vous administrez un cluster Kubernetes et devez déboguer des conteneurs au niveau du runtime (lister les pods, inspecter les logs, exécuter des commandes), crictl est l’outil qu’il vous faut. Version actuelle : v1.35.0 (décembre 2025).

Quand utiliser crictl ?

Utilisez crictl quand kubectl ne suffit pas : problèmes de kubelet, pods bloqués, inspection bas niveau des conteneurs. Pour le développement quotidien, préférez Docker.

Ce que vous allez apprendre

• Installer et configurer crictl pour containerd ou CRI-O
• Lister et inspecter les conteneurs et pods
• Déboguer les problèmes Kubernetes au niveau du runtime
• Utiliser les fonctionnalités avancées (exec parallèle, filtrage par namespace, TLS)

Comprendre le contexte : CRI et les runtimes

En 2016, Kubernetes a introduit la CRI (Container Runtime Interface) pour découpler le runtime de conteneurs du reste de la plateforme. Avant cela, Docker était le seul runtime supporté.

L’objectif : permettre à plusieurs runtimes (containerd, CRI-O, etc.) de fonctionner avec Kubernetes via une API gRPC standardisée.

Dépréciation de dockershim

Depuis Kubernetes 1.24 (mai 2022), le support direct de Docker (dockershim) a été retiré. Les clusters utilisent maintenant containerd ou CRI-O comme runtime. crictl devient donc l’outil de débogage standard.

Qu’est-ce qu’un runtime CRI ?

Un runtime CRI est un composant qui :

1. Reçoit des ordres de Kubernetes via l’API gRPC CRI
2. Crée et gère les conteneurs et leurs sandboxes (pods)
3. Rapporte l’état des conteneurs au kubelet

Runtime	Maintenu par	Usage principal
containerd	CNCF	Défaut sur la plupart des distributions K8s
CRI-O	Red Hat	Optimisé pour OpenShift
cri-dockerd	Mirantis	Pont vers Docker Engine

Glissez pour voir

Installation de crictl

crictl est distribué dans le projet cri-tools qui suit les versions mineures de Kubernetes. Utilisez la même version mineure que votre cluster (ex: crictl 1.35 pour Kubernetes 1.35).

Script (recommandé)

# Définir la version
VERSION="v1.35.0"
ARCH="amd64"  # ou arm64

# Télécharger et installer
curl -sL "https://github.com/kubernetes-sigs/cri-tools/releases/download/${VERSION}/crictl-${VERSION}-linux-${ARCH}.tar.gz" \
  | sudo tar -xzf - -C /usr/local/bin

# Vérifier l'installation
crictl --version
# crictl version v1.35.0

apt (Debian/Ubuntu)

# Installer les prérequis
sudo apt-get update && sudo apt-get install -y apt-transport-https

# Ajouter le dépôt Kubernetes
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
  https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list

# Installer crictl via cri-tools
sudo apt-get update && sudo apt-get install -y cri-tools

crictl --version

Pour maîtriser apt, consultez le guide apt.

Binaire manuel

# Télécharger
VERSION="v1.35.0"
wget "https://github.com/kubernetes-sigs/cri-tools/releases/download/${VERSION}/crictl-${VERSION}-linux-amd64.tar.gz"

# Vérifier le checksum (optionnel mais recommandé)
wget "https://github.com/kubernetes-sigs/cri-tools/releases/download/${VERSION}/crictl-${VERSION}-linux-amd64.tar.gz.sha256"
sha256sum -c crictl-${VERSION}-linux-amd64.tar.gz.sha256

# Extraire et installer
tar -xzf crictl-${VERSION}-linux-amd64.tar.gz
sudo mv crictl /usr/local/bin/

Configuration de crictl

crictl doit connaître le socket de votre runtime CRI. La configuration se fait dans /etc/crictl.yaml.

1. Identifiez votre runtime

   # containerd
   ls -la /run/containerd/containerd.sock
   
   # CRI-O
   ls -la /run/crio/crio.sock

2. Créez le fichier de configuration

   sudo tee /etc/crictl.yaml << EOF
   runtime-endpoint: unix:///run/containerd/containerd.sock
   image-endpoint: unix:///run/containerd/containerd.sock
   timeout: 10
   debug: false
   EOF

   Sockets par runtime

   Runtime	Socket
   containerd	unix:///run/containerd/containerd.sock
   CRI-O	unix:///run/crio/crio.sock
   cri-dockerd	unix:///var/run/cri-dockerd.sock

   Glissez pour voir

3. Testez la connexion

   crictl info

   Si la commande retourne les informations du runtime, la configuration est correcte.

Activer CRI dans containerd (si nécessaire)

Si vous utilisez containerd en dehors de Kubernetes, le plugin CRI peut être désactivé par défaut.

1. Générez la configuration par défaut

   sudo containerd config default | sudo tee /etc/containerd/config.toml

2. Vérifiez que CRI est activé

   Ouvrez /etc/containerd/config.toml et assurez-vous que cette ligne est commentée ou absente :

   # disabled_plugins = ["cri"]

3. Redémarrez containerd

   sudo systemctl restart containerd
   crictl info

Utiliser crictl sans sudo

Par défaut, le socket containerd appartient à root:root, ce qui oblige à utiliser sudo. Pour permettre l’accès sans privilèges root, créez un groupe dédié et configurez le socket.

1. Créez le groupe containerd et ajoutez votre utilisateur

   sudo groupadd containerd
   sudo usermod -aG containerd $USER

2. Changez le groupe du socket

   sudo chgrp containerd /run/containerd/containerd.sock

3. Rendez le changement permanent

   Créez un override systemd pour appliquer le changement à chaque démarrage :

   sudo mkdir -p /etc/systemd/system/containerd.service.d
   sudo tee /etc/systemd/system/containerd.service.d/socket-group.conf << 'EOF'
   [Service]
   ExecStartPost=/bin/chgrp containerd /run/containerd/containerd.sock
   EOF
   sudo systemctl daemon-reload

4. Appliquez les changements de groupe

   Déconnectez-vous et reconnectez-vous, ou utilisez :

   newgrp containerd

5. Vérifiez l’accès sans sudo

   crictl info -o json | jq '{runtime: .config.containerd.defaultRuntimeName}'

   Sortie

   {
     "runtime": "runc"
   }

Alternative : socket utilisateur

Containerd 2.0+ supporte un socket utilisateur. Consultez la documentation officielle pour configurer containerd --address $XDG_RUNTIME_DIR/containerd/containerd.sock.

Gestion des images

crictl permet de gérer les images de conteneurs stockées par le runtime.

Lister les images

crictl images

Sortie

IMAGE                       TAG       IMAGE ID       SIZE
docker.io/library/busybox   1.36      114f4abb67995  2.22MB
docker.io/library/nginx     1.27      1e5f3c5b981a9  72.4MB
registry.k8s.io/pause       3.10.1    cd073f4c5f6a8  320kB

Télécharger et inspecter une image

# Télécharger une image
crictl pull nginx:1.27

# Inspecter les métadonnées d'une image
crictl inspecti docker.io/library/busybox:1.36 | jq '{
  digest: .status.id[0:50],
  size: .status.size,
  tags: .status.repoTags
}'

Sortie

{
  "digest": "sha256:114f4abb67995cfe8e368760f3bc8a1d00e12ac98",
  "size": "2217150",
  "tags": ["docker.io/library/busybox:1.36"]
}

Supprimer une image

crictl rmi alpine:3.19
# Deleted: docker.io/library/alpine:3.19

Pas de build d'images

crictl ne permet pas de construire des images. Utilisez Docker, Buildah ou Kaniko pour le build, puis crictl pour vérifier leur présence sur le runtime.

Gestion des conteneurs avec crictl

Lister les conteneurs

# Conteneurs en cours d'exécution
crictl ps

Sortie

CONTAINER      IMAGE                            CREATED         STATE     NAME            ATTEMPT  POD ID
209fb8b19830c  docker.io/library/busybox:1.36   2 minutes ago   Running   test-container  0        027378143d3ff

# Tous les conteneurs (y compris arrêtés)
crictl ps -a

# Filtrer par état
crictl ps --state running

# Filtrer par nom
crictl ps --name test

# Filtrer par namespace Kubernetes (v1.32+)
crictl ps --namespace kube-system

# Filtrer par pod
crictl ps --pod <POD_ID>

# Sortie JSON
crictl ps -o json

Inspecter un conteneur

crictl inspect 209fb8b19830c | jq '{
  id: .status.id[0:12],
  state: .status.state,
  pid: .info.pid,
  image: .status.image.image
}'

Sortie

{
  "id": "209fb8b19830",
  "state": "CONTAINER_RUNNING",
  "pid": 136906,
  "image": "docker.io/library/busybox:1.36"
}

Gérer les conteneurs

# Démarrer un conteneur
crictl start <CONTAINER_ID>

# Arrêter un conteneur
crictl stop <CONTAINER_ID>

# Supprimer un conteneur
crictl rm <CONTAINER_ID>

Debugging et inspection

Logs des conteneurs

# Voir les logs
crictl logs <CONTAINER_ID>

Sortie

Hello from crictl test container
Hello from crictl test container
Hello from crictl test container

# Dernières N lignes
crictl logs --tail 2 <CONTAINER_ID>

# Suivre en temps réel
crictl logs -f <CONTAINER_ID>

# Filtrer par flux (v1.33+)
crictl logs --stream stdout <CONTAINER_ID>
crictl logs --stream stderr <CONTAINER_ID>

# Logs avec timestamps
crictl logs -t <CONTAINER_ID>

Exécuter des commandes

# Commande simple
crictl exec <CONTAINER_ID> uname -a

Sortie

Linux master1 6.8.0-90-generic #91-Ubuntu SMP ... x86_64 GNU/Linux

# Shell interactif
crictl exec -it <CONTAINER_ID> /bin/sh

# Exécution parallèle sur plusieurs conteneurs (v1.32+)
crictl exec --image nginx -x -- cat /etc/nginx/nginx.conf

# Avec support TLS (v1.32+)
crictl exec --tls-ca /path/to/ca.crt \
            --tls-cert /path/to/client.crt \
            --tls-key /path/to/client.key \
            -it <CONTAINER_ID> /bin/sh

Statistiques des conteneurs

# Stats d'un conteneur spécifique
crictl stats <CONTAINER_ID>

Sortie

CONTAINER      NAME            CPU %  MEM       DISK      INODES  SWAP
209fb8b19830c  test-container  0.01   327.7kB   16.38kB   7       0B

# Stats de tous les conteneurs
crictl stats

Gestion des pods avec crictl

Dans Kubernetes, un pod est un groupe de conteneurs partageant réseau et stockage. crictl permet de gérer les pods directement au niveau du runtime.

Lister et inspecter les pods

# Lister tous les pods
crictl pods

Sortie

POD ID         CREATED        STATE  NAME      NAMESPACE  ATTEMPT  RUNTIME
027378143d3ff  5 minutes ago  Ready  test-pod  default    0

# Filtrer par namespace
crictl pods --namespace kube-system

# Inspecter un pod
crictl inspectp <POD_ID> | jq '{
  id: .status.id[0:12],
  state: .status.state,
  ip: .status.network.ip
}'

Sortie

{
  "id": "027378143d3f",
  "state": "SANDBOX_READY",
  "ip": "10.88.0.2"
}

# Stats des pods (v1.28+)
crictl statsp

Créer un pod (test/debug)

Pour créer un pod manuellement (utile pour les tests), vous avez besoin d’un fichier de configuration JSON :

pod-config.json

{
  "metadata": {
    "name": "test-pod",
    "namespace": "default",
    "uid": "test-pod-uid-001"
  },
  "log_directory": "/tmp/crictl-logs",
  "linux": {}
}

# Créer le pod
crictl runp pod-config.json
# 027378143d3ff23e276aeffbd06002ac40a7c03c280ceb9ce94f971d4c7f90c5

# Lister pour vérifier
crictl pods

Prérequis CNI

Pour que le pod obtienne une adresse IP, les plugins CNI doivent être installés et configurés dans /etc/cni/net.d/. Sans CNI, la création de pod échouera avec l’erreur CNI plugin not initialized.

Créer un conteneur dans un pod

Une fois le pod créé, vous pouvez y ajouter un conteneur :

container-config.json

{
  "metadata": {
    "name": "test-container"
  },
  "image": {
    "image": "docker.io/library/busybox:1.36"
  },
  "command": ["sh", "-c", "while true; do echo 'Hello'; sleep 5; done"],
  "log_path": "test-container.log",
  "linux": {}
}

# Créer le conteneur (sans le démarrer)
POD_ID=$(crictl pods -q)
crictl create $POD_ID container-config.json pod-config.json
# 209fb8b19830c2e569d778285035b55db673fd88816d066a9b0cd1b83db076e3

# Démarrer le conteneur
crictl start 209fb8b19830c

Supprimer un pod

# Arrêter le pod (arrête les conteneurs)
crictl stopp <POD_ID>
# Stopped sandbox 027378143d3ff

# Supprimer le pod
crictl rmp <POD_ID>
# Removed sandbox 027378143d3ff

Fonctionnalités avancées

Les versions récentes de crictl ont introduit des fonctionnalités puissantes pour le débogage et la gestion à grande échelle. Voici les plus utiles, avec leurs dates de sortie et cas d’usage concrets.

Informations du runtime

# Informations de version
crictl version

Sortie

Version:  v1.35.0
RuntimeName:  containerd
RuntimeVersion:  v2.2.1
RuntimeApiVersion:  v1

# Configuration du runtime
crictl runtime-config
# cgroup driver:   CGROUPFS

# Informations détaillées
crictl info -o json | jq '{
  runtimeSpec: .config.containerd.defaultRuntimeName,
  cgroupDriver: .config.containerd.runtimes.runc.options.SystemdCgroup
}'

Informations sur le stockage

crictl imagefsinfo

Sortie

{
  "status": {
    "imageFilesystems": [{
      "fsId": {
        "mountpoint": "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"
      },
      "inodesUsed": { "value": "5908" },
      "usedBytes": { "value": "212267008" }
    }]
  }
}

Événements en temps réel

La commande events affiche les événements du runtime en temps réel. Utile pour surveiller ce qui se passe sur le nœud :

crictl events

Sortie (exemple)

{
  "containerId": "209fb8b19830c...",
  "containerEventType": "CONTAINER_STARTED_EVENT",
  "podSandboxStatus": {
    "id": "027378143d3ff...",
    "state": "SANDBOX_READY",
    "network": { "ip": "10.88.0.2" }
  }
}

Cas d'usage des événements

Utilisez crictl events pour déboguer des problèmes de démarrage de conteneurs. Vous verrez en temps réel les événements CREATED, STARTED, STOPPED, etc.

Exécution parallèle

Pourquoi c'est utile ?

Imaginez un cluster avec 50 conteneurs nginx. Vous devez vérifier une variable d’environnement sur tous. Sans l’exécution parallèle, vous auriez besoin de 50 commandes crictl exec. Avec -x, une seule commande suffit.

L’exécution parallèle permet de lancer une commande dans plusieurs conteneurs simultanément, filtré par image, pod, nom ou état. C’est indispensable pour :

• Audit rapide : vérifier une config sur tous les conteneurs d’un type
• Diagnostic de masse : collecter des infos système (date, env, mémoire)
• Nettoyage : exécuter un script de maintenance sur tous les conteneurs

Prérequis

L’exécution parallèle nécessite des conteneurs actifs correspondant au filtre. S’il n’y a aucun conteneur en cours d’exécution, la commande retournera No containers found per filter flags.

Créer un environnement de test

Pour tester l’exécution parallèle, créez plusieurs conteneurs busybox :

# Créer le fichier de configuration du pod (UID unique requis)
cat > /tmp/test-pod.json << EOF
{
  "metadata": {
    "name": "test-parallel",
    "namespace": "default",
    "uid": "test-parallel-$(date +%s)"
  },
  "log_directory": "/tmp/crictl-logs",
  "linux": {}
}
EOF

# Créer le pod
crictl runp /tmp/test-pod.json

# Récupérer l'ID du pod
POD_ID=$(crictl pods -q)
echo "Pod créé: $POD_ID"

# Créer et démarrer 3 conteneurs avec des noms uniques
for i in 1 2 3; do
  cat > /tmp/test-container-$i.json << EOF
{
  "metadata": { "name": "worker-$i" },
  "image": { "image": "docker.io/library/busybox:1.36" },
  "command": ["sh", "-c", "while true; do sleep 3600; done"],
  "log_path": "worker-$i.log",
  "linux": {}
}
EOF
  CID=$(crictl create $POD_ID /tmp/test-container-$i.json /tmp/test-pod.json)
  crictl start $CID
done

# Vérifier
crictl ps

Sortie

CONTAINER      IMAGE                            STATE     NAME       POD ID
720505c9523ac  docker.io/library/busybox:1.36   Running   worker-3   9418c9638da39
82e328bd61005  docker.io/library/busybox:1.36   Running   worker-2   9418c9638da39
0f83e10e7e4b3  docker.io/library/busybox:1.36   Running   worker-1   9418c9638da39

Exemples d’exécution parallèle

# Voir le hostname de tous les conteneurs busybox (nom complet requis)
crictl exec --image "docker.io/library/busybox:1.36" --parallel -- hostname

Sortie

master1
master1
master1

# Voir les variables d'environnement de tous les conteneurs actifs
crictl exec --state running -x -- env | grep "^PATH"

Sortie

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Lister les processus de tous les conteneurs d'un pod spécifique
crictl exec --pod $POD_ID -x -- ps aux

# Ignorer les erreurs et continuer sur tous les conteneurs
crictl exec --state running -x -e -- cat /etc/os-release

Nom d'image complet requis

Le filtre --image nécessite le nom complet de l’image tel qu’affiché par crictl ps -o json | jq '.containers[].image.image'. Utilisez docker.io/library/busybox:1.36 et non simplement busybox.

Nettoyer l’environnement de test

# Arrêter et supprimer tous les conteneurs du pod
for CID in $(crictl ps -q); do
  crictl stop $CID
  crictl rm $CID
done

# Supprimer le pod
crictl stopp $POD_ID
crictl rmp $POD_ID

Option	Description	Exemple
--image	Filtre par nom d’image (conteneurs actifs uniquement)	--image busybox
--pod	Filtre par ID de pod	--pod abc123def
--state	Filtre par état	--state running
--name	Filtre par nom de conteneur	--name worker
-x, --parallel	Active l’exécution parallèle	-x
-q, --quiet	Masque les IDs conteneurs dans la sortie	-q
-e, --ignore-error	Continue même si une commande échoue	-e

Glissez pour voir

Support TLS pour le streaming

Quand utiliser TLS ?

Dans les environnements de production sécurisés, les communications entre crictl et le runtime peuvent transiter par un réseau non fiable (ex: débogage distant). Le support TLS chiffre ces échanges pour éviter l’interception de données sensibles.

Les commandes exec, attach et portforward supportent maintenant le chiffrement TLS. C’est essentiel pour :

• Conformité sécurité : exigences PCI-DSS, HIPAA, SOC2
• Débogage distant : accès sécurisé aux conteneurs via réseau externe
• Zero-trust : ne jamais faire confiance au réseau interne

# Exécution avec authentification TLS mutuelle
crictl exec \
  --tls-ca /etc/kubernetes/pki/ca.crt \
  --tls-cert /etc/kubernetes/pki/admin.crt \
  --tls-key /etc/kubernetes/pki/admin.key \
  --tls-server-name containerd.local \
  -it abc123 /bin/sh

Option	Description
--tls-ca	Certificat CA pour valider le serveur
--tls-cert	Certificat client
--tls-key	Clé privée du certificat client
--tls-server-name	Nom du serveur pour la validation SNI

Glissez pour voir

Filtrage des logs par flux

Pourquoi séparer stdout et stderr ?

Dans un conteneur, stdout contient généralement les logs applicatifs normaux, tandis que stderr contient les erreurs. Séparer les deux permet de filtrer rapidement les problèmes sans être noyé dans les logs de fonctionnement normal.

L’option --stream permet de récupérer uniquement stdout ou stderr, facilitant le tri des logs :

# Voir uniquement les erreurs (stderr)
crictl logs --stream stderr abc123

# Voir uniquement les logs normaux (stdout)
crictl logs --stream stdout abc123

# Combiner avec tail pour les dernières erreurs
crictl logs --stream stderr --tail 50 abc123

Cas d’usage typique : un conteneur produit beaucoup de logs INFO sur stdout. Vous cherchez une erreur spécifique. Avec --stream stderr, vous isolez instantanément les messages d’erreur.

Découverte des fonctionnalités du runtime

Qu'est-ce qu'un KEP ?

Un KEP (Kubernetes Enhancement Proposal) est une proposition formelle d’amélioration de Kubernetes. Le KEP-3619 a standardisé la façon dont les runtimes exposent leurs fonctionnalités supportées.

L’API CRI permet d’interroger les capacités du runtime installé. C’est utile pour :

• Vérifier la compatibilité : le runtime supporte-t-il les user namespaces ?
• Diagnostic : pourquoi une fonctionnalité ne marche pas ?
• Automatisation : scripts qui s’adaptent aux capacités disponibles

# Voir toutes les fonctionnalités du runtime
crictl info -o json | jq '.features'

Sortie

{
  "supplementalGroupsPolicy": true,
  "recursiveReadOnlyMounts": true,
  "userNamespaces": true
}

Fonctionnalité	Description
supplementalGroupsPolicy	Gestion avancée des groupes Linux
recursiveReadOnlyMounts	Montages récursifs en lecture seule
userNamespaces	Isolation des user namespaces (rootless)

Glissez pour voir

Descripteurs de métriques

À quoi servent les métriques CRI ?

L’API CRI expose des métriques sur l’utilisation des ressources par les conteneurs. La commande metricdescs liste les métriques disponibles, permettant de savoir ce que vous pouvez monitorer via le runtime.

La commande metricdescs (introduite en v1.33, stabilisée en v1.34) liste les métriques disponibles via l’API ListMetricDescriptors :

crictl metricdescs | head -20

Sortie

{
  "descriptors": [
    {
      "name": "container_fs_reads_bytes_total",
      "help": "Cumulative count of bytes read",
      "labelKeys": ["id", "name", "device"]
    },
    {
      "name": "container_fs_reads_total",
      "help": "Cumulative count of reads completed",
      "labelKeys": ["id", "name", "device"]
    }
  ]
}

Cas d’usage : avant de configurer votre monitoring (Prometheus, Datadog), vérifiez quelles métriques le runtime expose nativement.

Ajustement du score OOM

Manipulation délicate

L’OOM score détermine quel processus le kernel Linux tue en premier quand la mémoire est épuisée. Un score bas (-1000 à 0) protège le conteneur, un score haut (0 à 1000) le rend prioritaire pour l’arrêt.

La commande crictl update --oom-score-adj permet de modifier la priorité OOM d’un conteneur en cours d’exécution, sans redémarrage :

# Protéger un conteneur critique (base de données)
# Score -500 = moins susceptible d'être tué
crictl update --oom-score-adj -500 abc123

# Rendre un conteneur moins prioritaire (tâche batch)
# Score +500 = plus susceptible d'être tué en cas de pénurie mémoire
crictl update --oom-score-adj 500 def456

# Vérifier le score actuel
crictl inspect abc123 | jq '.status.resources.oomScoreAdj'

Cas d’usage : votre cluster a une pression mémoire temporaire. Vous voulez protéger la base de données mais accepter que les workers de tâches batch soient tués en premier. Avec --oom-score-adj, vous ajustez les priorités sans redéployer.

Valeur	Comportement
-1000	Jamais tué par l’OOM killer (réservé au système)
-500	Fortement protégé
0	Comportement par défaut
+500	Prioritaire pour être tué
+1000	Tué en premier

Glissez pour voir

Intégration avec Kubernetes

Pourquoi utiliser crictl avec Kubernetes ?

Cas d’usage	kubectl	crictl
Gestion normale des workloads	✅	❌
Débogage kubelet défaillant	❌	✅
Inspection bas niveau	❌	✅
Pods bloqués en Terminating	❌	✅

Glissez pour voir

Workflow de débogage typique

1. Identifiez le problème avec kubectl

   kubectl get pods -A | grep -v Running

2. Connectez-vous au nœud concerné

   ssh worker-node-1

3. Listez les pods avec crictl

   crictl pods

4. Inspectez le pod problématique

   crictl inspectp <POD_ID>

5. Vérifiez les logs des conteneurs

   crictl logs <CONTAINER_ID>

Dépannage

Problème	Cause probable	Solution
FATA: Cannot connect to runtime	Socket introuvable	Vérifiez /etc/crictl.yaml
error: no running containers	Aucun conteneur actif	Utilisez crictl ps -a
permission denied	Droits insuffisants	Exécutez avec sudo
CRI plugin is disabled	containerd mal configuré	Activez CRI dans config.toml

Glissez pour voir

À retenir

• crictl est l’outil de débogage bas niveau pour les runtimes CRI
• Configurez le socket dans /etc/crictl.yaml
• Utilisez la même version mineure que Kubernetes
• crictl ps → conteneurs, crictl pods → pods
• Fonctionnalités avancées : exécution parallèle (-x), filtrage namespace, TLS
• Filtrage des logs par flux (stdout/stderr), ajustement OOM score

Prochaines étapes

containerd Configurez et utilisez containerd comme runtime de conteneurs

Kubernetes Maîtrisez l'orchestration de conteneurs avec Kubernetes

nerdctl CLI compatible Docker pour containerd

Podman Alternative rootless à Docker

Questions fréquentes

Quelle est la différence entre crictl et docker CLI ?

Comment configurer le socket crictl pour containerd ?

Comment lister les conteneurs d'un namespace Kubernetes avec crictl ?

Comment exécuter une commande dans plusieurs conteneurs en parallèle ?

Comment voir uniquement les logs stderr ou stdout d'un conteneur ?

Comment activer le support TLS pour crictl exec et attach ?

Comment déboguer un pod Kubernetes avec crictl ?

Comment voir les RuntimeFeatures supportées par containerd ?

Comment mettre à jour l'OOM score d'un conteneur en cours d'exécution ?

Comment installer crictl sur une machine sans Kubernetes ?

×

📖 Voir la documentation →