Architecture des adresses IP virtuelles dans Kubernetes : explications et exemples pratiques

Introduction

Les adresses IP virtuelles (VIP) de Kubernetes sont l'identité réseau stable qui permet aux clients d'atteindre un ensemble de Pods interchangeables. Au lieu de suivre les IP individuelles des Pods, vous créez un Service, obtenez une seule IP virtuelle, et Kubernetes s'assure que le trafic arrive sur un backend sain. L'astuce est que l'IP virtuelle est justement virtuelle : elle existe dans les règles de réseau du cluster, pas sur une interface unique. Comprendre comment ces règles sont construites, mises à jour et parfois cassées fait la différence entre un Service qui fonctionne silencieusement et un Service qui perd silencieusement du trafic.

Cet article s'adresse aux développeurs, consultants DevOps et équipes techniques de startup qui doivent passer de « le Service est en panne » à une cause racine vérifiée. Nous allons parcourir les composants, le flux de données, les décisions de conception et les commandes opérationnelles derrière les VIP Kubernetes, avec des exemples concrets et les sorties attendues. L'accent est mis sur la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et savoir comment récupérer si l'état attendu n'est pas atteint.

Inventaire de version et d'environnement

Avant de toucher à quoi que ce soit, capturez votre environnement. Pour les VIP Kubernetes, les composants pertinents sont le Service, les Endpoints/EndpointSlices et l'implémentation de kube-proxy sur chaque nœud. La plage de versions prise en charge est importante car les modes de kube-proxy et les comportements par défaut ont évolué au fil des versions. Par exemple, le mode iptables est stable et largement utilisé, le mode IPVS est disponible dans la plupart des distributions depuis Kubernetes 1.11, et les EndpointSlices sont devenus la valeur par défaut pour les Services avec de nombreux backends vers la version 1.21.

Commencez par des observations en lecture seule. Identifiez la version de Kubernetes et le mode de proxy sur un nœud du plan de contrôle :

kubectl version --short
kubectl get nodes -o wide
kubectl get configmap kube-proxy -n kube-system -o yaml | grep -A 2 'mode:'

La sortie attendue ressemblera à ceci (les numéros de version varient) :

Client Version: v1.28.0
Server Version: v1.28.2

Pour le mode proxy, si la configmap contient mode: ipvs, c'est votre mode. S'il est absent ou indique mode: "", kube-proxy utilise par défaut iptables. Cela compte car les commandes de dépannage diffèrent : pour iptables, vous utilisez iptables-save, pour IPVS, vous utilisez ipvsadm -Ln.

Ensuite, listez les Services et leurs VIP dans l'espace de noms qui vous intéresse :

kubectl get services -n production

Exemple de sortie :

NAME        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
orders      ClusterIP   10.96.120.45    <none>        8080/TCP   12d
payments    ClusterIP   10.96.0.12      <none>        443/TCP    30d
web         LoadBalancer 10.99.23.1     35.224.12.8    80:30021/TCP 5d

Cette colonne ClusterIP est votre IP virtuelle. Elle est allouée à partir du CIDR de service du cluster et n'a de sens qu'avec les règles de réseau du cluster. Capturez ces valeurs et les définitions de service avant d'apporter des modifications :

kubectl get service orders -n production -o yaml > orders-service-backup.yaml
kubectl get endpointslices -n production -l kubernetes.io/service-name=orders -o yaml > orders-endpointslices-backup.yaml

Prérequis pour un travail en toute sécurité : vous avez besoin des droits cluster-admin ou au moins de la permission d'obtenir et de décrire les Services, EndpointSlices et la configuration de kube-proxy ; et vous avez besoin d'un accès shell à un nœud pour inspecter les règles iptables/IPVS. Séparez toujours l'observation de l'intervention. Capturez d'abord l'état actuel et les horodatages, protégez les informations d'identification, puis ne modifiez qu'un élément limité uniquement lorsque vous comprenez son rayon d'impact et son chemin de récupération.

Comment fonctionnent réellement les adresses IP virtuelles Kubernetes

