Quand on monte son premier cluster VKS, le réseau “marche”. Pour un POC, c’est suffisant. Pour la production, c’est insuffisant — parce que la première fois qu’un paquet ne passe pas, il faut savoir où regarder.
Cet article retrace le chemin d’un paquet entre l’utilisateur et un pod, à travers les couches vSphere et NSX. L’objectif n’est pas d’être exhaustif sur NSX (les TechDocs Broadcom sont là pour ça) mais de donner un cadre mental clair pour diagnostiquer, dimensionner, et discuter avec l’équipe réseau.
Audience supposée : tu opères VCF 9 ou tu t’apprêtes à le faire, tu connais TCP/IP au niveau d’un ingénieur infra, et tu veux comprendre le réseau VKS au-delà du “ça marche”.
Nature de cet article
Synthèse d’architecte appuyée sur la documentation Broadcom NSX 4.x, les patterns de référence VCF 9, et les retours d’expérience de la communauté. Pas de capture de l’UI NSX. La valeur est dans le cadre d’analyse et les décisions de design.
Les couches en jeu
Avant de tracer un paquet, il faut nommer les couches. Quatre composants se partagent le travail.
vSphere Distributed Switch (vDS) — le switch L2 distribué entre tous les hôtes ESXi du cluster vSphere. Il transporte le trafic des VMs Supervisor, des nodes VKS, et du management. C’est la fondation, mais il ne fait pas grand-chose au-delà du forwarding L2.
NSX (segments + routeurs) — la couche overlay. Les segments NSX sont des “VLANs virtuels” portés par Geneve. Les routeurs Tier-0 et Tier-1 assurent le routage et le NAT.
Antrea (CNI VKS) — le CNI à l’intérieur du cluster Kubernetes. Antrea encapsule le trafic pod-à-pod et applique les NetworkPolicies. C’est une seconde overlay, à l’intérieur du node.
NSX Advanced Load Balancer (Avi) — le data plane qui matérialise les Services Kubernetes de type LoadBalancer. Il consomme un pool d’IPs et publie des VIPs accessibles depuis l’extérieur du cluster.
Le piège conceptuel. Beaucoup de débutants VKS pensent en termes de “réseau Kubernetes” d’un côté et “réseau vSphere” de l’autre. La réalité est qu’un paquet traverse séquentiellement les deux mondes, et chaque transition est un endroit où les choses peuvent casser. Comprendre les transitions est plus utile que de mémoriser la config de chaque composant isolément.
Le chemin descendant : utilisateur → pod
On suit un paquet HTTP entrant depuis Internet jusqu’à un pod applicatif. Sept étapes, chacune dans une couche différente.
[Client]
↓ TCP/IP public
[Edge firewall / SNAT entrée]
↓
[NSX Tier-0] ← frontière nord-sud, BGP avec le réseau d'entreprise
↓
[NSX Tier-1] ← gateway tenant, dédié au namespace VKS
↓
[Segment overlay] ← Geneve, transporté par le vDS
↓
[Node VKS (eth0)] ← VM avec IP du pool worker
↓ Antrea (Geneve interne)
[Pod (vethXXX)] ← container réseauÉtape 1 — Edge. Le paquet arrive sur l’edge externe (souvent un firewall périmétrique) qui forwarde vers la VIP exposée par NSX ALB. La VIP appartient à un Service Engine Avi, lui-même connecté à un segment NSX dédié au data plane Avi.
Étape 2 — NSX ALB. Le Service Engine reçoit le paquet, applique sa logique L4/L7 (round-robin, persistence cookie, terminaison TLS éventuelle), et choisit un endpoint pod. Le SE envoie le paquet vers l’IP du pod cible — pas vers le node, vers le pod directement, parce que les pods sont routables depuis NSX dans la topologie standard VKS.
Étape 3 — Tier-0. Si le SE Avi est dans une VRF différente du Tier-1 du namespace, le paquet remonte au T0 puis redescend. Sinon, le T0 est court-circuité. Le T0 est aussi le point d’annonce BGP des routes vers les pod CIDRs — c’est là que le réseau d’entreprise apprend l’existence des subnets pod.
Étape 4 — Tier-1. Le routeur T1 dédié au namespace VKS reçoit le paquet et le route vers le segment overlay du worker node cible. Le T1 porte les règles de microsegmentation (Distributed Firewall) appliquées à ce tenant.
Étape 5 — Segment overlay. Le segment NSX encapsule le paquet en Geneve et le transporte via le vDS jusqu’à l’hôte ESXi qui héberge le node cible. Le tunnel VTEP-à-VTEP est transparent du point de vue du paquet client.
Étape 6 — Node VKS. Le paquet arrive sur l’interface eth0 de la VM du node. À ce point, c’est un paquet standard avec l’IP du pod en destination.
Étape 7 — Antrea. Antrea reçoit le paquet, le route vers le bon namespace réseau via OVS, et le délivre sur le veth du pod. Si le pod cible est sur un autre node, Antrea encapsule à nouveau en Geneve interne — ce qui crée une double encapsulation (Geneve NSX + Geneve Antrea) avec implications MTU à connaître.
Double encapsulation et MTU
Geneve NSX ajoute ~52 octets de header. Geneve Antrea en ajoute autant. Avec un MTU de 1500 bout-en-bout, le payload utile chute à ~1396 octets. La pratique recommandée par Broadcom et VMware est un MTU de 1700 minimum sur le vDS et l’underlay physique pour absorber les deux encapsulations sans fragmentation. Ne pas le faire, c’est garantir des problèmes de TCP MSS et de PMTUD intermittents qui sont parmi les plus pénibles à diagnostiquer.
Le chemin retour : pod → extérieur
Un pod qui appelle un service externe (API tierce, base de données, registry) suit le chemin inverse, mais avec une nuance importante : le NAT.
Par défaut, le trafic sortant d’un pod est SNAT par le Tier-1 du namespace, pour utiliser l’IP du T1 (ou une IP publique si Tier-0 est configuré pour faire du SNAT). Le pod n’expose donc pas son IP réelle au monde extérieur.
Pourquoi c’est important. Dans certains contextes (firewalling sortant, traçabilité par IP source, connexions vers des bases on-premise), il peut être nécessaire de désactiver ce SNAT et de router le pod CIDR directement. NSX VPC (introduit en VCF 9) facilite cette configuration sans créer de manière artisanale des routes statiques.
Le piège. Si tu désactives le SNAT pour un namespace mais que ton réseau d’entreprise n’apprend pas le pod CIDR via BGP, les paquets retours ne reviendront jamais. C’est le scénario classique de routage asymétrique qui crée des connexions partiellement fonctionnelles (SYN passe, SYN-ACK ne revient pas) et des erreurs intermittentes.
T0 vs T1 : où passer la frontière
Une décision d’architecture qui revient toujours : combien de Tier-0, combien de Tier-1, qui partage quoi.
Modèle — un T0 unique, plusieurs T1, un T1 par namespace ou par groupe d’équipes.
Forces — simple à opérer, BGP centralisé, économie de ressources NSX Edge. C’est le pattern par défaut pour la plupart des organisations.
Limites — pas d’isolation réseau forte entre tenants au niveau north-south. Pour des tenants avec des contraintes réglementaires distinctes, c’est insuffisant.
Modèle — un T0 par tenant ou par environnement (prod/non-prod), avec des Edges dédiés.
Forces — isolation forte, sessions BGP indépendantes, blast radius contenu. Recommandé pour les services financiers ou la santé.
Limites — coût en ressources Edge (chaque T0 actif/actif consomme deux VMs Edge), complexité d’opération. À justifier par un besoin réel d’isolation, pas par confort.
Modèle — NSX VPC, abstraction introduite en VCF 9 qui regroupe T1 + segments + politiques sous une entité “VPC” alignée sur le concept d’un VPC AWS/Azure.
Forces — modèle déclaratif, self-service via API, alignement avec les patterns cloud public. Réduit drastiquement le ticket-volume vers l’équipe NSX.
Limites — feature jeune, courbe d’apprentissage pour les équipes habituées au modèle T0/T1 classique. La migration depuis un modèle traditionnel n’est pas triviale.
Recommandation assumée. Pour une nouvelle plateforme VCF 9, démarrer en NSX VPC. Pour une plateforme existante en T0/T1 classique, ne pas migrer pour migrer — la valeur du modèle VPC se révèle quand le nombre de tenants dépasse 10 ou que les équipes applicatives demandent du self-service réseau.
NSX ALB et les Services LoadBalancer
L’intégration entre VKS et NSX ALB est ce qui rend l’expérience développeur acceptable. Il faut comprendre comment elle fonctionne pour la dimensionner correctement.
Le contrôleur AKO (Avi Kubernetes Operator) tourne dans le cluster VKS et observe les Services Kubernetes. Quand un Service de type LoadBalancer est créé, AKO appelle l’API du contrôleur Avi pour provisionner une VirtualService et lui allouer une IP depuis le pool configuré au niveau du namespace vSphere.
Les Service Engines sont des VMs Avi déployées dans un segment NSX dédié. Elles portent les VIPs, exécutent la logique L4/L7, et envoient le trafic vers les pods endpoints. Une SE peut héberger plusieurs centaines de VirtualServices selon son sizing — mais la concentration crée du blast radius.
Le pool d’IPs est une ressource finie. Chaque Service LoadBalancer consomme une IP. Sur un cluster avec beaucoup de microservices exposés, le pool peut s’épuiser plus vite qu’on ne le pense. Mesurer la consommation tôt et ajuster avant que l’équipe applicative ne reçoive des erreurs de provisionning.
Ingress = une VIP partagée
Plutôt que d’exposer chaque service avec un Service LoadBalancer dédié, déployer un contrôleur Ingress (Contour, NGINX) qui consomme une seule VIP et route en L7 vers les services internes. Cela réduit la consommation du pool IP de plusieurs ordres de grandeur et donne un point unique pour la terminaison TLS et l’observabilité HTTP.
Segments overlay vs VLAN-backed
Quand on crée un segment NSX, on choisit entre overlay (Geneve) et VLAN-backed.
Overlay. C’est le mode standard pour les workloads VKS. Les segments overlay sont indépendants du plan d’adressage VLAN du datacenter, permettent la mobilité L2 entre hôtes ESXi distants, et bénéficient de la microsegmentation distribuée. Coût : la double encapsulation Geneve déjà mentionnée.
VLAN-backed. Utile pour des cas spécifiques : workloads legacy qui doivent être exposés directement sur un VLAN du datacenter, contraintes réglementaires qui interdisent l’overlay, intégration avec des équipements externes qui parlent VLAN tagging natif. À éviter par défaut pour les workloads VKS — la microsegmentation y est moins fine et la mobilité limitée.
Gotchas et limites
MTU mal dimensionné = pannes intermittentes
Routage asymétrique sur SNAT désactivé
Distributed Firewall = règles d'or à connaître
NSX ALB pool exhaustion
Service Engine sizing : prod ≠ POC
VRF leaks et tenant cross-talk
Conclusion et suite
Ce qu’il faut retenir. Le réseau VCF 9 superpose quatre couches : vDS, NSX, Antrea, NSX ALB. Un paquet traverse séquentiellement chacune d’entre elles, et chaque transition est un point de diagnostic. Le MTU est la première chose à vérifier sur tout problème intermittent. Le choix T0/T1/VPC engage sur plusieurs années — démarrer en VPC pour les nouvelles plateformes. NSX ALB transforme l’expérience développeur, mais doit être dimensionné explicitement.
Prochaine étape. L’article suivant traite des opérations day-2 sur VKS : lifecycle des clusters via CAPI, upgrades, et stack d’observabilité. Une fois le réseau compris, c’est l’autre grand chantier d’une mise en production.
Ressources.
Pour aller plus loin :
- Broadcom TechDocs — NSX Concepts — référence sur T0/T1, segments, DFW
- Broadcom TechDocs — VKS Networking — intégration VKS + NSX
- NSX VPC Design Guide — patterns de multi-tenancy
- Avi Kubernetes Operator (AKO) — documentation officielle du contrôleur
- Antrea Documentation — référence CNI Antrea
Reçois le prochain par email
Les nouveaux articles et séries, envoyés à leur publication. Aucun autre courrier.
