CNI, CSI et CRI, Les interfaces d'extension de Kubernetes

Kubernetes ne gère pas directement le réseau, le stockage ou l'exécution des conteneurs. Il délègue ces responsabilités à des plugins externes via trois interfaces standardisées : CNI (réseau), CSI (stockage) et CRI (runtime). Comprendre ces interfaces est essentiel pour la certification CKA (domaine Cluster Architecture, 25%).

Ce guide explique le rôle de chaque interface et comment les diagnostiquer.

Ce que vous allez apprendre

• CNI : comment Kubernetes configure le réseau des Pods
• CSI : comment Kubernetes accède au stockage externe
• CRI : comment le kubelet communique avec le runtime de conteneurs
• Les commandes de diagnostic pour chaque interface

Vue d'ensemble des trois interfaces

Les trois interfaces répondent à la même logique : Kubernetes définit un contrat, et n'importe quel fournisseur peut écrire un plugin qui le respecte. Le schéma montre qui appelle quoi. Retenez surtout que le kubelet est le point de départ pour le runtime et le stockage, alors que le réseau est configuré par le runtime lui-même au moment où il crée le Pod.

Interface	Acronyme	Rôle	Exemple de plugins
CRI	Container Runtime Interface	Créer/gérer les conteneurs	containerd, CRI-O
CNI	Container Network Interface	Configurer le réseau des Pods	Calico, Cilium, Flannel
CSI	Container Storage Interface	Provisionner le stockage	AWS EBS, Ceph, NFS

Glissez pour voir

CRI, Container Runtime Interface

C'est l'interface la plus proche du système : sans elle, aucun conteneur ne démarre sur le nœud. Elle définit un contrat gRPC entre le kubelet, qui sait ce qu'il faut lancer, et le runtime, qui sait comment le lancer. Un problème à ce niveau se manifeste toujours de la même façon, le nœud passe en NotReady et aucun Pod ne démarre.

C'est quoi ?

Le CRI est l'interface gRPC entre le kubelet et le runtime de conteneurs. Il permet au kubelet de créer, démarrer, arrêter et supprimer des conteneurs sans connaître les détails d'implémentation du runtime.

Pourquoi c'est important ?

Avant le CRI (Kubernetes < 1.5), le kubelet était couplé à Docker. Le CRI a permis de supporter d'autres runtimes comme containerd ou CRI-O.

API CRI v1

Depuis Kubernetes 1.26, seule l'API CRI v1 est supportée. Si votre runtime ne supporte pas cette version, le kubelet refuse de démarrer.

Runtimes CRI compatibles

Deux implémentations dominent aujourd'hui et se valent en production. Le choix est le plus souvent dicté par la distribution Kubernetes que vous installez, pas par une préférence technique.

Runtime	Description	Cas d'usage
containerd	Runtime léger, standard de facto	Clusters kubeadm, cloud providers
CRI-O	Optimisé pour Kubernetes	OpenShift, clusters minimalistes

Glissez pour voir

Vérifier le runtime configuré

La colonne CONTAINER-RUNTIME donne à la fois le runtime et sa version, nœud par nœud. Une colonne non homogène mérite un examen : c'est souvent le signe d'un nœud ajouté avec une autre procédure d'installation.

# Voir le runtime utilisé par le kubelet
kubectl get nodes -o wide

NAME      STATUS   ROLES           VERSION   CONTAINER-RUNTIME
master1   Ready    control-plane   v1.36.0   containerd://2.2.3
worker1   Ready    <none>          v1.36.0   containerd://2.2.3

# Détails du socket CRI
kubectl get node <node-name> -o jsonpath='{.status.nodeInfo.containerRuntimeVersion}'

Configuration kubelet

Le kubelet se connecte au runtime via un socket Unix. C'est le paramètre clé de la configuration CRI :

# Socket containerd (défaut sur la plupart des distributions)
--container-runtime-endpoint=unix:///run/containerd/containerd.sock

# Socket CRI-O
--container-runtime-endpoint=unix:///var/run/crio/crio.sock

La configuration exacte varie selon les distributions. Sur un nœud kubeadm, vous pouvez vérifier :

