CPU tarbimise benchmark Istio ja Linkerd jaoks

Sissejuhatus

Meie Shopify tegelevad Istio käitamisega teenuste võrku. Üldiselt on kõik okei, välja arvatud üks asi: see on kallis.

Uues avalikustatud bänkmärgid Istio kohta öeldakse:

Istio 1.1 puhul tarbib vaheproksi umbes 0,6 vCPU (virtuaalset tuuma) 1000 päringu kohta sekundis.

Esimeses piirkonnas teenuste võrgus (iga ühenduse poole jaoks 2 vaheproksi) vajame 1200 tuuma ainult vaheproksi jaoks, tuginedes miljoni päringu kohta sekundis. Google'i hinnakalkulaatori kohaselt maksab see umbes 40 dollarit / kuu / tuum konfiguratsioonile n1-standard-64, see tähendab, et see piirkond maksab meile üle 50 000 dollari kuus miljoni päringu kohta sekundis.

Ivan Sim (Ivan Sim) visualiseeris teenuste võrgu latentsust eelmisel aastal ja lubas sarnast hinnangut mälu ja protsessori kohta, kuid ei saanud sellega hakkama:

Tundub, et values-istio-test.yaml suurendab protsessori päringute arvu märk significantly. Kui ma õigesti arvasin, on vaja umbes 24 protsessorituuma juhtpaneeli ja 0,5 CPU iga vaheproksi jaoks. Mul ei ole nii palju. Kordan teste, kui saan rohkem ressursse.

Soovisin ise kontrollida, kui sarnased on Istio näitajad teiste avatud lähtekoodiga teenuste võrgu lahendustega: Linkerd.

Teenuste võrgu paigaldamine

Esmalt paigaldasin 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 SuperGloo, kuna see lihtsustab teenuste võrgu alglaadimist oluliselt. Mul ei olnud peaaegu midagi teha. Tootmises me SuperGloo ei kasuta, kuid sellise ülesande jaoks sobib see suurepäraselt. pidin rakendama vaid paar käsku iga teenuste võrgu jaoks. Kasutasin kahte klastri eraldamiseks — ühe Istio ja Linkerd jaoks.

Eksperimenti viidi läbi Google Kubernetes Engine'is. Kasutasin Kubernetesit 1.12.7-gke.7 ja sõlmede pinda n1-standard-4 automaatse sõlmede skaleerimisega (miinimum 4, maksimum 16).

Siis paigaldasin mõlemad teenuste võrgud käsurealt.

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

Järgneb 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 kestis mitu minutit ja seejärel juhtpaneel stabiliseerus.

(Märkus. SuperGloo toetab praegu ainult Istio 1.0.x. Kordasin katset Istio 1.1.3-ga, kuid mingit märkimisväärset erinevust ei märganud.)

Istio automaatse sisestamise seadistamine

Kuna Istio seadistab sidecar Envoy, kasutame sidecar-injektorit — MutatingAdmissionWebhook. Me ei räägi sellest artiklis. Ütlen vaid, et see on kontroller, mis jälgib kõigi uute pod'ide juurdepääsu ja dünaamiliselt lisab sidecar ja initContainer, mis vastutab ülesannete eest iptables.

Me Shopify's kirjutasime oma ligipääsukontrolleri sidecar'ide sisestamiseks, kuid selles benchmark'is kasutasin Istio kaasasolevat kontrollerit. Vaikimisi kontroller sisestab sidecar'id, kui nimeses on silt 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

Linkerd automaatse sisestamise seadistamine

Linkerdi sidecar'ide sisestamise seadmiseks kasutame annotatsioone (lisasin need käsitsi kaudu 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 talitlusekatsetaja

Oleme loonud Istio tipptasemel simulaatori, et katsetada Shopify'le spetsiifilist liiklust. Me vajame tööriista, mis võimaldab luua suvalisi topoloogiaid, mis esindavad meie teenuse graafi teatud osa koos dünaamilise seadistusega konkreetsete koormuste modelleerimiseks.

Shopify infrastruktuur kogeb flash-müükide ajal suurt koormust. Samuti soovitab Shopify müüjatel selliseid müüke sagedamini korraldada. Suuremad kliendid teavitavad mõnikord ette planeeritud flash-müügist. Teised korraldavad neid ootamatult igal kellaajal.

