Présentation d’un cas d’amélioration de la stabilité réseau de Cilium : des résultats remarquables grâce à une petite modification de code

• Présentation d’un cas de PR où une modification de code mineure (l’ajout d’un seul if) a fortement contribué à la stabilité du système
• Impact et importance de la PR "bpf:nat: Restore ORG NAT entry if it's not found"

Principe de base du NAT (Network Address Translation)

• Le NAT est une technologie qui permet à plusieurs appareils de partager une seule IP publique
• Il permet la communication entre les équipements internes (IP:Port privés) et Internet externe
• La table NAT stocke les informations de correspondance entre l’adresse d’origine et l’adresse traduite
• Processus :
  1. Un appareil interne tente de se connecter à un serveur externe
  2. L’équipement NAT convertit l’IP/le port source en IP/port public (SNAT)
  3. La réponse du serveur externe est reconvertie vers l’appareil interne (DNAT)

Utilisation du NAT dans Kubernetes

• Deux cas majeurs où le NAT est essentiel dans Kubernetes :
  1. Communication d’un Pod vers l’extérieur du cluster : conversion de l’IP interne du Pod en IP publique du nœud
  2. Communication depuis l’extérieur vers un Pod via NodePort : routage des requêtes externes vers un Pod spécifique

Méthode d’implémentation du NAT dans Cilium

• En général, sous Linux, le NAT est géré avec conntrack et iptables
• Cilium utilise la technologie eBPF pour contourner la pile réseau Linux traditionnelle
• Cilium gère directement la table NAT à l’aide d’une table de hachage LRU (BPF_MAP_TYPE_LRU_HASH)

Cause du problème

• Problème de lookup : pour traiter les paquets dans les deux sens (sortant/entrant), les mêmes données sont stockées deux fois (RevSNAT)
• Limite du LRU : en raison de ressources limitées, les entrées peu utilisées sont supprimées
• **Perte de connexion # Exemple d’une forte amélioration de la stabilité réseau de Cilium grâce à une petite modification de code

Introduction : le grand impact d’un petit changement de code

• Un cas où l’ajout d’un seul bloc if a apporté une contribution énorme à la stabilité du système
• PR concernée : "bpf:nat: Restore ORG NAT entry if it's not found"
• Explication accessible même à des non-spécialistes du réseau

Principe de base du NAT (Network Address Translation)

• Le NAT est une technologie qui permet à plusieurs appareils de partager une seule IP publique
• Il fonctionne en associant une combinaison IP:Port privée interne à une combinaison IP:Port publique externe
• Fonctionnement :
  • Un appareil interne tente d’accéder à un serveur externe
  • L’équipement NAT convertit la communication interne en communication externe (SNAT)
  • Quand la réponse revient, elle est reconvertie en communication interne d’origine (DNAT)
  • Les informations de traduction sont enregistrées dans la table NAT

Utilisation du NAT dans Kubernetes

• Kubernetes possède une structure réseau complexe et utilise le NAT à de nombreux endroits
• Principaux cas d’usage du NAT :
  1. Communication d’un Pod vers l’extérieur du cluster : conversion de l’IP privée du Pod en IP publique du nœud (SNAT)
  2. Communication depuis l’extérieur vers un Pod via NodePort : exécution simultanée de DNAT et SNAT pour acheminer le trafic externe vers le Pod approprié

L’approche particulière de Cilium

• Dans un système Linux classique, le NAT est géré par le sous-système conntrack et iptables
• Cilium utilise la technologie eBPF pour contourner la pile réseau Linux traditionnelle
• Pour le traitement SNAT, il gère directement la table SNAT sous forme de table de hachage LRU (BPF_MAP_TYPE_LRU_HASH)

Cause et symptômes du problème

• Problème de consultation (lookup) :

  • Une consultation de la table de hachage est nécessaire pour valider le traitement NAT
  • Pour accélérer la consultation, les mêmes données sont insérées deux fois dans la table en inversant les valeurs src et dst, sous forme de RevSNAT

• Problème de LRU (Least Recently Used) :

  • En raison des limites de ressources, les données peuvent être supprimées par la logique LRU

• Problème combiné :

  • Pour une seule connexion TCP, les mêmes données sont écrites deux fois
  • Si l’une des deux entrées est supprimée par le LRU, toute la connexion peut être interrompue

Une solution simple mais efficace

• Idée clé : si un paquet dans un sens est observé, mettre aussi à jour l’entrée dans le sens opposé
• Grâce à cette approche simple :
  • les entrées dans les deux sens sont mises à jour et deviennent moins prioritaires pour l’éviction LRU
  • la probabilité qu’une seule entrée soit supprimée et coupe toute la communication diminue
  • les tests de benchmark montrent une nette amélioration de la stabilité réseau

Conclusion et enseignements

• Un exemple qui montre que, même dans des systèmes complexes, une idée simple peut entraîner de grands changements
• Résolution du problème à partir de connaissances fondamentales en informatique (fonctionnement du NAT)
• Autre moyen d’éviter le problème : augmenter la taille de la table NAT
• Respect pour la passion du développeur qui a analysé le problème en profondeur et contribué avec des données probantes objectives

La valeur de l’approche technique

• Importance de comprendre et de résoudre la cause racine d’un problème
• Enseignement : une simple modification de code peut grandement améliorer la stabilité de l’ensemble d’un système
• Importance de comprendre les principes fondamentaux, même dans des systèmes complexes

[ethanhur]

Merci de nous avoir présenté cette belle expérience !