🥇CPU-forbrugsbenchmark for Istio og Linkerd

Benchmarking af CPU-forbrug for Istio og Linkerd

Introduktion

Vi i Shopify Vi har arbejdet med at implementere Istio som service mesh. Generelt er alt tilfredsstillende, undtagen én ting: det er dyrt.

I offentliggjorte benchmarktests for Istio hedder det:

Med Istio 1.1 bruger proxien cirka 0,6 vCPU (virtuel kerne) pr. 1000 anmodninger pr. sekund.

For den første region i service mesh (med 2 proxier på hver side af forbindelsen) vil vi have 1200 kerner kun til proxier, baseret på én million anmodninger pr. sekund. Ifølge Googles prismodel koster det cirka $40/måned/kerne til konfigurationen n1-standard-64, hvilket betyder, at denne region vil koste os over 50.000 dollars om måneden for 1 million anmodninger pr. sekund.

Ivan Sim (Ivan Sim) sammenlignede tydeligt forsinkelsen i service mesh fra sidste år og lovede det samme for hukommelse og CPU, men det gik ikke:

Det ser ud til, at values-istio-test.yaml vil øge belastningen på 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å mange. Jeg gentager testene, når jeg får tildelt flere ressourcer.

Jeg ville gerne selv opleve, hvorvidt Istios resultater svarer til en anden open-source service mesh: Linkerd.

Installation af service mesh

Først installerede jeg i klyngen 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!

Jeg brugte SuperGloo, fordi det gør initialiseringen af service mesh betydeligt enklere. Jeg skulle næsten ikke gøre noget. I produktionen bruger vi ikke SuperGloo, men til en opgave som denne er det ideelt. Jeg måtte kun udføre et par kommandoer for hver service mesh. Jeg brugte to klynger til isolation - én for Istio og én for Linkerd.

Eksperimentet fandt sted på Google Kubernetes Engine. Jeg brugte Kubernetes 1.12.7-gke.7 og en node-pool n1-standard-4 med automatisk skaleringsfunktion (minimum 4, maksimum 16).

Derefter installerede jeg begge service meshes fra kommandolinjen.

Først 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 |
+---------+--------------+---------+---------------------------+

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

Crash-loop tog tog flere minutter, men kontrolpanelerne stabiliserede sig bagefter.

(Bemærk: SuperGloo understøtter kun Istio 1.0.x. Jeg gentog eksperimentet med Istio 1.1.3, men jeg så ingen betydelig forskel.)

Opsætning af automatisk injektion af Istio

For at Istio kan installere sidecar Envoy, bruger vi sidecar-injektoren — MutatingAdmissionWebhook. Vi vil ikke tale om det i denne artikel. Jeg vil kun sige, at det er en controller, der overvåger adgangen til alle nye pods og dynamisk tilføjer sidecar og initContainer, som står for opgaverne iptables.

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år der er et label i navnerummet 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

Opsætning af automatisk injektion af Linkerd

For at konfigurere injektion af sidecars til Linkerd, bruger vi annotationer (jeg tilføjede dem manuelt 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

Istio fejltolerance simulator

Vi har lavet en Istio fejltolerancsimulator for at eksperimentere med trafik, der er unik for Shopify. Vi havde brug for et værktøj til at skabe en vilkårlig topologi, der ville repræsentere en bestemt del af grafen for vores service med dynamisk konfiguration til at modellere specifikke arbejdsbyrder.

Shopify-infrastrukturen oplever stor belastning under flashudsalg. I den forbindelse anbefaler Shopify forhandlere at afholde sådanne udsalg oftere.Store kunder varsler nogle gange om planlagte flashudsalg. Andre gennemfører dem uventet for os på alle tider af døgnet.

Vi ønskede, at vores fejltolerancsimulator skulle modellere arbejdsprocesser, som svarer til topologier og arbejdsbyrder, der tidligere har ført til overbelastning af Shopify-infrastrukturen. Hovedformålet med at bruge service mesh er, at vi har brug for pålidelighed og fejltolerance på netværksniveau, og det er vigtigt for os, at service mesh effektivt håndterer belastninger, som tidligere har forstyrret driften af tjenester.

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.

Her er et eksempel på en sådan proces:

Vi starter 10 servere som bar en tjeneste, der returnerer svaret 200/OK efter 100 ms.
Vi starter 10 klienter — hver sender 100 anmodninger per sekund til bar.
Hver 10. sekund fjerner vi 1 server, og overvåger fejl 5xx på klienten.

I slutningen af arbejdsprocessen studerer vi logfiler og metrics og tjekker, om testen er bestået. Således lærer vi om ydeevnen af vores service mesh og udfører en regressions test for at vurdere vores antagelser om fejltolerance.

(Bemærk. Vi overvejer at åbne kildekoden til Istio fejltolerancsimulator, men vi er endnu ikke klar til dette.)

Istio fejltolerancsimulator til benchmark af service mesh

Vi konfigurerer flere arbejdsnoder for simulatoren:

irs-client-loadgen: 3 replikaer, der sender 100 anmodninger per sekund til irs-client.
irs-client: 3 replikaer, der modtager anmodningen, venter 100 ms og videresender anmodningen til irs-server.
irs-server: 3 replikaer, der returnerer 200/OK efter 100 ms.

Med denne konfiguration kan vi måle en stabil trafikstrøm mellem 9 slutpunkter. Sidecar'er i irs-client-loadgen og irs-server modtager 100 forespørgsler i sekundet, og irs-client — 200 (indgående og udgående).

Vi overvåger ressourceforbruget via DataDog, fordi vi ikke har en Prometheus-kluster.

Resultater

Kontrolpaneler

Først undersøgte vi CPU-forbruget.

Linkerd kontrolpanel ~22 milliarder

Istio kontrolpanel: ~750 milliarder

Istio kontrolpanelet bruger cirka 35 gange flere processorressourcer, end Linkerd. Selvfølgelig er alt sat til standard, og mange processorressourcer bruges her af istio-telemetry (det kan deaktiveres ved at fravælge nogle funktioner). Hvis man fjerner denne komponent, får man stadig mere end 100 milliarder, altså 4 gange mere, end Linkerd.

Sidecar proxy

Derefter undersøgte vi proxyforbruget. Her skal der være en lineær afhængighed af antallet af forespørgsler, men for hver sidecar er der nogle omkostninger, der påvirker kurven.

Linkerd: ~100 milliarder for irs-client, ~50 milliarder for irs-client-loadgen

Resultaterne ser logiske ud, da proxyclienten modtager to gange mere trafik end proxyloadgen: for hver udgående forespørgsel fra loadgen er der en indgående og en udgående til klienten.

Istio/Envoy: ~155 milliarder for irs-client, ~75 milliarder for irs-client-loadgen

Vi ser lignende resultater for sidecar'erne i Istio.

Men generelt forbruger proxyene Istio/Envoy cirka 50% flere processorressourcer, end Linkerd.

Den samme skema ser vi på serversiden:

Linkerd: ~50 milliarder for irs-server

Istio/Envoy: ~80 milliarder for irs-server

På serversiden forbruger Istio/Envoy sidecar'en c. 60% flere processorressourcer, end Linkerd.

Konklusion

Proxy Istio Envoy bruger 50+% mere CPU end Linkerd under vores simulerede arbejdsbyrde. Linkerd kontrolpanel bruger langt færre ressourcer end Istio, især når det kommer til de grundlæggende komponenter.

Vi tænker stadig over, hvordan vi kan reducere disse omkostninger. Hvis du har nogle idéer, så del dem!

Kilde: habr.com