{"id":34366,"date":"2019-10-31T21:57:56","date_gmt":"2019-10-31T18:57:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd\/"},"modified":"2019-10-31T21:57:56","modified_gmt":"2019-10-31T18:57:56","slug":"benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"\u00c9valuation de la consommation CPU pour Istio et Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00c9valuation<\/p>\n

<\/p>\n

Introduction<\/h2>\n

<\/p>\n

Nous avons Shopify<\/a><\/noindex> nous avons commenc\u00e9 \u00e0 d\u00e9ployer Istio en tant que service mesh. En principe, tout va bien, sauf une chose : c'est cher<\/strong>.<\/p>\n

<\/p>\n

Dans les benchmarks publi\u00e9s<\/a><\/noindex> pour Istio, il est dit :<\/p>\n

<\/p>\n

Avec Istio 1.1, le proxy consomme environ 0,6 vCPU (c\u0153urs virtuels) pour 1000 requ\u00eates par seconde.<\/p><\/blockquote>\n

Pour la premi\u00e8re r\u00e9gion du service mesh (avec 2 proxies de chaque c\u00f4t\u00e9 de la connexion), nous aurons 1200 c\u0153urs juste pour les proxies, sur la base d'un million de requ\u00eates par seconde. Selon le calculateur de co\u00fbts de Google, cela revient \u00e0 environ 40 $\/mois\/c\u0153ur pour la configuration n1-standard-64<\/code>, c'est-\u00e0-dire que cette r\u00e9gion nous co\u00fbtera plus de 50 000 dollars par mois pour 1 million de requ\u00eates par seconde.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) a compar\u00e9 visuellement<\/a><\/noindex> les latences du service mesh l'ann\u00e9e derni\u00e8re et a promis la m\u00eame chose pour la m\u00e9moire et le processeur, mais cela n'a pas fonctionn\u00e9 :<\/p>\n

<\/p>\n

Apparemment, values-istio-test.yaml augmentera consid\u00e9rablement les demandes de CPU. Si j'ai bien calcul\u00e9, il faut environ 24 c\u0153urs de processeur pour le panneau de contr\u00f4le et 0,5 CPU pour chaque proxy. Je n'en ai pas autant. Je r\u00e9p\u00e9terai les tests quand on me donnera plus de ressources.<\/p><\/blockquote>\n

Je voulais voir par moi-m\u00eame \u00e0 quel point les performances d'Istio ressemblent \u00e0 une autre service mesh open-source : Linkerd<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Installation du service mesh<\/h3>\n

<\/p>\n

