{"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\/nl\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmark CPU-verbruik voor Istio en Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmark<\/p>\n

<\/p>\n

Inleiding<\/h2>\n

<\/p>\n

Wij bij Shopify<\/a><\/noindex> we hebben Istio als service mesh uitgerold. In principe is alles goed, behalve \u00e9\u00e9n ding: het is duur<\/strong>.<\/p>\n

<\/p>\n

In gepubliceerde benchmarks<\/a><\/noindex> voor Istio staat:<\/p>\n

<\/p>\n

Met Istio 1.1 verbruikt de proxy ongeveer 0,6 vCPU (virtuele cores) per 1000 aanvragen per seconde.<\/p><\/blockquote>\n

Voor de eerste regio in de service mesh (met 2 proxies aan elke kant van de verbinding) hebben we 1200 cores alleen voor de proxy, uitgaande van \u00e9\u00e9n miljoen aanvragen per seconde. Volgens de kostencalculator van Google komt dit neer op ongeveer $40\/maand\/core voor de configuratie n1-standard-64<\/code>, dat wil zeggen, alleen deze regio kost ons meer dan 50 duizend dollar per maand voor 1 miljoen aanvragen per seconde.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) vergeleek inzichtelijk<\/a><\/noindex> de latentie van service mesh vorig jaar en beloofde hetzelfde voor geheugen en CPU, maar dat is niet gelukt:<\/p>\n

<\/p>\n

Blijkbaar verhoogt values-istio-test.yaml de CPU-aanvragen aanzienlijk. Als ik het goed heb berekend, zijn er ongeveer 24 CPU-cores nodig voor het beheerpaneel en 0,5 CPU voor elke proxy. Ik heb die niet. Ik zal de tests herhalen zodra ik meer middelen toegewezen krijg.<\/p><\/blockquote>\n

Ik wilde zelf controleren hoe de statistieken van Istio zich verhouden tot een andere open-source service mesh: Linkerd<\/a><\/noindex>.<\/p>\n

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

Installatie van de service mesh<\/h3>\n

<\/p>\n

Als eerste heb ik in de cluster ge\u00efnstalleerd 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
Ik heb SuperGloo gebruikt omdat het de initi\u00eble installatie van de service mesh aanzienlijk vereenvoudigt. Ik hoefde bijna niets te doen. In productie gebruiken we SuperGloo niet, maar voor deze taak is het perfect. Ik moest letterlijk maar een paar commando's per service mesh uitvoeren. Ik gebruikte twee clusters voor isolatie - \u00e9\u00e9n voor Istio en \u00e9\u00e9n voor Linkerd.<\/p>\n
<\/p>\n
Het experiment werd uitgevoerd op Google Kubernetes Engine. Ik gebruikte Kubernetes 1.12.7-gke.7<\/code> en een nodepool n1-standard-4<\/code> met automatische schaling van nodes (minimum 4, maximum 16).<\/p>\n
<\/p>\n
Daarna installeerde ik beide service meshes vanuit de commandoregel.<\/p>\n
<\/p>\n
Eerst 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
Vervolgens 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
De crash-loop duurde enkele minuten, en daarna stabiliseerden de beheertools.<\/p>\n
<\/p>\n
(Opmerking. SuperGloo ondersteunt momenteel alleen Istio 1.0.x. Ik herhaalde het experiment met Istio 1.1.3, maar merkte geen significante verschillen.)<\/em><\/p>\n
<\/p>\n
Instelling van automatische injectie voor Istio<\/h3>\n
<\/p>\n
Om Istio een sidecar Envoy te laten installeren, gebruiken we de sidecar-injector \u2014 MutatingAdmissionWebhook<\/code>. We zullen hier niet verder op ingaan in dit artikel. Ik wil alleen zeggen dat dit een controller is die toezicht houdt op de toegang van nieuwe pods en dynamisch de sidecar en initContainer toevoegt die verantwoordelijk is voor taken. iptables<\/code>.<\/p>\n
<\/p>\n
Bij Shopify hebben we onze eigen toegangscontroller geschreven voor het injecteren van sidecars, maar in deze benchmark heb ik de controller gebruikt die wordt geleverd met Istio. De standaardcontroller injecteert sidecars wanneer er een label in de namespace is. istio-injection: enabled<\/code>:<\/p>\n
<\/p>\n
$ kubectl label namespace irs-client-dev istio-injection=enabled\nnamespace\/irs-client-dev gelabeld\n\n$ kubectl label namespace irs-server-dev istio-injection=enabled\nnamespace\/irs-server-dev gelabeld<\/code><\/pre>\n
<\/p>\n
Instelling van automatische injectie voor Linkerd<\/h3>\n
<\/p>\n
Om sidecar-injectie voor Linkerd in te stellen, gebruiken we annotaties (ik heb ze handmatig toegevoegd via kubectl edit<\/code>):<\/p>\n
<\/p>\n
metadata:\n  annotaties:\n    linkerd.io\/inject: enabled<\/code><\/pre>\n
<\/p>\n
$ k edit ns irs-server-dev \nnamespace\/irs-server-dev bewerkt\n\n$ k get ns irs-server-dev -o yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  annotaties:\n    linkerd.io\/inject: enabled\n  naam: irs-server-dev\nspec:\n  finalizers:\n  - kubernetes\nstatus:\n  fase: Actief<\/code><\/pre>\n
<\/p>\n
Simulator voor fouttolerantie van Istio<\/h3>\n
<\/p>\n
We hebben een fouttolerantiesimulator voor Istio gemaakt om te experimenteren met Shopify-specifiek verkeer. We hadden een tool nodig om een willekeurige topologie te cre\u00ebren die een bepaald deel van de graf van onze dienst vertegenwoordigt, met dynamische configuratie om specifieke werklasten te modelleren.<\/p>\n
<\/p>\n
De infrastructuur van Shopify wordt zwaar belast tijdens flashverkopen. Tijdens deze periode raadt Shopify verkopers aan om vaker dergelijke verkopen te houden.<\/a><\/noindex>Grote klanten waarschuwen soms voor een geplande flashverkoop. Anderen voeren deze opeens door op elk moment van de dag en nacht.<\/p>\n
<\/p>\n
We wilden dat onze fouttolerantiesimulator de werkprocessen modelleert die overeenkomen met de topologie\u00ebn en werklasten die in het verleden de infrastructuur van Shopify hebben overweldigd. Het belangrijkste doel van het gebruik van een service mesh is dat we betrouwbaarheid en fouttolerantie op netwerkniveau nodig hebben, en het is belangrijk voor ons dat de service mesh effectief omgaat met de workloads die eerder de diensten verstoorden.<\/p>\n
<\/p>\n
De simulator voor fouttolerantie is gebaseerd op een actieve node die fungeert als een service mesh-node. De actieve node kan statisch worden geconfigureerd bij het opstarten of dynamisch via de REST-API. We gebruiken dynamische configuratie van actieve nodes om workflows te cre\u00ebren in de vorm van regressietests.<\/p>\n
<\/p>\n
Hier is een voorbeeld van zo'n proces:<\/p>\n
<\/p>\n