Merilo porabe procesorja za Istio in Linkerd

Predstavitev

Smo notri Shopify začel uvajati Istio kot storitveno mrežo. Načeloma je vse v redu, razen ene stvari: to je drago.

В objavljena merila uspešnosti za Istio piše:

Z Istio 1.1 proxy porabi približno 0,6 vCPE-jev (navideznih jeder) na 1000 zahtev na sekundo.

Za prvo regijo v servisni mreži (2 proxyja na vsaki strani povezave) bomo imeli 1200 jeder samo za proxy s hitrostjo en milijon zahtev na sekundo. Po Googlovem kalkulatorju stroškov znaša približno 40 USD/mesec/jedro za konfiguracijo n1-standard-64, to pomeni, da nas bo samo ta regija stala več kot 50 tisoč dolarjev na mesec za 1 milijon zahtev na sekundo.

Ivan Sim (Ivan Sim) vizualno primerjali service mesh zamuja lani in obljublja isto za pomnilnik in procesor, pa se ni izšlo:

Očitno bo values-istio-test.yaml resno povečal zahteve procesorja. Če sem pravilno izračunal, potrebujete približno 24 CPE jeder za nadzorno ploščo in 0,5 CPE za vsak proxy. Nimam toliko. Teste bom ponovil, ko mi bo dodeljenih več sredstev.

Želel sem se na lastne oči prepričati, kako podobna je zmogljivost Istia drugi mreži odprtokodne storitve: Linkerd.

Montaža servisne mreže

Najprej sem ga namestil v gručo superglu:

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

Uporabil sem SuperGloo, ker olajša zagon servisne mreže. Ni mi bilo treba narediti veliko. SuperGloo ne uporabljamo v proizvodnji, vendar je idealen za tako nalogo. Za vsako storitveno mrežo sem moral uporabiti dobesedno nekaj ukazov. Za izolacijo sem uporabil dve gruči - po eno za Istio in Linkerd.

Poskus je bil izveden na Google Kubernetes Engine. Uporabil sem Kubernetes 1.12.7-gke.7 in nabor vozlišč n1-standard-4 s samodejnim skaliranjem vozlišč (najmanj 4, največ 16).

Nato sem namestil obe servisni mreži iz ukazne vrstice.

Prvi povezovalec:

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

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

Zanka zrušitve je trajala nekaj minut, nato pa so se nadzorne plošče stabilizirale.

(Opomba: SuperGloo trenutno podpira samo Istio 1.0.x. Ponovil sem poskus z Istio 1.1.3, vendar nisem opazil opazne razlike.)

Nastavitev samodejne uvedbe Istio

Za namestitev prikolice Envoy v Istio uporabimo injektor za prikolico − MutatingAdmissionWebhook. V tem članku o tem ne bomo govorili. Naj samo povem, da je to krmilnik, ki spremlja dostop vseh novih podov in dinamično doda stransko prikolico in initContainer, ki je odgovoren za opravila iptables.

V Shopifyju smo napisali lasten krmilnik dostopa za implementacijo stranskih prikolic, vendar sem za to primerjalno merilo uporabil krmilnik, ki je priložen Istiu. Krmilnik privzeto vstavi stranske prikolice, ko je v imenskem prostoru bližnjica 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

Nastavitev samodejne uvedbe Linkerda

