Benchmark spotreby CPU pre Istio a Linkerd

Úvod

Sme v tom Shopify začal nasadzovať Istio ako sieť služieb. V zásade je všetko v poriadku, až na jednu vec: je to drahé.

В zverejnené benchmarky pre Istio sa hovorí:

S Istio 1.1 proxy spotrebuje približne 0,6 vCPU (virtuálnych jadier) na 1000 požiadaviek za sekundu.

Pre prvý región v servisnej sieti (2 proxy na každej strane pripojenia) budeme mať 1200 jadier len pre proxy, rýchlosťou jeden milión požiadaviek za sekundu. Podľa kalkulačky nákladov Google to vychádza približne na 40 USD/mesiac/jadro na konfiguráciu n1-standard-64, to znamená, že len tento región nás bude stáť viac ako 50 tisíc dolárov mesačne za 1 milión žiadostí za sekundu.

Ivan Sim (Ivan Sim) vizuálne porovnať meškanie servisnej siete minulý rok a sľubovali to isté pre pamäť a procesor, ale nevyšlo to:

Hodnoty-istio-test.yaml zrejme vážne zvýšia požiadavky na CPU. Ak som počítal správne, potrebujete približne 24 jadier CPU pre ovládací panel a 0,5 CPU pre každý proxy. Nemám toľko. Testy zopakujem, keď mi bude pridelených viac zdrojov.

Chcel som na vlastné oči vidieť, aký podobný je výkon Istio inej sieti open source služieb: Linkerd.

Inštalácia servisnej siete

V prvom rade som ho nainštaloval do klastra 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!

Použil som SuperGloo, pretože výrazne uľahčuje bootstraping servisnej siete. Nemusel som robiť veľa. SuperGloo pri výrobe nepoužívame, ale na takúto úlohu je ideálny. Musel som použiť doslova pár príkazov pre každú servisnú sieť. Na izoláciu som použil dva klastre - každý pre Istio a jeden pre Linkerd.

Experiment sa uskutočnil na Google Kubernetes Engine. Použil som Kubernetes 1.12.7-gke.7 a skupina uzlov n1-standard-4 s automatickým škálovaním uzlov (minimálne 4, maximálne 16).

Potom som z príkazového riadku nainštaloval obe servisné siete.

Prvý 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 |
+---------+--------------+---------+---------------------------+

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

Nárazová slučka trvala niekoľko minút a potom sa ovládacie panely stabilizovali.

(Poznámka: SuperGloo zatiaľ podporuje iba Istio 1.0.x. Zopakoval som experiment s Istio 1.1.3, ale nezaznamenal som žiadny výrazný rozdiel.)

Nastavenie automatického nasadenia Istio

Aby Istio nainštaloval postranný vozík Envoy, používame vstrekovač postranného vozíka − MutatingAdmissionWebhook. O tom sa v tomto článku baviť nebudeme. Dovoľte mi povedať, že ide o ovládač, ktorý monitoruje prístup všetkých nových modulov a dynamicky pridáva postranný vozík a initContainer, ktorý je zodpovedný za úlohy iptables.

My v Shopify sme napísali vlastný prístupový kontrolér na implementáciu postranných vozíkov, ale pre tento benchmark som použil kontrolér, ktorý je dodávaný s Istio. Ovládač štandardne vstrekuje sajdkáry, keď je v mennom priestore skratka 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

Nastavenie automatického nasadenia Linkerd

