Benchmark spotřeby CPU pro Istio a Linkerd

úvod

Jsme v Shopify začal nasazovat Istio jako servisní síť. V zásadě je vše v pořádku, až na jednu věc: je to drahé.

В zveřejněné benchmarky pro Istio to říká:

S Istio 1.1 proxy spotřebuje přibližně 0,6 vCPU (virtuálních jader) na 1000 požadavků za sekundu.

Pro první oblast v síti služeb (2 proxy na každé straně připojení) budeme mít 1200 jader jen pro proxy, rychlostí jeden milion požadavků za sekundu. Podle kalkulátoru nákladů Google to vychází přibližně na 40 USD/měsíc/jádro za konfiguraci n1-standard-64, to znamená, že jen tento region nás bude stát více než 50 tisíc dolarů měsíčně za 1 milion požadavků za sekundu.

Ivan Sim (Ivan Sim) vizuálně srovnání Service mesh zpoždění v loňském roce a slíbili totéž pro paměť a procesor, ale nefungovalo to:

Hodnoty-istio-test.yaml zřejmě vážně zvýší požadavky na CPU. Pokud jsem počítal správně, potřebujete přibližně 24 jader CPU pro ovládací panel a 0,5 CPU pro každý proxy. Tolik toho nemám. Testy zopakuji, až mi bude přiděleno více zdrojů.

Chtěl jsem na vlastní oči vidět, jak podobný je výkon Istio jiné síti open source služeb: Linkerd.

Instalace servisní sítě

Nejprve jsem to nainstaloval do clusteru 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 jsem SuperGloo, protože usnadňuje bootstraping servisní sítě. Moc jsem toho dělat nemusel. SuperGloo ve výrobě nepoužíváme, ale pro takový úkol je ideální. Musel jsem použít doslova několik příkazů pro každou servisní síť. Pro izolaci jsem použil dva clustery – každý pro Istio a jeden pro Linkerd.

Experiment byl proveden na Google Kubernetes Engine. Použil jsem Kubernetes 1.12.7-gke.7 a skupina uzlů n1-standard-4 s automatickým škálováním uzlů (minimálně 4, maximálně 16).

Poté jsem z příkazového řádku nainstaloval obě servisní sítě.

První 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 |
+---------+--------------+---------+---------------------------+

Pak 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á smyčka trvala několik minut a pak se ovládací panely stabilizovaly.

(Poznámka: SuperGloo zatím podporuje pouze Istio 1.0.x. Zopakoval jsem experiment s Istio 1.1.3, ale nezaznamenal jsem žádný znatelný rozdíl.)

Nastavení automatického nasazení Istio

Aby Istio nainstaloval postranní vozík Envoy, použijeme vstřikovač postranního vozíku − MutatingAdmissionWebhook. O tom se v tomto článku bavit nebudeme. Dovolte mi jen říci, že se jedná o ovladač, který sleduje přístup všech nových modulů a dynamicky přidává postranní vozík a initContainer, který je zodpovědný za úkoly iptables.

My v Shopify jsme napsali náš vlastní přístupový kontrolér k implementaci postranních vozíků, ale pro tento benchmark jsem použil kontrolér, který je dodáván s Istio. Ovladač standardně injektuje postranní vozíky, když je v jmenném prostoru zástupce 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

Nastavení automatického nasazení Linkerd

