Kubernetes 054 – IPVS vs iptables : pourquoi et configuration

TL;DR

kube-proxy implemente la partie Service du reseau Kubernetes. En mode iptables, il programme des regles NAT. En mode IPVS, il utilise le load balancing du kernel Linux via IP Virtual Server. IPVS peut etre plus adapte a un grand nombre de Services, mais demande des modules kernel et une configuration correcte.

La video de reference

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

Elle termine cette sequence reseau en comparant deux modes importants de kube-proxy.

Rappel sur les Services

Un Service Kubernetes donne une IP virtuelle stable et un nom DNS devant un ensemble de pods. Quand un client contacte le Service, le trafic doit etre envoye vers un endpoint reel.

kube-proxy est un des composants qui rendent cette redirection possible.

Mode iptables

En mode iptables, kube-proxy cree des chaines et regles NAT. C’est robuste et largement utilise.

On peut observer les regles avec:

sudo iptables-save | grep KUBE-SVC
sudo iptables-save | grep KUBE-SEP

Les chaines KUBE-SVC representent des Services, les chaines KUBE-SEP des endpoints.

Mode IPVS

IPVS est une fonctionnalite du kernel Linux pour faire du load balancing L4. kube-proxy programme des virtual servers et real servers.

On observe l’etat avec:

sudo ipvsadm -Ln

Chaque Service apparait comme un virtual server avec des backends.

Pourquoi IPVS ?

IPVS peut offrir de meilleures performances ou une meilleure scalabilite dans des clusters avec beaucoup de Services. Il propose aussi plusieurs algorithmes de scheduling, comme round robin ou least connection.

Cela ne signifie pas qu’iptables est mauvais. Pour beaucoup de clusters, iptables fonctionne tres bien.

Modules kernel

Pour IPVS, il faut charger des modules:

sudo modprobe ip_vs
sudo modprobe ip_vs_rr
sudo modprobe ip_vs_wrr
sudo modprobe ip_vs_sh
sudo modprobe nf_conntrack

Pour les rendre persistants, on peut utiliser /etc/modules-load.d/ selon la distribution.

Configurer kube-proxy

La configuration de kube-proxy est stockee dans une ConfigMap:

kubectl -n kube-system get configmap kube-proxy -o yaml

On y trouve un champ de mode:

mode: "ipvs"
ipvs:
  scheduler: "rr"

Apres modification, il faut redemarrer les pods kube-proxy.

Redemarrer kube-proxy

kubectl -n kube-system rollout restart daemonset kube-proxy
kubectl -n kube-system rollout status daemonset kube-proxy
kubectl -n kube-system logs -l k8s-app=kube-proxy

Les logs indiquent souvent le mode utilise et les erreurs de modules manquants.

Verifier le mode

kubectl -n kube-system logs -l k8s-app=kube-proxy | grep -i ipvs
sudo ipvsadm -Ln
sudo iptables-save | grep KUBE

Meme en mode IPVS, certaines regles iptables peuvent rester necessaires pour du marquage, du masquerading ou d’autres fonctions.

Exemple de Service de test

kubectl create deployment web --image=nginx --replicas=3
kubectl expose deployment web --port=80 --target-port=80
kubectl get svc,endpoints web
curl http://$(kubectl get svc web -o jsonpath='{.spec.clusterIP}')

Depuis un pod de debug, on peut tester le ClusterIP et observer IPVS sur le noeud.

Liens utiles

• Video: https://www.youtube.com/watch?v=5f3c0UPyZ0k
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Services Kubernetes: https://kubernetes.io/docs/concepts/services-networking/service/
• kube-proxy: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/

FAQ

IPVS remplace-t-il CNI ?

Non. IPVS concerne principalement la logique Services via kube-proxy. CNI configure le reseau des pods.

Faut-il toujours passer en IPVS ?

Non. Il faut une raison: volumetrie, performance, standard interne ou apprentissage.

Pourquoi voir encore iptables en mode IPVS ?

Parce que kube-proxy peut encore utiliser iptables pour certaines fonctions complementaires.

Erreurs frequentes

• Oublier les modules kernel IPVS.
• Modifier la ConfigMap sans redemarrer kube-proxy.
• Croire que IPVS corrige un CNI mal configure.
• Ne pas verifier les logs kube-proxy.

Pour pratiquer

Passez un lab kubeadm de iptables a IPVS, creez un Service nginx, puis comparez iptables-save et ipvsadm -Ln avant et apres.

Notions et definitions

• Service: point d’entree stable devant un ensemble de pods.
• Endpoint ou EndpointSlice: liste des backends reels selectionnes par le Service.
• kube-proxy: composant qui programme les regles reseau necessaires sur chaque noeud.

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 web expose par un Service web-svc permet a un client de viser une IP stable, meme si les pods web sont recrees avec de nouvelles adresses IP.

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

• Creer un Deployment avec un label clair, par exemple app=web.
• Creer un Service dont le selecteur cible ce label.
• Verifier que les endpoints apparaissent et correspondent aux pods attendus.
• Tester depuis un pod de debug plutot que depuis uniquement votre machine locale.

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 chemin reseau complet entre un client, un Service, kube-proxy et les pods cibles. 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 svc,endpoints,endpointslices -o wide
• kubectl describe svc <service> pour verifier le selecteur, les ports et les endpoints
• kubectl logs -n kube-system -l k8s-app=kube-proxy pour confirmer le mode et les erreurs reseau

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

• confondre Service, Pod IP et endpoint reel
• oublier qu’un Service sans endpoint ne peut pas router de trafic applicatif
• diagnostiquer le CNI alors que le probleme vient du selecteur ou du port du Service

Exercice conseille

Creez deux Deployments nginx avec des labels differents, exposez-en un avec un Service, puis modifiez volontairement le selecteur pour observer la disparition des endpoints.

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 revenir au sujet precedent, consultez aussi Kubernetes 053 – CNI : LibCNI et plugin kube-router.

Conclusion

iptables et IPVS sont deux manieres de materialiser les Services Kubernetes cote noeud. Comprendre leur role clarifie la frontiere entre CNI, kube-proxy et le kernel Linux.