CPU neysluviðmið fyrir Istio og Linkerd

Inngangur

Við erum í Shopify byrjaði að dreifa Istio sem þjónustuneti. Í grundvallaratriðum er allt í lagi, nema eitt: það er dýrt.

В birt viðmið fyrir Istio segir:

Með Istio 1.1 eyðir umboðið um það bil 0,6 vCPUs (sýndarkjarna) á 1000 beiðnir á sekúndu.

Fyrir fyrsta svæðið í þjónustunetinu (2 umboðsmenn á hvorri hlið tengingarinnar) munum við hafa 1200 kjarna bara fyrir umboðið, á hraðanum ein milljón beiðna á sekúndu. Samkvæmt kostnaðarreiknivél Google virkar það vera um það bil $40/mánuði/kjarna fyrir uppsetningu n1-standard-64, það er, þetta svæði eitt og sér mun kosta okkur meira en 50 þúsund dollara á mánuði fyrir 1 milljón beiðna á sekúndu.

Ivan Sim (Ívan Sim) sjónrænt borið saman tafir á þjónustuneti á síðasta ári og lofaði því sama fyrir minni og örgjörva, en það gekk ekki upp:

Svo virðist sem values-istio-test.yaml muni auka örgjörvabeiðnir verulega. Ef ég hef reiknað út rétt, þarftu um það bil 24 CPU kjarna fyrir stjórnborðið og 0,5 CPU fyrir hvern proxy. Ég á ekki svo mikið. Ég mun endurtaka prófin þegar meira fjármagn er úthlutað til mín.

Mig langaði að sjá sjálfur hversu svipuð frammistaða Istio er öðrum opnum þjónustuneti: Linkerd.

Uppsetning þjónustunets

Fyrst af öllu setti ég það upp í klasa ofurgló:

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

Ég notaði SuperGloo vegna þess að það gerir ræsingu á þjónustunetinu miklu auðveldara. Ég þurfti ekki að gera mikið. Við notum ekki SuperGloo í framleiðslu en það er tilvalið í svona verkefni. Ég þurfti að nota bókstaflega nokkrar skipanir fyrir hvert þjónustunet. Ég notaði tvo klasa til einangrunar - einn hvor fyrir Istio og Linkerd.

Tilraunin var gerð á Google Kubernetes Engine. Ég notaði Kubernetes 1.12.7-gke.7 og laug af hnútum n1-standard-4 með sjálfvirkri hnútkvörðun (lágmark 4, hámark 16).

Síðan setti ég upp báða þjónustunetin frá skipanalínunni.

Fyrst tengdur:

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

Þá 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      |
+---------+------------+---------+---------------------------+

Áreksturslykkjan tók nokkrar mínútur og síðan komust stjórnborðin á stöðugleika.

(Athugið: SuperGloo styður aðeins Istio 1.0.x í bili. Ég endurtók tilraunina með Istio 1.1.3, en tók ekki eftir neinum merkjanlegum mun.)

Uppsetning Istio sjálfvirkrar uppsetningar

Til að láta Istio setja upp hliðarvagninn Envoy notum við hliðarvagninnsprautuna − MutatingAdmissionWebhook. Við munum ekki tala um það í þessari grein. Leyfðu mér bara að segja að þetta er stjórnandi sem fylgist með aðgangi allra nýrra belg og bætir við hliðarvagni og initContainer á virkan hátt, sem ber ábyrgð á verkefnum iptables.

Við hjá Shopify skrifuðum okkar eigin aðgangsstýringu til að útfæra hliðarvagna, en fyrir þetta viðmið notaði ég stjórnandann sem fylgir Istio. Stýringin sprautar hliðarvagna sjálfgefið þegar það er flýtileið í nafnrýminu 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

Setja upp sjálfvirka Linkerd dreifingu

