🥇CPU forbrug benchmark for Istio og Linkerd

Indledning

Vi er inde Shopify begyndte at implementere Istio som et servicenet. I princippet er alt fint, bortset fra én ting: det er dyrt.

В offentliggjorte benchmarks for Istio står der:

Med Istio 1.1 bruger proxyen cirka 0,6 vCPU'er (virtuelle kerner) pr. 1000 anmodninger pr. sekund.

For den første region i servicenetværket (2 proxyer på hver side af forbindelsen), vil vi have 1200 kerner kun til proxyen med en hastighed på en million anmodninger pr. sekund. Ifølge Googles omkostningsberegner virker det til at være cirka 40 USD/måned/kerne for konfiguration n1-standard-64, det vil sige, at denne region alene vil koste os mere end 50 tusind dollars om måneden for 1 million anmodninger i sekundet.

Ivan Sim (Ivan Sim) visuelt sammenlignet service mesh forsinkelser sidste år og lovede det samme for hukommelse og processor, men det lykkedes ikke:

Tilsyneladende vil values-istio-test.yaml alvorligt øge CPU-anmodninger. Hvis jeg har lavet mit regnestykke korrekt, skal du bruge cirka 24 CPU-kerner til kontrolpanelet og 0,5 CPU til hver proxy. Jeg har ikke så meget. Jeg vil gentage testene, når der er tildelt flere ressourcer til mig.

Jeg ville selv se, hvor lig Istios ydeevne er med en anden open source-tjenestemesh: Linkerd.

Installation af servicenet

Først og fremmest installerede jeg det i en klynge 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 bootstrapping af servicenet meget nemmere. Jeg behøvede ikke gøre meget. Vi bruger ikke SuperGloo i produktionen, men den er ideel til sådan en opgave. Jeg var nødt til at bruge bogstaveligt talt et par kommandoer for hver service mesh. Jeg brugte to klynger til isolering - en hver til Istio og Linkerd.

Eksperimentet blev udført på Google Kubernetes Engine. Jeg brugte Kubernetes 1.12.7-gke.7 og en pulje af noder n1-standard-4 med automatisk nodeskalering (minimum 4, maksimum 16).

Så installerede jeg begge servicemasker fra kommandolinjen.

Første linked:

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

Så 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-loopet tog et par minutter, og så stabiliserede kontrolpanelerne sig.

(Bemærk: SuperGloo understøtter kun Istio 1.0.x indtil videre. Jeg gentog eksperimentet med Istio 1.1.3, men bemærkede ikke nogen mærkbar forskel.)

Opsætning af Istio Automatic Deployment

For at få Istio til at installere sidevognen Envoy bruger vi sidevognsinjektoren − MutatingAdmissionWebhook. Vi vil ikke tale om det i denne artikel. Lad mig bare sige, at dette er en controller, der overvåger adgangen til alle nye pods og dynamisk tilføjer en sidevogn og initContainer, som er ansvarlig for opgaver iptables.

Vi hos Shopify skrev vores egen adgangscontroller til at implementere sidevogne, men til dette benchmark brugte jeg den controller, der følger med Istio. Controlleren injicerer sidevogne som standard, når der er en genvej 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 Linkerd-implementering