K nastavení vkládání postranního vozíku Linkerd používáme anotace (přidal jsem je ručně přes 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

Postavili jsme simulátor odolnosti proti chybám s názvem Istio, abychom experimentovali s provozem jedinečným pro Shopify. Potřebovali jsme nástroj k vytvoření vlastní topologie, která by představovala konkrétní část grafu našich služeb, dynamicky konfigurovanou pro modelování konkrétních úloh.

Infrastruktura Shopify je během bleskových prodejů pod velkým zatížením. Zároveň Shopify doporučuje prodejcům, aby takové prodeje pořádali častěji. Velcí zákazníci občas varují před plánovaným bleskovým výprodejem. Jiní je pro nás provádějí nečekaně v kteroukoli denní i noční dobu.

Chtěli jsme, aby náš simulátor odolnosti modeloval pracovní postupy, které odpovídají topologiím a pracovním zátěžím, které v minulosti zahlcovaly infrastrukturu Shopify. Hlavním účelem použití servisní sítě je, že potřebujeme spolehlivost a odolnost proti chybám na úrovni sítě a je pro nás důležité, aby se servisní síť efektivně vypořádala se zátěží, která dříve narušovala služby.

Srdcem simulátoru odolnosti proti chybám je pracovní uzel, který funguje jako uzel sítě služeb. Pracovní uzel lze konfigurovat staticky při spuštění nebo dynamicky přes REST API. Dynamickou konfiguraci pracovních uzlů využíváme k vytváření pracovních postupů ve formě regresních testů.

Zde je příklad takového procesu:

• Spouštíme 10 serverů jako bar služba, která vrací odpověď 200/OK po 100 ms.
• Spouštíme 10 klientů - každý odešle 100 požadavků za sekundu bar.
• Každých 10 sekund odebereme 1 server a sledujeme chyby 5xx na klientovi.

Na konci pracovního postupu prozkoumáme protokoly a metriky a zkontrolujeme, zda test prošel. Tímto způsobem se dozvíme o výkonu naší servisní sítě a spustíme regresní test, abychom otestovali naše předpoklady o odolnosti proti chybám.

(Poznámka: Uvažujeme o otevřeném získávání simulátoru odolnosti proti chybám Istio, ale zatím na to nejsme připraveni.)

Simulátor odolnosti proti chybám Istio pro benchmark servisní sítě

Nastavili jsme několik pracovních uzlů simulátoru:

• irs-client-loadgen: 3 repliky, které odesílají 100 požadavků za sekundu za irs-client.
• irs-client: 3 repliky, které přijmou požadavek, počkají 100 ms a předají požadavek na irs-server.
• irs-server: 3 repliky, které se vracejí 200/OK po 100 ms.

S touto konfigurací můžeme měřit stabilní tok provozu mezi 9 koncovými body. Postranní vozíky v irs-client-loadgen и irs-server přijímat 100 požadavků za sekundu a irs-client — 200 (příchozí a odchozí).

Sledujeme využití zdrojů prostřednictvím DataDogprotože nemáme shluk Prometheus.

výsledky

Ovládací panely

Nejprve jsme zkoumali spotřebu CPU.

Ovládací panel Linkerd ~22 milicore

Ovládací panel Istio: ~750 milicore

Ovládací panel Istio využívá přibližně 35krát více zdrojů CPUnež Linkerd. Vše je samozřejmě standardně nainstalováno a istio-telemetrie zde spotřebovává spoustu procesorových prostředků (lze ji deaktivovat vypnutím některých funkcí). Pokud tuto komponentu odstraníme, stále získáme více než 100 milicores, tzn 4krát vícenež Linkerd.

Sidecar proxy

Poté jsme vyzkoušeli použití proxy. Měl by existovat lineární vztah s počtem požadavků, ale pro každý postranní vozík existuje určitá režie, která ovlivňuje křivku.

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

Výsledky vypadají logicky, protože klientský proxy přijímá dvakrát tolik provozu než loadgen proxy: pro každý odchozí požadavek z loadgen má klient jeden příchozí a jeden odchozí.

Istio/Envoy: ~155 milicore pro irs-client, ~75 millicore pro irs-client-loadgen

Podobné výsledky vidíme u sajdkár Istio.

Ale obecně Istio/Envoy proxy spotřebovávají přibližně o 50 % více zdrojů CPUnež Linkerd.

Stejné schéma vidíme na straně serveru:

Linkerd: ~50 milicore pro irs-server

Istio/Envoy: ~80 milicore pro irs-server

Na straně serveru spotřebovává postranní vozík Istio/Envoy přibližně o 60 % více zdrojů CPUnež Linkerd.

Závěr

Istio Envoy proxy spotřebovává o 50+ % více CPU než Linkerd při naší simulované zátěži. Ovládací panel Linkerd spotřebovává mnohem méně zdrojů než Istio, zejména pro základní komponenty.

Stále přemýšlíme, jak tyto náklady snížit. Pokud máte nápady, sdílejte je!

Zdroj: www.habr.com