L'IP virtuelle est réalisée par kube-proxy sur chaque nœud. kube-proxy surveille l'API Kubernetes pour les changements de Service et d'EndpointSlice, puis programme les règles de réseau du noyau du nœud afin que le trafic envoyé à la ClusterIP soit réécrit vers une IP de Pod. Il existe trois modes principaux :

• iptables : le mode par défaut dans de nombreux clusters. kube-proxy écrit des chaînes dans la table NAT. Pour chaque Service, il y a une chaîne KUBE-SERVICES qui correspond à la destination ClusterIP:port et saute vers une chaîne KUBE-SVC-.... Cette chaîne utilise la correspondance statistique pour distribuer vers une chaîne KUBE-SEP-... par Endpoint, où DNAT réécrit la destination vers l'IP et le port du Pod.
• IPVS : utilise le serveur virtuel IP de Linux pour l'équilibrage de charge. Il crée un serveur virtuel pour la ClusterIP et des serveurs réels pour chaque Pod. IPVS prend en charge plus d'algorithmes de planification (round robin, least connections, etc.) et passe à l'échelle avec plus de Services et d'Endpoints avec moins de surcharge.
• Userspace : le mode le plus ancien, où kube-proxy agit lui-même comme proxy et le trafic passe par l'espace utilisateur. C'est lent et rarement utilisé, mais il existe encore dans certains clusters existants.

Suivons une requête concrète. Supposons que vous ayez un déploiement de 3 Pods étiquetés app: orders-api, et un Service orders avec ClusterIP 10.96.120.45 et port 8080. Un client à l'intérieur du cluster se connecte à 10.96.120.45:8080. Sur le nœud où le Pod client s'exécute, les règles iptables créées par kube-proxy ressembleront à ceci (simplifié à partir de iptables-save -t nat) :

-A KUBE-SERVICES -d 10.96.120.45/32 -p tcp -m comment --comment "production/orders:http cluster IP" -m tcp --dport 8080 -j KUBE-SVC-XYZABC
-A KUBE-SVC-XYZABC -m comment --comment "production/orders:http" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-AAA111
-A KUBE-SVC-XYZABC -m comment --comment "production/orders:http" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BBB222
-A KUBE-SVC-XYZABC -j KUBE-SEP-CCC333
-A KUBE-SEP-AAA111 -s 10.244.1.5/32 -m comment --comment "production/orders:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-AAA111 -p tcp -m comment --comment "production/orders:http" -m tcp -j DNAT --to-destination 10.244.1.5:8080
... et similaire pour BBB222 et CCC333

Ici, vous pouvez voir la distribution aléatoire : le premier endpoint reçoit 1/3 des connexions, le deuxième reçoit 1/2 du reste, et le troisième reçoit le reste. Les probabilités réelles sont calculées pour approximer une distribution égale. Si kube-proxy est en mode IPVS, vous verriez à la place :

ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.120.45:8080 rr
  -> 10.244.1.5:8080              Masq    1      0          0
  -> 10.244.2.8:8080              Masq    1      0          0
  -> 10.244.3.9:8080              Masq    1      0          0

Le planificateur rr signifie round robin, et chaque serveur réel a un poids de 1. C'est un modèle plus propre pour déboguer la distribution des connexions.

Le compromis de conception clé : l'IP virtuelle n'existe pas en tant qu'interface. Vous ne pouvez pas la ping et espérer une réponse. C'est une correspondance de modèle dans la pile réseau du noyau. C'est pourquoi un Service peut avoir zéro Pod sans erreur, mais les connexions vers la ClusterIP seront suspendues ou refusées selon le mode de proxy et le paramètre publishNotReadyAddresses.

Chemin de configuration sûr

Lorsque vous devez modifier un Service, une VIP ou une configuration réseau associée, suivez un chemin sûr qui commence par l'observation et se termine par la vérification. Parcourons une tâche réaliste : ajouter un nouveau Service pour une API de paiement et sélectionner les bons Pods backend.

Tout d'abord, vérifiez que les Pods sont en cours d'exécution et ont les étiquettes que vous prévoyez d'utiliser :

kubectl get pods -n production -l app=payments-api --show-labels

Résultat attendu :

