🥇Benchmark spotreby CPU pre Istio a Linkerd

Benchmark spotreby CPU pre Istio a Linkerd

Úvod

My v Shopify sme zaoberali nasadením Istio ako service mesh. V zásade je všetko v poriadku, okrem jednej veci: je to drahé.

V publikovaných benchmarkoch pre Istio sa uvádza:

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

Pre prvú oblasť v service mesh (po 2 proxy na každej strane pripojenia) budeme potrebovať 1200 jadier len pre proxy, pričom počítame s jedným miliónom požiadaviek za sekundu. Podľa kalkulačky nákladov od Google to vychádza na približne 40 dolárov/mesiac/jadro pre konfiguráciu n1-standard-64, teda jedna táto oblasť nás bude stáť viac ako 50 tisíc dolárov mesačne za 1 milión požiadaviek za sekundu.

Ivan Sim (Ivan Sim) jasne porovnal latencie service mesh z minulého roka a sľúbil to isté pre pamäť a procesor, ale nepodarilo sa:

Zrejme values-istio-test.yaml vážne zvýši požiadavky na procesor. Ak som to správne vypočítal, potrebujem približne 24 procesorových jadier pre ovládací panel a 0,5 CPU pre každý proxy. Nemám toľko. Opakujem testy, keď mi pridelia viac zdrojov.

Chcel som sa sám presvedčiť, ako sa ukazovatele Istio porovnávajú s inou service mesh s otvoreným kódom: Linkerd.

Inštalácia service mesh

Najprv som nainštaloval v klastri 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 začiatok nasadenia service mesh. Takmer som nemusel nič robiť. V produkcii nepoužívame SuperGloo, ale na podobnú úlohu je ideálny. Musel som použiť len pár príkazov pre každú service mesh. Použil som dve klastry na izoláciu — po jednom pre Istio a Linkerd.

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

Potom som nainštaloval obe service mesh z príkazového riadku.

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

Crash-loop trval niekoľko minút, a potom sa ovládacie panely stabilizovali.

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

Nastavenie automatického vkladania Istio

Aby Istio nainštaloval sidecar Envoy, používame sidecar-injektor — MutatingAdmissionWebhook. Nebudeme o ňom hovoriť v tomto článku. Len poviem, že je to kontrolér, ktorý sleduje prístup všetkých nových podov a dynamicky pridáva sidecar a initContainer, ktorý sa zaoberá úlohami iptables.

V Shopify sme napísali svoj kontrolér prístupu na vkladanie sidecar-ov, ale v tomto benchmarku som vzal kontrolér, ktorý dodáva Istio. Predvolený kontrolér vkladá sidecar-y, keď v názvoslovnom priestore existuje štítok 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 vkladania Linkerd