# Voir l'endpoint configuré
ps aux | grep kubelet | grep container-runtime-endpoint

# Ou dans la config kubelet (selon distribution)
cat /var/lib/kubelet/kubeadm-flags.env

Diagnostic CRI

Ces commandes s'exécutent sur le nœud, en SSH, et fonctionnent même quand l'API server est injoignable : crictl parle directement au socket du runtime, sans passer par le control plane.

# Vérifier que le socket existe
ls -la /run/containerd/containerd.sock

# Tester la connexion avec crictl
crictl info

# Lister les conteneurs via CRI
crictl ps

# Lister les images
crictl images

L'outil de diagnostic standard de cette interface s'appelle crictl. Il est présent sur la plupart des nœuds Kubernetes et parle directement au socket du runtime, ce qui en fait le seul recours quand l'API server ne répond plus. Sur le cluster de cette formation, crictl version rend RuntimeName: containerd, RuntimeVersion: v2.3.4 et surtout RuntimeApiVersion: v1, qui confirme d'un coup d'œil la contrainte énoncée plus haut.

CNI, Container Network Interface

Kubernetes impose un modèle réseau (chaque Pod a sa propre IP, joignable depuis tous les autres Pods sans NAT) mais ne fournit aucune implémentation. C'est le rôle du plugin CNI, choisi à l'installation du cluster. Tant qu'aucun plugin n'est installé, les Pods restent bloqués en ContainerCreating et les nœuds en NotReady.

C'est quoi ?

Le CNI est la spécification qui définit comment configurer le réseau des conteneurs. Quand un Pod est créé, le runtime appelle les plugins CNI pour :

1. Créer une interface réseau dans le Pod
2. Assigner une adresse IP
3. Configurer les routes

Le flow réseau Pod

L'ordre des étapes explique un comportement déroutant : le conteneur existe avant d'avoir une adresse. Si le plugin CNI échoue à l'étape 4, le Pod est créé mais sans réseau, d'où un statut ContainerCreating qui ne se résout jamais.

1. kubelet demande la création d'un Pod au runtime (CRI)
                    │
                    ▼
2. Le runtime crée le conteneur et son namespace réseau
                    │
                    ▼
3. Le runtime appelle les plugins CNI configurés
                    │
                    ▼
4. CNI assigne une IP et configure le réseau
                    │
                    ▼
5. Le Pod est accessible sur le réseau du cluster

Plugins CNI populaires

Le mode réseau détermine comment un paquet voyage d'un nœud à l'autre : VXLAN encapsule le trafic dans un tunnel, ce qui fonctionne partout mais ajoute de la latence ; BGP annonce les routes des Pods au réseau sous-jacent, ce qui est plus rapide mais suppose un réseau coopératif ; eBPF traite les paquets directement dans le noyau. Ce choix est structurant, changer de plugin CNI sur un cluster en production est une opération lourde.

Plugin	Mode réseau	Forces
Calico	BGP / VXLAN / IP-in-IP	Network Policies, performance
Cilium	eBPF	Observabilité, sécurité avancée
Flannel	VXLAN / host-gw	Simplicité, idéal pour débuter
Canal	Calico + Flannel	Combine les deux

Glissez pour voir

Weave Net obsolète

Le projet Weave Net a été archivé en juin 2024 et n'est plus maintenu. Ne l'utilisez pas pour de nouveaux clusters.

Kubernetes recommande les plugins compatibles avec la spec CNI v1.0.0, et c'est ce que vous lirez dans le champ cniVersion d'un fichier de configuration moderne. N'en déduisez pas un plancher : relevé sur le cluster kind de cette formation, 10-kindnet.conflist déclare "cniVersion": "0.3.1" et le réseau fonctionne parfaitement. Ce champ décrit le format du fichier de configuration, pas le niveau de fonctionnalités du plugin : une valeur ancienne n'est pas en soi le signe d'un problème.

Configuration CNI

Les plugins CNI sont configurés dans /etc/cni/net.d/ :

# Lister les configurations CNI
ls /etc/cni/net.d/

10-calico.conflist

