Paraqitje
Ne jemi në filloi vendosjen e Istio si një rrjetë shërbimi. Në parim, gjithçka është në rregull, përveç një gjëje: është e shtrenjtë.
В për Istio thotë:
Me Istio 1.1, proxy konsumon afërsisht 0,6 vCPU (bërthamë virtuale) për 1000 kërkesa në sekondë.
Për rajonin e parë në rrjetën e shërbimit (2 përfaqësues në secilën anë të lidhjes), do të kemi 1200 bërthama vetëm për përfaqësuesin, me një normë prej një milion kërkesash për sekondë. Sipas kalkulatorit të kostos së Google, rezulton të jetë afërsisht 40 dollarë/muaj/bërthamë për konfigurim n1-standard-64dmth vetëm ky rajon do të na kushtojë më shumë se 50 mijë dollarë në muaj për 1 milion kërkesa në sekondë.
Ivan Sim () Vonesa e rrjetës së shërbimit vitin e kaluar dhe premtoi të njëjtën gjë për memorien dhe procesorin, por nuk funksionoi:
Me sa duket, values-istio-test.yaml do të rrisë seriozisht kërkesat e CPU. Nëse e kam bërë saktë matematikën time, ju nevojiten afërsisht 24 bërthama CPU për panelin e kontrollit dhe 0,5 CPU për çdo përfaqësues. Unë nuk kam aq shumë. Unë do t'i përsëris testet kur të më ndahen më shumë burime.
Doja të shihja vetë se sa e ngjashme është performanca e Istio me një rrjetë tjetër shërbimi me burim të hapur: .
Instalimi i rrjetës së shërbimit
Para së gjithash, e instalova në një grup :
$ 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!Kam përdorur SuperGloo sepse e bën shumë më të lehtë nisjen e rrjetës së shërbimit. Nuk më duhej të bëja shumë. Ne nuk përdorim SuperGloo në prodhim, por është ideal për një detyrë të tillë. Më duhej të përdorja fjalë për fjalë disa komanda për çdo rrjetë shërbimi. Kam përdorur dy grupe për izolim - një për Istio dhe Linkerd.
Eksperimenti u krye në Google Kubernetes Engine. Kam përdorur Kubernetes 1.12.7-gke.7 dhe një grup nyjesh n1-standard-4 me shkallëzim automatik të nyjeve (minimumi 4, maksimumi 16).
Pastaj instalova të dy rrjetat e shërbimit nga linja e komandës.
Lidhja e parë:
$ 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 |
+---------+--------------+---------+---------------------------+Pastaj 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 zgjati disa minuta dhe më pas panelet e kontrollit u stabilizuan.
(Shënim: SuperGloo mbështet vetëm Istio 1.0.x për momentin. Unë përsërita eksperimentin me Istio 1.1.3, por nuk vura re ndonjë ndryshim të dukshëm.)
Konfigurimi i vendosjes automatike Istio
Për ta bërë Istio të instalojë karrocën anësore Envoy, ne përdorim injektorin e kartës anësore − MutatingAdmissionWebhook. Ne nuk do të flasim për këtë në këtë artikull. Më lejoni të them vetëm se ky është një kontrollues që monitoron aksesin e të gjitha podeve të reja dhe shton në mënyrë dinamike një karrige anësore dhe initContainer, i cili është përgjegjës për detyrat iptables.
Ne në Shopify kemi shkruar kontrolluesin tonë të aksesit për të zbatuar karriget anësore, por për këtë pikë referimi kam përdorur kontrolluesin që vjen me Istio. Kontrolluesi injekton karriget anësore si parazgjedhje kur ka një shkurtore në hapësirën e emrave 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 labeledKonfigurimi i vendosjes automatike të Linkerd
Për të konfiguruar lidhjen e kartës anësore të Linkerd, ne përdorim shënime (i shtova ato manualisht nëpërmjet 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: ActiveSimulatori i tolerancës së gabimeve Istio
Ne ndërtuam një imitues të tolerancës së gabimeve të quajtur Istio për të eksperimentuar me trafikun unik për Shopify. Na duhej një mjet për të krijuar një topologji të personalizuar që do të përfaqësonte një pjesë specifike të grafikut tonë të shërbimit, të konfiguruar në mënyrë dinamike për të modeluar ngarkesa specifike të punës.
Infrastruktura e Shopify është nën ngarkesë të madhe gjatë shitjeve flash. Në të njëjtën kohë, Shopify . Klientët e mëdhenj ndonjëherë paralajmërojnë për një shitje të planifikuar flash. Të tjerët i kryejnë ato në mënyrë të papritur për ne në çdo kohë të ditës ose të natës.
Ne donim që imituesi ynë i elasticitetit të modelonte flukset e punës që përputhen me topologjitë dhe ngarkesat e punës që kanë tejkaluar infrastrukturën e Shopify në të kaluarën. Qëllimi kryesor i përdorimit të rrjetës së shërbimit është që ne kemi nevojë për besueshmëri dhe tolerancë ndaj gabimeve në nivel rrjeti, dhe është e rëndësishme për ne që rrjeta e shërbimit të përballojë në mënyrë efektive ngarkesat që ndërpresin shërbimet më parë.
Në zemër të simulatorit të tolerancës së gabimeve është një nyje punëtore, e cila vepron si një nyje rrjetë shërbimi. Nyja e punës mund të konfigurohet në mënyrë statike në fillim ose në mënyrë dinamike nëpërmjet një API REST. Ne përdorim konfigurimin dinamik të nyjeve të punëtorëve për të krijuar flukse pune në formën e testeve të regresionit.
Këtu është një shembull i një procesi të tillë:
- Ne lançojmë 10 serverë si
barshërbimi që kthen një përgjigje200/OKpas 100 ms. - Ne lëshojmë 10 klientë - secili dërgon 100 kërkesa në sekondë tek
bar. - Çdo 10 sekonda heqim 1 gabime të serverit dhe monitorimit
5xxmbi klientin.
Në fund të rrjedhës së punës, ne shqyrtojmë regjistrat dhe metrikat dhe kontrollojmë nëse testi ka kaluar. Në këtë mënyrë ne mësojmë për performancën e rrjetës sonë të shërbimit dhe kryejmë një test regresioni për të testuar supozimet tona në lidhje me tolerancën e gabimeve.
(Shënim: Ne po shqyrtojmë dhënien e burimeve të hapura të simulatorit të tolerancës së gabimeve Istio, por nuk jemi ende gati për ta bërë këtë.)
Simulator i tolerancës së gabimeve Istio për standardin e rrjetës së shërbimit
Ne po krijojmë disa nyje pune të simulatorit:
irs-client-loadgen: 3 kopje që dërgojnë 100 kërkesa në sekondë përirs-client.irs-client: 3 kopje që marrin kërkesën, prisni 100ms dhe dërgoni kërkesën tekirs-server.irs-server: 3 kopje që kthehen200/OKpas 100 ms.
Me këtë konfigurim, ne mund të matim një fluks të qëndrueshëm trafiku midis 9 pikave fundore. Makinat anësore në irs-client-loadgen и irs-server merrni 100 kërkesa në sekondë, dhe irs-client - 200 (hyrje dhe dalje).
Ne ndjekim përdorimin e burimeve përmes sepse ne nuk kemi një grup Prometeu.
Gjetjet
Panelet e kontrollit
Së pari, ne ekzaminuam konsumin e CPU-së.
Paneli i kontrollit Linkerd ~22 millicore
Paneli i kontrollit Istio: ~750 millicore
Paneli i kontrollit Istio përdor afërsisht 35 herë më shumë burime CPUse Linkerd. Sigurisht, gjithçka është instaluar si parazgjedhje, dhe istio-telemetria konsumon shumë burime të procesorit këtu (mund të çaktivizohet duke çaktivizuar disa funksione). Nëse e heqim këtë komponent, prapë marrim më shumë se 100 milikorë, domethënë 4 herë më shumëse Linkerd.
Përfaqësues i makinës anësore
Më pas testuam përdorimin e një përfaqësuesi. Duhet të ketë një lidhje lineare me numrin e kërkesave, por për çdo karrige anësore ka një kosto të lartë që ndikon në kurbën.
Linkerd: ~ 100 millicore për irs-client, ~ 50 millicores për irs-client-loadgen
Rezultatet duken logjike, sepse përfaqësuesi i klientit merr dy herë më shumë trafik sesa përfaqësuesi i ngarkuesit: për çdo kërkesë dalëse nga loadgen, klienti ka një hyrje dhe një dalëse.
Istio/I dërguari: ~ 155 millicore për irs-client, ~ 75 millicore për irs-client-loadgen
Ne shohim rezultate të ngjashme për karriget anësore Istio.
Por në përgjithësi, proxies Istio/Envoy konsumojnë afërsisht 50% më shumë burime CPUsesa Linkerd.
Ne shohim të njëjtën skemë në anën e serverit:
Linkerd: ~ 50 millicore për serverin irs
Istio/I dërguari: ~ 80 millicore për serverin irs
Nga ana e serverit, karriera anësore Istio/Envoy konsumon afërsisht 60% më shumë burime CPUsesa Linkerd.
Përfundim
Proxy Istio Envoy konsumon 50+% më shumë CPU se Linkerd në ngarkesën tonë të simuluar të punës. Paneli i kontrollit Linkerd konsumon shumë më pak burime se Istio, veçanërisht për komponentët bazë.
Ne ende po mendojmë se si t'i reduktojmë këto kosto. Nëse keni ide, ju lutemi shpërndajeni!
Burimi: www.habr.com