Za nastavitev vdelave Linkerd sidecar uporabljamo opombe (dodal sem jih ročno prek 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

Simulator tolerance napak Istio

Zgradili smo simulator tolerance napak, imenovan Istio, za eksperimentiranje s prometom, ki je edinstven za Shopify. Potrebovali smo orodje za ustvarjanje topologije po meri, ki bi predstavljala določen del našega storitvenega grafa, dinamično konfiguriranega za modeliranje določenih delovnih obremenitev.

Shopifyjeva infrastruktura je med hitro prodajo zelo obremenjena. Hkrati Shopify prodajalcem priporoča pogostejše razprodaje. Velike stranke včasih opozorijo na načrtovano hitro prodajo. Drugi jih izvajajo za nas nepričakovano kadar koli podnevi ali ponoči.

Želeli smo, da naš simulator odpornosti modelira poteke dela, ki se ujemajo s topologijami in delovnimi obremenitvami, ki so v preteklosti preobremenile Shopifyjevo infrastrukturo. Glavni namen uporabe storitvenega omrežja je, da potrebujemo zanesljivost in toleranco na napake na ravni omrežja, pri čemer je za nas pomembno, da se storitveno omrežje učinkovito spopade z obremenitvami, ki so prej motile storitve.

V središču simulatorja tolerance napak je delovno vozlišče, ki deluje kot servisno mrežno vozlišče. Delovno vozlišče je mogoče konfigurirati statično ob zagonu ali dinamično prek API-ja REST. Uporabljamo dinamično konfiguracijo delovnih vozlišč za ustvarjanje delovnih tokov v obliki regresijskih testov.

Tukaj je primer takega postopka:

• Zaženemo 10 strežnikov kot bar storitev, ki vrne odgovor 200/OK po 100 ms.
• Zaženemo 10 odjemalcev - vsak pošlje 100 zahtev na sekundo bar.
• Vsakih 10 sekund odstranimo 1 strežnik in spremljamo napake 5xx na stranko.

Na koncu delovnega toka pregledamo dnevnike in metrike ter preverimo, ali je test uspel. Na ta način izvemo o zmogljivosti naše storitvene mreže in izvedemo regresijski test, da preizkusimo svoje predpostavke o toleranci napak.

(Opomba: razmišljamo o odprtokodnem simulatorju tolerance napak Istio, vendar na to še nismo pripravljeni.)

Simulator tolerance napak Istio za merilo uspešnosti storitvenega omrežja

Vzpostavljamo več delovnih vozlišč simulatorja:

• irs-client-loadgen: 3 replike, ki pošljejo 100 zahtev na sekundo na irs-client.
• irs-client: 3 replike, ki prejmejo zahtevo, počakajo 100 ms in posredujejo zahtevo na irs-server.
• irs-server: 3 replike, ki se vračajo 200/OK po 100 ms.

S to konfiguracijo lahko merimo stabilen prometni tok med 9 končnimi točkami. Stranske prikolice noter irs-client-loadgen и irs-server prejmete 100 zahtev na sekundo in irs-client — 200 (dohodni in odhodni).

Porabo virov spremljamo prek DataDogker nimamo kopice Prometheus.

Ugotovitve

Nadzorne plošče

Najprej smo preučili porabo procesorja.

Nadzorna plošča Linkerd ~22 millicore

Nadzorna plošča Istio: ~750 milicore

Nadzorna plošča Istio uporablja približno 35-krat več virov procesorjakot Linkerd. Seveda je vse nameščeno privzeto in istio-telemetrija tukaj porabi veliko virov procesorja (onemogočite jo lahko z onemogočanjem nekaterih funkcij). Če to komponento odstranimo, še vedno dobimo več kot 100 milicore, tj 4 krat večkot Linkerd.

Sidecar proxy

Nato smo preizkusili uporabo proxyja. Obstajati mora linearna povezava s številom zahtev, vendar je za vsako stransko prikolico nekaj režijskih stroškov, ki vplivajo na krivuljo.

Linkerd: ~100 milicores za irs-client, ~50 milicores za irs-client-loadgen

Rezultati so videti logični, saj odjemalski proxy prejme dvakrat več prometa kot loadgen proxy: za vsako odhodno zahtevo od loadgen ima odjemalec eno dohodno in eno odhodno.

Istio/Envoy: ~155 milicores za irs-client, ~75 milicores za irs-client-loadgen

Podobne rezultate vidimo za stranske prikolice Istio.

Toda na splošno proxyji Istio/Envoy porabijo približno 50 % več virov procesorjakot Linkerd.

Vidimo isto shemo na strani strežnika:

Linkerd: ~50 millicore za irs-strežnik

Istio/Envoy: ~80 milicorejev za strežnik irs

Na strani strežnika stranska prikolica Istio/Envoy porabi približno 60 % več virov procesorjakot Linkerd.

Zaključek

Istio Envoy proxy porabi 50+ % več CPU kot Linkerd pri naši simulirani delovni obremenitvi. Nadzorna plošča Linkerd porabi veliko manj virov kot Istio, zlasti za osnovne komponente.

Kako te stroške zmanjšati, še razmišljamo. Če imate ideje, jih prosim delite!

Vir: www.habr.com