For at konfigurere Linkerd sidevognsindlejring bruger vi annoteringer (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 Fault Tolerance Simulator

Vi byggede en fejltolerancesimulator kaldet Istio for at eksperimentere med trafik, der er unik for Shopify. Vi havde brug for et værktøj til at skabe en tilpasset topologi, der ville repræsentere en specifik del af vores servicegraf, dynamisk konfigureret til at modellere specifikke arbejdsbelastninger.

Shopifys infrastruktur er under hård belastning under flash-salg. Samtidig Shopify anbefaler sælgere at afholde sådanne salg oftere. Store kunder advarer nogle gange om et planlagt flash-udsalg. Andre udfører dem uventet for os på et hvilket som helst tidspunkt af dagen eller natten.

Vi ønskede, at vores modstandsdygtighedssimulator skulle modellere arbejdsgange, der matcher de topologier og arbejdsbelastninger, der tidligere har overvældet Shopifys infrastruktur. Hovedformålet med at bruge en 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 kan klare belastninger, der tidligere forstyrrede tjenester.

Kernen i fejltolerancesimulatoren er en arbejderknude, der fungerer som en servicemaskeknude. Arbejdernoden kan konfigureres statisk ved opstart eller dynamisk via en REST API. Vi bruger dynamisk konfiguration af arbejderknudepunkter til at skabe arbejdsgange i form af regressionstest.

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

Vi lancerer 10 servere som bar service, der returnerer et svar 200/OK efter 100 ms.
Vi lancerer 10 klienter - hver sender 100 anmodninger i sekundet til bar.
Hvert 10. sekund fjerner vi 1 server og overvåger fejl 5xx på klienten.

I slutningen af arbejdsgangen undersøger vi logfilerne og metrikken og kontrollerer, om testen bestod. På denne måde lærer vi om ydeevnen af vores servicenetværk og kører en regressionstest for at teste vores antagelser om fejltolerance.

(Bemærk: Vi overvejer at åbne Istio-fejltolerancesimulatoren, men er ikke klar til at gøre det endnu.)

Istio fejltolerancesimulator til benchmark for servicenet

Vi opsætter flere arbejdsknuder i simulatoren:

irs-client-loadgen: 3 replikaer, der sender 100 anmodninger i sekundet pr irs-client.
irs-client: 3 replikaer, der modtager anmodningen, vent 100ms og videresend anmodningen til irs-server.
irs-server: 3 kopier, der vender tilbage 200/OK efter 100 ms.

Med denne konfiguration kan vi måle et stabilt trafikflow mellem 9 endepunkter. Sidevogne ind irs-client-loadgen и irs-server modtage 100 anmodninger i sekundet, og irs-client — 200 (indgående og udgående).

Vi sporer ressourceforbruget igennem DataDogfordi vi ikke har en Prometheus-klynge.

Fund

Kontrolpaneler

Først undersøgte vi CPU-forbruget.

Linkerd kontrolpanel ~22 millicore

Istio kontrolpanel: ~750 millicore

Istio kontrolpanelet bruger ca 35 gange flere CPU-ressourcerend Linkerd. Alt er selvfølgelig installeret som standard, og istio-telemetri bruger mange processorressourcer her (det kan deaktiveres ved at deaktivere nogle funktioner). Hvis vi fjerner denne komponent, får vi stadig mere end 100 millicores, dvs 4 gange mereend Linkerd.

Sidevogn proxy

Vi testede derefter brugen af en proxy. Der bør være en lineær sammenhæng med antallet af anmodninger, men for hver sidevogn er der noget overhead, der påvirker kurven.

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

Resultaterne ser logiske ud, fordi klientproxyen modtager dobbelt så meget trafik som loadgen-proxyen: for hver udgående anmodning fra loadgen har klienten én indgående og én udgående.

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

Vi ser lignende resultater for Istio sidevogne.

Men generelt forbruger Istio/Envoy proxyer cirka 50 % flere CPU-ressourcerend Linkerd.

Vi ser det samme skema på serversiden:

Linkerd: ~50 millicore for irs-server

Istio/Envoy: ~80 millicore til irs-server

På serversiden forbruger sidevogn Istio/Envoy cirka 60 % flere CPU-ressourcerend Linkerd.

Konklusion

Istio Envoy-proxyen bruger 50+ % mere CPU end Linkerd på vores simulerede arbejdsbyrde. Linkerd kontrolpanel bruger meget mindre ressourcer end Istio, især for kernekomponenterne.

Vi overvejer stadig, hvordan vi kan reducere disse omkostninger. Hvis du har ideer, så del gerne!

Kilde: www.habr.com

CPU-forbrug benchmark for Istio og Linkerd