Le préfixe numérique donne l'ordre de lecture : c'est le premier fichier par ordre alphabétique qui est retenu. La sélection revient au runtime de conteneurs, containerd ou CRI-O, et non au kubelet : c'est lui qui appelle le plugin, conformément à la chaîne kubelet -> runtime CRI -> CNI décrite plus haut. Le nom du fichier vous dit donc quel plugin est réellement actif, ce qui est le moyen le plus rapide de le savoir. Sur un cluster de lab monté avec Kind, vous lirez 10-kindnet.conflist.

Exemple de configuration Calico :

{
  "name": "k8s-pod-network",
  "cniVersion": "1.0.0",
  "plugins": [
    {
      "type": "calico",
      "datastore_type": "kubernetes",
      "ipam": {
        "type": "calico-ipam"
      },
      "policy": {
        "type": "k8s"
      }
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true}
    }
  ]
}

Binaires CNI

Les binaires des plugins sont dans /opt/cni/bin/ :

ls /opt/cni/bin/

Sur un cluster avec Calico

bandwidth  bridge  calico  calico-ipam  flannel  host-local  loopback  portmap  ...

Ne soyez pas surpris par la brièveté de la liste sur un cluster de lab. Relevé sur le cluster kind de cette formation, il n'y a que quatre binaires :

Sur le cluster kind de cette formation

host-local  loopback  portmap  ptp

Aucun ne s'appelle kindnet : le plugin réseau tourne comme un DaemonSet dans le cluster et s'appuie sur ces briques de base, là où Calico dépose en plus son propre binaire. Compter les fichiers de ce répertoire ne dit donc rien du plugin réellement actif ; c'est /etc/cni/net.d/ qui le nomme.

Diagnostic CNI

Le diagnostic part toujours du même constat : un Pod n'a pas d'adresse, ou n'en joint pas un autre. Ces commandes vérifient successivement que le plugin tourne, que l'adresse a été attribuée, et que la plage du nœud correspond au CIDR du cluster.

# Quel plugin tourne, sans présumer de son nom
kubectl get daemonset -n kube-system

# Voir l'IP attribuée à un Pod
kubectl get pod <pod-name> -o wide

# Vérifier le CIDR du cluster
kubectl cluster-info dump | grep -m 1 cluster-cidr

# Voir le CIDR alloué à chaque nœud
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

Problèmes CNI courants

Trois symptômes couvrent la grande majorité des incidents réseau sur un cluster neuf. Ils se distinguent par le moment où la panne apparaît : à la création du Pod, à l'attribution de l'adresse, ou seulement lors des échanges entre Pods.

Symptôme	Cause probable	Solution
Pod en ContainerCreating	Plugin CNI manquant	Installer un CNI (Calico, Flannel...)
Pod sans IP	Erreur IPAM	Vérifier logs du plugin CNI
Pods ne communiquent pas	Network Policy ou erreur plugin	Vérifier les Network Policies

Glissez pour voir

CSI, Container Storage Interface

Le stockage est le domaine où les fournisseurs sont les plus nombreux : baies NAS, disques cloud, systèmes distribués. Plutôt que d'intégrer leur code dans Kubernetes, le CSI leur donne une interface commune, implémentée par un driver déployé comme n'importe quelle application du cluster. C'est aussi la seule des trois interfaces qui met en jeu des données persistantes, donc la seule où une erreur peut avoir des conséquences irréversibles.

C'est quoi ?

Le CSI est l'interface standard pour provisionner et attacher du stockage aux conteneurs. Il remplace les plugins de stockage "in-tree" (intégrés au code de Kubernetes).

Pourquoi CSI ?

Avant CSI, chaque type de stockage (AWS EBS, GCE PD, Ceph...) nécessitait du code dans le core Kubernetes. Avec CSI :

• Les drivers sont développés indépendamment de Kubernetes
• Les mises à jour de drivers n'impactent pas le cycle de release Kubernetes
• N'importe quel vendor peut créer un driver CSI

Deux sorts différents pour les anciens plugins in-tree

Tous les anciens types de stockage in-tree sont dépréciés, mais ils ne subissent pas le même sort, et la nuance change ce que vous avez à faire.

