Kubernetes 022 – Services : kube-proxy, modes et iptables

TL;DR

Un Service n’est pas un processus applicatif classique. kube-proxy observe les Services et endpoints, puis configure le noeud pour router le trafic. Selon les clusters, cela peut passer par iptables, IPVS ou d’autres mecanismes.

La video de reference

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

Elle va un peu plus loin dans la mecanique interne des Services.

Le role de kube-proxy

kube-proxy tourne sur les noeuds. Il regarde l’API Kubernetes pour connaitre les Services et leurs endpoints. Il met ensuite en place les regles qui permettent a une ClusterIP de rediriger vers des pods.

Cela explique pourquoi la ClusterIP n’est pas simplement l’IP d’un pod.

Mode iptables

En mode iptables, kube-proxy programme des chaines NAT. Quand un paquet vise la ClusterIP et le port du Service, des regles redirigent vers un endpoint.

Le detail exact peut etre dense, mais l’idee principale suffit: les regles du noeud implementent l’abstraction Service.

Mode IPVS

IPVS utilise les mecanismes de load balancing du noyau Linux. Il peut etre plus adapte a certains environnements a grande echelle, mais le principe reste le meme: Service virtuel vers endpoints reels.

Observer sans tout casser

kubectl get svc
kubectl get endpoints
kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system ds/kube-proxy

Sur un noeud de lab, on peut inspecter les regles, mais il faut eviter de les modifier a la main.

Service, endpoints et readiness

Les endpoints disponibles dependent aussi de l’etat des pods. Un pod non pret ne doit pas recevoir de trafic de Service classique.

kubectl describe pod <pod>
kubectl describe endpoints <service>

Liens utiles

• Video: https://www.youtube.com/watch?v=SZ65IzcUniM
• Services: https://kubernetes.io/docs/concepts/services-networking/service/
• Virtual IPs and service proxies: https://kubernetes.io/docs/reference/networking/virtual-ips/
• kube-proxy: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/

FAQ

kube-proxy est-il obligatoire ?

Il est tres courant, mais certaines solutions CNI ou eBPF peuvent remplacer une partie de son role.

Peut-on modifier les regles iptables a la main ?

Il ne faut pas. kube-proxy les reconcilie et vos changements seront fragiles.

Pourquoi mon Service marche sur un noeud et pas un autre ?

Il faut verifier kube-proxy, le CNI, les regles locales et la connectivite entre noeuds.

Erreurs frequentes

• Croire qu’un Service est un conteneur qui ecoute.
• Debugger uniquement l’application sans regarder endpoints et kube-proxy.
• Modifier iptables manuellement sur un noeud.
• Oublier que le CNI joue aussi un role majeur.

Pour pratiquer

kubectl create deployment web --image=nginx
kubectl expose deployment web --port=80
kubectl get svc,endpoints
kubectl logs -n kube-system ds/kube-proxy --tail=50

L’objectif n’est pas de memoriser toutes les regles, mais de comprendre ou se situe la couche de redirection.

Suivre le chemin d’un paquet

Pour comprendre un Service, il faut suivre le trajet logique d’un paquet. Un client vise une ClusterIP et un port. Le paquet arrive sur un noeud. Les regles programmees par kube-proxy reconnaissent cette destination virtuelle et choisissent un endpoint reel, c’est-a-dire une IP de pod et un port cible.

Cette redirection peut donner l’impression qu’un Service est une machine ou un proxy central. Ce n’est pas le bon modele mental. Un Service est un objet d’API qui decrit une abstraction stable. kube-proxy et le reseau du cluster implementent cette abstraction sur les noeuds.

Verifier les endpoints avant kube-proxy

Avant d’aller inspecter iptables ou IPVS, il faut commencer plus simplement:

kubectl get svc web
kubectl get endpoints web
kubectl get pods -l app=web -o wide

Si le Service n’a pas d’endpoints, kube-proxy ne peut pas inventer une destination. Le probleme vient alors souvent des labels, du selector du Service ou de la readiness des pods.

Quand aller voir plus bas

L’inspection de kube-proxy devient pertinente quand les objets Kubernetes semblent corrects mais que le trafic ne passe pas. On regarde alors les logs de kube-proxy, l’etat du CNI, les routes, les policies reseau et les regles locales du noeud.

Cette couche est plus avancee. En formation, l’objectif est surtout de comprendre que Kubernetes s’appuie sur Linux et sur le reseau du cluster. Les objets Kubernetes donnent une API lisible, mais leur effet final repose sur des mecanismes concrets.

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 poursuivre la progression, consultez aussi Kubernetes 023 – Lab Dockercoin : transformer un Docker Compose.

Conclusion

Comprendre kube-proxy aide a depasser la vision magique des Services. Kubernetes expose une API simple, mais le reseau repose sur des mecanismes concrets dans les noeuds.