NAME                            READY   STATUS    RESTARTS   AGE   LABELS
payments-api-6c9f8f7b4d-abcde   1/1     Running   0          3d    app=payments-api,version=v2
payments-api-6c9f8f7b4d-fghij   1/1     Running   0          3d    app=payments-api,version=v2

Ensuite, créez le Service avec un manifeste YAML, mais ne l'appliquez pas aveuglément. Faites un dry-run et validez :

kubectl apply -f payments-service.yaml --dry-run=server

S'il y a des erreurs dans le YAML ou le sélecteur, vous les voyez ici. Le manifeste pourrait ressembler à ceci :

apiVersion: v1
kind: Service
metadata:
  name: payments
  namespace: production
  labels:
    app: payments-api
spec:
  selector:
    app: payments-api
    version: v2
  ports:
  - name: https
    protocol: TCP
    port: 443
    targetPort: 8443
  type: ClusterIP

Remarquez que le sélecteur utilise deux étiquettes. C'est plus sûr qu'un sélecteur large car cela limite le rayon d'impact aux seuls Pods version: v2. Si vous déployez plus tard version: v3, il ne recevra pas de trafic tant que vous n'aurez pas mis à jour le sélecteur du Service. Gardez le test local petit : appliquez un manifeste, inspectez les ressources générées et testez avec kubectl port-forward avant de passer à un équilibreur de charge cloud ou à un contrôleur d'entrée. Par exemple :

kubectl apply -f payments-service.yaml
kubectl get service payments -n production -o wide

La ClusterIP attendue est attribuée (par exemple, 10.96.0.12) et ENDPOINTS affiche les IP des Pods. Testez ensuite la connectivité avec un Pod temporaire :

kubectl run -it --rm debug --image=busybox -- sh
# À l'intérieur du Pod :
wget -qO- --timeout=2 https://10.96.0.12:443 --no-check-certificate

Si vous obtenez une réponse ou une erreur d'application spécifique (pas un délai d'attente), le chemin VIP fonctionne. Un délai d'attente avant toute réponse suggère que les règles de routage sont manquantes ou que les Pods n'écoutent pas sur targetPort.

Séparez toujours l'observation de l'intervention. Avant d'appliquer une modification, enregistrez le Service actuel et les EndpointSlices comme indiqué précédemment. Sachez comment annuler : kubectl delete -f payments-service.yaml supprime le Service et sa VIP, mais les Pods restent. Si vous avez modifié un Service existant, restaurez à partir de votre YAML de sauvegarde.

Vérification et diagnostics

Lorsque la VIP d'un Service ne fonctionne pas, le problème se situe généralement dans l'une des quatre couches : la définition du Service (inadéquation du sélecteur), l'EndpointSlice (aucun Pod prêt), les règles de kube-proxy (obsolètes ou manquantes) ou la politique réseau (blocage du trafic). Parcourons un chemin de diagnostic systématique.

Étape 1 : Confirmez le Service et son IP virtuelle.

kubectl describe service orders -n production

Recherchez le champ Endpoints. S'il est vide (<none>), aucun Pod ne correspond au sélecteur, ou les Pods correspondants ne sont pas prêts. Par exemple :

Endpoints:          <none>

C'est une défaillance courante : le sélecteur dans la spécification du Service ne correspond à aucune étiquette de Pod en cours d'exécution. Vérifiez le sélecteur avec :

kubectl get pods -n production --selector=app=orders-api

Si aucun Pod n'est listé, les étiquettes sont incorrectes. Corrigez le sélecteur pour correspondre aux étiquettes réelles des Pods, ou mettez à jour le déploiement pour utiliser les étiquettes attendues. Soyez prudent : modifier les étiquettes sur un déploiement en cours peut provoquer une mise à jour progressive. Au lieu de cela, modifiez le sélecteur du Service si vous le contrôlez.

Étape 2 : Vérifiez l'EndpointSlice pour le Service.

Les EndpointSlices sont les successeurs des Endpoints et sont utilisés par kube-proxy pour programmer les règles. Listez-les :

kubectl get endpointslices -n production -l kubernetes.io/service-name=orders

Exemple avec une tranche et trois endpoints :

NAME           ADDRESSTYPE   PORTS   ENDPOINTS   AGE
orders-abcde   IPv4          8080    3           12m

