Concepts avancés de Kube-Proxy expliqués avec des exemples pratiques

Introduction

Kube-proxy est un composant critique du réseau Kubernetes, mais son fonctionnement interne est souvent mal compris. Si l'utilisation de base peut sembler simple, le dépannage en production et l'optimisation des performances nécessitent une compréhension approfondie de ses mécanismes. Cet article propose une exploration pratique des concepts avancés de kube-proxy, avec des exemples concrets basés sur des commandes pour diagnostiquer les problèmes, configurer efficacement les modes et l'exploiter en toute sécurité.

Que vous soyez développeur cherchant à résoudre des problèmes de connectivité de service, ingénieur DevOps optimisant le réseau du cluster ou consultant technique conseillant des startups, ce guide vous aidera à passer de l'observation d'un problème à la vérification d'une solution. Nous explorerons l'architecture de kube-proxy, ses modes d'implémentation (iptables, IPVS et userspace), les détails de configuration et les métriques. Vous apprendrez à inspecter l'état actuel, à effectuer des modifications en toute sécurité et à récupérer après une défaillance.

Tout au long de cet article, nous mettons l'accent sur la sécurité opérationnelle : toujours observer avant de modifier, limiter le rayon d'impact, utiliser des valeurs fictives plutôt que de vrais secrets, vérifier les résultats et documenter les procédures de récupération.

Inventaire de la version et de l'environnement

Avant de plonger dans les détails de kube-proxy, établissez une image claire de votre environnement. Cela évite les attentes incompatibles et guide votre dépannage. Pour toute investigation sur kube-proxy, identifiez les éléments suivants :

• Composant : kube-proxy
• Plage de versions prises en charge : Kubernetes 1.20 à 1.29 (à adapter selon votre cluster)
• Prérequis : Un cluster Kubernetes en cours d'exécution avec accès kubectl et les autorisations appropriées pour consulter la configuration et les journaux de kube-proxy.
• Observation en lecture seule : Rassemblez l'état actuel à l'aide de commandes non intrusives.
• Modification la plus petite justifiée : N'apportez une modification que si nécessaire, et limitez sa portée.
• Vérification : Vérifiez toujours le résultat avec une commande ou un signal.

Observation de l'état actuel

Commencez par vérifier la version de kube-proxy et l'état des pods. Cela vous indique quelle implémentation est utilisée et si elle est saine.

kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide

Résultat attendu : une liste de pods kube-proxy, un par nœud, avec le statut Running et un faible nombre de redémarrages.

NAME               READY   STATUS    RESTARTS   AGE   IP              NODE
kube-proxy-abcde   1/1     Running   0          10d   192.168.1.10    node-1
kube-proxy-fghij   1/1     Running   0          10d   192.168.1.11    node-2

Pour voir la version exacte de kube-proxy, exécutez :

kubectl exec -n kube-system kube-proxy-abcde -- kube-proxy --version

Cela renvoie la chaîne de version, par exemple Kubernetes v1.28.0.

Déterminez le mode de proxy en consultant les journaux ou la configuration. Une méthode en lecture seule consiste à examiner la ConfigMap (si elle est utilisée).

kubectl describe configmap kube-proxy -n kube-system

Recherchez le champ mode sous config.conf ou kubeconfig.conf. Il peut être défini sur iptables, ipvs ou vide (par défaut, iptables). Sinon, inspectez les arguments du processus en cours d'exécution :

kubectl exec -n kube-system kube-proxy-abcde -- ps aux | grep kube-proxy

La ligne de commande inclut souvent --proxy-mode=ipvs ou similaire.

Comprendre la topologie de déploiement

Kube-proxy est généralement déployé sous forme de DaemonSet, garantissant une instance par nœud. Confirmez le DaemonSet :

kubectl get daemonset kube-proxy -n kube-system

Résultat attendu :

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
kube-proxy   3         3         3       3            3           <none>          30d

Si le nombre de pods prêts est inférieur à celui souhaité, identifiez le nœud défaillant et enquêtez. Utilisez des étiquettes pour filtrer :

kubectl get pods -n kube-system -l k8s-app=kube-proxy -o wide --field-selector spec.nodeName=node-2

