{"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\/da\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmarking af CPU-forbrug for Istio og Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmarking<\/p>\n

<\/p>\n

Introduktion<\/h2>\n

<\/p>\n

Vi i Shopify<\/a><\/noindex> Vi har arbejdet med at implementere Istio som service mesh. Generelt er alt tilfredsstillende, undtagen \u00e9n ting: det er dyrt<\/strong>.<\/p>\n

<\/p>\n

I offentliggjorte benchmarktests<\/a><\/noindex> for Istio hedder det:<\/p>\n

<\/p>\n

Med Istio 1.1 bruger proxien cirka 0,6 vCPU (virtuel kerne) pr. 1000 anmodninger pr. sekund.<\/p><\/blockquote>\n

For den f\u00f8rste region i service mesh (med 2 proxier p\u00e5 hver side af forbindelsen) vil vi have 1200 kerner kun til proxier, baseret p\u00e5 \u00e9n million anmodninger pr. sekund. If\u00f8lge Googles prismodel koster det cirka $40\/m\u00e5ned\/kerne til konfigurationen n1-standard-64<\/code>, hvilket betyder, at denne region vil koste os over 50.000 dollars om m\u00e5neden for 1 million anmodninger pr. sekund.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) sammenlignede tydeligt<\/a><\/noindex> forsinkelsen i service mesh fra sidste \u00e5r og lovede det samme for hukommelse og CPU, men det gik ikke:<\/p>\n

<\/p>\n

Det ser ud til, at values-istio-test.yaml vil \u00f8ge belastningen p\u00e5 CPU'en alvorligt. Hvis jeg regner rigtigt, skal der omkring 24 CPU-kerner til kontrolpanelet og 0,5 CPU pr. proxy. Jeg har ikke s\u00e5 mange. Jeg gentager testene, n\u00e5r jeg f\u00e5r tildelt flere ressourcer.<\/p><\/blockquote>\n

Jeg ville gerne selv opleve, hvorvidt Istios resultater svarer til en anden open-source service mesh: Linkerd<\/a><\/noindex>.<\/p>\n

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

Installation af service mesh<\/h3>\n

<\/p>\n

F\u00f8rst installerede jeg i klyngen SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstalling supergloo version 0.3.12\nusing chart uri https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources created\nserviceaccount\/supergloo created\nserviceaccount\/discovery created\nserviceaccount\/mesh-discovery created\nclusterrole.rbac.authorization.k8s.io\/discovery created\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery created\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding created\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding created\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding created\ndeployment.extensions\/supergloo created\ndeployment.extensions\/discovery created\ndeployment.extensions\/mesh-discovery created\ninstall successful!<\/code><\/pre>\n
<\/p>\n
Jeg brugte SuperGloo, fordi det g\u00f8r initialiseringen af service mesh betydeligt enklere. Jeg skulle n\u00e6sten ikke g\u00f8re noget. I produktionen bruger vi ikke SuperGloo, men til en opgave som denne er det ideelt. Jeg m\u00e5tte kun udf\u00f8re et par kommandoer for hver service mesh. Jeg brugte to klynger til isolation - \u00e9n for Istio og \u00e9n for Linkerd.<\/p>\n
<\/p>\n
Eksperimentet fandt sted p\u00e5 Google Kubernetes Engine. Jeg brugte Kubernetes 1.12.7-gke.7<\/code> og en node-pool n1-standard-4<\/code> med automatisk skaleringsfunktion (minimum 4, maksimum 16).<\/p>\n
<\/p>\n
Derefter installerede jeg begge service meshes fra kommandolinjen.<\/p>\n
<\/p>\n
F\u00f8rst 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
Derefter 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
Crash-loop tog  tog flere minutter, men kontrolpanelerne stabiliserede sig bagefter.<\/p>\n
<\/p>\n
(Bem\u00e6rk: SuperGloo underst\u00f8tter kun Istio 1.0.x. Jeg gentog eksperimentet med Istio 1.1.3, men jeg s\u00e5 ingen betydelig forskel.)<\/em><\/p>\n
<\/p>\n
Ops\u00e6tning af automatisk injektion af Istio<\/h3>\n
<\/p>\n
For at Istio kan installere sidecar Envoy, bruger vi sidecar-injektoren \u2014 MutatingAdmissionWebhook<\/code>. Vi vil ikke tale om det i denne artikel. Jeg vil kun sige, at det er en controller, der overv\u00e5ger adgangen til alle nye pods og dynamisk tilf\u00f8jer sidecar og initContainer, som st\u00e5r for opgaverne iptables<\/code>.<\/p>\n
<\/p>\n
Vi i Shopify har skrevet vores egen adgangscontroller til injektion af sidecars, men i denne benchmark brugte jeg den controller, der leveres med Istio. Standardcontrolleren injicerer sidecars, n\u00e5r der er et label i navnerummet 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
Ops\u00e6tning af automatisk injektion af Linkerd<\/h3>\n
<\/p>\n
For at konfigurere injektion af sidecars til Linkerd, bruger vi annotationer (jeg tilf\u00f8jede dem manuelt 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
Istio fejltolerance simulator<\/h3>\n
<\/p>\n
Vi har lavet en Istio fejltolerancsimulator for at eksperimentere med trafik, der er unik for Shopify. Vi havde brug for et v\u00e6rkt\u00f8j til at skabe en vilk\u00e5rlig topologi, der ville repr\u00e6sentere en bestemt del af grafen for vores service med dynamisk konfiguration til at modellere specifikke arbejdsbyrder.<\/p>\n
<\/p>\n
Shopify-infrastrukturen oplever stor belastning under flashudsalg. I den forbindelse anbefaler Shopify forhandlere at afholde s\u00e5danne udsalg oftere.<\/a><\/noindex>Store kunder varsler nogle gange om planlagte flashudsalg. Andre gennemf\u00f8rer dem uventet for os p\u00e5 alle tider af d\u00f8gnet.<\/p>\n
<\/p>\n
Vi \u00f8nskede, at vores fejltolerancsimulator skulle modellere arbejdsprocesser, som svarer til topologier og arbejdsbyrder, der tidligere har f\u00f8rt til overbelastning af Shopify-infrastrukturen. Hovedform\u00e5let med at bruge service mesh er, at vi har brug for p\u00e5lidelighed og fejltolerance p\u00e5 netv\u00e6rksniveau, og det er vigtigt for os, at service mesh effektivt h\u00e5ndterer belastninger, som tidligere har forstyrret driften af tjenester.<\/p>\n
<\/p>\n
I centrum af fejltolerancsimulatoren ligger en arbejdsnode, der fungerer som en node i service mesh. Arbejdsnode kan konfigureres statisk ved opstart eller dynamisk via REST API. Vi bruger dynamisk konfiguration af arbejdsnoder til at skabe arbejdsprocesser i form af regressions tests.<\/p>\n
<\/p>\n
Her er et eksempel p\u00e5 en s\u00e5dan proces:<\/p>\n
<\/p>\n