Soovisime, et meie tipptasemel simulaator modelleeriks tööprotsesse, mis vastavad topoloogiatele ja koormustele, mis on varasemalt põhjustanud Shopify infrastruktuuri ülekoormust. Service mesh'i kasutamise peamine eesmärk – me vajame usaldusväärsust ja tõrketaluvust võrgu tasandil ning on oluline, et service mesh suudaks tõhusalt hakkama saada koormustega, mis on varem teenuste tööd häirinud.

Tipptasemel simulaatori aluseks on töönõlv, mis toimib service mesh'i sõlmena. Töönõlva saab seadistada staatiliselt käivitamise hetkel või dünaamiliselt REST API kaudu. Kasutame töötavate nodede dünaamilist seadistust, et luua tööprotsesse regressioonitestide vormis.

Siin on sellise protsessi näide:

• Käivitame 10 serverit kui bar teenust, 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, jälgime vigu 5xx kliendi peal.

Protsessi lõpus uurime logisid ja mõõtmeid ning kontrollime, kas test on läbitud. Nii saame teada meie service mesh'i tulemuslikkusest ja teostame regressioonitesti, et kontrollida meie oletusi tõrketaluvuse kohta.

(Märkus. Mõtleme, et avame Istio tipptasemel simulaatori lähtekoodi, kuid hetkel pole me sellega veel valmis.)

Istio tipptasemel simulaator service mesh'i testimiseks

Seadistame mitmeid simulaatori töötavaid sõlmi:

• irs-client-loadgen: 3 koopiat, mis saadavad 100 päringut sekundis irs-client.
• irs-client: 3 koopiat, mis saavad päringu, ootavad 100 ms ja suunavad päringu edasi irs-server.
• irs-server: 3 koopiat, mis tagastavad 200/OK 100 ms pärast.

Sellise konfiguratsiooniga saame mõõta stabiilset liiklust 9 lõpppunkti vahel. Sidecar'id irs-client-loadgen ja irs-server saavad 100 päringut sekundis, ja irs-client — 200 (sisse- ja väljaminevad).

Kasutame ressursside jälgimiseks DataDog, kuna meil ei ole Prometheuse klastrit.

tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest.

Juhtpaneelid

Esmalt uurisime CPU tarbimist.

Linkerdi armatuurlaud ~22 millijärku

Istio armatuurlaud: ~750 millijärku

Istio armatuurlaud kasutab umbes 35 korda rohkem protsessori ressursse, kui Linkerd. Loomulikult on kõik vaikeseaded ja palju protsessori ressursse tarbib istio-telemetry (seda saab keelata, loobudes mõnest funktsioonist). Kui see komponent eemaldada, jääb ikkagi üle 100 millijärgu, st 4 korda rohkem, kui Linkerd.

Sidecar proxy

Seejärel kontrollisime proxy kasutamist. Siin peaks olema lineaarne sõltuvus päringute arvust, kuid iga sidecar'i puhul on mõned kulud, mis mõjutavad kõverat.

Linkerd: ~100 millijärku irs-client jaoks, ~50 millijärku irs-client-loadgen'i jaoks

Tulemused näivad olevat loogilised, kuna client proxy saab kaks korda rohkem liiklust kui loadgen proxy: iga väljamineva päringu kohta loadgen'ilt on client'il üks sisenev ja üks väljuv.

Istio/Envoy: ~155 millijärku irs-client jaoks, ~75 millijärku irs-client-loadgen'i jaoks

Näeme sarnaseid tulemusi Istio sidecar'ide puhul.

Kuid üldiselt tarbivad Istio/Envoy proxy'd umbes 50% rohkem protsessori ressursse, kui Linkerd.

Sama mustrit näeme serveri küljel:

Linkerd: ~50 millijärku irs-server jaoks

Istio/Envoy: ~80 millijärku irs-server jaoks

Serveri küljel tarbib Istio/Envoy sidecar umbes 60% rohkem protsessori ressursse, kui Linkerd.

Kokkuvõte

Istio Envoy proxy tarbib meie simuleeritud töökoormuse puhul 50+% rohkem CPU-d kui Linkerd. Linkerdi armatuurlaud tarbib palju vähem ressursse kui Istio, eriti põhi komponentide osas.

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

Allikas: habr.com