CPU tarbimise etalon Istio ja Linkerdi jaoks

Sissejuhatus

Me oleme sees Shopify alustas Istio juurutamist teenindusvõrguna. Põhimõtteliselt on kõik hästi, välja arvatud üks asi: see on kallis.

В avaldatud võrdlusnäitajad Istio kohta öeldakse:

Istio 1.1 puhul tarbib puhverserver umbes 0,6 vCPU-d (virtuaalseid südamikke) 1000 päringu kohta sekundis.

Teenindusvõrgu esimese piirkonna jaoks (2 puhverserverit ühenduse mõlemal küljel) on meil ainult puhverserveri jaoks 1200 tuuma, kiirusega üks miljon päringut sekundis. Google'i kulukalkulaatori järgi on see seadistamise eest umbes 40 dollarit kuus/tuum n1-standard-64st ainuüksi see piirkond maksab meile 50 miljoni päringu eest sekundis üle 1 tuhande dollari kuus.

Ivan Sim (Ivan Sim) visuaalselt võrrelda teenindusvõrgu viivitused eelmisel aastal ja lubasid sama mälu ja protsessori jaoks, kuid see ei õnnestunud:

Ilmselt suurendab väärtuste-istio-test.yaml protsessori taotlusi tõsiselt. Kui ma olen õigesti arvutanud, vajate juhtpaneeli jaoks umbes 24 protsessorituuma ja iga puhverserveri jaoks 0,5 CPU-d. Mul pole nii palju. Kordan teste, kui mulle rohkem ressursse eraldatakse.

Tahtsin ise näha, kui sarnane on Istio jõudlus mõne teise avatud lähtekoodiga teenusevõrguga: Linkerd.

Teenindusvõrgu paigaldamine

Kõigepealt installisin selle klastrisse 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!

Kasutasin SuperGlood, kuna see muudab teenindusvõrgu alglaadimise palju lihtsamaks. Ma ei pidanud palju tegema. Tootmises me SuperGlood ei kasuta, kuid see sobib ideaalselt selliseks ülesandeks. Ma pidin iga teenindusvõrgu jaoks kasutama sõna otseses mõttes paar käsku. Isoleerimiseks kasutasin kahte klastrit – ühte Istio ja Linkerdi jaoks.

Katse viidi läbi Google Kubernetes Engine'is. Kasutasin Kubernetes 1.12.7-gke.7 ja sõlmede kogum n1-standard-4 automaatse sõlme skaleerimisega (minimaalselt 4, maksimaalselt 16).

Seejärel installisin käsurealt mõlemad teenindusvõrgud.

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

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

Kokkupõrke ahel kestis paar minutit ja seejärel juhtpaneelid stabiliseerusid.

(Märkus: SuperGloo toetab praegu ainult versiooni Istio 1.0.x. Kordasin katset versiooniga Istio 1.1.3, kuid ei märganud märgatavat erinevust.)

Istio automaatse juurutamise seadistamine

Selleks, et Istio paigaldaks külgkorvi Envoy, kasutame külgkorvi pihustit − MutatingAdmissionWebhook. Selles artiklis me sellest ei räägi. Lubage mul lihtsalt öelda, et see on kontroller, mis jälgib juurdepääsu kõigile uutele taskutele ja lisab dünaamiliselt külgkorvi ja initContaineri, mis vastutab ülesannete eest iptables.

Meie Shopifys kirjutasime külgkorvide rakendamiseks oma juurdepääsukontrolleri, kuid selle võrdlusaluse jaoks kasutasin Istioga kaasasolevat kontrollerit. Kontroller sisestab vaikimisi külgkorvid, kui nimeruumis on otsetee 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

Linkerdi automaatse juurutamise seadistamine

