Kubernetes 051 – CNI : installer des network namespaces

TL;DR

Un pod Kubernetes repose sur des primitives Linux comme les network namespaces, les interfaces virtuelles veth, les routes et parfois les bridges. CNI automatise ces manipulations. Les reproduire a la main aide a comprendre ce qu’un plugin reseau fait pour chaque pod.

La video de reference

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

Elle descend sous Kubernetes pour expliquer les bases reseau qui rendent CNI possible.

Qu’est-ce qu’un network namespace ?

Un network namespace isole une pile reseau: interfaces, routes, tables ARP, iptables, ports. Deux namespaces peuvent avoir chacun une interface lo, des IP et des routes differentes.

Un conteneur utilise ce mecanisme pour avoir son propre reseau tout en partageant le kernel.

Creer un namespace

sudo ip netns add ns1
sudo ip netns list
sudo ip netns exec ns1 ip addr

Au depart, le namespace est vide sauf loopback, souvent down.

Activer loopback

sudo ip netns exec ns1 ip link set lo up
sudo ip netns exec ns1 ping -c 1 127.0.0.1

Cette etape rappelle que chaque namespace a sa propre pile reseau.

Creer une paire veth

Une paire veth agit comme un cable virtuel: ce qui entre d’un cote sort de l’autre.

sudo ip link add veth-host type veth peer name veth-ns
sudo ip link set veth-ns netns ns1

Un cote reste sur l’hote, l’autre entre dans le namespace.

Ajouter des adresses IP

sudo ip addr add 10.10.0.1/24 dev veth-host
sudo ip link set veth-host up

sudo ip netns exec ns1 ip addr add 10.10.0.2/24 dev veth-ns
sudo ip netns exec ns1 ip link set veth-ns up

Test:

ping -c 1 10.10.0.2
sudo ip netns exec ns1 ping -c 1 10.10.0.1

Ajouter une route par defaut

sudo ip netns exec ns1 ip route add default via 10.10.0.1
sudo ip netns exec ns1 ip route

Pour sortir vers Internet, il faut aussi du forwarding et souvent du NAT sur l’hote.

Activer le forwarding

sudo sysctl -w net.ipv4.ip_forward=1

Avec iptables ou nftables, on peut ensuite masquerader le trafic sortant selon l’interface externe.

Lien avec Kubernetes

Quand kubelet cree un pod, le runtime cree un sandbox. Le plugin CNI configure ensuite le reseau du pod: interface, IP, routes, DNS et connectivite selon le plugin.

Les commandes manuelles vues ici ressemblent aux actions automatisees par CNI.

Commandes utiles

ip netns list
ip link show
ip addr show
ip route show
sudo ip netns exec ns1 ip route
sudo ip netns delete ns1

Toujours nettoyer les namespaces de test pour eviter les confusions.

Liens utiles

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

FAQ

Un pod est-il un network namespace ?

Un pod utilise un network namespace partage par ses conteneurs.

Pourquoi une paire veth ?

Elle connecte le namespace du pod au reseau de l’hote ou a un bridge.

CNI cree-t-il les namespaces ?

Generalement le runtime cree le namespace, puis CNI le configure.

Erreurs frequentes

• Oublier d’activer l’interface loopback.
• Mettre les deux extremites veth dans le meme namespace par erreur.
• Oublier les routes.
• Confondre connectivite locale et sortie Internet.

Pour pratiquer

Creez deux namespaces, connectez-les via un bridge Linux, attribuez des IP, puis testez un ping entre eux. Comparez ensuite avec deux pods Kubernetes.

Notions et definitions

• CNI: specification et plugins permettant de brancher un pod au reseau.
• Network namespace: isolation Linux qui donne au pod sa propre pile reseau.
• Pod IP: adresse attribuee au pod et routable selon le plugin utilise.

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

Quand un pod demarre, le kubelet appelle le plugin CNI pour creer les interfaces reseau, attribuer une IP et installer les routes necessaires.

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

• Observer les Pod IP sur plusieurs noeuds.
• Tester pod-to-pod, puis pod-to-service pour separer CNI et kube-proxy.
• Lire les logs du plugin CNI dans kube-system.
• Comparer l’etat Kubernetes avec les interfaces et routes visibles sur le noeud.

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 la creation du reseau des pods, les namespaces reseau Linux et le role exact du plugin CNI. 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 -A -o wide pour verifier les Pod IP
• ip netns et ip link sur un noeud de lab lorsque c’est pertinent
• kubectl -n kube-system logs du plugin CNI pour lire les erreurs de configuration

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

• attribuer a kube-proxy un probleme de connectivite pod-to-pod
• oublier que CNI intervient a la creation du pod
• melanger routage inter-noeuds, DNS et exposition de Services

Exercice conseille

Deployeez deux pods sur deux noeuds differents, testez la connectivite pod-to-pod, puis reliez le resultat aux routes et interfaces observees sur les noeuds.

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 052 – Container Network Interface : what is it ?.

Conclusion

Comprendre les network namespaces rend CNI beaucoup moins magique. Kubernetes automatise ces operations, mais les briques restent celles du reseau Linux.