Il s'agit d'une mise à jour de mon précédent benchmark , qui fonctionne désormais sur Kubernetes 1.14 avec la version actuelle de CNI pour avril 2019.
Tout d'abord, je tiens à remercier l'équipe Cilium: les gars m'ont aidé à vérifier et à corriger les scripts de surveillance des métriques.
Ce qui a changé depuis novembre 2018
Voici ce qui a changé depuis (si vous êtes intéressé):
La flanelle reste l'interface la plus rapide et la plus simple de CNI, mais ne prend toujours pas en charge les stratégies réseau et le cryptage.
Romana n'est plus pris en charge, nous l'avons donc supprimé de la référence.
WeaveNet prend désormais en charge les stratégies réseau pour Ingress et Egress! Mais la productivité a baissé.
Dans Calico, vous devez toujours configurer manuellement la taille maximale des paquets (MTU) pour de meilleures performances. Calico propose deux options d'installation CNI, vous pouvez donc vous passer d'un référentiel ETCD distinct:
- stockage d'état dans l'API Kubernetes en tant que magasin de données (taille de cluster <50 nœuds);
- stockage d'état dans l'API Kubernetes en tant que magasin de données avec le proxy Typha pour soulager la charge de l'API K8S (taille de cluster> 50 nœuds).
Calico annonce une prise en charge des politiques au niveau des applications en plus d'Istio pour la sécurité au niveau des applications.
Cilium prend désormais en charge le cryptage! Cilium fournit le chiffrement avec des tunnels IPSec et offre 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 essayé de réduire le poids de son CNI, réduisant la consommation de mémoire et les coûts de processeur, mais les concurrents sont toujours plus légers.
Contexte de référence
La référence est exécutée sur trois serveurs Supermicro non virtualisés avec un commutateur Supermicro de 10 Go. Les serveurs sont connectés directement au commutateur via des câbles DFP SFP + passifs et configurés dans le même VLAN avec des trames jumbo (MTU 9000).
Kubernetes 1.14.0 est installé sur Ubuntu 18.04 LTS avec Docker 18.09.2 (la version par défaut de Docker 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 de la référence sur le deuxième serveur et la partie client sur le troisième. Pour cela, nous utilisons NodeSelector dans les déploiements Kubernetes.
Les résultats de référence seront décrits sur une telle échelle:
Choisir CNI comme référence
Il s'agit d'une référence CNI uniquement dans la liste de la section sur la création d'un cluster maître avec kubeadm dans la documentation officielle de Kubernetes. De CNI 9, nous n'en prenons que 6: nous excluons ceux qui sont difficiles à installer et / ou qui ne fonctionnent pas sans configuration de la documentation (Romana, Contiv-VPP et JuniperContrail / TungstenFabric).
Nous comparerons les CNI suivants:
- Calico v3.6
- Canal v3.6 (essentiellement une Flanelle pour la mise en réseau + Calico comme un pare-feu)
- Cilium 1.4.2
- Flanelle 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
L'installation
Plus il est facile d'installer CNI, meilleure sera notre première impression. Tous les CNI du benchmark sont très simples à installer (avec une ou deux équipes).
Comme nous l'avons dit, le serveur et le commutateur sont configurés avec des trames jumbo activées (nous avons installé MTU 9000). Nous serions heureux si CNI déterminait automatiquement le MTU en fonction des paramètres de l'adaptateur. Cependant, seuls Cilium et Flannel s'en sont occupés. Les CNI restants ont des demandes sur GitHub pour ajouter la détection automatique de MTU, mais nous allons la configurer manuellement en changeant le ConfigMap pour Calico, Canal et Kube-router, ou en passant une variable d'environnement pour WeaveNet.
Quel est le problème avec le mauvais MTU? Ce diagramme montre la différence entre WeaveNet avec le MTU par défaut et les trames jumbo activées:
Comment MTU affecte la bande passante
Nous avons compris l'importance du MTU pour les performances, et voyons maintenant comment nos CNI le détectent automatiquement:
CNI détecte automatiquement MTU
Le graphique montre que vous devez configurer MTU pour Calico, Canal, Kube-router et WeaveNet pour des performances optimales. Cilium et Flannel eux-mêmes ont pu déterminer correctement le MTU sans aucun réglage.
La sécurité
Nous comparerons la sécurité CNI sous deux aspects: la capacité de crypter les données transmises et la mise en œuvre des politiques du réseau Kubernetes (selon de vrais tests, pas selon la documentation).
Seuls deux CNI chiffrent les données: Cilium et WeaveNet. Le cryptage WeaveNet est activé en définissant le mot de passe de cryptage comme variable d'environnement CNI. La documentation WeaveNet décrit que c'est compliqué, mais tout se fait simplement. Le cryptage Cilium est configuré par des commandes, en créant des secrets Kubernetes et en modifiant daemonSet (un peu plus compliqué que dans WeaveNet, mais Cilium a des instructions pas à pas).
En ce qui concerne la mise en œuvre de la politique de réseau, Calico, Canal, Cilium et WeaveNet ont réussi ici, dans lequel vous pouvez configurer les règles d'entrée et de sortie. Pour le routeur Kube, il n'y a de règles que pour Ingress, tandis que Flannel n'a aucune politique de réseau.
Voici les résultats généraux:
Résultats de référence pour les fonctionnalités de sécurité
Performances
Cette référence montre le débit moyen pour au moins trois exécutions de chaque test. Nous testons les performances de TCP et UDP (en utilisant iperf3), de vraies applications, par exemple HTTP (avec Nginx et curl) ou FTP (avec vsftpd et curl), et enfin, des applications utilisant le cryptage basé sur le protocole SCP (en utilisant client et serveur OpenSSH).
Pour tous les tests, nous avons fait un benchmark nu (ligne verte) pour comparer les performances CNI avec les performances du réseau natif. Ici, nous utilisons la même échelle, mais la couleur:
- Jaune = très bon
- Orange = bon
- Bleu = so-so
- Rouge = mauvais
Nous ne prendrons pas de CNI mal configurés et afficherons uniquement les résultats des CNI avec le MTU correct. (Remarque: Cilium ne prend pas correctement en compte MTU si le cryptage est activé, vous devrez donc réduire manuellement MTU à 8900 dans la version 1.4. Dans la prochaine version, 1.5, cela se fait automatiquement.)
Voici les résultats:
Performances TCP
Tous les CNI ont bien performé dans le benchmark TCP. Les CNI chiffrés sont loin derrière car le chiffrement coûte cher.
Performances UDP
Ici aussi, tous les CNI se portent bien. Les CNI cryptés ont montré presque le même résultat. Cilium est légèrement en retard sur ses concurrents, mais il ne représente que 2,3% du métal nu, donc le résultat n'est pas mauvais. N'oubliez pas que seuls Cilium et Flannel eux-mêmes ont correctement déterminé le MTU, et ce sont leurs résultats sans configuration supplémentaire.
Que diriez-vous d'une vraie application? Comme vous pouvez le voir, pour HTTP, les performances globales sont légèrement inférieures à celles de TCP. Même si vous utilisez HTTP avec TCP, dans le benchmark TCP, nous avons configuré iperf3 pour éviter un démarrage lent, et cela affectera le benchmark HTTP. Tout a été bien fait ici. Le routeur Kube a un avantage évident, et WeaveNet ne s'est pas montré du meilleur côté: environ 20% pire que le métal nu. Cilium et WeaveNet avec cryptage ont l'air très tristes.
Avec FTP, un autre protocole basé sur TCP, les résultats sont différents. La flanelle et le routeur Kube se débrouillent, tandis que Calico, Canal et Cilium sont légèrement en retrait et fonctionnent environ 10% plus lentement que le métal nu. WeaveNet ne suit pas jusqu'à 17%, mais WeaveNet avec cryptage a 40% d'avance sur Cilium crypté.
Avec SCP, vous pouvez immédiatement voir ce que le chiffrement SSH nous coûte. Presque tous les CNI le font et WeaveNet est à nouveau à la traîne. Cilium et WeaveNet avec cryptage devraient être les pires de tous en raison du double cryptage (SSH + CNI).
Voici un tableau récapitulatif avec les résultats:
Consommation de ressources
Comparons maintenant la façon dont CNI consomme les ressources sous de lourdes charges (pendant la transmission sur TCP, 10 Gb / s). Dans les tests de performance, nous comparons CNI avec du métal nu (ligne verte). Pour consommer des ressources, nous allons montrer des Kubernetes purs (ligne violette) sans CNI et voir combien de ressources supplémentaires CNI consomme.
Commençons par la mémoire. Voici la valeur moyenne de la mémoire hôte (sans tampons et cache) en Mo lors du transfert.
Consommation de mémoire
La flanelle et le routeur Kube 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, tandis que Cilium en utilise jusqu'à 400.
Vérifions maintenant l'utilisation du CPU. À noter : dans le diagramme, pas des pourcentages, mais pour mille, c'est-à -dire 38 ppm pour le «fer nu» - c'est 3,8%. Voici les résultats:
Consommation CPU
Calico, Canal, Flannel et Kube-router utilisent le processeur très efficacement - seulement 2% de plus que Kubernetes sans CNI. WeaveNet est loin derrière avec 5% supplémentaires, suivi de Cilium - 7%.
Voici un résumé de la consommation des ressources:
Résumé
Tableau avec tous les résultats:
Résultats de référence généraux
Conclusion
Dans la dernière partie, je vais exprimer mon opinion subjective sur les résultats. N'oubliez pas que cette référence teste uniquement le débit d'une connexion sur un très petit cluster (3 nœuds). Elle 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:
- Vous avez des nœuds avec une petite quantité de ressources dans votre cluster (plusieurs Go de RAM, plusieurs cœurs) et vous n'avez pas besoin de fonctionnalités de sécurité - choisissez Flannel . C'est l'un des CNI les plus économiques. 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 (le second est Cilium) CNI, qui peut déterminer automatiquement le MTU, de sorte que vous n'avez rien à configurer. Le routeur Kube convient également, mais il n'est pas si standard et vous devrez configurer manuellement MTU.
- Si vous devez crypter le réseau pour des raisons de sécurité, utilisez WeaveNet . N'oubliez pas de spécifier la taille du MTU, si vous utilisez des trames jumbo, et activez le chiffrement en spécifiant un mot de passe via une variable d'environnement. Mais il vaut mieux oublier les performances - ce sont les frais de cryptage.
- Pour une utilisation normale, je recommande Calico . Ce CNI est largement utilisé dans divers outils de déploiement de Kubernetes (Kops, Kubespray, Rancher, etc.). Comme avec WeaveNet, n'oubliez pas de configurer le MTU dans ConfigMap si vous utilisez des trames jumbo. Il s'agit d'un outil multifonctionnel, efficace en termes de consommation de ressources, de productivité et de sécurité.
Et enfin, je vous conseille de suivre le développement de Cilium . Ce CNI dispose d'une équipe très active qui travaille beaucoup sur son produit (fonctions, économie de ressources, productivité, sécurité, distribution de cluster ...), et ils ont des plans très intéressants.
Diagramme visuel pour CNI Choice