Si le nombre d'EndpointSlices est zéro ou si les adresses des endpoints sont incorrectes, kube-proxy n'a rien à programmer. Décrivez la tranche pour voir l'état de préparation des endpoints :

kubectl describe endpointslices orders-abcde -n production

Recherchez conditions: ready: true sur chaque endpoint. Si un endpoint n'est pas prêt, le Pod peut échouer aux sondes de préparation.

Étape 3 : Inspectez les règles réseau du nœud.

Sur un nœud worker (utilisez kubectl get nodes -o wide pour trouver une IP, puis SSH), vérifiez les règles de proxy. Pour iptables :

sudo iptables-save -t nat | grep 10.96.120.45

Vous devriez voir la correspondance de la chaîne KUBE-SERVICES et un DNAT vers une IP de Pod. Si rien n'apparaît, kube-proxy n'a pas programmé la VIP sur ce nœud. Cela peut arriver si kube-proxy n'est pas en cours d'exécution ou est bloqué. Vérifiez les Pods kube-proxy :

kubectl get pods -n kube-system -l k8s-app=kube-proxy
kubectl logs -n kube-system kube-proxy-<node-name> --tail=50

Recherchez des erreurs sur l'écriture de règles iptables ou la connectivité au serveur API. Si les journaux sont propres mais que les règles sont manquantes, redémarrez le Pod kube-proxy sur le nœud affecté :

kubectl delete pod -n kube-system kube-proxy-<node-name>

Il sera recréé par son DaemonSet et repeuplera les règles.

Pour le mode IPVS, utilisez sudo ipvsadm -Ln et vérifiez que le serveur virtuel existe avec les bons serveurs réels. Vérifiez également que les modules du noyau sont chargés :

lsmod | grep ip_vs

Si IPVS n'est pas fonctionnel, kube-proxy peut revenir à iptables selon la configuration. Vérifiez les journaux de kube-proxy pour des messages comme Failed to load kernel module ip_vs.

Étape 4 : Testez depuis un Pod client et capturez le trafic.

Exécutez un Pod de débogage et tentez une connexion :

kubectl run -it --rm debug --image=nicolaka/netshoot -- bash
# À l'intérieur :
curl -v http://10.96.120.45:8080/health

Une réponse réussie avec HTTP 200 confirme le chemin complet. Si la connexion se bloque, utilisez tcpdump sur l'espace de noms réseau ou conntrack -L pour voir où les paquets s'arrêtent.

Modes de défaillance et récupération

Comprendre les modes de défaillance courants vous aide à réagir rapidement et sans panique. Voici les problèmes les plus fréquents avec les VIP Kubernetes, pourquoi ils surviennent et comment récupérer.

1. Endpoints vides (inadéquation du sélecteur ou Pods non prêts)

Symptômes : le Service existe, la ClusterIP est attribuée, mais les connexions expirent ou sont refusées. kubectl describe service montre Endpoints: <none>.

Pourquoi cela arrive : le sélecteur du Service ne correspond à aucune étiquette de Pod en cours d'exécution, ou tous les Pods correspondants échouent aux sondes de préparation. Cela est souvent causé par une faute de frappe dans la clé ou la valeur de l'étiquette, ou par un déploiement mis à l'échelle à zéro.

Comment éviter : utilisez kubectl get pods --show-labels pour vérifier les étiquettes exactes, et testez le sélecteur avec kubectl get pods -l <selector> avant de créer le Service. Dans le manifeste du Service, gardez le sélecteur simple et aligné sur le modèle de Pod.

Comment récupérer : mettez à jour le sélecteur du Service pour correspondre aux Pods réels, ou corrigez la sonde de préparation pour que les Pods deviennent Ready. Appliquez le changement et vérifiez que les endpoints apparaissent en quelques secondes.

2. Règles kube-proxy obsolètes

Symptômes : les Endpoints sont présents dans l'API, mais le trafic d'un client vers la ClusterIP échoue toujours ou va vers une ancienne IP de Pod. Sur le nœud, iptables-save montre des règles pour une IP qui n'existe plus.