Til að setja upp Linkerd hliðarvagnainnfellingu notum við athugasemdir (ég bætti þeim við handvirkt í gegnum 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 villuþolshermir

Við smíðuðum bilanaþolshermi sem heitir Istio til að gera tilraunir með umferð sem er einstök fyrir Shopify. Okkur vantaði tól til að búa til sérsniðna staðfræði sem myndi tákna ákveðinn hluta af þjónustugrafinu okkar, virkt stillt til að móta tiltekið vinnuálag.

Innviðir Shopify eru undir miklu álagi meðan á leiftursölu stendur. Á sama tíma, Shopify mælir með seljendum að halda slíka sölu oftar. Stórir viðskiptavinir vara stundum við fyrirhugaðri skyndisölu. Aðrir haga þeim óvænt fyrir okkur hvenær sem er sólarhringsins.

Við vildum að seigluhermirinn okkar myndi móta vinnuflæði sem passa við staðfræði og vinnuálag sem hefur gagntekið innviði Shopify áður. Megintilgangur þess að nota þjónustunet er að við þurfum áreiðanleika og bilanaþol á netstigi og það er mikilvægt fyrir okkur að þjónustunetið ráði á áhrifaríkan hátt við álag sem áður truflaði þjónustu.

Kjarninn í bilunarþolsherminum er vinnuhnútur, sem virkar sem þjónustunetshnútur. Starfsmannahnútinn er hægt að stilla kyrrstætt við ræsingu eða virkt í gegnum REST API. Við notum kraftmikla uppsetningu starfsmannahnúta til að búa til verkflæði í formi aðhvarfsprófa.

Hér er dæmi um slíkt ferli:

• Við ræsum 10 netþjóna sem bar þjónustu sem skilar svari 200/OK eftir 100 ms.
• Við ræsum 10 viðskiptavini - hver sendir 100 beiðnir á sekúndu til bar.
• Á 10 sekúndna fresti fjarlægjum við 1 netþjón og fylgjumst með villum 5xx á viðskiptavininn.

Í lok verkflæðisins skoðum við annálana og mælikvarðana og athugum hvort prófið hafi staðist. Þannig lærum við um frammistöðu þjónustunetsins okkar og keyrum aðhvarfspróf til að prófa forsendur okkar um bilanaþol.

(Athugið: Við erum að hugsa um að útvega Istio bilanaþolsherminn með opnum hætti en erum ekki tilbúin til að gera það ennþá.)

Istio bilunarþolshermir fyrir þjónustumöskunarviðmið

Við erum að setja upp nokkra vinnuhnúta hermirsins:

• irs-client-loadgen: 3 eftirlíkingar sem senda 100 beiðnir á sekúndu pr irs-client.
• irs-client: 3 eftirlíkingar sem fá beiðnina, bíða í 100 ms og framsenda beiðnina til irs-server.
• irs-server: 3 eftirlíkingar sem skila sér 200/OK eftir 100 ms.

Með þessari uppsetningu getum við mælt stöðugt umferðarflæði á milli 9 endapunkta. Hliðarvagnar inn irs-client-loadgen и irs-server fá 100 beiðnir á sekúndu, og irs-client — 200 (komandi og út).

Við fylgjumst með auðlindanotkun í gegnum DataDogvegna þess að við höfum ekki Prometheus þyrping.

Niðurstöður

Stjórnborð

Fyrst skoðuðum við örgjörvanotkunina.

Linkerd stjórnborð ~22 millikjarna

Istio stjórnborð: ~750 millikjarna

Istio stjórnborðið notar u.þ.b 35 sinnum meira CPU auðlindiren Linkerd. Auðvitað er allt sjálfgefið uppsett og istio-telemetry eyðir miklu af örgjörvaauðlindum hér (hægt að slökkva á því með því að slökkva á sumum aðgerðum). Ef við fjarlægjum þennan þátt fáum við samt meira en 100 millikjarna, það er 4 sinnum meiraen Linkerd.

Sidecar proxy

Við prófuðum síðan notkun umboðs. Það ætti að vera línulegt samband við fjölda beiðna, en fyrir hvern hliðarvagn er einhver kostnaður sem hefur áhrif á ferilinn.

Linkerd: ~100 millikjarna fyrir irs-client, ~50 millicore fyrir irs-client-loadgen

Niðurstöðurnar líta rökrétt út, vegna þess að umboð viðskiptavinarins fær tvöfalt meiri umferð en loadgen umboðið: fyrir hverja sendandi beiðni frá loadgen hefur viðskiptavinurinn eina innkomna og eina áleiðis.

Istio/Envoy: ~155 millikjarna fyrir irs-viðskiptavin, ~75 millikjarna fyrir irs-client-loadgen

Við sjáum svipaðar niðurstöður fyrir Istio hliðarvagna.

En almennt neyta Istio/Envoy umboðsmenn um það bil 50% meira CPU auðlindiren Linkerd.

Við sjáum sama kerfi á miðlarahliðinni:

Linkerd: ~50 millikjarna fyrir irs-þjónn

Istio/Envoy: ~80 millikjarna fyrir irs-þjónn

Á miðlarahlið, hliðarvagn Istio/Envoy eyðir um það bil 60% meira CPU auðlindiren Linkerd.

Ályktun

Istio Envoy umboðið eyðir 50+% meiri örgjörva en Linkerd á hermt vinnuálagi okkar. Linkerd stjórnborðið eyðir miklu minna fjármagni en Istio, sérstaklega fyrir kjarnahlutana.

Við erum enn að hugsa um hvernig eigi að draga úr þessum kostnaði. Ef þú hefur hugmyndir, vinsamlegast deila!

Heimild: www.habr.com