Kubernetes 052 – Container Network Interface : what is it ?

TL;DR

CNI, Container Network Interface, definit comment un runtime appelle un plugin reseau pour ajouter ou supprimer la connectivite d’un conteneur ou pod. Dans Kubernetes, un plugin CNI attribue une IP au pod, configure les interfaces, les routes et la connectivite entre pods.

La video de reference

Video: https://www.youtube.com/watch?v=PJwzTWXF-k0

Elle pose les bases conceptuelles de CNI apres la manipulation des network namespaces.

Le probleme a resoudre

Kubernetes impose un modele reseau: les pods doivent pouvoir communiquer entre eux sans NAT, les noeuds doivent joindre les pods, et les Services doivent fonctionner au-dessus.

Mais Kubernetes ne fournit pas un seul reseau universel. Il delegue a des plugins CNI.

CNI en pratique

Un plugin CNI est un executable appele avec des variables d’environnement et une configuration JSON. Les commandes principales sont souvent ADD, DEL, CHECK et parfois VERSION.

Le runtime demande: ajoute le reseau a ce namespace. Le plugin repond avec une IP et les informations configurees.

Repertoires importants

Sur un noeud Kubernetes, on trouve souvent:

/etc/cni/net.d/
/opt/cni/bin/

Le premier contient les configurations. Le second contient les binaires des plugins.

Exemple de configuration CNI

{
  "cniVersion": "1.0.0",
  "name": "mynet",
  "type": "bridge",
  "bridge": "cni0",
  "isGateway": true,
  "ipMasq": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

Cette configuration demande un plugin bridge avec une gestion IP locale.

Role de l’IPAM

IPAM signifie IP Address Management. C’est la partie qui attribue une IP au pod et garde une trace des allocations.

Sans IPAM, le plugin ne saurait pas quelle IP donner a chaque namespace.

CNI et kubelet

Kubelet utilise le runtime CRI. Le runtime appelle CNI pour configurer le reseau du sandbox pod. Si CNI est absent ou mal configure, les pods restent souvent bloques en ContainerCreating.

Diagnostic:

kubectl describe pod <pod>
journalctl -u kubelet
ls /etc/cni/net.d
ls /opt/cni/bin

Plugins connus

On rencontre souvent:

• Flannel;
• Calico;
• Cilium;
• Weave Net;
• kube-router;
• les plugins reference CNI comme bridge, loopback, host-local.

Chaque plugin a ses choix: overlay, routage, BGP, eBPF, politiques reseau.

Installer un CNI Kubernetes

Dans un lab kubeadm, l’installation ressemble souvent a:

kubectl apply -f <manifest-du-plugin-cni.yaml>
kubectl get pods -n kube-system
kubectl get nodes

Le noeud passe Ready quand le reseau pod est operationnel.

Liens utiles

• Video: https://www.youtube.com/watch?v=PJwzTWXF-k0
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• CNI project: https://github.com/containernetworking/cni
• Networking Kubernetes: https://kubernetes.io/docs/concepts/cluster-administration/networking/

FAQ

Kubernetes fonctionne-t-il sans CNI ?

Pas correctement pour les pods. Le control plane peut demarrer, mais les noeuds restent souvent NotReady.

CNI gere-t-il les Services ?

Pas directement dans tous les cas. Les Services impliquent aussi kube-proxy ou un remplacement selon le plugin.

Peut-on changer de CNI ?

Oui, mais c’est une operation sensible qui impacte tout le reseau pod.

Erreurs frequentes

• Installer kubeadm puis oublier le CNI.
• Utiliser un pod CIDR incompatible avec le plugin.
• Supprimer /etc/cni/net.d sans redemarrer proprement les composants.
• Confondre CNI et kube-proxy.

Pour pratiquer

Sur un lab kubeadm, observez l’etat avant CNI, installez le plugin, puis comparez les fichiers crees dans /etc/cni/net.d et les pods systeme.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 053 – CNI : LibCNI et plugin kube-router.

Conclusion

CNI est le contrat entre Kubernetes et le reseau des pods. Le comprendre aide a diagnostiquer une grande partie des problemes NotReady et ContainerCreating.