Istio eta Linkerd-en CPU kontsumoaren erreferentzia

Sarrera

Hemen gaude Shopify Istio zerbitzu sare gisa zabaltzen hasi zen. Printzipioz, dena ondo dago, gauza bat izan ezik: garestia da.

В argitaratutako erreferentziak Istiorentzat dio:

Istio 1.1-ekin, proxyak 0,6 vCPU (nukleo birtualak) kontsumitzen ditu segundoko 1000 eskaera bakoitzeko.

Zerbitzu sareko lehen eskualderako (2 proxi konexioaren alde bakoitzean), 1200 nukleo izango ditugu proxyrako soilik, segundoko milioi bat eskaeraren abiaduran. Google-ren kostuen kalkulagailuaren arabera, gutxi gorabehera $ 40 hilean/nukleoan konfiguratzeko balio du n1-standard-64, hau da, eskualde honek bakarrik hilero 50 mila dolar baino gehiago kostatuko digu segundoko milioi bat eskaera egiteko.

Ivan Sim (Ivan Sim) bisualki alderatuta zerbitzu-sareak iaz atzeratu egin zuen eta gauza bera agindu zuen memoria eta prozesadorearentzat, baina ez zuen funtzionatu:

Antza denez, values-istio-test.yaml-k PUZaren eskaerak handituko ditu. Matematika ondo egin badut, gutxi gorabehera 24 CPU nukleo behar dituzu kontrol panelerako eta 0,5 CPU proxy bakoitzeko. Ez daukat horrenbeste. Baliabide gehiago esleitzen zaizkidanean errepikatuko ditut probak.

Neure kabuz ikusi nahi nuen Istioren errendimendua kode irekiko beste zerbitzu sare batekin zein antzekoa den: Linkerd.

Zerbitzu-sareen instalazioa

Lehenik eta behin, kluster batean instalatu nuen 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!

SuperGloo erabili dut, zerbitzu-sarearen abiarazpena askoz errazten duelako. Ez nuen gauza handirik egin behar. Ez dugu SuperGloo erabiltzen ekoizpenean, baina aproposa da horrelako zereginetarako. Literalki komando pare bat erabili behar izan ditut zerbitzu sare bakoitzeko. Bi kluster erabili ditut isolatzeko - Istio eta Linkerd-entzat bana.

Esperimentua Google Kubernetes Engine-n egin zen. Kubernetes erabili dut 1.12.7-gke.7 eta nodo multzo bat n1-standard-4 nodoen eskalatze automatikoarekin (gutxienez 4, gehienez 16).

Ondoren, bi zerbitzu sareak komando lerrotik instalatu nituen.

Lehenengo Lotura:

$ 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 |
+---------+--------------+---------+---------------------------+

Orduan 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-ak minutu batzuk behar izan zituen, eta gero kontrol panelak egonkortu ziren.

(Oharra: SuperGloo-k Istio 1.0.x bakarrik onartzen du oraingoz. Istio 1.1.3-rekin esperimentua errepikatu nuen, baina ez nuen desberdintasun nabarmenik nabaritu.)

Istio inplementazio automatikoa konfiguratzea

Istio sidecar Envoy instalatzeko, sidecar injektorea − erabiltzen dugu MutatingAdmissionWebhook. Artikulu honetan ez dugu horri buruz hitz egingo. Esan iezadazu hau pod berri guztien sarbidea kontrolatzen duen kontrolagailu bat dela eta dinamikoki sidecar bat eta initContainer gehitzen dituena, zereginez arduratzen dena. iptables.

Shopify-n gure sarbide-kontrolatzailea idatzi genuen sidecar-ak ezartzeko, baina erreferentzia honetarako Istio-rekin datorren kontrolagailua erabili nuen. Kontrolatzaileak sidecar-ak injektatzen ditu berez izen-eremuan lasterbide bat dagoenean 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

Linkerd inplementazio automatikoa konfiguratzea

