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

┌─────────────────────────────────────────────────────────────────────────┐
│                              KUBERNETES                                  │
│                                                                          │
│  ┌─────────────────────────────────────────────────────────────────┐   │
│  │                           kubelet                                │   │
│  └───────────┬─────────────────────┬─────────────────────┬─────────┘   │
│              │                     │                     │              │
│              ▼                     ▼                     ▼              │
│       ┌──────────┐          ┌──────────┐          ┌──────────┐         │
│       │   CRI    │          │   CNI    │          │   CSI    │         │
│       │ Runtime  │          │  Réseau  │          │ Stockage │         │
│       └────┬─────┘          └────┬─────┘          └────┬─────┘         │
│            │                     │                     │                │
└────────────┼─────────────────────┼─────────────────────┼────────────────┘
             │                     │                     │
             ▼                     ▼                     ▼
      ┌────────────┐        ┌────────────┐        ┌────────────┐
      │ containerd │        │   Calico   │        │  AWS EBS   │
      │   CRI-O    │        │   Cilium   │        │  Ceph CSI  │
      │    etc.    │        │  Flannel   │        │  NFS CSI   │
      └────────────┘        └────────────┘        └────────────┘

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 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

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é

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

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

# 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

# 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

crictl

crictl est l’outil de diagnostic standard pour les runtimes CRI. Il est fréquemment présent sur les environnements d’administration Kubernetes et permet de diagnostiquer les problèmes de runtime sans passer par kubectl.

CNI — Container Network Interface

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

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

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.

Spec CNI

Kubernetes recommande les plugins compatibles avec la spec CNI v1.0.0. Les plugins conformes à la v0.4.0 ou supérieure fonctionnent aussi.

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

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/

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

Diagnostic CNI

# Vérifier le plugin CNI installé
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|weave'

# 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

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

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

Plugins in-tree en cours de retrait

Kubernetes retire progressivement les anciens drivers de stockage in-tree au profit de CSI. En 1.35, plusieurs types historiques comme cephfs ou azureDisk ne sont plus inclus. Utilisez les drivers CSI correspondants.

Migration CSI

Kubernetes redirige automatiquement les appels aux plugins in-tree vers les drivers CSI correspondants :

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

┌─────────────────────────────────────────────────────────────────┐
│                        Kubernetes                                │
│                                                                  │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐       │
│  │ PVC          │───▶│ StorageClass │───▶│ CSI Driver   │       │
│  │ (claim)      │    │ (provisioner)│    │ (controller) │       │
│  └──────────────┘    └──────────────┘    └──────┬───────┘       │
│                                                  │               │
└──────────────────────────────────────────────────┼───────────────┘
                                                   │
                                                   ▼
                                          ┌──────────────┐
                                          │   Stockage   │
                                          │   externe    │
                                          └──────────────┘

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

Controller placement

Le composant Controller d’un driver CSI est généralement déployé comme un Deployment dans kube-system. Il ne tourne pas nécessairement “sur le control plane” — Kubernetes le schedule comme n’importe quel autre workload.

Vérifier les drivers CSI

# Lister les CSI Drivers installés
kubectl get csidrivers

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

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

StorageClass CSI

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

# 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

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

Structurez votre diagnostic par interface :

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

# === 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

Prochaines étapes

Pod Networking Comprendre la communication réseau entre Pods

Storage Volumes, PV et PVC dans Kubernetes

Troubleshooting Diagnostiquer les problèmes de cluster

Architecture Architecture complète de Kubernetes

×

📖 Voir la documentation →