Benchmark spotřeby CPU pro Istio a Linkerd

Úvod

ITGLOBAL.COM Shopify zabýváme se nasazením Istio jako service mesh. V zásadě je všechno v pořádku, kromě jedné věci: je to drahé.

V publikovaných benchmarků pro Istio se uvádí:

S Istio 1.1 proxy spotřebovává přibližně 0,6 vCPU (virtuálního jádra) na 1000 požadavků za sekundu.

Pro první region v service mesh (po 2 proxy na každé straně spojení) budeme mít 1200 jader pouze pro proxy, na základě jednoho milionu požadavků za sekundu. Podle kalkulačky nákladů od Google to vychází přibližně 40 $/měsíc/jádro pro konfiguraci n1-standard-64, což znamená, že 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) viditelně porovnal latence service mesh v minulém roce a slíbil totéž pro paměť a procesor, ale nedopadlo to:

Zdá se, že values-istio-test.yaml výrazně zvyšuje požadavky na procesor. Pokud jsem vše správně spočítal, potřebuji přibližně 24 procesorových jader pro ovládací panel a 0,5 CPU pro každý proxy. Tolik nemám. Znovu provedu testy, když mi přidělí více zdrojů.

Chtěl jsem se sám přesvědčit, jak jsou ukazatele Istio podobné jinému open-source service mesh: Linkerd.

Instalace service mesh

Nejdříve jsem nainstaloval v clusteru SuperGloo:

$ supergloo init
instalace supergloo verze 0.3.12
použití uri grafu https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources vytvořen
serviceaccount/supergloo vytvořen
serviceaccount/discovery vytvořen
serviceaccount/mesh-discovery vytvořen
clusterrole.rbac.authorization.k8s.io/discovery vytvořen
clusterrole.rbac.authorization.k8s.io/mesh-discovery vytvořen
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding vytvořen
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding vytvořen
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding vytvořen
deployment.extensions/supergloo vytvořen
deployment.extensions/discovery vytvořen
deployment.extensions/mesh-discovery vytvořen
instalace úspěšná!

Použil jsem SuperGloo, protože výrazně zjednodušuje počáteční nasazení service mesh. Téměř jsem nemusel nic dělat. V produkci SuperGloo nepoužíváme, ale pro takový úkol je ideální. Musel jsem použít doslova pár příkazů na každou service mesh. Použil jsem dva clustry pro izolaci — jeden pro Istio a jeden pro Linkerd.

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

Poté jsem nainstaloval obě service mesh z příkazové řádky.

Nejdříve 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 |
+---------+--------------+---------+---------------------------+

Poté 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 několik minut, a pak se panely ovládání stabilizovaly.

(Poznámka. SuperGloo zatím podporuje pouze Istio 1.0.x. Experimentoval jsem s Istio 1.1.3, ale žádné podstatné rozdíly jsem nezaznamenal.)

Nastavení automatického zavádění Istio

Aby Istio nainstalovalo sidecar Envoy, používáme sidecar-injektor — MutatingAdmissionWebhook. O tom nebudeme hovořit v tomto článku. Řeknu jen, že je to řadič, který sleduje přístup všech nových podů a dynamicky přidává sidecar a initContainer, který se stará o úkoly iptables.

Ve společnosti Shopify jsme napsali vlastní řadič oprávnění pro zavádění sidecarů, ale v této analýze jsem použil řadič dodávaný s Istio. Výchozí řadič zavádí sidecary, když je v prostoru názvů štítek 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 zavádění Linkerd

Abychom nastavili zavádění sidecarů 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

Simulátor odolnosti Istio

Vytvořili jsme simulátor odolnosti Istio, abychom experimentovali s unikátním provozem pro Shopify. Potřebovali jsme nástroj, který by vytvořil libovolnou topologii představující určitou část grafu našich služeb s dynamickým nastavením pro modelování konkrétních pracovních zátěží.