Linkerdi külgkorvi manustamise seadistamiseks kasutame märkusi (lisasin need käsitsi, kasutades 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 tõrketaluvuse simulaator

Ehitasime tõrketaluvuse simulaatori nimega Istio, et katsetada Shopify ainulaadse liiklusega. Vajasime tööriista kohandatud topoloogia loomiseks, mis esindaks meie teenusegraafiku kindlat osa, mis on dünaamiliselt konfigureeritud konkreetsete töökoormuste modelleerimiseks.

Shopify infrastruktuur on välklambi müügi ajal suure koormuse all. Samal ajal Shopify soovitab müüjatel selliseid müüke sagedamini korraldada. Suured kliendid hoiatavad mõnikord plaanitava välkmüügi eest. Teised viivad neid meile ootamatult läbi igal kellaajal päeval või öösel.

Tahtsime, et meie vastupidavuse simulaator modelleeriks töövooge, mis vastavad topoloogiatele ja töökoormustele, mis on varem Shopify taristu üle koormanud. Teenusvõrgu kasutamise põhieesmärk on see, et vajame võrgutasandil töökindlust ja tõrketaluvust ning meie jaoks on oluline, et teenindusvõrk tuleks tõhusalt toime koormustega, mis varem teenuseid häirisid.

Veataluvuse simulaatori keskmes on töötaja sõlm, mis toimib teenindusvõrgu sõlmena. Töötaja sõlme saab konfigureerida staatiliselt käivitamisel või dünaamiliselt REST API kaudu. Regressioonitestide vormis töövoogude loomiseks kasutame töötajate sõlmede dünaamilist konfiguratsiooni.

Siin on näide sellisest protsessist:

• Käivitame 10 serverit kui bar teenus, mis tagastab vastuse 200/OK 100 ms pärast.
• Käivitame 10 klienti – igaüks saadab 100 päringut sekundis bar.
• Iga 10 sekundi järel eemaldame 1 serveri ja jälgime vigu 5xx kliendi peal.

Töövoo lõpus uurime logisid ja mõõdikuid ning kontrollime, kas test läbis. Nii õpime tundma oma teenindusvõrgu toimivust ja käivitame regressioonitesti, et testida oma eeldusi veataluvuse kohta.

(Märkus: kaalume Istio tõrketaluvuse simulaatori avatud hankimist, kuid pole veel valmis seda tegema.)

Istio rikketaluvuse simulaator hooldusvõrgu võrdlusaluse jaoks

Seadistame simulaatori mitu töötavat sõlme:

• irs-client-loadgen: 3 koopiat, mis saadavad 100 päringut sekundis irs-client.
• irs-client: 3 koopiat, mis võtavad päringu vastu, ootavad 100 ms ja edastavad päringu aadressile irs-server.
• irs-server: 3 koopiat, mis tagastavad 200/OK 100 ms pärast.

Selle konfiguratsiooniga saame mõõta stabiilset liiklusvoogu 9 lõpp-punkti vahel. Külgvankrid sisse irs-client-loadgen и irs-server saada 100 päringut sekundis ja irs-client — 200 (sissetulev ja väljaminev).

Jälgime ressursside kasutamist DataDogsest meil pole Prometheuse klastrit.

Järeldused

Juhtpaneelid

Esiteks uurisime protsessori tarbimist.

Linkerdi juhtpaneel ~22 millituuma

Istio juhtpaneel: ~750 millituuma

Istio juhtpaneel kasutab ligikaudu 35 korda rohkem protsessori ressurssekui Linkerd. Loomulikult on kõik vaikimisi installitud ja istio-telemeetria kulutab siin palju protsessori ressursse (selle saab keelata mõne funktsiooni keelamisega). Kui me selle komponendi eemaldame, saame ikkagi üle 100 millicore 4 korda rohkemkui Linkerd.

Külgkorvi puhverserver

Seejärel testisime puhverserveri kasutamist. Päringute arvuga peaks olema lineaarne seos, kuid iga külgkorvi puhul on kõverat mõjutav kulu.

Linkerd: ~100 millituuma irs-kliendi jaoks, ~50 millituuma irs-client-loadgeni jaoks

Tulemused tunduvad loogilised, sest kliendi puhverserver võtab vastu kaks korda rohkem liiklust kui loadgeni puhverserver: iga loadgenilt väljamineva päringu kohta on kliendil üks sissetulev ja üks väljaminev.

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

Sarnaseid tulemusi näeme ka Istio külgkorvide puhul.

Aga üldiselt Istio/Envoy puhverserverid tarbivad umbes 50% rohkem protsessori ressurssekui Linkerd.

Sama skeemi näeme serveri poolel:

Linkerd: ~50 millituuma irs-serveri jaoks

Istio/Envoy: ~80 millituuma irs-serveri jaoks

Serveri poolel tarbib külgkorvi Istio/Envoy umbes 60% rohkem protsessori ressurssekui Linkerd.

Järeldus

Istio Envoy puhverserver tarbib meie simuleeritud töökoormuse juures 50+% rohkem protsessorit kui Linkerd. Linkerdi juhtpaneel tarbib palju vähem ressursse kui Istio, eriti põhikomponentide jaoks.

Me veel mõtleme, kuidas neid kulusid vähendada. Kui teil on ideid, palun jagage!

Allikas: www.habr.com