Prérequis pour des modifications sécurisées

Avant d'apporter une modification de configuration, assurez-vous d'avoir :

• Une sauvegarde de la ConfigMap actuelle ou des paramètres.
• La possibilité de revenir en arrière (par exemple, en utilisant un contrôle de version pour les manifestes).
• La compréhension du rayon d'impact : une modification de kube-proxy affecte le réseau des services sur le ou les nœuds où il s'exécute, pouvant perturber le trafic.

Exemple de modification limitée : passer du mode iptables à ipvs s'applique à l'ensemble du cluster et nécessite une planification minutieuse. Commencez par un nœud de test si possible.

Chemin de configuration sécurisé

La configuration de kube-proxy se fait principalement via une ConfigMap nommée kube-proxy dans l'espace de noms kube-system, ou via des indicateurs de ligne de commande. Le changement de mode (par exemple, d'iptables à IPVS) nécessite de redémarrer kube-proxy et peut provoquer de brèves perturbations. Suivez ce chemin sécurisé :

Étape 1 : Capturer la configuration actuelle

Exportez la ConfigMap existante vers un fichier pour la sauvegarde.

kubectl get configmap kube-proxy -n kube-system -o yaml > kube-proxy-config-backup.yaml

Inspectez les paramètres clés :

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

Recherchez la section config.conf. Exemple :

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-proxy
  namespace: kube-system
data:
  config.conf: |-
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    mode: "iptables"
    iptables:
      masqueradeAll: false
      syncPeriod: 30s

Étape 2 : Planifier le changement

Supposons que vous souhaitiez passer à IPVS pour de meilleures performances avec de nombreux services. Vérifiez si les modules du noyau IPVS sont chargés sur tous les nœuds. Sur chaque nœud :

lsmod | grep ip_vs

Si les modules sont absents, vous devez les charger ou installer des paquets (par exemple, ipvsadm). C'est un prérequis.

Étape 3 : Modifier la ConfigMap

Utilisez kubectl edit pour modifier la ConfigMap. Changez mode en "ipvs".

kubectl edit configmap kube-proxy -n kube-system

Effectuez la modification et enregistrez. Notez que la ConfigMap seule ne déclenche pas de redémarrage ; les pods kube-proxy doivent être redémarrés pour prendre en compte les changements.

Étape 4 : Redémarrer Kube-Proxy

Redémarrez le DaemonSet en supprimant les pods (ils seront recréés). Cela peut provoquer une brève interruption de service pendant que les nouvelles règles sont programmées.

kubectl delete pods -n kube-system -l k8s-app=kube-proxy

Sinon, effectuez un redémarrage progressif :

kubectl rollout restart daemonset kube-proxy -n kube-system

Étape 5 : Vérifier le changement

Vérifiez que les pods sont en cours d'exécution et que le mode est actif.

kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=10 | grep "Using ipvs Proxier"

Ligne de journal attendue : I0125 10:00:00.000000 1 server.go:650] Using ipvs Proxier.

Vérifiez également que les règles IPVS sont créées sur un nœud :

ipvsadm -Ln

Vous devriez voir des entrées pour les services Kubernetes.

Chemin de récupération

Si le changement cause des problèmes (par exemple, services inaccessibles), rétablissez la ConfigMap à partir de la sauvegarde et redémarrez kube-proxy à nouveau.

kubectl apply -f kube-proxy-config-backup.yaml
kubectl rollout restart daemonset kube-proxy -n kube-system

Architecture et internes de Kube-Proxy

Pour vraiment maîtriser kube-proxy, comprenez son architecture de base et comment il implémente les abstractions de service.

Rôle dans le réseau Kubernetes

Kube-proxy s'exécute sur chaque nœud et maintient des règles réseau qui permettent au trafic d'atteindre les services. Il surveille l'API Kubernetes pour les services et les EndpointSlices (ou Endpoints) et met à jour la configuration réseau du nœud en conséquence. L'objectif est de fournir une IP virtuelle stable (ClusterIP) et, si nécessaire, un équilibrage de charge entre les pods backend.

Il existe trois modes d'implémentation principaux :

