CP tarbimise töökohandustabel Istio ja Linkerd jaoks

Sissejuhatus

Meie ITGLOBAL.COM Shopify oleme alustanud Istio tõstmist teenuse võrguna. Üldiselt oleme rahul, välja arvatud ühe asja: see on kallis.

V avaldatud võrdlusuuringutes Istio kohta öeldakse:

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

Esimeses piirkonnas teenuse võrgus (iga ühenduse külje kohta 2 vaheline server) vajame me 1200 tuuma, lähtudes miljonist päringust sekundis. Google'i maksumuse kalkulaatori järgi maksab see umbes 40 $/kuu/tuum selle konfiguratsiooni jaoks. n1-standard-64, see tähendab, et see piirkond läheb meile maksma üle 50 000 dollari kuus miljoni päringu eest sekundis.

Ivan Sim (Ivan Sim) visuaalselt võrrelda teenuse võrgu viivitusi eelmisel aastal ja lubas sama ka mälu ja protsessori jaoks, kuid see ei toiminud:

Tundub, et values-istio-test.yaml suurendab oluliselt protsessorikutsungeid. Kui ma õigesti arvestasin, on lade umbes 24 protsessorituuma juhtpaneeli jaoks ja 0,5 CPU iga vaheserveri jaoks. Mul pole neid piisavalt. Kordan testimist, kui mulle antakse rohkem ressursse.

Tahtsin ise veenduda, kui sarnased on Istio näitajad teise avatud lähtekoodiga teenuse võrguga: Linkerd.

teenuse võrgustiku paigaldamine

Esmaltasin esialgu klastrisse SuperGloo:

$ supergloo init
supergloo versiooni 0.3.12 installimine
kasutades chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources loodud
serviceaccount/supergloo loodud
serviceaccount/discovery loodud
serviceaccount/mesh-discovery loodud
clusterrole.rbac.authorization.k8s.io/discovery loodud
clusterrole.rbac.authorization.k8s.io/mesh-discovery loodud
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding loodud
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding loodud
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding loodud
deployment.extensions/supergloo loodud
deployment.extensions/discovery loodud
deployment.extensions/mesh-discovery loodud
installimine õnnestus!

Kasutasin SuperGloo'd, sest see lihtsustab service mesh'i algset seadistamist oluliselt. Peaaegu ei pidanud midagi tegema. Tootmisresidentsis me SuperGloo'd ei kasuta, kuid sellise ülesande jaoks sobib see ideaalselt. Pidin kasutama vaid paar käsku iga service mesh'i jaoks. Kasutasin kahte klastrit isolatsiooniks - üks Istio jaoks ja teine Linkerd jaoks.

Eksperiment viidi läbi Google Kubernetes Engine'il. Kasutasin Kubernetes'i 1.12.7-gke.7 ja sõlmede gruppi n1-standard-4 automaatselt skaleeritavate sõlmedega (minimaalselt 4, maksimaalselt 16).

Seejärel installisin mõlemad service mesh'id käsurealt.

Alustasin Linkerd'iga:

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

Seejärel 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 võttis mitu minutit, seejärel stabiliseerusid juhtpaneelid.

(Märkus. SuperGloo toetab praegu ainult Istio 1.0.x. Katsetasin uuesti Istio 1.1.3, kuid ei märganud mingit erilist erinevust.)

Istio automaatse süstimise seadistamine

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

Meie Shopify's oleme kirjutanud oma juurdepääsukontrolöri sidecar'ide implanteerimiseks, kuid selle bänšmargi jaoks kasutasin kontrolöri, mis tuleb koos Istio'ga. Vaikimisi implanteerib kontrolör sidecar'id, kui nimede ruumis 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 implanteerimise seadistamine

Linkerd sidecar'ide implanteerimise seadistamiseks kasutame annotatsioone (lisasin need käsitsi läbi 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 veakindluse simulaator

Oleme loonud Istio katsetussimulaatori, et katsetada Shopify-le ainulaadset liiklust. Vajasime tööriista, et luua omapära topoloogia, mis esindaks meie teenuse graafi teatud osa dünaamilise seadistamisega, et simuleerida konkreetseid töökoormusi.

