CPU-fogyasztási benchmark az Istio és Linkerd számára

Bevezetés

1cloud Shopify az Istio telepítésével foglalkoztunk mint szolgáltatás hálózattal. Alapvetően minden rendben van, kivéve egy dolgot: ez drága.

A publikált benchmarkok az Istioról azt mondják:

Az Istio 1.1 proxy körülbelül 0,6 vCPU (virtuális processzor) igényel 1000 kérelem másodpercenként.

Az első régióban a szolgáltatás hálózatban (mindkét oldalon 2 proxy) körülbelül 1200 processzorra lesz szükségünk, mivel 1 millió kérést számolunk másodpercenként. A Google költségkalkulálója alapján ez körülbelül 40 USD/hónap/processzor a konfigurációra n1-standard-64, tehát csak ez a régió havi több mint 50 000 dollárunkba kerül 1 millió kérés másodpercenként.

Ivan Sim (Ivan Sim) világosan összehasonlította a szolgáltatás hálózat késlekedéseit tavaly, és azt ígérte, hogy ugyanezt teszi a memóriával és a processzorral, de nem sikerült:

Úgy tűnik, hogy a values-istio-test.yaml jelentősen megnöveli a processzori igényeket. Ha jól számoltam, körülbelül 24 processzorra van szükség a vezérlőpanelhez és 0,5 CPU-ra minden proxyhoz. Nincs ennyi. Ismétlem a teszteket, amikor több erőforrást osztanak ki.

Szerettem volna megbizonyosodni róla, hogy az Istio teljesítménye mennyire hasonlít egy másik nyílt forráskódú szolgáltatás hálózatra: Linkerd.

Szolgáltatás hálózat telepítése

Először telepítettem a klaszterbe 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!

A SuperGloo-t használtam, mert jelentősen megkönnyíti a szolgáltatás hálózat kezdeti betöltését. Szinte semmit sem kellett tennem. A gyakorlatban nem használjuk a SuperGloo-t, de ehhez a feladathoz tökéletesen megfelel. Körülbelül néhány parancsot kellett alkalmaznom minden szolgáltatás hálózathoz. Két klasztert használtam az elszigeteléshez — egyet az Istiohoz és egyet a Linkerd-hez.

A kísérletet a Google Kubernetes Engine-en végeztük. Kubernetes-t használtam 1.12.7-gke.7 és a csomóponttartó n1-standard-4 automatikus csomópontskálázással (minimum 4, maximum 16).

Ezután a parancssorból telepítettem mindkét szolgáltatás hálózatot.

Először a 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 |
+---------+--------------+---------+---------------------------+

Aztán 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      |
+---------+------------+---------+---------------------------+

A Crash-loop néhány percet vett igénybe, majd a vezérlőpanele stabilizálódott.

(Megjegyzés: A SuperGloo jelenleg csak az Istio 1.0.x-et támogatja. Ismételten megismételtem a kísérletet az Istio 1.1.3-mal, de nem vettem észre érdemi különbséget.)

Az Istio automatikus injektálásának beállítása

Ahhoz, hogy az Istio telepítse a sidecar Envoy-t, a sidecar-injektort használjuk — MutatingAdmissionWebhook. Erről a cikkben nem fogunk beszélni. Csak annyit mondok, hogy ez egy vezérlő, amely figyelemmel kíséri az összes új pod hozzáférését, és dinamikusan hozzáadja a sidecar-t és az initContainer-t, amely a feladatokért felelős iptables.

Mi a Shopify-nál írtunk saját vezérlőnket a sidecar-ok injektálására, de ebben a benchmarkban az Istio-val szállított vezérlőt választottam. Az alapértelmezett vezérlő sidecar-okat injektál, amikor a névtérben egy címkét talál 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

A Linkerd automatikus injektálásának beállítása