La plupart sont redirigés. Un manifeste qui déclare encore awsElasticBlockStore, gcePersistentDisk, azureDisk, cinder ou vsphereVolume continue de fonctionner : Kubernetes appelle le driver CSI correspondant à votre place, à condition que ce driver soit installé. Vous avez donc du temps devant vous, mais pas l'éternité.

cephfs fait exception. Il n'est plus redirigé, il n'est plus supporté du tout, et l'API le dit sans détour : « the in-tree cephfs type is no longer supported ». Ici, passer au driver CSI n'est pas une bonne pratique à planifier, c'est une obligation dont dépend le démarrage de vos Pods.

Migration CSI

Kubernetes redirige automatiquement les appels aux plugins in-tree vers les drivers CSI correspondants. Le driver doit être installé : sans lui, la redirection n'a nulle part où aller.

Plugin in-tree (déprécié)	Driver CSI
awsElasticBlockStore	ebs.csi.aws.com
gcePersistentDisk	pd.csi.storage.gke.io
azureDisk	disk.csi.azure.com
cinder (OpenStack)	cinder.csi.openstack.org
vsphereVolume	csi.vsphere.vmware.com

Glissez pour voir

Architecture CSI

La chaîne se lit de gauche à droite : l'utilisateur crée un PVC, celui-ci désigne une StorageClass, qui indique quel driver contacter. Le driver dialogue ensuite avec le système de stockage pour créer le volume et le rendre disponible sur le nœud où le Pod est planifié.

Composants CSI

Un driver CSI se compose de plusieurs pods :

Composant	Rôle	Déploiement typique
Controller	Provisionne/supprime les volumes	Deployment dans kube-system
Node	Monte/démonte les volumes	DaemonSet sur chaque nœud
CSI Sidecars	external-provisioner, external-attacher...	Avec le controller

Glissez pour voir

Une précision sur le Controller d'un driver CSI : il est déployé comme un Deployment ordinaire, en général dans kube-system. Ne croyez pas pour autant qu'il tourne « sur le control plane » : Kubernetes le planifie comme n'importe quel autre workload, et il peut parfaitement atterrir sur un worker.

Vérifier les drivers CSI

Un pilote absent de cette liste ne sera jamais utilisé, quelle que soit la StorageClass déclarée. La colonne ATTACHREQUIRED indique si le volume doit être rattaché au nœud avant montage : c'est le cas des disques bloc, pas des partages réseau.

# Lister les CSI Drivers installés
kubectl get csidrivers

NAME                    ATTACHREQUIRED   PODINFOONMOUNT   ...
ebs.csi.aws.com         true             false
efs.csi.aws.com         false            false

Sur un cluster de lab, attendez-vous à une liste vide. Kind répond No resources found, et ce n'est pas une panne : son provisionneur rancher.io/local-path fournit bien du stockage, mais ce n'est pas un driver CSI. Vous le verrez dans kubectl get storageclass, pas ici. La distinction est justement ce que cette section enseigne : une StorageClass nomme un provisionneur, qui n'est pas forcément CSI.

# Détails d'un driver
kubectl describe csidriver ebs.csi.aws.com

StorageClass CSI

Le champ provisioner fait le lien avec le pilote CSI, les parameters étant propres à chaque fournisseur. Deux options méritent d'être connues : volumeBindingMode: WaitForFirstConsumer retarde la création du volume jusqu'à ce qu'un Pod soit planifié, ce qui évite de provisionner un disque dans la mauvaise zone ; allowVolumeExpansion autorise l'agrandissement d'un volume existant.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Diagnostic CSI

Un PVC qui reste en Pending ne dit pas pourquoi : la raison se trouve dans ses événements ou dans les logs du sidecar csi-provisioner, qui est le composant chargé de traduire la demande en appel au fournisseur de stockage.

# Vérifier les pods CSI
kubectl get pods -n kube-system | grep csi

# Logs du controller CSI
kubectl logs -n kube-system -l app=ebs-csi-controller -c csi-provisioner

# Vérifier les PV créés via CSI
kubectl get pv -o custom-columns=NAME:.metadata.name,DRIVER:.spec.csi.driver

# Événements de PVC
kubectl describe pvc <pvc-name>