Pourquoi cela arrive : kube-proxy n'a pas réussi à mettre à jour les règles du nœud en raison d'un problème de connexion à l'API, d'un crash ou d'une pression sur les ressources. Cela peut se produire lors d'une partition réseau ou lorsque kube-proxy est OOMKilled.

Comment éviter : surveillez les journaux et les métriques de kube-proxy pour les retards de synchronisation des règles. Assurez-vous que le nœud a suffisamment de mémoire et que le serveur API est joignable depuis tous les nœuds.

Comment récupérer : supprimez le Pod kube-proxy sur le nœud affecté pour forcer un redémarrage. Il resynchronisera les règles depuis l'API. Si le problème persiste, vérifiez la configuration et les journaux de kube-proxy pour l'erreur spécifique.

3. Problèmes de mode IPVS avec la correspondance des ports

Symptômes : en mode IPVS, les connexions vers la ClusterIP fonctionnent depuis certains Pods mais pas d'autres, ou certains ports sont inaccessibles. ipvsadm -Ln montre des ports incorrects ou le serveur virtuel est manquant.

Pourquoi cela arrive : IPVS utilise différents modules du noyau et a une gestion nuancée de targetPort et des ports nommés. De plus, IPVS peut ne pas gérer correctement tous les protocoles (par exemple, SCTP).

Comment éviter : testez le mode IPVS dans un cluster de staging avant de l'activer en production. Assurez-vous que tous les modules du noyau sont chargés et que kube-proxy est configuré avec strictARP: false si vous utilisez un CNI qui ne prend pas en charge les réponses ARP.

Comment récupérer : repassez en mode iptables en modifiant la configmap de kube-proxy et en redémarrant le DaemonSet kube-proxy, ou corrigez la configuration IPVS et assurez-vous que les serveurs réels sont corrects.

4. Politiques réseau bloquant le trafic

Symptômes : la VIP et les endpoints du Service sont corrects, les règles kube-proxy existent, mais les connexions d'un Pod échouent tandis que d'autres réussissent. Le Pod client expire simplement.

Pourquoi cela arrive : une politique réseau (NetworkPolicy) peut bloquer la sortie du Pod client ou l'entrée vers les Pods backend. Les politiques réseau sont appliquées par le plugin CNI et peuvent interrompre le flux DNAT.

Comment éviter : auditez les NetworkPolicies avant de déployer de nouveaux Services. Utilisez un outil de politique ou inspectez manuellement toutes les politiques dans l'espace de noms pour les règles conflictuelles.

Comment récupérer : identifiez la politique bloquante avec kubectl get networkpolicies -n <namespace>. Modifiez la politique pour autoriser le trafic requis (par exemple, des étiquettes du Pod client vers les étiquettes du Pod backend sur le port cible), puis testez à nouveau.

5. VIP visibles de l'extérieur (LoadBalancer) ne fonctionnant pas

Symptômes : un Service de type LoadBalancer a une IP externe mais elle n'est pas joignable depuis l'extérieur du cluster. La ClusterIP fonctionne en interne, mais le trafic externe échoue.

Pourquoi cela arrive : mauvaise configuration de l'équilibreur de charge du fournisseur cloud, règles de groupe de sécurité ou paramètres de pare-feu. L'équilibreur de charge peut ne pas transmettre correctement aux ports de nœud, ou les contrôles de santé échouent et marquent les nœuds comme non sains.

Comment éviter : testez avec un ClusterIP et kubectl port-forward avant de créer un LoadBalancer. Lorsque vous utilisez un fournisseur cloud, vérifiez les journaux de l'équilibreur de charge et l'état des contrôles de santé dans la console cloud.

Comment récupérer : recréez le Service si l'équilibreur de charge est bloqué. Vérifiez que les ports de nœud sont ouverts sur tous les nœuds et que le pare-feu cloud autorise le trafic de l'équilibreur de charge vers les nœuds sur la plage de ports de nœud (par défaut 30000-32767).

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle lors du déploiement ou de la modification d'un Service Kubernetes pour minimiser les risques et accélérer la récupération. Chaque élément comprend une commande ou une étape de vérification concrète, un propriétaire responsable (pas un groupe) et une fréquence d'examen.