A Linkerd sidecar-jainak injektálásához annotációkat használunk (ezeket kézzel adtam hozzá a következőn keresztül 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

Az Istio megbízhatósági szimulátora

Készítettünk egy Istio hibatűrő szimulátort, hogy kísérletezhessünk a Shopify-ra jellemző forgalommal. Szükségünk volt egy eszközre, amely lehetővé teszi tetszőleges topológiák létrehozását, amelyek egy adott részét képezik szolgáltatásunk grafikonjának, dinamikus beállítással, hogy konkrét munkaterheléseket modellezhessünk.

A Shopify infrastruktúrája nagy terhelésnek van kitéve a villámkiárusítások során. Ekkor a Shopify javasolja a kereskedőket, hogy gyakrabban tartsanak ilyen kiárusításokat. Nagyobb ügyfelek néha előre értesítenek a tervezett villámkiárusításról. Mások pedig váratlanul, bármikor, napközben vagy éjszaka tartanak ilyet számunkra.

Azt szerettük volna, hogy hibatűrő szimulátorunk olyan munkafolyamatokat modellezzen, amelyek megfelelnek a Shopify infrastruktúráját a múltban túlterhelő topológiáknak és munkaterheléseknek. A service mesh használatának alapvető célja — megbízhatóságra és hibatűrésre van szükségünk a hálózat szintjén, és fontos számunkra, hogy a service mesh hatékonyan kezelje azokat a terheket, amelyek korábban megzavarták a szolgáltatások működését.

A hibatűrő szimulátor alapja egy munkánk csomópontja, amely a service mesh csomópontjaként működik. A munkacsomópont statikusan beállítható indításkor vagy dinamikusan a REST API-n keresztül. Dinamikus munkacsoport-beállítást használunk, hogy munkafolyamatokat hozzunk létre regressziós tesztekként.

Íme egy példa egy ilyen folyamatra:

• 10 szervert indítunk el mint bar szolgáltatás, amely 200/OK választ ad 100 ms alatt.
• 10 klienst indítunk — mindegyik másodpercenként 100 kérést küld a bar.
• Minden 10 másodpercben eltávolítunk egy szervert, figyeljük az ügyfélhibákat. 5xx A folyamat végén átnézzük a naplókat és metrikákat, valamint ellenőrizzük, hogy a teszt sikeres volt-e. Így megtudjuk, hogyan teljesít a service mesh-ünk, és végzünk egy regressziós tesztet, hogy ellenőrizzük hibatűrési feltételezéseinket.

(Megjegyzés. Gondolkodunk az Istio hibatűrő szimulátor forráskódjának nyilvános közzétételén, de még nem vagyunk készen rá.)

Istio hibatűrő szimulátor a service mesh benchmarkhoz

Több munkacsoportot állítunk be a szimulátorhoz:

irs-client-loadgen

• : 3 replikával, amelyek másodpercenként 100 kérést küldenek azirs-client : 3 replikával, amelyek fogadják a kéréseket, várnak 100 ms-ot, és átirányítják a kéréseket a.
• : 3 replikával, amelyek fogadják a kéréseket, várnak 100 ms-ot, és átirányítják a kéréseket airs-server : 3 replikával, amelyek visszatérítik a választ.
• : 3 replikával, amelyek visszatérítik a választ: 3 replikával, amelyek visszaadnak. 200/OK választ ad 100 ms alatt.

Egy ilyen konfigurációval stabil forgalmat mérhetünk 9 végpont között. A Sidecar-ok : 3 replikával, amelyek másodpercenként 100 kérést küldenek az és : 3 replikával, amelyek visszatérítik a választ 100 kérést kapnak másodpercenként, míg : 3 replikával, amelyek fogadják a kéréseket, várnak 100 ms-ot, és átirányítják a kéréseket a — 200 (bejövő és kimenő).

Az erőforrások felhasználását nyomon követjük a DataDog, mivel nincs Prometheus klaszterünk.

Eredmények

Vezérlőpanelek

Először a CPU fogyasztást vizsgáltuk.

A Linkerd vezérlőpult ~22 milliárd

Az Istio vezérlőpult: ~750 milliárd

Az Istio vezérlőpult körülbelül 35-ször több CPU erőforrást használ, mint a Linkerd. Természetesen minden alapértelmezett beállításon van, és az istio-telemetry sok CPU erőforrást fogyaszt (le lehet tiltani, ha lemondunk néhány funkcióról). Ha ezt az összetevőt eltávolítjuk, akkor is több mint 100 milliárd lesz, azaz 4-szer több, mint a Linkerd.

Sidecar proxy

Ezután ellenőriztük a proxy használatát. Itt lineáris összefüggésnek kell lennie a kérések számával, de minden sidecar esetében vannak bizonyos adminisztrációs költségek, amelyek befolyásolják a görbét.

Linkerd: ~100 milliárd az irs-client számára, ~50 milliárd az irs-client-loadgen számára

Az eredmények logikusan néznek ki, hiszen a client proxy kétszer annyi forgalmat kap, mint a loadgen proxy: minden egyes kimenő kérelem után a loadgen-ből a client egy bejövő és egy kimenő kérdést kap.

Istio/Envoy: ~155 milliárd az irs-client számára, ~75 milliárd az irs-client-loadgen számára

Hasonló eredményeket látunk az Istio sidecar-ok esetében is.

De összességében az Istio/Envoy proxy körülbelül 50%-kal több CPU erőforrást fogyaszt, mint a Linkerd.

Ugyanezt a sémát látjuk a szerver oldalon:

Linkerd: ~50 milliárd az irs-server számára

Istio/Envoy: ~80 milliárd az irs-server számára

A szerver oldali sidecar Istio/Envoy körülbelül 60%-kal több CPU erőforrást fogyaszt, mint a Linkerd.

Zárás

Az Istio Envoy proxy több mint 50%-kal több CPU-t fogyaszt, mint a Linkerd a modellezett munkaterhelésünkben. A Linkerd vezérlőpult sokkal kevesebb erőforrást fogyaszt, mint az Istio, különösen a fő összetevők esetében.

Még mindig gondolkodunk rajta, hogyan lehetne csökkenteni ezeket a költségeket. Ha van ötleted, oszd meg velünk!

Forrás: habr.com