Benchmark i përdorimit të CPU për Istio dhe Linkerd

Hyrje

Ne në Shopify kemi u angazhuam në vendosjen e Istio si service mesh. Në thelb, gjithçka është në rregull, përveç një gjëje: është e shtrenjtë.

Në benchmark-ëve të publikuara për Istio thuhet:

Me Istio 1.1, proxy konsumon rreth 0.6 vCPU (në bërthamë virtuale) për 1000 kërkesa për sekondë.

Për rajonin e parë në service mesh (me 2 proxy në çdo anë të lidhjes) do të kemi 1200 bërthama vetëm për proxy, duke llogaritur një milion kërkesa për sekondë. Sipas kalkulatorit të kostos nga Google, del rreth $40/muaj/bërthamë për konfigurimin n1-standard-64, pra ky rajon do të na kushtojë më shumë se 50 mijë dollarë në muaj për 1 milion kërkesa për sekondë.

Aiven Sim (Ivan Sim) ) tregoi qartë ndalimet e service mesh vitin e kaluar dhe premtoi të njëjtën gjë për kujtesën dhe procesorin, por nuk ia doli:

Duket se values-istio-test.yaml do të rrisë ndjeshëm kërkesat për procesor. Nëse e kam llogaritur saktë, nevojiten rreth 24 bërthama për procesorin për panelin e kontrollit dhe 0.5 CPU për çdo proxy. Nuk kam aq. Do të përsëris testet kur të më jepen më shumë burime.

Dëshiroja të sigurohesha vetë, sa të ngjashme janë treguesit e Istio me një service mesh me kod të hapur tjetër: Linkerd.

Instalimi i service mesh

E para që bëra ishte të instaloja në klastri 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!

Përdora SuperGloo sepse ndihmon shumë në ngarkimin fillestar të service mesh. M'u desh thuajse të mos bëja asgjë. Në prodhim nuk përdorim SuperGloo, por për një detyrë të tillë është perfekt. Më duhej të aplikoja vetëm disa komanda për çdo service mesh. Përdora dy klasterë për izolim — një për Istio dhe një për Linkerd.

Eksperimenti u zhvillua në Google Kubernetes Engine. Përdora Kubernetes 1.12.7-gke.7 dhe grupin e nodëve n1-standard-4 me shkallëzim automatik të nodëve (minimum 4, maksimum 16).

Pastaj instalova të dy service mesh nga linja e komandës.

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

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 pastaj panelat kontrolli u stabilizuan.

(Shënim. SuperGloo për momentin mbështet vetëm Istio 1.0.x. E përsërita eksperimentin me Istio 1.1.3, por nuk vura re ndonjë ndryshim të dukshëm.)

Konfigurimi i injektimit automatik për Istio

Për të instaluar sidecar Envoy me Istio, përdorim injektor-in e sidecar-it — MutatingAdmissionWebhook. Nuk do të flasim për të në këtë artikull. Thjesht do të them se është një kontrollues që monitoron aksesin e të gjithë pod’ëve të rinj dhe dinamikisht shton sidecar dhe initContainer, i cili merret me detyrat iptables.

Ne në Shopify shkruam kontrolluesin tonë për injektimin e sidecar-ve, por në këtë benchmark kam marrë kontrolluesin që vjen me Istio. Kontrolluesi për default-in injekton sidecar-et kur ka një etiketë 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 labeled

Konfigurimi i injektimit automatik për Linkerd