• userspace : Le mode le plus ancien, transfère le trafic via le processus kube-proxy en espace utilisateur. Latence élevée, rarement utilisé.
• iptables : Par défaut sur la plupart des clusters. Utilise des règles iptables pour rediriger le trafic vers les pods backend. Efficace à échelle modérée, mais les règles croissent linéairement avec les services et les endpoints.
• IPVS : Utilise le serveur virtuel IP de Linux pour l'équilibrage de charge. Meilleures performances et plus d'algorithmes d'équilibrage. Recommandé pour les grands clusters.

Types de services et flux de trafic

Kube-proxy gère différents types de services :

• ClusterIP : Expose le service en interne. Kube-proxy programme des règles pour DNAT le trafic de la ClusterIP vers les IP des pods.
• NodePort : Ouvre un port statique sur chaque nœud. Kube-proxy ajoute des règles pour transférer le trafic de ce port vers le service.
• LoadBalancer : Utilise souvent NodePort en dessous ; kube-proxy garantit que le trafic depuis l'équilibreur de charge est acheminé vers les backends.
• ExternalName : Aucune implication de kube-proxy ; renvoie un CNAME.

Plongée dans le mode IPTables

En mode iptables, kube-proxy crée des chaînes pour les services. Pour chaque service, il y a une chaîne comme KUBE-SVC-XXXX et pour les endpoints KUBE-SEP-XXXX. Il utilise le module statistic pour un équilibrage de charge basé sur la probabilité (sélection aléatoire). Les règles sont régénérées toutes les syncPeriod (par défaut 30s).

Vérifiez les règles iptables (peut nécessiter les droits root ou sudo sur le nœud) :

sudo iptables -t nat -L KUBE-SERVICES -n -v

Cela montre la chaîne de niveau supérieur. Recherchez les règles qui sautent vers les chaînes de service. Pour voir une chaîne de service spécifique, trouvez d'abord son hachage. Vous pouvez lister toutes les chaînes :

sudo iptables -t nat -L | grep "Chain KUBE-SVC"

Choisissez une chaîne et inspectez :

sudo iptables -t nat -L KUBE-SVC-ABCD -n -v

La sortie peut montrer des règles DNAT vers les IP des pods.

Plongée dans le mode IPVS

En mode IPVS, kube-proxy crée un serveur virtuel pour chaque service et des serveurs réels pour chaque endpoint. Il prend en charge plusieurs ordonnanceurs (rr, lc, sh, etc.). Pour inspecter les règles IPVS :

sudo ipvsadm -Ln

Exemple de sortie :

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.1.10:6443            Masq    1      0          0
TCP  10.96.0.10:80 rr
  -> 10.244.1.5:8080              Masq    1      0          0
  -> 10.244.2.3:8080              Masq    1      0          0

Ici, l'ordonnanceur est round-robin (rr). Vous pouvez changer l'ordonnanceur via la configuration de kube-proxy.

EndpointSlices et évolutivité

Kube-proxy utilise les EndpointSlices (introduits dans 1.19 et par défaut dans 1.21) pour réduire la charge de l'API. Chaque EndpointSlice regroupe les endpoints par service et peut contenir jusqu'à 100 endpoints. Vérifiez :

kubectl get endpointslices -n default -l kubernetes.io/service-name=my-service

La sortie montre les slices. Assurez-vous que kube-proxy les voit correctement.

Vérification et diagnostics

Le diagnostic des problèmes de kube-proxy nécessite des vérifications systématiques. Voici les commandes essentielles et ce qu'il faut rechercher.

Vérifier la santé et les journaux des pods Kube-Proxy

Commencez par l'état des pods et les journaux.

kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=50

Recherchez des erreurs telles que Failed to list v1.Service, Failed to list v1.EndpointSlice ou iptables-restore failed.

Problèmes courants :

• Permissions RBAC : kube-proxy a besoin d'un ClusterRole et d'une liaison. Vérifiez si les règles sont suffisantes.
• Connectivité au serveur API : Si kube-proxy ne peut pas atteindre le serveur API, les journaux montrent une connexion refusée.
• Erreurs iptables/ipvs : par exemple, iptables-restore: line X failed.

