Benchmark CPU-verbruik voor Istio en Linkerd

Inleiding

Wij bij Shopify we hebben Istio als service mesh uitgerold. In principe is alles goed, behalve één ding: het is duur.

In gepubliceerde benchmarks voor Istio staat:

Met Istio 1.1 verbruikt de proxy ongeveer 0,6 vCPU (virtuele cores) per 1000 aanvragen per seconde.

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 één miljoen aanvragen per seconde. Volgens de kostencalculator van Google komt dit neer op ongeveer $40/maand/core voor de configuratie n1-standard-64, dat wil zeggen, alleen deze regio kost ons meer dan 50 duizend dollar per maand voor 1 miljoen aanvragen per seconde.

Ivan Sim (Ivan Sim) vergeleek inzichtelijk de latentie van service mesh vorig jaar en beloofde hetzelfde voor geheugen en CPU, maar dat is niet gelukt:

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.

Ik wilde zelf controleren hoe de statistieken van Istio zich verhouden tot een andere open-source service mesh: Linkerd.

Installatie van de service mesh

Als eerste heb ik in de cluster geïnstalleerd SuperGloo:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

Ik heb SuperGloo gebruikt omdat het de initiële 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 - één voor Istio en één voor Linkerd.

Het experiment werd uitgevoerd op Google Kubernetes Engine. Ik gebruikte Kubernetes 1.12.7-gke.7 en een nodepool n1-standard-4 met automatische schaling van nodes (minimum 4, maximum 16).

Daarna installeerde ik beide service meshes vanuit de commandoregel.

Eerst 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 |
+---------+--------------+---------+---------------------------+

Vervolgens 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      |
+---------+------------+---------+---------------------------+

De crash-loop duurde enkele minuten, en daarna stabiliseerden de beheertools.

(Opmerking. SuperGloo ondersteunt momenteel alleen Istio 1.0.x. Ik herhaalde het experiment met Istio 1.1.3, maar merkte geen significante verschillen.)

Instelling van automatische injectie voor Istio

Om Istio een sidecar Envoy te laten installeren, gebruiken we de sidecar-injector — MutatingAdmissionWebhook. 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.

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:

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

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

Instelling van automatische injectie voor Linkerd

Om sidecar-injectie voor Linkerd in te stellen, gebruiken we annotaties (ik heb ze handmatig toegevoegd via kubectl edit):

metadata:
  annotaties:
    linkerd.io/inject: enabled

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

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotaties:
    linkerd.io/inject: enabled
  naam: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  fase: Actief

Simulator voor fouttolerantie van Istio

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ëren die een bepaald deel van de graf van onze dienst vertegenwoordigt, met dynamische configuratie om specifieke werklasten te modelleren.

De infrastructuur van Shopify wordt zwaar belast tijdens flashverkopen. Tijdens deze periode raadt Shopify verkopers aan om vaker dergelijke verkopen te houden.Grote klanten waarschuwen soms voor een geplande flashverkoop. Anderen voeren deze opeens door op elk moment van de dag en nacht.

We wilden dat onze fouttolerantiesimulator de werkprocessen modelleert die overeenkomen met de topologieën 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.

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ëren in de vorm van regressietests.

Hier is een voorbeeld van zo'n proces:

• We starten 10 servers als bar een dienst die een reactie terugstuurt 200/OK binnen 100 ms.
• We starten 10 clients — elke client verzendt 100 verzoeken per seconde naar bar.
• Elke 10 seconden halen we 1 server weg en monitoren we fouten 5xx aan de clientzijde.

Aan het einde van het werkproces bestuderen we de logs en metrics en controleren we of de test is doorstaan. Zo leren we over de prestaties van onze service mesh en voeren we een regressietest uit om onze aannames over fouttolerantie te controleren.

(Opmerking. We overwegen de broncode van de Istio fouttolerantiesimulator vrij te geven, maar zijn daar nog niet klaar voor.)

Fouttolerantiesimulator voor Istio voor benchmarking van de service mesh

We configureren meerdere actieve nodes van de simulator:

• irs-client-loadgen: 3 replica's die elk 100 verzoeken per seconde verzenden naar irs-client.
• irs-client: 3 replica's die verzoeken ontvangen, 100 ms wachten en het verzoek doorsturen naar irs-server.
• irs-server: 3 replica's die antwoorden teruggeven 200/OK binnen 100 ms.

Met deze configuratie kunnen we een stabiele verkeersstroom meten tussen 9 eindpunten. Sidecar's in irs-client-loadgen en irs-server ontvangen elk 100 verzoeken per seconde, terwijl irs-client — 200 (inkomende en uitgaande).

We volgen het gebruik van middelen via DataDog, omdat we geen Prometheus-cluster hebben.

Resultaten

Beheerpanelen

Eerst hebben we het CPU-verbruik bestudeerd.

Linkerd-dashboard ~22 miljard

Istio-dashboard: ~750 miljard

Het Istio-dashboard gebruikt ongeveer 35 keer meer CPU-bronnen, dan Linkerd. Natuurlijk is alles op de standaardinstellingen ingesteld, en veel CPU-bronnen worden hier geconsumeerd door istio-telemetry (dit kan worden uitgeschakeld door enkele functies op te geven). Zelfs zonder deze component is er nog steeds meer dan 100 miljard, dat is 4 keer meer, dan bij Linkerd.

Sidecar-proxy

Vervolgens hebben we het gebruik van de proxy gecontroleerd. Er zou een lineaire relatie moeten zijn met het aantal verzoeken, maar voor elke sidecar zijn er enkele overheadkosten die de curve beïnvloeden.

Linkerd: ~100 miljard voor irs-client, ~50 miljard voor irs-client-loadgen

De resultaten lijken logisch, aangezien de client-proxy twee keer zoveel verkeer ontvangt als de loadgen-proxy: voor elk uitgaand verzoek van loadgen komt er één inkomend en één uitgaand bij de client.

Istio/Envoy: ~155 miljard voor irs-client, ~75 miljard voor irs-client-loadgen

We zien vergelijkbare resultaten voor de Istio-sidecar's.

Maar over het algemeen verbruiken de Istio/Envoy-proxy's ongeveer 50% meer CPU-bronnen, dan Linkerd.

We zien hetzelfde patroon aan de serverzijde:

Linkerd: ~50 miljard voor irs-server

Istio/Envoy: ~80 miljard voor irs-server

Aan de serverzijde verbruikt de Istio/Envoy-sidecar ongeveer 60% meer CPU-bronnen, dan Linkerd.

Conclusie

De Istio Envoy-proxy verbruikt meer dan 50% meer CPU dan Linkerd bij onze gesimuleerde werklast. Het Linkerd-dashboard verbruikt veel minder middelen dan Istio, vooral wat betreft de kerncomponenten.

We denken nog steeds na over hoe we deze kosten kunnen verlagen. Als je ideeën hebt, deel ze dan!

Bron: habr.com