Na nastavenie vkladania postranného vozíka Linkerd používame anotácie (pridal som ich manuálne cez 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

Simulátor odolnosti proti chybám Istio

Postavili sme simulátor odolnosti voči chybám s názvom Istio, aby sme experimentovali s návštevnosťou jedinečnú pre Shopify. Potrebovali sme nástroj na vytvorenie vlastnej topológie, ktorá by predstavovala špecifickú časť grafu našej služby, dynamicky nakonfigurovanú na modelovanie konkrétnych pracovných zaťažení.

Infraštruktúra Shopify je počas bleskových predajov veľmi zaťažená. Zároveň Shopify odporúča predajcom, aby takéto výpredaje organizovali častejšie. Veľkí odberatelia občas upozorňujú na pripravovaný bleskový výpredaj. Iní ich za nás vedú nečakane kedykoľvek počas dňa alebo v noci.

Chceli sme, aby náš simulátor odolnosti modeloval pracovné postupy, ktoré zodpovedajú topológiám a pracovným zaťaženiam, ktoré v minulosti zahlcovali infraštruktúru Shopify. Hlavným účelom použitia siete služieb je, že potrebujeme spoľahlivosť a odolnosť voči chybám na úrovni siete a je pre nás dôležité, aby sieť služieb efektívne zvládala záťaže, ktoré predtým narušovali služby.

Srdcom simulátora odolnosti voči chybám je pracovný uzol, ktorý funguje ako uzol siete služieb. Pracovný uzol možno konfigurovať staticky pri spustení alebo dynamicky cez REST API. Dynamickú konfiguráciu pracovných uzlov využívame na vytváranie pracovných tokov vo forme regresných testov.

Tu je príklad takéhoto procesu:

• Spúšťame 10 serverov ako bar službu, ktorá vráti odpoveď 200/OK po 100 ms.
• Spúšťame 10 klientov – každý odošle 100 požiadaviek za sekundu bar.
• Každých 10 sekúnd odstránime 1 server a monitorujeme chyby 5xx na klientovi.

Na konci pracovného postupu preskúmame protokoly a metriky a skontrolujeme, či test prešiel. Týmto spôsobom sa dozvieme o výkone našej servisnej siete a spustíme regresný test, aby sme otestovali naše predpoklady o odolnosti voči chybám.

(Poznámka: Uvažujeme o otvorenom zdroji simulátora odolnosti voči chybám Istio, ale ešte na to nie sme pripravení.)

Simulátor odolnosti proti chybám Istio pre test servisnej siete

Nastavili sme niekoľko pracovných uzlov simulátora:

• irs-client-loadgen: 3 repliky, ktoré odosielajú 100 požiadaviek za sekundu za irs-client.
• irs-client: 3 repliky, ktoré prijmú požiadavku, počkajú 100 ms a pošlú požiadavku na irs-server.
• irs-server: 3 repliky, ktoré sa vracajú 200/OK po 100 ms.

S touto konfiguráciou môžeme merať stabilný tok návštevnosti medzi 9 koncovými bodmi. Sidecars in irs-client-loadgen и irs-server prijímať 100 žiadostí za sekundu a irs-client — 200 (prichádzajúce a odchádzajúce).

Spotrebu zdrojov sledujeme prostredníctvom DataDogpretože nemáme zhluk Prometheus.

výsledky

Ovládacie panely

Najprv sme skúmali spotrebu CPU.

Ovládací panel Linkerd ~22 milicore

Ovládací panel Istio: ~750 milicore

Ovládací panel Istio využíva približne 35-krát viac zdrojov CPUnež Linkerd. Samozrejme, všetko je štandardne nainštalované a istio-telemetria tu spotrebúva veľa procesorových zdrojov (dá sa deaktivovať zakázaním niektorých funkcií). Ak odstránime túto zložku, stále dostaneme viac ako 100 milijadrov, tj 4 krát viacnež Linkerd.

Sidecar proxy

Potom sme testovali použitie proxy. Mal by existovať lineárny vzťah s počtom požiadaviek, ale pre každý postranný vozík existuje určitá réžia, ktorá ovplyvňuje krivku.

Linkerd: ~100 milijadrov pre irs-client, ~50 milicores pre irs-client-loadgen

Výsledky vyzerajú logicky, pretože klientsky proxy prijíma dvakrát toľko prevádzky ako loadgen proxy: pre každú odchádzajúcu požiadavku z loadgen má klient jednu prichádzajúcu a jednu odchádzajúcu.

Istio/Envoy: ~155 milicore pre klienta irs, ~75 milicore pre klienta irs-loadgen

Podobné výsledky vidíme aj pre sajdkáry Istio.

Ale vo všeobecnosti Istio/Envoy proxy spotrebúvajú približne o 50 % viac zdrojov CPUnež Linkerd.

Rovnakú schému vidíme na strane servera:

Linkerd: ~50 milicore pre irs-server

Istio/Envoy: ~80 milicore pre irs-server

Na strane servera spotrebuje postranný vozík Istio/Envoy približne o 60 % viac zdrojov CPUnež Linkerd.

Záver

Istio Envoy proxy spotrebuje o 50+ % viac CPU ako Linkerd pri našom simulovanom pracovnom zaťažení. Ovládací panel Linkerd spotrebuje oveľa menej zdrojov ako Istio, najmä pokiaľ ide o základné komponenty.

Stále rozmýšľame, ako tieto náklady znížiť. Ak máte nápady, zdieľajte!

Zdroj: hab.com