Vérifier les règles de service

À l'aide d'un pod de test, vérifiez si un service se résout et se connecte.

Créez un pod de test s'il n'existe pas :

kubectl run test-pod --image=busybox --restart=Never -- sleep 3600

Puis exécutez une commande dans le pod et interrogez un service :

kubectl exec -it test-pod -- wget -qO- http://my-service.default.svc.cluster.local

Si cela échoue, vérifiez le service et les endpoints :

kubectl get svc my-service -n default
kubectl get endpoints my-service -n default

Si les endpoints sont vides, le sélecteur de service peut ne pas correspondre aux pods.

Inspecter les métriques de Kube-Proxy

Kube-proxy expose des métriques sur le port 10249 (par défaut). Vous pouvez les collecter pour surveiller les performances et la santé.

Depuis un nœud, accédez à :

curl http://localhost:10249/metrics

Métriques utiles :

• kubeproxy_sync_proxy_rules_duration_seconds - temps pour synchroniser les règles.
• kubeproxy_network_programming_duration_seconds - temps pour programmer le réseau.
• kubeproxy_sync_proxy_rules_endpoint_changes_pending - changements en attente.

Une durée de synchronisation élevée ou des changements en attente peuvent indiquer des problèmes de performance.

Étude de cas de dépannage : Service inaccessible

Scénario : Un service avec ClusterIP 10.96.0.100 n'est pas accessible depuis les pods.

Étapes :

1. Vérifiez que le service existe et les endpoints :

   kubectl get svc -n my-ns my-service
   kubectl get endpoints -n my-ns my-service

Si les endpoints sont vides, vérifiez le sélecteur et les pods.

1. Vérifiez les journaux de kube-proxy pour les erreurs :

   kubectl logs -n kube-system -l k8s-app=kube-proxy | grep -i error

1. Si mode iptables, vérifiez les règles sur le nœud où le pod source s'exécute :

   sudo iptables -t nat -L KUBE-SERVICES -n | grep 10.96.0.100

Remarque : La chaîne KUBE-SERVICES a une règle pour le service. Si elle est absente, kube-proxy peut ne pas synchroniser.

1. Si mode IPVS, vérifiez les règles IPVS :

   sudo ipvsadm -Ln | grep 10.96.0.100

1. Vérifiez la configuration de kube-proxy pour toute erreur, par exemple, clusterCIDR incorrect.
2. Si tout semble bon, testez depuis un autre nœud pour isoler.

Modes de défaillance et récupération

Même avec une gestion prudente, des défaillances surviennent. Préparez-vous aux modes de défaillance courants et connaissez les étapes de récupération.

Mode de défaillance 1 : Pod Kube-Proxy en CrashLoopBackOff

La cause peut être une mauvaise modification de configuration, des permissions manquantes ou des contraintes de ressources.

Récupération :

• Vérifiez les journaux pour l'erreur exacte.
• Si erreur de configuration, rétablissez la ConfigMap à la version précédente.
• Si contraintes de ressources, augmentez les limites CPU/mémoire dans le DaemonSet.
• Si permissions, corrigez les RBAC.

Exemple : après être passé au mode IPVS sans charger les modules, les pods plantent. Corrigez en chargeant les modules sur tous les nœuds et en redémarrant.

Mode de défaillance 2 : Utilisation CPU élevée ou synchronisation iptables lente

Dans les grands clusters, les règles iptables peuvent devenir énormes, causant des retards de synchronisation. Symptômes : CPU élevé sur kube-proxy, services intermittemment inaccessibles.

Récupération :

• Passez au mode IPVS (voir Chemin de configuration sécurisé).
• Augmentez iptables.syncPeriod pour réduire la fréquence de synchronisation, mais cela peut retarder les mises à jour.
• Utilisez minSyncPeriod et iptables.minSyncPeriod pour le réglage (dans les versions plus récentes).
• Envisagez d'utiliser le backend nftables si disponible (Kubernetes 1.29+).

Mode de défaillance 3 : Endpoint non mis à jour