Après avoir terminé la liste de contrôle, documentez les résultats et les exceptions dans votre runbook. Le propriétaire responsable doit approuver les modifications de production et s'assurer que la fréquence d'examen est respectée. Cela évite que des erreurs de configuration silencieuses ne deviennent des pannes.

Pièges courants et comment les éviter

Au-delà des modes de défaillance ci-dessus, plusieurs erreurs subtiles font trébucher à plusieurs reprises les équipes travaillant avec les VIP Kubernetes. Reconnaissez ces signes précoces.

Supposer que la ClusterIP est pingable

Les nouveaux venus exécutent souvent ping 10.96.120.45 et n'obtiennent aucune réponse, puis supposent que le Service est en panne. La ClusterIP n'est pas une interface ; c'est une règle NAT. Le test correct est de tenter une connexion TCP au port du Service depuis un Pod ou un nœud. Utilisez curl, wget ou nc à l'intérieur du cluster.

Utiliser --service-cluster-ip-range de manière incohérente

Si votre cluster a été initialisé avec un CIDR de service particulier, tous les Services doivent avoir des ClusterIPs dans cette plage. Le modifier plus tard est destructeur et nécessite de recréer le cluster. Confirmez toujours le CIDR avec kubectl cluster-info dump | grep service-cluster-ip-range avant de créer de nombreux Services. Si vous voyez des erreurs comme ClusterIP out of range, vous avez une incohérence.

Ne pas gérer différemment les Services headless

Un Service headless (avec clusterIP: None) n'a pas d'IP virtuelle. Au lieu de cela, le DNS renvoie les IP individuelles des Pods. De nombreux opérateurs le traitent comme un Service régulier et se demandent pourquoi la VIP ne fonctionne pas. Si votre spécification de Service indique clusterIP: None, vous devez utiliser directement les IP des Pods ou via un résolveur DNS personnalisé. Évitez les Services headless sauf si vous avez spécifiquement besoin de la découverte au niveau des Pods.

Ignorer l'affinité de session lorsque l'état est impliqué

Si votre application stocke l'état de session sur le Pod, vous avez besoin de sessionAffinity: ClientIP sur le Service. Sinon, kube-proxy peut acheminer un client vers un Pod différent à chaque connexion, cassant l'état. Ajoutez le champ et testez avec des requêtes répétées depuis la même IP. Sachez que cela limite l'équilibrage de charge et peut entraîner une distribution inégale.

Oublier de supprimer un Service LoadBalancer

La suppression d'un Service LoadBalancer peut laisser des ressources cloud orphelines (par exemple, un ELB) qui continuent d'engendrer des coûts. Vérifiez toujours la console de votre fournisseur cloud après avoir supprimé de tels Services, ou utilisez kubectl get svc -A | grep LoadBalancer pour auditer. Certains fournisseurs ont des finaliseurs qui ralentissent la suppression ; assurez-vous qu'ils se terminent.

Compliquer à l'excès les sélecteurs

Un sélecteur avec de nombreuses étiquettes est fragile. Si une étiquette change lors d'une mise à jour de déploiement, le Service perd tous les backends. Utilisez le minimum d'étiquettes nécessaire pour identifier les bons Pods, et évitez les étiquettes susceptibles de changer (comme version si vous faites des mises à jour progressives avec les deux versions simultanément).

Conclusion

Les adresses IP virtuelles Kubernetes sont le ciment entre les noms de réseau stables et les IP éphémères des Pods. Comprendre comment kube-proxy programme les règles du noyau du nœud, comment les EndpointSlices alimentent ces règles et comment diagnostiquer les défaillances est essentiel pour quiconque exploite des Services en production. L'architecture est délibérément simple, mais les erreurs de configuration dans les sélecteurs, le mode de proxy ou les politiques réseau peuvent casser silencieusement la connectivité.

Un flux de travail opérationnel fiable rend la défaillance visible, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Commencez par une vérification à faible risque de la liste de contrôle : enregistrez l'état actuel d'un Service, exécutez une commande de diagnostic, comparez le résultat avec la sortie attendue et examinez les dépendances comme les EndpointSlices et les journaux de kube-proxy. Vous pourrez alors gérer en toute confiance les adresses IP virtuelles dans votre cluster sans conjectures.