1. Concepts de base à connaître
- Service Kubernetes : Abstraction qui permet d’exposer un ensemble de pods (appli web, backend, etc.) derrière une IP virtuelle appelée ClusterIP. Cette IP est uniquement accessible à l’intérieur du cluster.
- Endpoint : Objet qui contient toutes les adresses IP et ports des pods associés à un Service. C’est la liaison réelle entre le Service et ses pods cibles.
À retenir :
- On ne peut pas ping une ClusterIP : elle n’est utilisée que pour la découverte de service et le routage interne, pas pour l’accès direct.
2. Rôle de kube-proxy
Fonction essentielle du kube-proxy:
- Daemon qui tourne sur chaque nœud du cluster (sous forme de DaemonSet).
- Gère la partie “proxy” : il implémente le fonctionnement des Services Kubernetes en créant des règles réseau qui acheminent le trafic vers les pods derrière un Service (équilibrage de charge inclus).
- Fonctionne pour les protocoles TCP, UDP, SCTP, mais pas au niveau HTTP (ce n’est pas un reverse proxy type nginx).
Résumé caricatural
Kube-proxy = répartiteur de trafic réseau interne pour tous les services Kubernetes, sur tous les nœuds du cluster.
3. Modes de fonctionnement de kube-proxy
Kube-proxy maintient les règles réseau via trois modes principaux :
| Mode | Explication | Usage / Notes |
|---|---|---|
| IPTables | Par défaut : génère des règles iptables qui capturent le trafic vers une ClusterIP et le redirigent vers les pods. | Simple, robuste, mais peut devenir lent si beaucoup de services/règles. |
| NFTables | Nouvelle génération (mode bêta), vise à offrir de meilleures performances et scalabilité que iptables. | Adapté aux très grands clusters, remplace progressivement iptables. |
| IPVS | Basé sur IP Virtual Server : offre un load balancing performant avec plusieurs algorithmes de choix des pods. | Préféré pour >1,000 services ; supporte round robin, least connection, etc. |
| Userspace | Ancien mode, très lent, déconseillé aujourd’hui. | Pour mémoire/histoire seulement. |
| Kernelspace | Réservé à Windows nodes. | Peu utilisé sur Linux. |
Algorithmes IPVS principaux
- rr : Round Robin (par défaut)
- lc : Least connection
- dh/sh : Hashing (destination/source)
- sed/nq : Délai minimal / ne jamais mettre en queue
4. Schéma du fonctionnement de kube-proxy
| Étape | Description |
|---|---|
| 1 | Récupère la config des Services/Endpoints via l’API server |
| 2 | Surveille les changements (nouveau pod, nouveau service, etc.) |
| 3 | Met à jour dynamiquement les règles réseau locales (selon le mode) |
| 4 | Acheminer le trafic réçu sur la ClusterIP vers un pod cible (endpoint) |
Illustration notionnelle
Exemple :
- Un client veut contacter un Service via la ClusterIP (par exemple, front-end).
- kube-proxy redirige le trafic vers l’une des IPs réelles des pods associés, en faisant du load balancing.
5. Points clefs et clarification
- kube-proxy ne comprend pas le protocole applicatif : il s’arrête au niveau réseau (couche 4).
- Il ne fait pas office de reverse proxy HTTP (nginx, HAproxy… : ce rôle est tenu par l’Ingress Controller dans Kubernetes).
- Il est indispensable à l’interconnexion réseau interne des services pods → pods et services → pods.
- On peut aussi utiliser des solutions alternatives à kube-proxy, comme Cilium, qui suppriment le besoin de proxy par iptables/ipvs via une implémentation eBPF.
- Tous les nœuds d’un cluster exécutent une instance de kube-proxy : la configuration est donc auto-répliquée dès qu’un service ou un endpoint change.
6. Résumé de kube-proxy
| Élément | Explication courte |
|---|---|
| Rôle | Acheminer et équilibrer le trafic réseau vers les pods derrière un Service (ClusterIP) |
| Emplacement | S’exécute sur chaque nœud Linux/Windows du cluster (DaemonSet) |
| Fonctionnement principal | Crée & met à jour dynamiquement les règles réseau pour chaque service/endpoint |
| Modes | iptables (par défaut), nftables (beta), IPVS (performance), userspace (legacy), kernelspace (Windows) |
| Prise en charge protocole | UDP, TCP, SCTP (couche 4 uniquement) |
| Spécificité | Ne comprend pas HTTP ; gestion fine du load balancing au niveau IP/port |
| Alternatives possibles | Solutions eBPF comme Cilium qui peuvent remplacer totalement kube-proxy |
| Spécificités cluster large | IPVS/nftables recommandés pour les très gros clusters (>1,000 services) |
En résumé :
kube-proxy agit comme un gestionnaire de trafic automatique, invisible mais capital, qui assure que chaque Service Kubernetes route correctement le trafic vers ses pods, avec équilibrage de charge—et ce, de façon totalement transparente pour l’utilisateur ou les applications.
Scénario : Exposer une application web interne
Imaginons que vous déployez une application web (par exemple, un service front-end Nginx) dans un cluster Kubernetes, et que vous souhaitez que d’autres applications internes puissent y accéder facilement, sans connaître l’IP de chaque pod.
- Déploiement du service
-
Vous créez un Deployment Kubernetes contenant plusieurs pods Nginx.
-
Ensuite, vous créez un Service de type
ClusterIPpour exposer ces pods :textapiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP
- Rôle du Service et des Endpoints
- Le Service reçoit une ClusterIP (ex. 10.96.25.100), utilisable par toutes les applications du cluster.
- Le contrôleur Endpoints référence dynamiquement toutes les IPs des pods du déploiement (
nginx-xyz) associés au Service.
3. Intervention de kube-proxy
- Sur chaque nœud du cluster, kube-proxy configure des règles réseau locales (par défaut avec iptables) :
- Si une application tente d’accéder à l’IP 10.96.25.100:80 (ClusterIP), le trafic est intercepté par cette règle.
- kube-proxy sélectionne alors de façon transparente l’IP d’un des pods “Nginx” pour faire transiter la requête (load balancing).
4. Conséquence pratique
Pour le développeur ou l’application cliente :
- Il suffit d’utiliser le nom DNS du service (
nginx-service) ou directement son ClusterIP, sans jamais se soucier des adresses IP réelles des pods (qui peuvent changer lors d’un redémarrage). - Si un pod Nginx meurt ou est remplacé, kube-proxy ajuste automatiquement les règles pour retirer l’IP obsolète et ajouter la nouvelle, sans aucune coupure.
5. Schéma simplifié
| Action | Composant intervenant |
|---|---|
| Déploiement de pods Nginx | Deployment/Pods |
| Création d’un Service de type ClusterIP | Service/Endpoints |
| Ajustement auto des règles réseau | kube-proxy sur chaque nœud |
| Répartition du trafic entre pods Nginx | kube-proxy (load balancing IP) |
Résumé
Grâce à kube-proxy :
- Tous les flux entrants à destination de l’IP virtuelle du Service sont transparents pour les applications.
- Le routage, la tolérance aux pannes et la mise à l’échelle des pods sont automatisés : la connectivité reste toujours opérationnelle, quelle que soit la mobilité des pods dans le cluster.