Linkerd sidecar kapsulatzea konfiguratzeko, oharrak erabiltzen ditugu (eskuz gehitu ditut 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

Istio akatsen tolerantzia simulatzailea

Istio izeneko akatsen tolerantzia simulatzaile bat eraiki dugu Shopify-ren esklusiboki den trafikoarekin esperimentatzeko. Tresna bat behar genuen gure zerbitzu grafikoaren zati zehatz bat irudikatuko zuen topologia pertsonalizatu bat sortzeko, dinamikoki konfiguratuta lan-karga zehatzak modelatzeko.

Shopify-ren azpiegitura karga handia dago flash salmentetan. Aldi berean, Shopify salmenta horiek maizago egitea gomendatzen die saltzaileei. Bezero handiek batzuetan aurreikusitako flash salmenta bati buruz ohartarazten dute. Beste batzuek ustekabean egiten dizkigute eguneko edo gaueko edozein ordutan.

Gure erresilientzia-simulagailuak iraganean Shopify-ren azpiegitura gainezka egin duten topologiekin eta lan-kargarekin bat datozen lan-fluxuak modelatzea nahi genuen. Zerbitzu-sare bat erabiltzearen helburu nagusia sare mailan fidagarritasuna eta akats-tolerantzia behar ditugula da, eta guretzat garrantzitsua da zerbitzu-sareak aurrez zerbitzuak eten zituzten kargari eraginkortasunez aurre egitea.

Akatsen tolerantziaren simulagailuaren muinean langile-nodo bat dago, zerbitzu-sare-nodo gisa jokatzen duena. Langile-nodoa abiaraztean edo modu dinamikoan konfiguratu daiteke REST API baten bidez. Langile-nodoen konfigurazio dinamikoa erabiltzen dugu erregresio proben moduan lan-fluxuak sortzeko.

Hona hemen prozesu horren adibide bat:

• 10 zerbitzari gisa abiarazten ditugu bar erantzuna itzultzen duen zerbitzua 200/OK 100 ms ondoren.
• 10 bezero abiarazten ditugu - bakoitzak 100 eskaera bidaltzen dizkio segundoko bar.
• 10 segundoro zerbitzari bat kentzen dugu eta erroreak kontrolatzen ditugu 5xx bezeroaren gainean.

Lan-fluxuaren amaieran, erregistroak eta neurketak aztertu eta proba gainditu duen ala ez egiaztatzen dugu. Horrela, gure zerbitzu-sarearen errendimendua ezagutuko dugu eta erregresio-proba bat egiten dugu akatsen tolerantziari buruzko gure hipotesiak probatzeko.

(Oharra: Istio akatsen tolerantzia simulagailuaren iturri irekian ari gara pentsatzen, baina oraindik ez gaude horretarako prest).

Istio akatsen tolerantzia-simulagailua zerbitzu sarearen erreferentziarako

Simulagailuaren hainbat lan-nodo ezarri ditugu:

• irs-client-loadgen: segundoko 3 eskaera bidaltzen dituzten 100 erreplika irs-client.
• irs-client: eskaera jasotzen duten 3 erreplika, 100 ms itxaron eta eskaera helarazi irs-server.
• irs-server: itzultzen diren 3 erreplika 200/OK 100 ms ondoren.

Konfigurazio honekin, 9 punturen artean trafiko-fluxu egonkorra neurtu dezakegu. Sidecar-ak sartu irs-client-loadgen и irs-server segundoko 100 eskaera jaso, eta irs-client — 200 (sarrera eta irteera).

Baliabideen erabileraren jarraipena egiten dugu DataDogez baitugu Prometeo klusterrik.

Findings

Kontrol-panelak

Lehenik eta behin, CPU kontsumoa aztertu dugu.

Linkerd kontrol panela ~ 22 milicore

Istio kontrol panela: ~ 750 milicore

Istio kontrol panelak gutxi gorabehera erabiltzen du 35 aldiz CPU baliabide gehiagoLinkerd baino. Noski, dena lehenespenez instalatuta dago, eta istio-telemetriak prozesadorearen baliabide asko kontsumitzen ditu hemen (funtzio batzuk desgaituz desgaitu daiteke). Osagai hau kentzen badugu, oraindik 100 milikore baino gehiago lortzen ditugu, alegia 4 aldiz gehiagoLinkerd baino.

Sidecar proxy

Ondoren, proxy baten erabilera probatu dugu. Erlazio lineala egon behar da eskaera kopuruarekin, baina sidecar bakoitzeko kurba eragiten duen gainkosturen bat dago.

Linkerd: ~ 100 milicore irs-client-erako, ~ 50 milicore irs-client-loadgen

Emaitzek logikoak dirudite, bezeroaren proxyak loadgen proxyak baino bi aldiz trafiko gehiago jasotzen duelako: loadgen-en irteerako eskaera bakoitzeko, bezeroak sarrerako bat eta irteerako bat ditu.

Istio/Envoy: ~ 155 milicore irs-client-erako, ~ 75 milicore irs-client-loadgen

Istio sidecar-en antzeko emaitzak ikusten ditugu.

Baina, oro har, Istio/Envoy proxyek kontsumitzen dute gutxi gorabehera, CPU baliabideak %50 gehiagoLinkerd baino.

Zerbitzariaren aldean eskema bera ikusten dugu:

Linkerd: ~ 50 milicore irs-zerbitzarirako

Istio/Envoy: ~80 milicore irs-zerbitzarirako

Zerbitzariaren aldean, Istio/Envoy sidecar-ak kontsumitzen du gutxi gorabehera, CPU baliabideak %60 gehiagoLinkerd baino.

Ondorioa

Istio Envoy proxyak Linkerdek baino % 50 + CPU gehiago kontsumitzen du gure simulatutako lan-kargan. Linkerd kontrol panelak Istio baino askoz baliabide gutxiago kontsumitzen ditu, batez ere oinarrizko osagaietarako.

Oraindik kostu horiek nola murriztu pentsatzen ari gara. Ideiak badituzu, partekatu mesedez!

Iturria: www.habr.com