įvedimas
Mes esame pradėjo diegti Istio kaip paslaugų tinklą. Iš esmės viskas gerai, išskyrus vieną dalyką: tai brangu.
В Istio sako:
Naudojant Istio 1.1, tarpinis serveris sunaudoja maždaug 0,6 vCPU (virtualaus branduolio) 1000 užklausų per sekundę.
Pirmajame paslaugų tinklelio regione (po 2 tarpinius serverius kiekvienoje ryšio pusėje) turėsime 1200 branduolių, skirtų tik tarpiniam serveriui, vieno milijono užklausų per sekundę greičiu. Remiantis „Google“ sąnaudų skaičiuokle, konfigūracija kainuoja apie 40 USD per mėnesį už branduolį n1-standard-64, tai yra, vien šis regionas mums kainuos daugiau nei 50 tūkstančių dolerių per mėnesį už 1 milijoną užklausų per sekundę.
Ivanas Simas () Paslaugų tinklelis vėlavo praėjusiais metais ir pažadėjo tą patį atminčiai ir procesoriui, tačiau tai nepasiteisino:
Matyt, value-istio-test.yaml rimtai padidins procesoriaus užklausas. Jei teisingai apskaičiavau, jums reikia maždaug 24 procesoriaus branduolių valdymo pultui ir 0,5 procesoriaus kiekvienam tarpiniam serveriui. Neturiu tiek daug. Bandymus pakartosiu, kai man bus skirta daugiau resursų.
Norėjau pats įsitikinti, kuo Istio našumas panašus į kitą atvirojo kodo paslaugų tinklą: .
Serviso tinklelio montavimas
Visų pirma, aš įdiegiau jį į klasterį :
$ 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!Naudojau SuperGloo, nes tai labai palengvina paslaugų tinklo paleidimą. Man nereikėjo daug daryti. SuperGloo gamyboje nenaudojame, bet puikiai tinka tokiai užduočiai. Kiekvienam paslaugų tinklui turėjau naudoti kelias komandas. Išskyrimui naudojau dvi grupes – po vieną Istio ir Linkerd.
Eksperimentas buvo atliktas naudojant Google Kubernetes Engine. Naudojau Kubernetes 1.12.7-gke.7 ir mazgų telkinys n1-standard-4 su automatiniu mazgų mastelio keitimu (mažiausiai 4, daugiausiai 16).
Tada aš įdiegiau abu paslaugų tinklelius iš komandinės eilutės.
Pirmą kartą susieta:
$ 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 |
+---------+--------------+---------+---------------------------+Tada 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 |
+---------+------------+---------+---------------------------+Avarijos kilpa užtruko kelias minutes, o tada valdymo pultai stabilizavosi.
(Pastaba: „SuperGloo“ kol kas palaiko tik „Istio 1.0.x“. Pakartojau eksperimentą su Istio 1.1.3, bet nepastebėjau jokio pastebimo skirtumo.)
„Istio“ automatinio diegimo nustatymas
Kad Istio sumontuotų šoninės priekabos Envoy, naudojame šoninės priekabos purkštuką − MutatingAdmissionWebhook. Šiame straipsnyje apie tai nekalbėsime. Leiskite tik pasakyti, kad tai yra valdiklis, kuris stebi prieigą prie visų naujų blokų ir dinamiškai prideda šoninę priekabą ir initContainer, kuris yra atsakingas už užduotis. iptables.
Mes, Shopify, sukūrėme savo prieigos valdiklį, kad įdiegtume šonines priekabas, tačiau šiam etalonui naudojau valdiklį, pateiktą su Istio. Valdiklis pagal numatytuosius nustatymus įveda šonines priekabas, kai vardų erdvėje yra nuoroda 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 labeledAutomatinio Linkerd diegimo nustatymas
Norėdami nustatyti „Linkerd“ šoninės priekabos įterpimą, naudojame komentarus (aš juos pridėjau rankiniu būdu per 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 gedimų tolerancijos simuliatorius
Sukūrėme atsparumo gedimams simuliatorių, pavadintą „Istio“, kad galėtume eksperimentuoti su unikaliu „Shopify“ srautu. Mums reikėjo įrankio, kad sukurtume pasirinktinę topologiją, kuri atspindėtų konkrečią mūsų paslaugų grafiko dalį, dinamiškai sukonfigūruotą, kad modeliuotų konkrečius darbo krūvius.
„Flash“ pardavimo metu „Shopify“ infrastruktūra patiria didelę apkrovą. Tuo pačiu metu Shopify . Stambūs klientai kartais perspėja apie planuojamą „flash“ išpardavimą. Kiti juos mums netikėtai atlieka bet kuriuo dienos ar nakties metu.
Norėjome, kad mūsų atsparumo simuliatorius modeliuotų darbo eigas, kurios atitiktų topologijas ir darbo krūvius, kurie praeityje užvaldė Shopify infrastruktūrą. Pagrindinis paslaugų tinklelio naudojimo tikslas yra tai, kad mums reikia patikimumo ir gedimų tolerancijos tinklo lygiu, o mums svarbu, kad paslaugų tinklelis efektyviai susidorotų su apkrovomis, kurios anksčiau trikdė paslaugas.
Gedimų tolerancijos simuliatoriaus esmė yra darbuotojo mazgas, kuris veikia kaip aptarnavimo tinklo mazgas. Darbuotojo mazgas gali būti konfigūruojamas statiškai paleidžiant arba dinamiškai naudojant REST API. Mes naudojame dinaminę darbuotojų mazgų konfigūraciją, kad sukurtume darbo eigas regresijos testų forma.
Štai tokio proceso pavyzdys:
- Paleidžiame 10 serverių kaip
barpaslauga, kuri pateikia atsakymą200/OKpo 100 ms. - Paleidžiame 10 klientų – kiekvienas išsiunčia 100 užklausų per sekundę
bar. - Kas 10 sekundžių pašaliname 1 serverį ir stebime klaidas
5xxant kliento.
Darbo eigos pabaigoje išnagrinėjame žurnalus ir metrikas bei patikriname, ar testas išlaikytas. Taip sužinome apie savo aptarnavimo tinklo veikimą ir atliekame regresijos testą, kad patikrintume savo prielaidas apie atsparumą gedimams.
(Pastaba: galvojame apie atvirą Istio gedimų tolerancijos simuliatoriaus šaltinį, bet dar nesame pasiruošę tai padaryti.)
Istio gedimų tolerancijos simuliatorius, skirtas aptarnavimo tinklo etalonui
Mes nustatėme keletą darbo treniruoklio mazgų:
irs-client-loadgen: 3 kopijos, išsiunčiančios 100 užklausų per sekundęirs-client.irs-client: 3 kopijos, kurios gauna užklausą, palaukite 100 ms ir persiunčia užklausą įirs-server.irs-server: 3 kopijos, kurios grįžta200/OKpo 100 ms.
Naudodami šią konfigūraciją galime išmatuoti stabilų srautą tarp 9 galinių taškų. Šoninės priekabos irs-client-loadgen и irs-server gauti 100 užklausų per sekundę ir irs-client — 200 (įeinantys ir išeinantys).
Mes stebime išteklių naudojimą nes mes neturime Prometėjo klasterio.
rezultatai
Valdymo skydai
Pirmiausia ištyrėme procesoriaus suvartojimą.
Linkerd valdymo pultas ~22 milicore
Istio valdymo pultas: ~750 milicore
Istio valdymo pultas sunaudoja apytiksliai 35 kartus daugiau procesoriaus ištekliųnei Linkerdas. Žinoma, viskas yra įdiegta pagal nutylėjimą, o istio-telemetrija čia sunaudoja daug procesoriaus resursų (išjungti galima išjungus kai kurias funkcijas). Jei pašalinsime šį komponentą, vis tiek gausime daugiau nei 100 milikorių, tai yra 4 karto daugiaunei Linkerdas.
Priekabos tarpinis serveris
Tada išbandėme tarpinio serverio naudojimą. Turėtų būti tiesinis ryšys su užklausų skaičiumi, tačiau kiekvienai priekabai yra tam tikros papildomos išlaidos, kurios turi įtakos kreivei.
Linkerd: ~100 milicore irs-client, ~50 milicore irs-client-loadgen
Rezultatai atrodo logiški, nes kliento tarpinis serveris gauna dvigubai daugiau srauto nei „loadgen“ tarpinis serveris: kiekvienai iš „loadgen“ siunčiamai užklausai klientas turi vieną įeinantį ir vieną išeinantį.
Istio/Envoy: ~155 milicores irs-client, ~75 milicores irs-client-loadgen
Panašius rezultatus matome ir Istio šoninėms priekaboms.
Bet apskritai Istio/Envoy įgaliotiniai vartoja maždaug 50 % daugiau procesoriaus resursųnei Linkerdas.
Tą pačią schemą matome serverio pusėje:
Linkerd: ~50 milicore irs-serveriui
Istio/Envoy: ~80 milicore irs-serveriui
Serverio pusėje sunaudoja šoninė priekaba Istio/Envoy maždaug 60 % daugiau procesoriaus resursųnei Linkerdas.
išvada
„Istio Envoy“ tarpinis serveris sunaudoja 50+% daugiau procesoriaus nei „Linkerd“ mūsų imituojamoje darbo apkrovoje. „Linkerd“ valdymo pultas sunaudoja daug mažiau išteklių nei „Istio“, ypač pagrindiniams komponentams.
Vis dar galvojame, kaip šias išlaidas sumažinti. Jei turite idėjų, pasidalinkite!
Šaltinis: www.habr.com