Tableau comparatif

La ligne la plus utile est « Appelé par » : elle explique pourquoi une panne CRI bloque tout le nœud, alors qu'une panne CSI n'affecte que les Pods qui réclament un volume. Retenez aussi l'emplacement de la configuration : c'est la première chose à vérifier en dépannage.

Aspect	CRI	CNI	CSI
Rôle	Exécuter les conteneurs	Configurer le réseau	Provisionner le stockage
Appelé par	kubelet	Container runtime	kubelet + sidecars + controller
Config	Socket runtime	/etc/cni/net.d/	StorageClass
Exemples	containerd, CRI-O	Calico, Cilium	AWS EBS, Ceph
Diagnostic	crictl	kubectl get pods -n kube-system	kubectl get csidrivers

Glissez pour voir

Où regarder quand ça casse

Les trois interfaces échouent à des moments différents du cycle de vie d'un Pod, et c'est ce qui permet de les départager sans rien deviner. Un problème CRI frappe le plus tôt : le conteneur n'est jamais lancé. Un problème CNI laisse le conteneur démarrer mais le Pod reste sans adresse. Un problème CSI arrive encore plus tard : le Pod est planifié, son volume ne se monte pas. Le moment de la panne désigne donc l'interface, avant même de lire le moindre message.

Problèmes CRI (runtime)

Symptômes : kubelet ne lance pas les Pods, erreurs "container runtime is down"

# Vérifier que le socket existe
ls -la /run/containerd/containerd.sock

# Vérifier l'état du service
systemctl status containerd
journalctl -u containerd -n 50

# Tester la connexion
crictl info

Problèmes CNI (réseau)

Symptômes : Pods bloqués en ContainerCreating, pas d'IP assignée

# Vérifier qu'un plugin CNI est installé
ls /etc/cni/net.d/
ls /opt/cni/bin/

# Vérifier les Pods CNI
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel'

# Logs du plugin CNI
kubectl logs -n kube-system -l k8s-app=calico-node

Problèmes CSI (stockage)

Symptômes : PVC en Pending, volume qui ne se monte pas

# Vérifier le driver CSI
kubectl get csidrivers

# Vérifier les événements du PVC
kubectl describe pvc <name>

# Logs du controller CSI
kubectl logs -n kube-system -l app=ebs-csi-controller -c csi-provisioner

Commandes CKA essentielles

Ce bloc regroupe les commandes à connaître pour l'examen, classées par interface. Les deux premières de chaque groupe suffisent généralement à identifier le composant fautif ; les suivantes servent à confirmer l'hypothèse.

# === CRI ===
# Vérifier le runtime
kubectl get nodes -o wide
crictl info
crictl ps

# === CNI ===
# Voir le plugin CNI
ls /etc/cni/net.d/
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel'

# Voir les CIDR par nœud
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

# === CSI ===
# Lister les drivers CSI
kubectl get csidrivers

# Vérifier les StorageClasses
kubectl get storageclasses

# Debug un PVC bloqué
kubectl describe pvc <name>

À retenir

1. CRI = interface kubelet ↔ container runtime (containerd, CRI-O)
2. CNI = interface pour configurer le réseau des Pods
3. CSI = interface pour provisionner du stockage externe
4. Les plugins in-tree sont dépréciés, utilisez CSI pour le stockage
5. crictl pour diagnostiquer le runtime
6. Config CNI dans /etc/cni/net.d/, binaires dans /opt/cni/bin/
7. StorageClass définit quel driver CSI utiliser

Testez vos connaissances

Dix questions pour vérifier que vous savez attribuer chaque symptôme à la bonne interface, un réflexe directement évalué par le domaine Cluster Architecture de la CKA.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Haute disponibilité du control plane : Ce que devient le choix du CNI quand le plan de contrôle est réparti sur plusieurs nœuds.
• Alternative : Talos Linux : Un système qui impose ses propres choix d'interfaces, utile pour mesurer ce que kubeadm vous laisse décider.
• Diagnostiquer une panne du cluster : Le diagnostic des pannes qui remontent à un plugin CNI ou CSI défaillant.

×

📖 Voir la documentation →