🥇 Pîvana xerckirina CPU ji bo Istio û Linkerd

Pîrozbahiyê

Em tê de ne shopify dest bi belavkirina Istio wekî tevnek karûbarê kir. Di prensîbê de, her tişt baş e, ji bilî tiştek: biha ye.

В pîvanên weşandin ji bo Istio dibêje:

Bi Istio 1.1-ê re, proxy di her 0,6 daxwazî her saniyeyê de bi qasî 1000 vCPU (kokên virtual) dixwe.

Ji bo herêma yekem di tevna karûbarê de (2 proxy li her aliyek pêwendiyê), em ê 1200 core tenê ji bo proxy-ê, bi rêjeya yek mîlyon daxwazî di çirkeyê de hebin. Li gorî hesabkera lêçûnê ya Google-ê, ew ji bo veavakirinê bi qasî 40 $ / meh / bingehîn e. n1-standard-64yanî ev herêm bi tena serê xwe ji bo 50 milyon daxwazan her meh 1 hezar dolar mesrefa me dike.

Ivan Sim (Ivan Sim) dîtbarî danberhev karûbarê tevna sala borî dereng ma û ji bo bîranîn û pêvajoyê heman soz da, lê ew bi ser neket:

Xuya ye, values-istio-test.yaml dê daxwazên CPU bi giranî zêde bike. Ger min matematîka xwe rast kiribe, ji bo panela kontrolê bi qasî 24 core CPU û ji bo her proxy 0,5 CPU hewce ne. Min ew qas tune. Dema ku bêtir çavkanî ji min re werin veqetandin ez ê ceribandinan dubare bikim.

Min xwest ku ez bi xwe bibînim ka performansa Istio çiqas dişibihe tevna karûbarê çavkaniyek vekirî ya din: Linkerd.

Sazkirina tevna xizmetê

Berî her tiştî, min ew di komekê de saz kir 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!

Min SuperGloo bikar anî ji ber ku ew bootstrapping tevna karûbarê pir hêsantir dike. Ne hewce bû ku ez pir bikim. Em di hilberînê de SuperGloo bikar neynin, lê ew ji bo karekî weha îdeal e. Ez neçar bûm ku ji bo her tevnek karûbarê bi rastî çend fermanan bikar bînim. Min du kom ji bo veqetandinê bikar anîn - her yek ji bo Istio û Linkerd.

Ezmûn li Google Kubernetes Engine hate kirin. Min Kubernetes bikar anî 1.12.7-gke.7 û hewzek girêk n1-standard-4 bi pîvana nodê ya otomatîkî (kêmtirîn 4, herî zêde 16).

Dûv re min herdu tevnên karûbarê ji rêzika fermanê saz kirin.

Yekem Girêdayî:

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

Paşê 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      |
+---------+------------+---------+---------------------------+

Qeza-loop çend hûrdem girt, û dûv re panelên kontrolê stabîl bûn.

(Têbînî: SuperGloo heya niha tenê Istio 1.0.x piştgirî dike. Min ceribandina bi Istio 1.1.3 re dubare kir, lê ferqek berbiçav nedît.)

Sazkirina Rakirina Otomatîk Istio

Ji bo ku Istio sazkera sidecar Envoy saz bike, em derzkera kêlekê bikar tînin - MutatingAdmissionWebhook. Em ê di vê gotarê de nebêjin. Bihêle ez tenê bibêjim ku ev kontrolkerek e ku çavdêriya gihîştina hemî podên nû dike û bi dînamîk rêyek û initContainer, ku berpirsiyarê karan e, zêde dike. iptables.

Me li Shopify kontrolkarê gihîştina xwe nivîsand da ku rêgez bicîh bîne, lê ji bo vê pîvanê min kontrola ku bi Istio re tê bikar anî. Dema ku di qada navan de kurtebirek hebe, kontrolker ji hêla xwerû ve kêlekan derdixe 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

Sazkirina sazkirina Linkerd-a otomatîkî

