🥇Benchmark de consommation de CPU pour Istio et Linkerd

Évaluation de la consommation CPU pour Istio et Linkerd

Introduction

Nous avons Shopify nous avons commencé à déployer Istio en tant que service mesh. En principe, tout va bien, sauf une chose : c'est cher.

Dans les benchmarks publiés pour Istio, il est dit :

Avec Istio 1.1, le proxy consomme environ 0,6 vCPU (cœurs virtuels) pour 1000 requêtes par seconde.

Pour la première région du service mesh (avec 2 proxies de chaque côté de la connexion), nous aurons 1200 cœurs juste pour les proxies, sur la base d'un million de requêtes par seconde. Selon le calculateur de coûts de Google, cela revient à environ 40 $/mois/cœur pour la configuration n1-standard-64, c'est-à-dire que cette région nous coûtera plus de 50 000 dollars par mois pour 1 million de requêtes par seconde.

Ivan Sim (Ivan Sim) a comparé visuellement les latences du service mesh l'année dernière et a promis la même chose pour la mémoire et le processeur, mais cela n'a pas fonctionné :

Apparemment, values-istio-test.yaml augmentera considérablement les demandes de CPU. Si j'ai bien calculé, il faut environ 24 cœurs de processeur pour le panneau de contrôle et 0,5 CPU pour chaque proxy. Je n'en ai pas autant. Je répéterai les tests quand on me donnera plus de ressources.

Je voulais voir par moi-même à quel point les performances d'Istio ressemblent à une autre service mesh open-source : Linkerd.

Installation du service mesh

Tout d'abord, j'ai installé dans le cluster SuperGloo:

$ supergloo init
installation de la version 0.3.12 de supergloo
utilisation de l'uri de chart https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources créé
serviceaccount/supergloo créé
serviceaccount/discovery créé
serviceaccount/mesh-discovery créé
clusterrole.rbac.authorization.k8s.io/discovery créé
clusterrole.rbac.authorization.k8s.io/mesh-discovery créé
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding créé
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding créé
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding créé
deployment.extensions/supergloo créé
deployment.extensions/discovery créé
deployment.extensions/mesh-discovery créé
installation réussie !

J'ai utilisé SuperGloo parce qu'il simplifie considérablement le déploiement initial du service mesh. Je n'ai presque rien eu à faire. En production, nous n'utilisons pas SuperGloo, mais pour une tâche comme celle-ci, il est parfait. J'ai dû exécuter littéralement quelques commandes pour chaque service mesh. J'ai utilisé deux clusters pour l'isolation - un pour Istio et un pour Linkerd.

L'expérience a été menée sur Google Kubernetes Engine. J'ai utilisé Kubernetes 1.12.7-gke.7 et un pool de nœuds n1-standard-4 avec l'autoscaling des nœuds (minimum 4, maximum 16).

Ensuite, j'ai installé les deux service meshes depuis la ligne de commande.

D'abord Linkerd :

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

Ensuite Istio :

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

Le crash-loop a duré plusieurs minutes, puis les panneaux de contrôle se sont stabilisés.

(Remarque : SuperGloo ne prend pour l'instant en charge que Istio 1.0.x. J'ai répété l'expérience avec Istio 1.1.3, mais je n'ai remarqué aucune différence significative.)

Configuration de l'injection automatique Istio

Pour qu'Istio installe le sidecar Envoy, nous utilisons un injecteur de sidecar — MutatingAdmissionWebhook. Nous n'en parlerons pas dans cet article. Je dirai seulement que c'est un contrôleur qui surveille l'accès de tous les nouveaux pod et ajoute dynamiquement le sidecar ainsi que l'initContainer, qui est responsable des tâches iptables.

Nous chez Shopify avons écrit notre propre contrôleur d'accès pour l'injection de sidecar, mais dans cette comparaison, j'ai pris le contrôleur fourni avec Istio. Le contrôleur par défaut injecte les sidecar lorsque le namespace a un label istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

Configuration de l'injection automatique Linkerd

Pour configurer l'injection de sidecar Linkerd, nous utilisons des annotations (je les ai ajoutées manuellement via kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Simulateur de tolérance aux pannes Istio

Nous avons développé un simulateur de tolérance aux pannes Istio pour expérimenter avec le trafic unique de Shopify. Nous avions besoin d'un outil capable de créer une topologie arbitraire représentant une partie spécifique du graphe de notre service avec une configuration dynamique pour modéliser des charges de travail spécifiques.

