TL; DR: Tous les CNI fonctionnent comme ils le devraient, à l'exception de Kube-Router et Kube-OVN, Calico, à l'exception de la détection automatique du MTU, est le meilleur.
Article-mise à jour de mes chèques passés ( и ), au moment des tests, j'utilise Kubernetes 1.19 sur Ubuntu 18.04 avec des CNI mis à jour en août 2020.
Avant de plonger dans les métriques...
Quoi de neuf depuis avril 2019 ?
- Peut tester sur votre propre cluster : vous pouvez exécuter des tests sur votre propre cluster à l'aide de notre outil Analyse comparative du réseau Kubernetes:
- De nouveaux membres sont apparus
- de VMware Tanzu
- de alauda.io
- Nouveaux scénarios : les vérifications actuelles exécutent des tests de performances réseau « Pod-to-Pod », et un nouveau script « Pod-to-Service » a été ajouté pour exécuter des tests plus proches des conditions réelles. En pratique, votre Pod avec API fonctionne avec la base en tant que service, et non via l'adresse IP du Pod (bien sûr, nous vérifions à la fois TCP et UDP pour les deux scénarios).
- Consommation de ressources : chaque test dispose désormais de sa propre comparaison de ressources
- Suppression des tests d'application : nous ne faisons plus de tests HTTP, FTP et SCP car notre collaboration fructueuse avec la communauté et les mainteneurs de CNI a découvert un écart entre les résultats iperf sur TCP et les résultats curl en raison d'un retard dans le démarrage de CNI (les premières secondes du Pod démarrage, ce qui n'est pas typique en conditions réelles).
- Open source : toutes les sources de tests (scripts, paramètres yml et données « brutes » originales) sont disponibles
Protocole de test de référence
Le protocole est décrit en détail Veuillez noter que cet article concerne Ubuntu 18.04 avec le noyau par défaut.
Sélection d'un CNI pour l'évaluation
Ce test vise à comparer les CNI configurés avec un seul fichier yaml (par conséquent, tous ceux installés par des scripts, tels que VPP et autres, sont exclus).
Nos CNI sélectionnés pour comparaison :
- Antrée v.0.9.1
- Calico v3.16
- Canal v3.16 (réseau Flannel + politiques du réseau Calico)
- Cil 1.8.2
- Flanelle 0.12.0
- Dernier routeur Kube (2020-08-25)
- WeaveNet 2.7.0
Configuration de MTU pour CNI
Tout d’abord, nous vérifions l’impact de la détection automatique de MTU sur les performances TCP :
Impact du MTU sur les performances TCP
Un écart encore plus grand est constaté lors de l'utilisation d'UDP :
Impact de MTU sur les performances UDP
Compte tenu de l'impact ÉNORME sur les performances révélé dans les tests, nous aimerions envoyer une lettre d'espoir à tous les responsables de CNI : veuillez ajouter la détection automatique de MTU à CNI. Vous sauverez des chatons, des licornes et même la plus mignonne : la petite Devop.
Toutefois, si vous devez utiliser CNI sans prise en charge de la détection automatique de MTU, vous pouvez le configurer manuellement pour obtenir des performances. Veuillez noter que cela s'applique à Calico, Canal et WeaveNet.
Ma petite demande aux CNI accompagnateurs...
Tests CNI : données brutes
Dans cette section, nous comparerons le CNI avec le MTU correct (déterminé automatiquement ou défini manuellement). L'objectif principal ici est de montrer les données brutes sous forme de graphiques.
Légende des couleurs :
- gris - échantillon (c'est-à-dire fer nu)
- vert - bande passante supérieure à 9500 XNUMX Mbps
- jaune - bande passante supérieure à 9000 XNUMX Mbps
- orange - bande passante supérieure à 8000 XNUMX Mbps
- rouge - bande passante inférieure à 8000 XNUMX Mbps
- bleu - neutre (non lié à la bande passante)
Consommation de ressources à vide
Tout d’abord, vérifiez la consommation des ressources lorsque le cluster est « en veille ».
Consommation de ressources à vide
Pod à Pod
Ce scénario suppose que le pod client se connecte directement au pod serveur à l'aide de son adresse IP.
Scénario Pod à Pod
TCP
Résultats TCP de pod à pod et consommation de ressources correspondante :
UDP
Résultats UDP de pod à pod et consommation de ressources correspondante :
Pod-to-Service
Cette section est pertinente pour les cas d'utilisation réels, le Pod client se connecte au Pod serveur via le service ClusterIP.
Script pod-to-service
TCP
Résultats TCP du pod vers le service et consommation de ressources correspondante :
UDP
Résultats UDP du pod vers le service et consommation de ressources correspondante :
Prise en charge de la politique de réseau
Parmi tout ce qui précède, le seul qui ne soutient pas la politique est Flannel. Tous les autres implémentent correctement les politiques réseau, y compris entrantes et sortantes. Bon travail!
Cryptage CNI
Parmi les CNI vérifiés, il y a ceux qui peuvent chiffrer les échanges réseau entre les Pods :
- Antrea utilisant IPsec
- Calico utilisant un grillage
- Cil utilisant IPsec
- WeaveNet utilisant IPsec
Bande passante
Puisqu’il reste moins de CNI, regroupons tous les scénarios dans un seul graphique :
La consommation de ressources
Dans cette section, nous évaluerons les ressources utilisées lors du traitement de la communication Pod-to-Pod en TCP et UDP. Il ne sert à rien de dessiner un graphique Pod-to-Service puisqu'il ne fournit pas d'informations supplémentaires.
Mettre tous ensemble
Essayons de répéter tous les graphiques, nous avons introduit ici un peu de subjectivité, en remplaçant les valeurs réelles par les mots « vwry fast », « low », etc.
Conclusion et mes conclusions
C'est un peu subjectif, puisque je transmets ma propre interprétation des résultats.
Je suis heureux que de nouveaux CNI soient apparus, Antrea a bien fonctionné, de nombreuses fonctions ont été implémentées même dans les premières versions : détection automatique du MTU, cryptage et installation facile.
Si l'on compare les performances, tous les CNI fonctionnent bien, à l'exception de Kube-OVN et Kube-Router. Kube-Router n'a pas non plus pu détecter le MTU, je n'ai trouvé aucun moyen de le configurer nulle part dans la documentation ( une demande sur ce sujet est ouverte).
En termes de consommation de ressources, Cilium utilise toujours plus de RAM que les autres, mais le constructeur vise clairement les gros clusters, ce qui n'est clairement pas la même chose qu'un test sur un cluster à trois nœuds. Kube-OVN consomme également beaucoup de ressources CPU et RAM, mais c'est un jeune CNI basé sur Open vSwitch (comme Antrea, il est plus performant et consomme moins).
Tout le monde, sauf Flannel, a des politiques de réseau. Il est fort probable qu’il ne les soutiendra jamais, puisque le but est plus simple qu’un navet cuit à la vapeur : plus c’est léger, mieux c’est.
Entre autres choses, les performances de cryptage sont étonnantes. Calico est l'un des CNI les plus anciens, mais le cryptage n'a été ajouté qu'il y a quelques semaines. Ils ont choisi Wireguard au lieu d'IPsec, et en termes simples, cela fonctionne très bien et de manière étonnante, éclipsant complètement les autres CNI dans cette partie des tests. Bien sûr, la consommation de ressources augmente en raison du cryptage, mais le débit obtenu en vaut la peine (Calico a montré une amélioration six fois supérieure au test de cryptage par rapport à Cilium, qui occupe la deuxième place). De plus, vous pouvez activer Wireguard à tout moment après avoir déployé Calico sur le cluster, et vous pouvez également le désactiver pendant une courte période ou définitivement si vous le souhaitez. Mais c'est incroyablement pratique ! Nous vous rappelons que Calico ne détecte pas automatiquement la MTU pour le moment (cette fonctionnalité est prévue pour les futures versions), veillez donc à configurer la MTU si votre réseau prend en charge les Jumbo Frames (MTU 9000).
Notons entre autres que Cilium peut chiffrer le trafic entre les nœuds du cluster (et pas seulement entre les Pods), ce qui peut être très important pour les nœuds du cluster publics.
En conclusion, je suggère les cas d'utilisation suivants :
- Besoin de CNI pour un très petit cluster OU je n'ai pas besoin de sécurité: travailler avec Flanelle, le CNI le plus léger et le plus stable (il est aussi l'un des plus anciens, selon la légende il aurait été inventé par Homo Kubernautus ou Homo Contaitorus). Vous pourriez également être intéressé par le projet le plus ingénieux , vérifier!
- Besoin de CNI pour un cluster régulier: Calicot - votre choix, mais n'oubliez pas de configurer le MTU si besoin. Vous pouvez facilement et naturellement jouer avec les politiques réseau, activer et désactiver le cryptage, etc.
- Besoin de CNI pour un cluster à (très) grande échelle: Eh bien, le test ne montre pas le comportement des grands clusters, je serais heureux de faire des tests, mais nous n'avons pas des centaines de serveurs avec une connexion 10 Gbps. La meilleure option est donc d'exécuter un test modifié sur vos nœuds, au moins avec Calico et Cilium.
Source: habr.com