Shopify infrastruktuur kohtub suure koormusega flash-müükide ajal. Sellega seoses soovitab Shopify müüjatel juhtida sagedamini selliseid eripakkumisi. Suured kliendid teavitavad mõnikord planeeritud flash-müügi kohta. Teised viivad neid läbi ootamatult, igal ajal ööpäevaringselt.

Soovisime, et meie kõrgtase simulaator simuleeriks töövooge, mis vastavad topoloogiatele ja töökoormustele, mis on põhjustanud Shopify infrastruktuuri ülekoormuse minevikus. Peamine eesmärk service mesh'i kasutamisel on usaldusväärsus ja võrgu tasemel töökindlus, ning on oluline, et service mesh suudaks tõhusalt hallata koormusi, mis varem teenuste toimimist häirisid.

Tõrketaluvuse simulaatori aluseks on töövoog, mis toimib teenusevaheketi sõlm. Töövoogu saab konfigureerida staatiliselt käivitamise ajal või dünaamiliselt REST API kaudu. Kasutame töövoogude dünaamilist seadistamist, et luua tööprotsesse regressioonitestide kujul.

Siin on selle protsessi näide:

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

Tööprotsessi lõpus uurime logisid ja mõõdikuid ning kontrollime, kas test on läbitud. Nii saame teada meie teenusevaheketi sooritusvõimest ja teeme regressioonitesti, et kontrollida meie oletusi tõrketaluvuse kohta.

(Märkus. Mõtleme avada Istio tõrketaluvuse simulaatori lähtekoodi, kuid pole veel valmis selleks.)

Istio tõrketaluvuse simulaator teenusevaheketi mõõtmiseks

Seadistame simulaatori mitu töövoogu:

• 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 irs-server.
• irs-server: 3 koopiat, mis tagastavad 200/OK 100 ms jooksul.

Sellise konfiguratsiooniga suudame mõõta stabiilset liiklusvoogu 9 lõpp-punkti vahel. Sidecar’id irs-client-loadgen ja irs-server saavad 100 päringut sekundis, ja irs-client — 200 (sissetulevad ja väljuvad).

Jälgime ressursikasutust läbi DataDog, kuna meil ei ole Prometheuse klastrit.

Tulemused

Halduspanelid

Esmalt uurisime CPU tarbimist.

Linkerdi juhtpaneel ~22 miljonit

Istio juhtpaneel: ~750 miljonit

Istio juhtpaneel kasutab umbes 35 korda rohkem protsessorivõimsust, kui Linkerd. Loomulikult on kõik vaikeseadistusega ning palju protsessorivõimsust tarbib istio-telemetry (seda saab välja lülitada, loobudes mõnest funktsioonist). Kui see komponent eemaldada, on jääk siiski üle 100 miljoni, st 4 korda rohkem, kui Linkerd.

Sidecar proksi

Seejärel kontrollisime proksi kasutamist. Siin peaks olema lineaarne sõltuvus päringute arvust, kuid igal sidecar'il on teatud tegevuskulud, mis mõjutavad kõverat.

Linkerd: ~100 miljonit irs-client’i jaoks, ~50 miljonit irs-client-loadgen’i jaoks

Tulemused on loogilised, kuna proxy client saab kaks korda rohkem liiklust kui proxy loadgen: igale väljaminevale päringule loadgenilt vastab üks sisenemine ja üks väljumine clientilt.

Istio/Envoy: ~155 miljardit irs-clienti jaoks, ~75 miljardit irs-client-loadgeni jaoks

Näeme sarnaseid tulemusi Istio sidecar'ide puhul.

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

Sama skeemi näeme serveri poolel:

Linkerd: ~50 miljardit irs-serveri jaoks

Istio/Envoy: ~80 miljardit irs-serveri jaoks

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

Kokkuvõte

Proxy Istio Envoy tarbib meie simuleeritud töökoormuse all 50% rohkem CPU-d kui Linkerd. Linkerd juhtpaneel tarbib palju vähem ressursse kui Istio, eriti see kehtib põhikomponentide kohta.

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

Allikas: habr.com