Ceci est ma mise à jour , qui fonctionne désormais sur Kubernetes 1.14 avec la dernière version CNI en avril 2019.
Tout d'abord, je tiens à remercier l'équipe Cilium : les gars m'ont aidé à vérifier et corriger les scripts de suivi des métriques.
Ce qui a changé depuis novembre 2018
Voici ce qui a changé depuis (si cela vous intéresse) :
Flannel reste l'interface CNI la plus rapide et la plus simple, mais ne prend toujours pas en charge les politiques réseau et le cryptage.
Romana n'est plus pris en charge, nous l'avons donc supprimé du benchmark.
WeaveNet prend désormais en charge les politiques réseau pour les entrées et sorties ! Mais la productivité a diminué.
Dans Calico, vous devez toujours configurer manuellement la taille maximale des paquets (MTU) pour obtenir de meilleures performances. Calico propose deux options pour installer CNI, vous pouvez donc vous passer d'un référentiel ETCD séparé :
- stocker l'état dans l'API Kubernetes en tant que magasin de données (taille du cluster < 50 nœuds) ;
- stocker l'état dans l'API Kubernetes en tant que magasin de données avec un proxy Typha pour alléger la charge sur l'API K8S (taille du cluster > 50 nœuds).
Calico a annoncé son soutien au-dessus d'Istio pour la sécurité au niveau des applications.
Cilium prend désormais en charge le cryptage ! Cilium assure le chiffrement avec les tunnels IPSec et propose une alternative au réseau WeaveNet chiffré. Mais WeaveNet est plus rapide que Cilium avec le cryptage activé.
Cilium est désormais plus facile à déployer grâce à l'opérateur ETCD intégré.
L'équipe Cilium a tenté d'alléger son CNI en réduisant la consommation de mémoire et les coûts du CPU, mais ses concurrents sont toujours plus légers.
Contexte de référence
Le benchmark est exécuté sur trois serveurs Supermicro non virtualisés avec un commutateur Supermicro de 10 Go. Les serveurs sont connectés directement au switch via des câbles DAC SFP+ passifs et sont configurés sur le même VLAN avec des trames jumbo (MTU 9000).
Kubernetes 1.14.0 installé sur Ubuntu 18.04 LTS avec Docker 18.09.2 (la version Docker par défaut dans cette version).
Pour améliorer la reproductibilité, nous avons décidé de toujours configurer le maître sur le premier nœud, de placer la partie serveur du benchmark sur le deuxième serveur, et la partie client sur le troisième. Pour ce faire, nous utilisons NodeSelector dans les déploiements Kubernetes.
Nous décrirons les résultats du benchmark à l’échelle suivante :
Sélection d'un CNI pour un benchmark
Il s'agit d'une référence uniquement pour le CNI de la liste de la section Consultez la documentation officielle de Kubernetes. Sur les 9 CNI, nous n'en retiendrons que 6 : nous exclurons ceux qui sont difficiles à installer et/ou ne fonctionnent pas sans configuration selon la documentation (Romana, Contiv-VPP et JuniperContrail/TungstenFabric).
Nous comparerons les CNI suivants :
- Calico v3.6
- Canal v3.6 (essentiellement Flannel pour le réseau + Calico comme pare-feu)
- Cil 1.4.2
- Flanelle 0.11.0
- Kube-routeur 0.2.5
- WeaveNet 2.5.1
Installation
Plus le CNI est facile à installer, meilleure sera notre première impression. Tous les CNI du benchmark sont très simples à installer (avec une ou deux commandes).
Comme nous l'avons dit, les serveurs et le commutateur sont configurés avec les trames jumbo activées (nous définissons le MTU sur 9000). Nous serions heureux si CNI déterminait automatiquement le MTU en fonction de la configuration des adaptateurs. Cependant, seuls Cilium et Flannel y sont parvenus. Le reste des CNI ont des demandes sur GitHub pour ajouter la découverte automatique de MTU, mais nous la configurerons manuellement en modifiant le ConfigMap pour Calico, Canal et Kube-router, ou en passant une variable d'environnement pour WeaveNet.
Quel est le problème avec une MTU incorrecte ? Ce diagramme montre la différence entre WeaveNet avec le MTU par défaut et les trames jumbo activées :
Comment le paramètre MTU affecte-t-il le débit ?
Nous avons vu à quel point le MTU est important pour les performances, voyons maintenant comment nos CNI le déterminent automatiquement :
CNI détecte automatiquement MTU
Le graphique montre que vous devez configurer le MTU pour Calico, Canal, Kube-router et WeaveNet pour des performances optimales. Cilium et Flannel ont pu déterminer eux-mêmes correctement le MTU sans aucun réglage.
sécurité
Nous comparerons la sécurité CNI sous deux aspects : la capacité à chiffrer les données transmises et la mise en œuvre de politiques réseau Kubernetes (basées sur des tests réels et non sur de la documentation).
Seuls deux CNI chiffrent les données : Cilium et WeaveNet. Chiffrement TisserNet activé en définissant le mot de passe de cryptage en tant que variable d'environnement CNI. DANS WeaveNet le décrit de manière compliquée, mais tout est fait simplement. Chiffrement Cil configuré par des commandes, en créant des secrets Kubernetes et en modifiant le daemonSet (un peu plus compliqué que dans WeaveNet, mais Cilium a étape par étape ).
Quant à la mise en œuvre de la politique des réseaux, elle a réussi Calico, Canal, Cilium et WeaveNet, dans lequel vous pouvez configurer les règles d'entrée et de sortie. Pour Routeur Kube il n'y a de règles que pour Ingress, et Flanelle Il n’y a aucune politique de réseau.
Voici les résultats globaux :
Résultats du test de performance en matière de sécurité
Performance
Ce benchmark montre le débit moyen sur au moins trois exécutions de chaque test. Nous testons les performances de TCP et UDP (en utilisant iperf3), d'applications réelles comme HTTP (avec Nginx et curl) ou FTP (avec vsftpd et curl) et enfin les performances des applications en utilisant le cryptage basé sur SCP (en utilisant le client et le serveur OpenSSH).
Pour tous les tests, nous avons effectué un benchmark bare metal (ligne verte) pour comparer les performances CNI avec les performances du réseau natif. Ici nous utilisons la même échelle, mais en couleur :
- Jaune = très bien
- Orange = bon
- Bleu = couci-couça
- Rouge = mauvais
Nous ne prendrons pas les CNI mal configurés et n’afficherons les résultats que pour les CNI avec le MTU correct. (Remarque : Cilium ne calcule pas correctement le MTU si vous activez le cryptage, vous devrez donc réduire manuellement le MTU à 8900 1.4 dans la version 1.5. La version suivante, XNUMX, le fait automatiquement.)
Voici les résultats:
Performances TCP
Tous les CNI ont bien performé dans le benchmark TCP. CNI avec cryptage est loin derrière car le cryptage coûte cher.
Performances UDP
Ici aussi, tous les CNI se portent bien. CNI avec cryptage a montré presque le même résultat. Cilium est un peu en retard par rapport à la concurrence, mais il ne représente que 2,3% de bare metal, ce n'est donc pas un mauvais résultat. N'oubliez pas que seuls Cilium et Flannel ont eux-mêmes déterminé correctement le MTU, et voici leurs résultats sans aucune configuration supplémentaire.
Et une vraie application ? Comme vous pouvez le constater, les performances globales de HTTP sont légèrement inférieures à celles de TCP. Même si vous utilisez HTTP avec TCP, nous avons configuré iperf3 dans le benchmark TCP pour éviter un démarrage lent qui affecterait le benchmark HTTP. Tout le monde a fait du bon travail ici. Le routeur Kube a un net avantage, mais WeaveNet n'a pas bien fonctionné : environ 20 % moins bon que le bare metal. Cilium et WeaveNet avec cryptage ont l'air vraiment tristes.
Avec FTP, un autre protocole basé sur TCP, les résultats varient. Flannel et Kube-router font le travail, mais Calico, Canal et Cilium sont un peu en retard et sont environ 10 % plus lents que le bare metal. WeaveNet est en retard jusqu'à 17 %, mais WeaveNet crypté a 40 % d'avance sur Cilium crypté.
Avec SCP, nous pouvons immédiatement voir combien nous coûte le cryptage SSH. Presque tous les CNI se portent bien, mais WeaveNet est encore à la traîne. Cilium et WeaveNet avec cryptage sont probablement les pires en raison du double cryptage (SSH + CNI).
Voici un tableau récapitulatif des résultats :
La consommation de ressources
Comparons maintenant comment CNI consomme des ressources sous de lourdes charges (lors d'un transfert TCP, 10 Gbps). Dans les tests de performances, nous comparons CNI au bare metal (ligne verte). Pour la consommation de ressources, montrons Kubernetes pur (ligne violette) sans CNI et voyons combien de ressources supplémentaires CNI consomme.
Commençons par la mémoire. Voici la valeur moyenne de la RAM des nœuds (hors tampons et cache) en Mo lors du transfert.
Consommation mémoire
Flannel et Kube-router ont montré d'excellents résultats - seulement 50 Mo. Calico et Canal en ont chacun 70. WeaveNet consomme clairement plus que les autres - 130 Mo, et Cilium en utilise jusqu'à 400.
Vérifions maintenant la consommation de temps CPU. Remarquable: le diagramme ne montre pas des pourcentages, mais des ppm, soit 38 ppm pour le « fer nu » soit 3,8 %. Voici les résultats:
Consommation du processeur
Calico, Canal, Flannel et Kube-router sont très efficaces en termes de CPU - seulement 2 % de plus que Kubernetes sans CNI. WeaveNet est loin derrière avec 5 % supplémentaires, suivi de Cilium avec 7 %.
Voici un résumé de la consommation des ressources :
Les résultats de
Tableau avec tous les résultats :
Résultats de référence généraux
Conclusion
Dans la dernière partie, j'exprimerai mon opinion subjective sur les résultats. N'oubliez pas que ce benchmark teste uniquement le débit d'une seule connexion sur un très petit cluster (3 nœuds). Cela ne s'applique pas aux grands clusters (<50 nœuds) ou aux connexions parallèles.
Je recommande d'utiliser les CNI suivants selon le scénario :
- Avez-vous dans votre cluster nœuds avec peu de ressources (plusieurs Go de RAM, plusieurs cœurs) et vous n'avez pas besoin de fonctionnalités de sécurité - choisissez Flanelle. C’est l’un des CNI les plus rentables. Et il est compatible avec une grande variété d’architectures (amd64, arm, arm64, etc.). De plus, il s’agit de l’un des deux CNI (l’autre est Cilium) qui peuvent déterminer automatiquement le MTU, vous n’avez donc rien à configurer. Kube-router convient également, mais ce n'est pas un standard et vous devrez configurer manuellement le MTU.
- Si nécessaire chiffrer le réseau pour votre sécurité, prenez TisserNet. N'oubliez pas de spécifier la taille MTU si vous utilisez des trames jumbo, et activez le cryptage en spécifiant un mot de passe via une variable d'environnement. Mais il vaut mieux oublier les performances : c’est le coût du cryptage.
- Pour utilisation normale Советую Calicot. Ce CNI est largement utilisé dans divers outils de déploiement Kubernetes (Kops, Kubespray, Rancher, etc.). Comme avec WeaveNet, assurez-vous de configurer le MTU dans ConfigMap si vous utilisez des trames jumbo. C'est un outil multifonctionnel efficace en termes de consommation de ressources, de performances et de sécurité.
Et enfin, je vous conseille de suivre l'évolution Cil. Ce CNI a une équipe très active qui travaille beaucoup sur son produit (fonctionnalités, économies de ressources, performances, sécurité, clustering...) et ils ont des projets très intéressants.
Schéma visuel pour la sélection CNI
Source: habr.com