En décembre 2022, nous avons annoncé notre partenariat avec Isovalent pour mettre à jour le plan de données eBPF (Berkeley Packet Filter) de nouvelle génération pour les applications natives cloud dans Microsoft Azure et nous avons révélé que la prochaine génération de dataplane DNI (Container Network Interface) d’Azure Container Network Interface (CNI) serait alimentée par eBPF et Cilium.

Aujourd’hui, nous sommes ravis d’annoncer la disponibilité générale d’Azure CNI optimisée par Cilium. Azure CNI optimisé par Cilium est une plateforme de mise en réseau de nouvelle génération qui combine deux technologies puissantes : Azure CNI pour le contrôle de mise en réseau de pods scalable et flexible, intégré à la pile Azure Réseau virtuel et Cilium, un projet open source qui utilise un plan de données alimenté par eBPF pour la mise en réseau, la sécurité et l’observabilité dans Kubernetes. Azure CNI optimisé par Cilium tire parti du mode de routage direct de Cilium dans les machines virtuelles invitées et les combine avec le routage natif Azure à l’intérieur du réseau Azure, ce qui permet d’améliorer les performances réseau des charges de travail déployées dans des clusters Azure Kubernetes Service (AKS) et avec prise en charge intégrée de l’application de la sécurité réseau.

Dans ce blog, nous allons approfondir les résultats des performances et de l’extensibilité obtenus grâce à cette offre réseau puissante dans Azure Kubernetes Service.

Performances et résultats de mise à l’échelle

Les tests de performances sont effectués dans des clusters AKS en mode superposition pour analyser le comportement du système et évaluer les performances dans des conditions de charge lourdes. Ces tests simulent des scénarios où le cluster est soumis à des niveaux élevés d’utilisation des ressources, tels que les demandes simultanées volumineuses ou les charges de travail élevées. L’objectif est de mesurer différentes métriques de performances telles que les temps de réponse, le débit, l’extensibilité et l’utilisation des ressources pour comprendre le comportement du cluster et identifier les goulots d’étranglement des performances.

Latence du routage des services

L’expérience a utilisé le pool de nœuds SKU Standard D4 v3 (16 Go mem, 4 processeurs virtuels) dans un cluster AKS. L’outil Apachebench, couramment utilisé pour l’évaluation et le test de charge des serveurs web, a été utilisé pour mesurer la latence de routage du service. Au total, 50 000 demandes ont été générées et mesurées pour le temps d’achèvement global. Il a été observé que la latence de routage du service d’Azure CNI alimentée par Cilium et kube-proxy présente initialement des performances similaires jusqu’à ce que le nombre de pods atteigne 5000. Au-delà de ce seuil, la latence du routage du service pour le cluster basé sur kube-proxy commence à augmenter, tandis qu’elle conserve un niveau de latence cohérent pour les clusters basés sur Cilium.

Notamment, lorsque vous effectuez un scale-up jusqu’à 16 000 pods, le cluster Azure CNI alimenté par Cilium démontre une amélioration significative avec une réduction de 30 % de la latence de routage des services par rapport au cluster kube-proxy. Ces résultats confirment que le routage de service basé sur eBPF s’effectue mieux à grande échelle par rapport au routage de service basé sur IPTables utilisé par kube-proxy.

Latence de routage des services en secondes

Mettre à l’échelle les performances des tests

Le test de mise à l’échelle a été effectué dans un cluster Azure CNI alimenté par Cilium Azure Kubernetes Service, utilisant le pool de nœuds SKU Standard D4 v3 (16 Go mem, 4 processeurs virtuels). L’objectif du test était d’évaluer les performances du cluster dans des conditions de mise à l’échelle élevées. Le test s’est concentré sur la capture de l’unité centrale de traitement (UC) et de l’utilisation de la mémoire des nœuds, ainsi que sur la surveillance de la charge sur le serveur d’API et Cilium.

Le test comprenait trois scénarios distincts, chacun conçu pour évaluer différents aspects des performances du cluster dans des conditions variables.

Mettre à l’échelle le test avec des pods de 100 000 ko sans stratégie réseau

Le test d’échelle a été exécuté avec un cluster comprenant 1 000 nœuds et un total de 100 000 pods. Le test a été effectué sans aucune stratégie réseau et les services Kubernetes déployés.

Pendant le test de mise à l’échelle, comme le nombre de pods a augmenté de 20 000 à 100 000 ko, l’utilisation du processeur de l’agent Cilium est restée constamment faible, ne dépassant pas 100 cœurs et la mémoire est d’environ 500 Mio.

Mettre à l’échelle le test avec 100 000 pods avec des stratégies réseau 2k

Le test de mise à l’échelle a été exécuté avec un cluster comprenant 1 000 nœuds et un total de 100 000 pods. Le test a impliqué le déploiement de stratégies réseau 2K, mais n’incluait aucun service Kubernetes.

L’utilisation du processeur de l’agent Cilium est restée inférieure à 150 millièmes et la mémoire est d’environ 1 Gio. Cela a démontré que Cilium a maintenu une faible surcharge même si le nombre de stratégies réseau a été doublé.

Mettre à l’échelle des tests avec des services 1 000 avec des pods back-end et des stratégies réseau 2k 60 000

Ce test est exécuté avec 1 000 nœuds et 60 000 pods, accompagnés de stratégies réseau 2K et de services 1K, chacun ayant 60 pods associés.

L’utilisation du processeur de l’agent Cilium est restée à environ 200 000 cœurs et la mémoire reste à environ 1 Gio. Cela montre que Cilium continue de maintenir une faible surcharge même quand un grand nombre de services ont été déployés et, comme nous l’avons vu précédemment, le routage des services via eBPF offre des gains de latence significatifs pour les applications et il est agréable de voir que cela est obtenu avec une charge très faible au niveau de l’infrastructure.

Prise en main d’Azure CNI optimisée par Cilium

Pour encapsuler, comme indiqué dans les résultats ci-dessus, Azure CNI avec le plan de données eBPF de Cilium est plus performant et s’adapte beaucoup mieux avec les nœuds, les pods, les services et les stratégies réseau tout en conservant la surcharge faible. Cette offre de produit est désormais en disponibilité générale dans Azure Kubernetes Service (AKS) et fonctionne avec le mode Overlay et VNET pour CNI. Nous sommes heureux de vous inviter à essayer Azure CNI optimisé par Cilium et d’expérimenter les avantages de votre environnement AKS.

Pour commencer aujourd’hui, consultez la documentation disponible sur Azure CNI optimisé par Cilium.