Si des pods sont ajoutés ou supprimés mais que le trafic de service va vers des endpoints obsolètes, le problème peut être que kube-proxy ne traite pas les changements d'EndpointSlice.

Récupération :

• Vérifiez les journaux de kube-proxy pour les erreurs d'EndpointSlice.
• Vérifiez que les EndpointSlices sont créés correctement.
• Redémarrez les pods kube-proxy.
• Vérifiez la charge du serveur API ; s'il est submergé, kube-proxy peut prendre du retard.

Procédures générales de récupération

Ayez toujours un plan de retour en arrière. Utilisez un contrôle de version pour les ConfigMaps et les DaemonSets. En cas de défaillance complète d'un nœud, kube-proxy redémarre lorsque le nœud récupère. Si le DaemonSet est supprimé accidentellement, réappliquez son manifeste.

Pour simuler une défaillance dans un environnement de test, supprimez un pod kube-proxy et observez la recréation :

kubectl delete pod -n kube-system -l k8s-app=kube-proxy --field-selector spec.nodeName=node-1

Puis observez :

kubectl get pods -n kube-system -w

Il devrait être recréé rapidement.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour vous assurer de couvrir tous les aspects lorsque vous travaillez avec kube-proxy. Chaque élément comprend un exemple concret de valeur et d'objectif.

Cette liste de contrôle peut être adaptée à votre environnement ; remplacez les noms et les valeurs par les vôtres.

Exemples de configuration avancée

Réglage des paramètres de synchronisation iptables

Pour les grands clusters, vous pouvez ajuster la période de synchronisation dans la ConfigMap.

data:
  config.conf: |-
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    iptables:
      syncPeriod: 60s
      minSyncPeriod: 10s

Appliquez et redémarrez kube-proxy. Surveillez la durée de synchronisation pour vous assurer d'une amélioration.

Configuration de l'ordonnanceur IPVS

IPVS prend en charge différents algorithmes d'ordonnancement. Définissez l'ordonnanceur dans la ConfigMap :

ipvs:
  scheduler: "lc"  # least connection

Ou utilisez sh pour le hachage de source (affinité de session). Redémarrez kube-proxy et vérifiez avec ipvsadm -Ln que l'ordonnanceur apparaît.

Activation de l'affinité de session

Pour les services nécessitant des sessions persistantes, définissez sessionAffinity: ClientIP dans la spécification du service. Kube-proxy utilise alors l'affinité par IP source. En mode iptables, il ajoute des règles du module recent ; en mode IPVS, il utilise la persistance. Vérifiez l'effet avec des requêtes répétées du même client.

Utilisation du backend nftables (expérimental)

Kubernetes 1.29 a introduit le backend nftables. Pour l'activer, définissez mode: nftables (si pris en charge). Cela peut améliorer les performances et la gestion des règles. Testez soigneusement.

Conclusion

Kube-proxy est un cheval de trait silencieux du réseau Kubernetes. Comprendre ses concepts avancés, son architecture et ses nuances opérationnelles vous permet de dépanner efficacement et d'optimiser les performances. Cet article a fourni un guide complet avec des exemples pratiques : de l'inventaire de version à la configuration sécurisée, en passant par la vérification et la récupération après défaillance.

Nous avons couvert les commandes clés pour inspecter l'état de kube-proxy, changer les modes de proxy en toute sécurité, diagnostiquer les problèmes de connectivité et utiliser les métriques. La liste de contrôle opérationnelle et les exemples de configuration avancée servent de références rapides pour les tâches réelles.

Comme prochaine étape, choisissez une vérification à faible risque de ce guide, comme vérifier votre mode de proxy actuel et les métriques. Enregistrez l'état actuel, exécutez les vérifications et comparez avec les signaux attendus. Ensuite, planifiez tout changement avec une sauvegarde et un chemin de récupération. En appliquant ces pratiques, vous garantissez un réseau de services fiable dans vos clusters Kubernetes.

Rappelez-vous toujours : observez avant de modifier, limitez le rayon d'impact et vérifiez les résultats. Avec ces principes, vous pouvez maîtriser les concepts avancés de kube-proxy et maintenir vos clusters en bon état de fonctionnement.