Infrastruktura Shopify čelí vysoké zátěži během flash výprodejů. Přitom Shopify doporučuje prodávajícím častěji organizovat takové výprodeje. Velcí klienti někdy varují před plánovaným flash výprodejem. Jiní je pořádají nečekaně kdykoli během dne a noci.

Chtěli jsme, aby náš simulátor odolnosti modeloval pracovní postupy, které odpovídají topologiím a pracovním zátěžím vedoucím k přetížení infrastruktury Shopify v minulosti. Hlavním cílem používání service mesh je zajistit spolehlivost a odolnost na úrovni sítě, a je pro nás důležité, aby si service mesh efektivně poradila se zátěžemi, které dříve narušovaly provoz služeb.

Základem simulátoru odolnosti je pracovní uzel, který funguje jako uzel service mesh. Pracovní uzel lze nastavit staticky při spuštění nebo dynamicky prostřednictvím REST API. Používáme dynamické nastavení pracovních uzlů 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žbu, která vrací odpověď 200/OK během 100 ms.
• Spouštíme 10 klientů – každý posílá 100 požadavků za sekundu na bar.
• Každých 10 sekund odstraníme 1 server a sledujeme chyby 5xx na klientovi.

Na konci pracovního postupu zkoumáme protokoly a metriky a kontrolujeme, zda test proběhl úspěšně. Takto se dozvíme o výkonu naší service mesh a provedeme regresní test, abychom ověřili naše předpoklady o odolnosti.

(Poznámka: Zvažujeme otevření zdrojového kódu simulátoru odolnosti Istio, ale zatím na to nejsme připraveni.)

Simulátor odolnosti Istio pro benchmark service mesh

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

• irs-client-loadgen: 3 repliky, které posílají 100 požadavků za sekundu do irs-client.
• irs-client: 3 repliky, které přijímají požadavek, čekají 100 ms a přesměrovávají požadavek na irs-server.
• irs-server: 3 repliky, které vracejí 200/OK během 100 ms.

S touto konfigurací můžeme měřit stabilní tok provozu mezi 9 koncovými body. Sidecary v irs-client-loadgen a irs-server dostávají 100 požadavků za sekundu, a irs-client — 200 (příchozích a odchozích).

Sledujeme využití zdrojů přes DataDog, protože nemáme cluster Prometheus.

Výsledky

Ovládací panely

Nejprve jsme prozkoumali spotřebu CPU.

Ovládací panel Linkerd ~22 miliard

Ovládací panel Istio: ~750 miliard

Ovládací panel Istio používá přibližně 35krát více procesorových zdrojů, než Linkerd. Samozřejmě, vše je nastaveno na výchozí hodnoty a mnoho procesorových zdrojů zde spotřebovává istio-telemetry (může být vypnuto tím, že se vzdáte některých funkcí). I bez této komponenty stále získáváme více než 100 miliard, což je 4krát více, než Linkerd.

Proxy sidecar

Pak jsme zkontrolovali využití proxy. Měla by existovat lineární závislost na počtu požadavků, ale pro každého sidecar existují určité režijní náklady, které ovlivňují křivku.

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

Výsledky vypadají logicky, protože proxy klient získává dvakrát více provozu, než proxy loadgen: na každý odchozí požadavek od loadgenu připadá jeden příchozí a jeden odchozí.

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

Vidíme podobné výsledky pro sidecary Istio.

Celkově však proxy Istio/Envoy spotřebovávají přibližně o 50% více procesorových zdrojů, než Linkerd.

Stejný vzor vidíme na straně serveru:

Linkerd: ~50 miliard pro irs-server

Istio/Envoy: ~80 miliard pro irs-server

Na straně serveru sidecar Istio/Envoy spotřebovává přibližně o 60% více procesorových zdrojů, než Linkerd.

Závěr

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

Stále přemýšlíme, jak snížit tyto náklady. Pokud máte nějaké nápady, podělte se!

Zdroj: habr.com