L'infrastructure de Shopify subit une forte pression pendant les ventes flash. Dans ce contexte, Shopify recommande aux vendeurs d'organiser plus souvent ce genre de ventes. De gros clients nous préviennent parfois d'une vente flash planifiée. D'autres la mettent en place de manière inattendue à tout moment de la journée ou de la nuit.

Nous souhaitions que notre simulateur de tolérance aux pannes modélise des flux de travail correspondant à des topologies et charges de travail qui avaient précédemment provoqué des surcharges de l'infrastructure de Shopify. L'objectif principal de l'utilisation d'un service mesh est d'assurer la fiabilité et la tolérance aux pannes au niveau du réseau, et il est crucial que le service mesh gère efficacement les charges qui avaient autrefois perturbé le fonctionnement des services.

Au cœur du simulateur de tolérance aux pannes se trouve un nœud de travail qui agit comme un nœud de service mesh. Ce nœud de travail peut être configuré statiquement au démarrage ou dynamiquement via une API REST. Nous utilisons la configuration dynamique des nœuds de travail pour créer des flux de travail sous forme de tests de régression.

Voici un exemple de ce processus :

Nous lançons 10 serveurs en tant que bar service qui renvoie une réponse 200/OK en 100 ms.
Nous lançons 10 clients — chacun envoie 100 requêtes par seconde à bar.
Toutes les 10 secondes, nous retirons 1 serveur et surveillons les erreurs 5xx du côté client.

À la fin du processus, nous examinons les journaux et les métriques pour vérifier si le test a été réussi. Cela nous permet d'analyser les performances de notre service mesh et de réaliser un test de régression pour évaluer nos hypothèses sur la tolérance aux pannes.

(Remarque : Nous envisageons d'ouvrir le code source du simulateur de tolérance aux pannes Istio, mais nous ne sommes pas encore prêts à le faire.)

Simulateur de tolérance aux pannes Istio pour le benchmarking de service mesh

Nous configurons plusieurs nœuds de travail pour le simulateur :

irs-client-loadgen: 3 répliques, chacune envoyant 100 requêtes par seconde vers irs-client.
irs-client: 3 répliques, qui reçoivent la requête, attendent 100 ms et redirigent la requête vers irs-server.
irs-server: 3 répliques, qui retournent 200/OK en 100 ms.

Avec cette configuration, nous pouvons mesurer un flux de trafic stable entre 9 points de terminaison. Les sidecars à irs-client-loadgen et irs-server reçoivent 100 requêtes par seconde, et irs-client — 200 (entrantes et sortantes).

Nous suivons l'utilisation des ressources via DataDog, car nous n'avons pas de cluster Prometheus.

Résultats

Panneaux de contrôle

Tout d'abord, nous avons examiné la consommation du CPU.

Le tableau de bord Linkerd ~22 milliards

Le tableau de bord Istio : ~750 milliards

Le tableau de bord Istio utilise environ 35 fois plus de ressources processeur, que Linkerd. Bien sûr, tout est configuré par défaut, et beaucoup de ressources processeur sont consommées par istio-telemetry (il peut être désactivé en renonçant à certaines fonctionnalités). Même sans ce composant, cela reste plus de 100 milliards, c'est-à-dire 4 fois plus, que Linkerd.

Proxy sidecar

Ensuite, nous avons vérifié l'utilisation du proxy. Il devrait y avoir une dépendance linéaire par rapport au nombre de requêtes, mais pour chaque sidecar, il y a certains frais généraux qui influencent la courbe.

Linkerd : ~100 milliards pour irs-client, ~50 milliards pour irs-client-loadgen

Les résultats semblent logiques, car le proxy client reçoit deux fois plus de trafic que le proxy loadgen : pour chaque requête sortante de loadgen, il y a une requête entrante et sortante pour le client.

Istio/Envoy : ~155 milliards pour irs-client, ~75 milliards pour irs-client-loadgen

Nous voyons des résultats similaires pour les sidecars d'Isto.

Mais dans l’ensemble, le proxy Istio/Envoy consomme environ 50% de ressources processeur en plus, que Linkerd.

Nous voyons le même schéma du côté serveur :

Linkerd : ~50 milliards pour irs-server

Istio/Envoy : ~80 milliards pour irs-server

Du côté serveur, le sidecar Istio/Envoy consomme environ 60% de ressources processeur en plus, que Linkerd.

Conclusion

Le proxy Istio Envoy consomme plus de 50% de CPU que Linkerd, sur notre charge de travail simulée. Le tableau de bord Linkerd consomme beaucoup moins de ressources que l'Isto, surtout en ce qui concerne les composants de base.

Nous réfléchissons encore à la façon de réduire ces coûts. Si vous avez des idées, partagez-les !

Source : habr.com