Kubernetes 053 – CNI : LibCNI et plugin kube-router

TL;DR

LibCNI est la bibliotheque Go qui permet a des runtimes d’appeler des plugins CNI selon la specification. Des plugins comme kube-router fournissent ensuite une implementation concrete du reseau pod, avec routage, service proxying selon les modes et parfois NetworkPolicy.

La video de reference

Video: https://www.youtube.com/watch?v=nyXMeiRjCB4

L’episode relie la specification CNI, son implementation et un plugin utilisable dans Kubernetes.

CNI spec vs LibCNI

La specification CNI decrit le contrat: format de configuration, commandes, entrees, sorties et comportement attendu.

LibCNI est une implementation qui aide a charger les configurations et appeler les binaires plugins.

Cela evite a chaque runtime de reimplementer toute la logique d’appel.

Cycle ADD et DEL

Quand un pod demarre, le runtime appelle le plugin avec ADD. Quand le pod disparait, il appelle DEL.

Le plugin doit alors:

• creer ou configurer les interfaces;
• attribuer ou liberer une IP;
• installer des routes;
• nettoyer correctement a la suppression.

Un mauvais nettoyage produit des interfaces ou allocations IP orphelines.

Exemple de chainage

CNI permet de chainer plusieurs plugins:

{
  "cniVersion": "1.0.0",
  "name": "podnet",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipam": {
        "type": "host-local",
        "subnet": "10.244.1.0/24"
      }
    },
    {
      "type": "portmap",
      "capabilities": { "portMappings": true }
    }
  ]
}

Le chainage permet d’ajouter des fonctions comme le port mapping apres la creation de l’interface.

kube-router en bref

kube-router est un composant reseau Kubernetes qui peut fournir du routage pod, du service proxying et des NetworkPolicies selon la configuration.

Il illustre une approche orientee routage, souvent avec BGP, plutot qu’un overlay systematique.

Installation de principe

Dans Kubernetes, un plugin comme kube-router est generalement installe via un manifest:

kubectl apply -f https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter.yaml
kubectl -n kube-system get pods -l k8s-app=kube-router
kubectl get nodes

Il faut toujours verifier la documentation du projet et la compatibilite avec la version Kubernetes.

Observer cote noeud

ls /etc/cni/net.d
ls /opt/cni/bin
ip route
ip addr
kubectl -n kube-system logs -l k8s-app=kube-router

Ces commandes montrent les traces concretes de l’installation CNI.

CNI et NetworkPolicy

Toutes les solutions CNI ne gerent pas les NetworkPolicies. C’est un point important: creer une NetworkPolicy ne suffit pas si le plugin ne l’applique pas.

Avec un plugin compatible, les politiques deviennent une brique de securite reseau entre pods.

Interaction avec kube-proxy

Certains plugins peuvent remplacer ou completer kube-proxy. Il faut eviter d’activer deux composants qui gerent les Services de maniere incompatible.

Lire les options du plugin est indispensable avant de modifier kube-proxy.

Liens utiles

• Video: https://www.youtube.com/watch?v=nyXMeiRjCB4
• 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
• kube-router: https://github.com/cloudnativelabs/kube-router

FAQ

LibCNI est-elle un plugin ?

Non. C’est une bibliotheque qui aide a appeler les plugins.

kube-router est-il le seul CNI possible ?

Non. Il existe de nombreux plugins, avec des philosophies differentes.

Pourquoi regarder les routes Linux ?

Parce que beaucoup de problemes CNI se voient directement dans les routes, interfaces et logs du noeud.

Erreurs frequentes

• Installer deux plugins CNI en meme temps.
• Croire qu’une NetworkPolicy est appliquee par tous les CNI.
• Ne pas nettoyer les anciennes configurations CNI.
• Ignorer les logs du DaemonSet reseau.

Pour pratiquer

Installez un plugin CNI dans un lab, observez /etc/cni/net.d, deployez deux pods sur deux noeuds, puis suivez les routes utilisees pour leur communication.

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 054 – IPVS vs iptables : pourquoi et configuration.

Conclusion

LibCNI et les plugins comme kube-router montrent que le reseau Kubernetes est un assemblage de contrats, binaires et configurations. Comprendre ces couches rend le debug beaucoup plus concret.