Ji bo sazkirina girêdana kêleka Linkerd, em şîroveyan bikar tînin (min wan bi destan lê zêde kir 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

Me simulatorek tolerasyona xeletiyê bi navê Istio çêkir da ku bi seyrûsefera ku ji Shopify-ê re bêhempa ye ceribandine. Ji me re amûrek hewce bû ku em topolojîyek xwerû biafirînin ku dê beşek taybetî ya grafiya karûbarê me temsîl bike, ku bi dînamîk ve hatî mîheng kirin da ku modela barkêşên xebatê yên taybetî bide çêkirin.

Binesaziya Shopify di dema firotana flash de di bin barek giran de ye. Di heman demê de, Shopify firoşkaran pêşniyar dike ku pir caran firotanên weha bigirin. Xerîdarên mezin carinan li ser firotek flash plankirî hişyar dikin. Yên din di her wextê rojê û şevê de wan ji me re neçaverê dikin.

Me xwest ku simulatora xweya berxwedêriyê modela karûbaran bike ku bi topolojî û barkêşên xebatê yên ku di paşerojê de binesaziya Shopify-ê zexm kiriye, model bike. Armanca sereke ya karanîna tevna karûbarê ev e ku em hewceyê pêbawerî û tolerasyona xeletiyê di asta torê de ne, û ji me re girîng e ku tevna karûbarê bi bandor bi barên ku berê karûbaran qut kirine re mijûl bibe.

Di dilê simulatora tolerasyona xeletiyê de girêkek karker heye, ku wekî girêka tevna karûbarê tevdigere. Girêdana karker dikare di destpêkê de an jî dînamîkî bi riya API-ya REST-ê ve statîk were mîheng kirin. Em veavakirina dînamîkî ya girêkên karker bikar tînin da ku di forma ceribandinên regresyonê de rêçikên xebatê biafirînin.

Li vir mînakek pêvajoyek weha ye:

Em wekî 10 serveran dest pê dikin bar karûbarê ku bersivek vedigere 200/OK piştî 100 ms.
Em 10 xerîdar didin destpêkirin - her yek saniyeyê 100 daxwazan dişîne bar.
Her 10 çirkeyan em 1 server û xeletiyên çavdêriyê jê dikin 5xx li ser muwekîlê.

Di dawiya xebata xebatê de, em têketin û metrîkan lêkolîn dikin û kontrol dikin ka ceribandin derbas bûye. Bi vî rengî em li ser performansa tevna karûbarê xwe fêr dibin û ceribandinek regresyonê dimeşînin da ku texmînên xwe di derheqê tolerasyona xeletiyê de biceribînin.

(Têbînî: Em li ser çavkaniya vekirî ya simulatora tolerasyona xeletiya Istio difikirin, lê hîn ne amade ne ku wiya bikin.)

Ji bo pîvana tevna karûbarê simulatora tolerasyona xeletiya Istio

Me gelek girêkên xebatê yên simulatorê saz kirin:

irs-client-loadgen: 3 kopiyên ku di her çirkekê de 100 daxwazan dişînin irs-client.
irs-client: 3 kopiyên ku daxwazê distînin, 100ms bisekinin û daxwazê bişînin irs-server.
irs-server: 3 kopiyên ku vedigerin 200/OK piştî 100 ms.

Bi vê veavakirinê, em dikarin di navbera 9 xalên dawî de herikîna trafîkê ya domdar bipîvin. Sidecars in irs-client-loadgen и irs-server bistînin 100 daxwazên per second, û irs-client - 200 (hatin û derketin).

Em karanîna çavkaniyê bi rê ve dişopînin DataDogji ber ku koma me ya Prometheus tune.

Encam

Panelên kontrolê

Pêşîn, me vexwarina CPU lêkolîn kir.

Panela kontrolê ya Linkerd ~ 22 milîkor

Panela kontrolê ya Istio: ~ 750 milîkor

Panela kontrolê ya Istio bi qasî bikar tîne 35 caran bêtir çavkaniyên CPUji Linkerd. Bê guman, her tişt ji hêla xwerû ve hatî saz kirin, û istio-telemetry li vir gelek çavkaniyên pêvajoyê vedixwe (dibe ku bi neçalakkirina hin fonksiyonan ve were asteng kirin). Ger em vê hêmanê rakin, em dîsa jî ji 100 mîlîkoran zêdetir dibin, yanî 4 carî bêtirji Linkerd.

Sidecar proxy

Dûv re me karanîna proxy ceriband. Pêdivî ye ku bi hejmara daxwazan re têkiliyek xêzek hebe, lê ji bo her kêlekê hin sermayek heye ku bandorê li ser kêşanê dike.

Linkerd: ~ 100 millicore ji bo irs-client, ~ 50 millicores ji bo irs-client-loadgen

Encam mentiqî xuya dikin, ji ber ku proxya xerîdar du caran ji wekîlê loadgen seyrûseferê werdigire: ji bo her daxwazek derketinê ya ji loadgen, xerîdar yek tê û yek jî derdikeve.

Istio/Envoy: ~ 155 millicore ji bo irs-client, ~ 75 millicore ji bo irs-client-loadgen

Em encamên heman rengî ji bo kêlên Istio dibînin.

Lê bi gelemperî, proxeyên Istio/Envoy dixwe nêzîkî 50% bêtir çavkaniyên CPUji Linkerd.

Em heman nexşeyê li ser milê serverê dibînin:

Linkerd: ~ 50 millicore ji bo irs-server

Istio / Şand: ~ 80 milîkor ji bo server-irs

Li aliyê serverê, sidecar Istio / Envoy dixwe nêzîkî 60% bêtir çavkaniyên CPUji Linkerd.

encamê

Proxy Istio Envoy li ser barê xebata meya simulkirî 50+% zêdetir CPU ji Linkerd dixwe. Panela kontrolê ya Linkerd ji Istio, nemaze ji bo pêkhateyên bingehîn, pir kêmtir çavkaniyan dixwe.

Em hîn jî li ser wê yekê difikirin ku van lêçûn çawa kêm bikin. Ger ramanên we hene, ji kerema xwe parve bikin!

Source: www.habr.com

Ji bo Istio û Linkerd pîvana xerckirina CPU