Për të konfiguruar injektimin e sidecar-ve të Linkerd, përdorim annotacione (i kam shtuar ato manualisht përmes 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

Simulator i qëndrueshmërisë Istio

Kemi krijuar një simulator qëndrestariteti Istio për të eksperimentuar me trafikun unik për Shopify. Na nevojitej një mjet për të krijuar topologji të rastësishme që do të përfaqësonte një pjesë të caktuar të grafit të shërbimit tonë me konfigurim dinamik për modelimin e ngarkesave specifike të punës.

Infrastruktura e Shopify përjeton një ngarkesë të madhe gjatë shitjeve flash. Në këtë rast, Shopify i rekomandon tregtarët të bëjnë shpesh shitje të tilla. Klientët e mëdhenj ndonjëherë paralajmërojnë për një shitje flash të planifikuar. Të tjerët i kryejnë ato papritur për ne, në çdo kohë të ditës e natës.

Ne dëshironim që simulatori ynë i qëndrestaritetit të modelonte proceset e punës që i përkasin topologjive dhe ngarkesave të punës që çuan në mbingarkesën e infrastruktrurës së Shopify në të kaluarën. Qëllimi kryesor i përdorimit të service mesh është se na nevojitet qëndrueshmëri dhe qëndrestaritet në nivelin e rrjetit dhe është e rëndësishme që service mesh të përballojë ngarkesat që më parë e kishin shqetësuar funksionin e shërbimeve.

Në thelbin e simulatorit të qëndrestaritetit është një nod pune që vepron si nod i service mesh. Nodi i punës mund të konfigurohet statikisht gjatë nisjes ose dinamikisht përmes REST API. Ne përdorim konfigurimin dinamik të noderve të punës për të krijuar proceset e punës si teste regresive.

Ja një shembull i një procesi:

• Nisim 10 servera si bar një shërbim që kthen një përgjigje 200/OK pas 100 ms.
• Nisim 10 klientë — secili dërgon 100 kërkesa në sekondë në bar.
• Çdo 10 sekonda heqim 1 server, monitorojmë gabimet 5xx në klient.

Në fund të procesit të punës, studioshim logët dhe metrikat dhe kontrollojmë nëse testi ka kaluar. Kështu, mësojmë për performancën e service mesh tonë dhe kryejmë një test regresiv për të verifikuar supozimet tona mbi qëndrestaritetin.

(Shënim. Po mendojmë të hapim kodin burimor të simulatorit të qëndrestaritetit Istio, por ende nuk jemi gati për këtë.)

Simulatori i qëndrestaritetit Istio për benchmark-un e service mesh

Ne konfigurojmë disa nodë pune të simulatorit:

• irs-client-loadgen: 3 replika, të cilat dërgojnë 100 kërkesa në sekondë në irs-client.
• irs-client: 3 replika, të cilat marrin kërkesën, presin 100 ms dhe ridrejtojnë kërkesën në irs-server.
• irs-server: 3 replika, të cilat kthejnë 200/OK pas 100 ms.

Me këtë konfigurim, ne mund të masim një fluks stabil trafiku mes 9 pikave të fundit. Sidecar-ët në irs-client-loadgen dhe irs-server marrin 100 kërkesa në sekondë, ndërsa irs-client – 200 (të hyrë dhe të dalë).

Ne ndjekim përdorimin e burimeve përmes DataDog, sepse nuk kemi një klaster Prometheus.

Rezultatet

Panele kontrolli

Fillimisht, ne shqyrtuam konsumimin e CPU-së.

Paneli i kontrollit Linkerd ~22 miliardë

Paneli i kontrollit Istio: ~750 miliardë

Paneli i kontrollit Istio përdor rreth 35 herë më shumë burime procesori, sesa Linkerd. Sigurisht, gjithçka është e vendosur sipas paracaktimit, dhe shumë burime procesori këtu konsumohen nga istio-telemetry (mund të çaktivizohet duke hequr dorë nga disa funksione). Nëse hiqet ky komponent, përsëri rezultati është mbi 100 miliardë, pra 4 herë më shumë, sesa Linkerd.

Proxy Sidecar

Më pas, ne kontrolluam përdorimin e proxy-it. Këtu duhet të ketë një varësi lineare nga numri i kërkesave, por për secilin sidecar ka disa shpenzime të përbashkëta që ndikojnë në kurbën.

Linkerd: ~100 miliardë për irs-client, ~50 miliardë për irs-client-loadgen

Rezultatet duken logjike, pasi proxy klient merr dyfish më shumë trafik sesa proxy loadgen: për çdo kërkesë në dalje nga loadgen, klienti ka një kërkesë në hyrje dhe një në dalje.

Istio/Envoy: ~155 miliardë për irs-client, ~75 miliardë për irs-client-loadgen

Ne shohim rezultate të ngjashme për sidecar-ët Istio.

Por në përgjithësi, proxy Istio/Envoy konsumon rreth 50% më shumë burime procesori, sesa Linkerd.

Të njëjtin skemë e shohim në anën e serverit:

Linkerd: ~50 miliardë për irs-server

Istio/Envoy: ~80 miliardë për irs-server

Në anën e serverit, sidecar Istio/Envoy konsumon rreth 60% më shumë burime procesori, sesa Linkerd.

Përfundim

Proxy Istio Envoy konsumon mbi 50% më shumë CPU, sesa Linkerd, në ngarkesën tonë të simuluar. Paneli i kontrollit Linkerd konsumon shumë më pak burime sesa Istio, veçanërisht në lidhje me komponentët kryesorë.

Ne ende po mendojmë se si t'i ulim këto shpenzime. Nëse keni ide, ndani!

Burimi: habr.com