Bevezetés
Benne vagyunk megkezdte az Istio szolgáltatási hálóként történő telepítését. Elvileg minden rendben van, egy dolgot kivéve: ez drága.
В Istio esetében ez áll:
Az Istio 1.1 esetében a proxy körülbelül 0,6 vCPU-t (virtuális magot) fogyaszt 1000 kérésenként másodpercenként.
A szolgáltatásháló első régiójában (2 proxy a kapcsolat mindkét oldalán) 1200 magunk lesz csak a proxy számára, másodpercenként egymillió kérés sebességével. A Google költségkalkulátora szerint ez körülbelül 40 USD/hó/mag a konfigurációért n1-standard-64, vagyis egyedül ez a régió több mint 50 ezer dollárunkba fog kerülni havonta másodpercenként 1 millió kérésért.
Ivan Sim () A szervizháló késések tavaly, és ugyanezt ígérték a memóriára és a processzorra is, de nem sikerült:
Úgy tűnik, a value-istio-test.yaml komolyan megnöveli a CPU kérések számát. Ha jól számoltam, körülbelül 24 CPU magra van szüksége a vezérlőpulthoz és 0,5 CPU-ra minden proxyhoz. nekem nincs annyi. Megismétlem a teszteket, ha több erőforrást osztanak ki rám.
Magam szerettem volna meggyőződni arról, hogy az Istio teljesítménye mennyire hasonlít egy másik nyílt forráskódú szolgáltatáshálóhoz: .
Szervizháló telepítés
Először is fürtbe telepítettem :
$ 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 azért használtam, mert sokkal könnyebbé teszi a szervizháló rendszerindítását. Nem kellett sokat tennem. A SuperGloo-t nem használjuk a gyártásban, de ideális egy ilyen feladatra. Szó szerint néhány parancsot kellett használnom minden egyes szolgáltatási hálóhoz. Két klasztert használtam az elkülönítéshez – egyet-egyet az Istio és a Linkerd számára.
A kísérletet a Google Kubernetes Engine-en végezték. Kuberneteset használtam 1.12.7-gke.7 és csomópontok készlete n1-standard-4 automatikus csomópontskálázással (minimum 4, maximum 16).
Ezután mindkét szervizhálót telepítettem a parancssorból.
Első 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 |
+---------+------------+---------+---------------------------+Az ütközés néhány percig tartott, majd a vezérlőpanelek stabilizálódtak.
(Megjegyzés: A SuperGloo egyelőre csak az Istio 1.0.x-et támogatja. Megismételtem a kísérletet az Istio 1.1.3-mal, de nem vettem észre észrevehető különbséget.)
Az Istio automatikus telepítésének beállítása
Ahhoz, hogy az Istio beszerelje az oldalkocsi Envoy-t, az oldalkocsi befecskendezőjét használjuk MutatingAdmissionWebhook. Ebben a cikkben nem beszélünk róla. Csak annyit mondok, hogy ez egy vezérlő, amely figyeli az összes új pod hozzáférését, és dinamikusan hozzáad egy oldalkocsit és egy initContainer-t, amely a feladatokért felelős. iptables.
Mi a Shopifynál saját beléptetővezérlőnket írtunk az oldalkocsik megvalósításához, de ehhez a benchmarkhoz az Istio-hoz mellékelt vezérlőt használtam. A vezérlő alapértelmezés szerint beadja az oldalkocsikat, ha van egy parancsikon a névtérben 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 labeledAutomatikus Linkerd-telepítés beállítása
A Linkerd oldalkocsi-beágyazás beállításához megjegyzéseket használunk (manuálisan adtam hozzá őket 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: ActiveIstio hibatűrés szimulátor
Építettünk egy Istio nevű hibatűrési szimulátort, hogy kísérletezzünk a Shopify egyedi forgalmával. Szükségünk volt egy eszközre egy egyéni topológia létrehozásához, amely szolgáltatási gráfunk egy meghatározott részét képviseli, dinamikusan konfigurálva, hogy modellezzen bizonyos munkaterheléseket.
A Shopify infrastruktúrája nagy terhelés alatt áll a flash-eladások során. Ugyanakkor a Shopify . A nagy ügyfelek időnként figyelmeztetnek egy tervezett gyorsakcióra. Mások váratlanul levezénylik őket számunkra a nap vagy az éjszaka bármely szakában.
Azt akartuk, hogy a rugalmassági szimulátorunk olyan munkafolyamatokat modellezzen, amelyek megfelelnek a Shopify infrastruktúráját korábban túlterhelt topológiáknak és munkaterheléseknek. A service mesh használatának fő célja, hogy hálózati szinten megbízhatóságra és hibatűrésre van szükségünk, és fontos számunkra, hogy a service mesh hatékonyan tudjon megbirkózni azokkal a terhelésekkel, amelyek korábban megzavarták a szolgáltatásokat.
A hibatűrés-szimulátor középpontjában egy dolgozó csomópont áll, amely szervizháló csomópontként működik. A dolgozó csomópont statikusan konfigurálható indításkor vagy dinamikusan a REST API-n keresztül. A dolgozó csomópontok dinamikus konfigurációját használjuk munkafolyamatok létrehozásához regressziós tesztek formájában.
Íme egy példa egy ilyen folyamatra:
- 10 szervert indítunk mint
barválaszt küldő szolgáltatás200/OK100 ms után. - 10 ügyfelet indítunk el – mindegyik másodpercenként 100 kérést küld a címre
bar. - 10 másodpercenként eltávolítunk 1 szervert és figyeljük a hibákat
5xxaz ügyfélen.
A munkafolyamat végén megvizsgáljuk a naplókat és a mérőszámokat, és ellenőrizzük, hogy a teszt sikeres volt-e. Így megismerjük szervizhálónk teljesítményét, és regressziós tesztet futtatunk, hogy teszteljük a hibatűréssel kapcsolatos feltételezéseinket.
(Megjegyzés: Az Istio hibatűrés-szimulátor nyílt forráskódú beszerzésén gondolkodunk, de még nem állunk készen erre.)
Istio hibatűrés szimulátor szervizháló benchmarkhoz
A szimulátor több működő csomópontját állítjuk be:
irs-client-loadgen: 3 replika, amely másodpercenként 100 kérést küldirs-client.irs-client: 3 replika, amely megkapja a kérést, várjon 100 ms-t, és továbbítsa a kéréstirs-server.irs-server: 3 replika, amely visszatér200/OK100 ms után.
Ezzel a konfigurációval stabil forgalmi áramlást mérhetünk 9 végpont között. Oldalkocsik be irs-client-loadgen и irs-server másodpercenként 100 kérést kap, és irs-client — 200 (bejövő és kimenő).
Nyomon követjük az erőforrás-felhasználást mert nincs Prometheus klaszterünk.
Álláspontja
Vezérlőpanelek
Először a CPU fogyasztását vizsgáltuk.
Linkerd vezérlőpanel ~22 millicore
Istio vezérlőpanel: ~750 millicore
Az Istio vezérlőpanel kb 35-ször több CPU erőforrásmint Linkerd. Természetesen alapból minden telepítve van, és az istio-telemetria itt rengeteg processzor erőforrást fogyaszt (egyes funkciók letiltásával letiltható). Ha ezt a komponenst eltávolítjuk, akkor is több mint 100 millicoret kapunk, vagyis 4-szer többmint Linkerd.
Oldalkocsi proxy
Ezután teszteltük a proxy használatát. Lineáris kapcsolatnak kell lennie a kérelmek számával, de minden oldalkocsi esetében van némi rezsi, amely befolyásolja a görbét.
Linkerd: ~100 millicore irs-client, ~50 millicore irs-client-loadgen
Az eredmények logikusnak tűnnek, mivel a kliens proxy kétszer akkora forgalmat kap, mint a loadgen proxy: minden loadgen kimenő kérésére a kliensnek van egy bejövő és egy kimenő.
Istio/Envoy: ~155 millicore irs-client, ~75 millicore irs-client-loadgen
Hasonló eredményeket látunk az Istio oldalkocsiknál is.
De általában az Istio/Envoy proxy-k fogyasztanak körülbelül 50%-kal több CPU erőforrásmint Linkerd.
Ugyanezt a sémát látjuk a szerver oldalon:
Linkerd: ~50 millicore irs-szerverhez
Istio/Envoy: ~80 millicore az irs-szerverhez
A szerver oldalon az oldalkocsi Istio/Envoy fogyaszt körülbelül 60%-kal több CPU erőforrásmint Linkerd.
Következtetés
Az Istio Envoy proxy 50+%-kal több CPU-t fogyaszt, mint a Linkerd a szimulált munkaterhelésünkön. A Linkerd vezérlőpanel sokkal kevesebb erőforrást fogyaszt, mint az Istio, különösen az alapvető összetevők esetében.
Továbbra is gondolkodunk azon, hogyan lehetne ezeket a költségeket csökkenteni. Ha van ötletetek, kérlek osszátok meg!
Forrás: will.com