Tout d'abord, j'ai install\u00e9 dans le cluster SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstallation de la version 0.3.12 de supergloo\nutilisation de l'uri de chart https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources cr\u00e9\u00e9\nserviceaccount\/supergloo cr\u00e9\u00e9\nserviceaccount\/discovery cr\u00e9\u00e9\nserviceaccount\/mesh-discovery cr\u00e9\u00e9\nclusterrole.rbac.authorization.k8s.io\/discovery cr\u00e9\u00e9\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery cr\u00e9\u00e9\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding cr\u00e9\u00e9\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding cr\u00e9\u00e9\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding cr\u00e9\u00e9\ndeployment.extensions\/supergloo cr\u00e9\u00e9\ndeployment.extensions\/discovery cr\u00e9\u00e9\ndeployment.extensions\/mesh-discovery cr\u00e9\u00e9\ninstallation r\u00e9ussie !<\/code><\/pre>\n
<\/p>\n
J'ai utilis\u00e9 SuperGloo parce qu'il simplifie consid\u00e9rablement le d\u00e9ploiement initial du service mesh. Je n'ai presque rien eu \u00e0 faire. En production, nous n'utilisons pas SuperGloo, mais pour une t\u00e2che comme celle-ci, il est parfait. J'ai d\u00fb ex\u00e9cuter litt\u00e9ralement quelques commandes pour chaque service mesh. J'ai utilis\u00e9 deux clusters pour l'isolation - un pour Istio et un pour Linkerd.<\/p>\n
<\/p>\n
L'exp\u00e9rience a \u00e9t\u00e9 men\u00e9e sur Google Kubernetes Engine. J'ai utilis\u00e9 Kubernetes 1.12.7-gke.7<\/code> et un pool de n\u0153uds n1-standard-4<\/code> avec l'autoscaling des n\u0153uds (minimum 4, maximum 16).<\/p>\n
<\/p>\n
Ensuite, j'ai install\u00e9 les deux service meshes depuis la ligne de commande.<\/p>\n
<\/p>\n
D'abord Linkerd :<\/p>\n
<\/p>\n
$ supergloo install linkerd --name linkerd\n+---------+--------------+---------+---------------------------+\n| INSTALL |     TYPE     | STATUS  |          DETAILS          |\n+---------+--------------+---------+---------------------------+\n| linkerd | Linkerd Mesh | Pending | enabled: true             |\n|         |              |         | version: stable-2.3.0     |\n|         |              |         | namespace: linkerd        |\n|         |              |         | mtls enabled: true        |\n|         |              |         | auto inject enabled: true |\n+---------+--------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Ensuite Istio :<\/p>\n
<\/p>\n
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true\n+---------+------------+---------+---------------------------+\n| INSTALL |    TYPE    | STATUS  |          DETAILS          |\n+---------+------------+---------+---------------------------+\n| istio   | Istio Mesh | Pending | enabled: true             |\n|         |            |         | version: 1.0.6            |\n|         |            |         | namespace: istio-system   |\n|         |            |         | mtls enabled: true        |\n|         |            |         | auto inject enabled: true |\n|         |            |         | grafana enabled: true     |\n|         |            |         | prometheus enabled: true  |\n|         |            |         | jaeger enabled: true      |\n+---------+------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Le crash-loop a dur\u00e9 plusieurs minutes, puis les panneaux de contr\u00f4le se sont stabilis\u00e9s.<\/p>\n
<\/p>\n
(Remarque : SuperGloo ne prend pour l'instant en charge que Istio 1.0.x. J'ai r\u00e9p\u00e9t\u00e9 l'exp\u00e9rience avec Istio 1.1.3, mais je n'ai remarqu\u00e9 aucune diff\u00e9rence significative.)<\/em><\/p>\n
<\/p>\n
Configuration de l'injection automatique Istio<\/h3>\n
<\/p>\n
Pour qu'Istio installe le sidecar Envoy, nous utilisons un injecteur de sidecar \u2014 MutatingAdmissionWebhook<\/code>. Nous n'en parlerons pas dans cet article. Je dirai seulement que c'est un contr\u00f4leur qui surveille l'acc\u00e8s de tous les nouveaux pod et ajoute dynamiquement le sidecar ainsi que l'initContainer, qui est responsable des t\u00e2ches iptables<\/code>.<\/p>\n
<\/p>\n
Nous chez Shopify avons \u00e9crit notre propre contr\u00f4leur d'acc\u00e8s pour l'injection de sidecar, mais dans cette comparaison, j'ai pris le contr\u00f4leur fourni avec Istio. Le contr\u00f4leur par d\u00e9faut injecte les sidecar lorsque le namespace a un label istio-injection: enabled<\/code>:<\/p>\n
<\/p>\n
$ kubectl label namespace irs-client-dev istio-injection=enabled\nnamespace\/irs-client-dev labeled\n\n$ kubectl label namespace irs-server-dev istio-injection=enabled\nnamespace\/irs-server-dev labeled<\/code><\/pre>\n
<\/p>\n
Configuration de l'injection automatique Linkerd<\/h3>\n
<\/p>\n
Pour configurer l'injection de sidecar Linkerd, nous utilisons des annotations (je les ai ajout\u00e9es manuellement via kubectl edit<\/code>):<\/p>\n
<\/p>\n
metadata:\n  annotations:\n    linkerd.io\/inject: enabled<\/code><\/pre>\n
<\/p>\n
$ k edit ns irs-server-dev \nnamespace\/irs-server-dev edited\n\n$ k get ns irs-server-dev -o yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  annotations:\n    linkerd.io\/inject: enabled\n  name: irs-server-dev\nspec:\n  finalizers:\n  - kubernetes\nstatus:\n  phase: Active<\/code><\/pre>\n
<\/p>\n
Simulateur de tol\u00e9rance aux pannes Istio<\/h3>\n
<\/p>\n
Nous avons d\u00e9velopp\u00e9 un simulateur de tol\u00e9rance aux pannes Istio pour exp\u00e9rimenter avec le trafic unique de Shopify. Nous avions besoin d'un outil capable de cr\u00e9er une topologie arbitraire repr\u00e9sentant une partie sp\u00e9cifique du graphe de notre service avec une configuration dynamique pour mod\u00e9liser des charges de travail sp\u00e9cifiques.<\/p>\n
<\/p>\n
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<\/a><\/noindex>. De gros clients nous pr\u00e9viennent parfois d'une vente flash planifi\u00e9e. D'autres la mettent en place de mani\u00e8re inattendue \u00e0 tout moment de la journ\u00e9e ou de la nuit.<\/p>\n
<\/p>\n
Nous souhaitions que notre simulateur de tol\u00e9rance aux pannes mod\u00e9lise des flux de travail correspondant \u00e0 des topologies et charges de travail qui avaient pr\u00e9c\u00e9demment provoqu\u00e9 des surcharges de l'infrastructure de Shopify. L'objectif principal de l'utilisation d'un service mesh est d'assurer la fiabilit\u00e9 et la tol\u00e9rance aux pannes au niveau du r\u00e9seau, et il est crucial que le service mesh g\u00e8re efficacement les charges qui avaient autrefois perturb\u00e9 le fonctionnement des services.<\/p>\n
<\/p>\n
Au c\u0153ur du simulateur de tol\u00e9rance aux pannes se trouve un n\u0153ud de travail qui agit comme un n\u0153ud de service mesh. Ce n\u0153ud de travail peut \u00eatre configur\u00e9 statiquement au d\u00e9marrage ou dynamiquement via une API REST. Nous utilisons la configuration dynamique des n\u0153uds de travail pour cr\u00e9er des flux de travail sous forme de tests de r\u00e9gression.<\/p>\n
<\/p>\n
Voici un exemple de ce processus :<\/p>\n
<\/p>\n