Aby sme nastavili vkladanie sidecar-ov Linkerd, používame anotácie (pridal som ich ručne 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 Istio

Vytvorili sme simulátor odolnosti Istio, aby sme experimentovali s prevádzkovým tokom špecifickým pre Shopify. Potrebovali sme nástroj na vytváranie ľubovoľnej topológie, ktorá bude predstavovať konkrétnu časť grafu našej služby s dynamickým nastavením na modelovanie špecifických pracovných záťaží.

Infrastruktúra Shopify zažíva veľké zaťaženie počas bleskových výpredajov. Shopify odporúča predajcom častejšie organizovať takéto výpredaje. Veľkí zákazníci niekedy varujú o plánovanej bleskovej akcii. Iní ich vykonávajú nečakane pre nás v akomkoľvek čase počas dňa a noci.

Chceli sme, aby náš simulátor odolnosti modeloval pracovné procesy, ktoré sú v súlade s topológiami a pracovnými záťažami, ktoré v minulosti viedli k preťaženiu infraštruktúry Shopify. Hlavným cieľom použitia service mesh je, že potrebujeme spoľahlivosť a odolnosť na úrovni siete a je pre nás dôležité, aby si service mesh efektívne poradila s zaťaženiami, ktoré predtým narúšali prevádzku služieb.

Na základe simulátora odolnosti stojí pracovný uzol, ktorý funguje ako uzol service mesh. Pracovný uzol je možné nakonfigurovať staticky pri spustení alebo dynamicky prostredníctvom REST API. Používame dynamické nastavenie pracovných uzlov na vytváranie pracovných procesov vo forme regresných testov.

Tu je príklad takéhoto procesu:

Spúšťame 10 serverov ako bar služba, ktorá vracia odpoveď 200/OK po 100 ms.
Spúšťame 10 klientov - každý odosiela 100 požiadaviek za sekundu na bar.
Každých 10 sekúnd zrušíme 1 server, monitorujeme chyby 5xx na klientovi.

Na konci pracovného procesu skúmame logy a metriky a kontrolujeme, či test prešiel. Takto sa dozvedáme o výkonnosti našich service mesh a vykonávame regresný test, aby sme preverili naše predpoklady o odolnosti.

(Poznámka: Zvažujeme otvorenie zdrojového kódu simulátora odolnosti Istio, ale ešte nie sme na to pripravení.)

Simulátor odolnosti Istio pre benchmarkovanie service mesh

Nastavujeme niekoľko pracovných uzlov simulátora:

irs-client-loadgen: 3 repliky, ktoré odosielajú 100 požiadaviek za sekundu do irs-client.
irs-client: 3 repliky, ktoré prijímajú požiadavku, čakajú 100 ms a presmerovávajú požiadavku na irs-server.
irs-server: 3 repliky, ktoré vracajú 200/OK po 100 ms.

S touto konfiguráciou môžeme merať stabilný tok prevádzky medzi 9 koncovými bodmi. Sidecar-y v irs-client-loadgen a irs-server dostávajú 100 požiadaviek za sekundu, a irs-client — 200 (prichádzajúcich a odchádzajúcich).

Sledujeme využitie zdrojov cez DataDog, pretože nemáme klaster Prometheus.

Výsledky

Ovládacie panely

Najprv sme preskúmali spotrebu CPU.

Ovládací panel Linkerd ~22 miliardy

Ovládací panel Istio: ~750 miliárd

Ovládací panel Istio využíva približne 35-krát viac procesorových zdrojov, než Linkerd. Samozrejme, všetko je nastavené predvolene a veľa procesorových zdrojov tu spotrebuje istio-telemetry (to je možné vypnúť, ak sa vzdáte niektorých funkcií). Ak tento komponent odstránite, stále to bude viac ako 100 miliárd, teda 4-krát viac, než Linkerd.

Sidecar proxy

Potom sme skontrolovali využitie proxy. Tu by mala byť lineárna závislosť od počtu požiadaviek, ale pre každý sidecar sú určité náklady, ktoré ovplyvňujú krivku.

Linkerd: ~100 miliárd pre irs-client, ~50 miliárd pre irs-client-loadgen

Výsledky vyzerajú logicky, pretože proxy klient dostáva dvakrát viac prevádzky, ako proxy loadgen: na každú odchádzajúcu požiadavku od loadgen pripadá jedna prichádzajúca a jedna odchádzajúca.

Istio/Envoy: ~155 miliárd pre irs-client, ~75 miliárd pre irs-client-loadgen

Vidíme podobné výsledky pre sidecar-y Istio.

Ale celkovo proxy Istio/Envoy spotrebovávajú približne o 50% viac procesorových zdrojov, než Linkerd.

Tú istú schému vidíme na strane servera:

Linkerd: ~50 miliárd pre irs-server

Istio/Envoy: ~80 miliárd pre irs-server

Na strane servera sidecar Istio/Envoy spotrebuje približne o 60% viac procesorových zdrojov, než Linkerd.

Záver

Proxy Istio Envoy spotrebuje o 50+% viac CPU, než Linkerd, na našej simulovanej pracovnej záťaži. Ovládací panel Linkerd spotrebuje omnoho menej zdrojov, než Istio, najmä sa to týka základných komponentov.

Stále premýšľame, ako tieto náklady znížiť. Ak máte nápady, podeľte sa!

Zdroj: habr.com