🥇Benchmark i konsumit të CPU për Istio dhe Linkerd

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

Hyrje

Ne në Shopify ne filluam përdorimin e Istio si një rrjet shërbimesh. Në thelb, gjithçka është mirë, përveç një gjëje: është e shtrenjtë.

Në në benchmark-ët e publikuar për Istio thuhet:

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

Për rajonin e parë në rrjetin e shërbimeve (me 2 proksi nga secila anë e lidhjes), do të kemi 1200 bërthama vetëm për proksi, duke u bazuar në një milion kërkesa në sekondë. Sipas kalkulatorit të çmimeve të Google, rezulton rreth $40/muaj/bërthama për konfigurimin n1-standard-64, kështu që ky rajon do të na kushtojë më shumë se 50 mijë dollarë në muaj për 1 milion kërkesa në sekondë.

Ivan Sim (Ivan Sim) ilustroi qartë vonimet e rrjetit të shërbimeve vitin e kaluar dhe premtoi të njëjtën gjë për memorinë dhe procesorin, por nuk arriti:

Duket se values-istio-test.yaml do të rrisë ndjeshëm kërkesat për procesorin. Nëse e kam llogaritur siç duhet, janë rreth 24 bërthama procesori për panelin e kontrollit dhe 0.5 CPU për çdo proksi. Nuk kam aq shumë. Do t'i përsëris testet kur më ndahen më shumë burime.

Dëshiroja të sigurohesha sa të ngjashme janë treguesit e Istio me një rrjet shërbimesh me kod të hapur: Linkerd.

Instalimi i rrjetit të shërbimeve

I pari që instalova në klasër 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!

Kam përdorur SuperGloo, sepse ai e bën shumë më të lehtë ngarkimin fillestar të rrjetit të shërbimeve. Nuk më duhej të bëja shumë. Në prodhim, nuk përdorim SuperGloo, por për një detyrë të tillë ai është perfekt. Më duhej të aplikoj vetëm disa komandë për çdo rrjet shërbimesh. Përdorja dy klastra për izolim - një për Istio dhe një për Linkerd.

Eksperimenti u realizua në Google Kubernetes Engine. Kam përdorur Kubernetes 1.12.7-gke.7 dhe një grup nyjesh n1-standard-4 me shkallëzim automatik nyjesh (minimum 4, maksimum 16).

Pastaj instalova të dy rrjetet e shërbimeve nga linja e komandave.

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

Më pas 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, pastaj panelet e kontrollit u stabilizuan.

(Shënim. SuperGloo aktualisht mbështet vetëm Istio 1.0.x. E përsëris eksperimentin me Istio 1.1.3, por nuk vë re ndonjë ndryshim të ndjeshëm.)

Konfigurimi i injektimit automatik të Istio

Për të instaluar sidecar-in Envoy, përdorim injektorin e sidecar-it - MutatingAdmissionWebhook. Nuk do të flasim për të në këtë artikull. Thjesht do të them se ky është një kontrollues që monitoron qasjen e të gjitha pod-ve të rinj dhe shton dinamikisht sidecar dhe initContainer, i cili është përgjegjës për detyrat iptables.

Ne në Shopify shkruam kontrolluesin tonë të aksesit për injektimin e sidecar-eve, por në këtë benchmark mora kontrolluesin që vjen me Istio. Kontrolluesi për default injekton sidecar-e kur në hapësirën e emrave ka një etikët 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 të Linkerd

Për të konfiguruar injektimin e sidecar-eve të Linkerd, përdorim anota (i kam shtuar 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

Simuluesi i mungesës së qëndrueshmërisë të Istio

Ne kemi krijuar një simulator qëndrueshmërie për Istio për të eksperimentuar me trafikun unik për Shopify. Na duhej një mjet për të krijuar një topologji të rastësishme që do përfaqësonte një pjesë të caktuar të grafikut të shërbimit tonë me konfigurim dinamik për modelimin e ngarkesave të caktuara.

Infrastruktura e Shopify përballet me një ngarkesë të madhe gjatë shitjeve flash. Në të njëjtën kohë, Shopify u rekomandon shitësve që të organizojnë shpesh shitje të tilla. Klientët e mëdhenj ndonjëherë lajmërojnë për shitjet e planifikuara flash. Të tjerë i organizojnë ato papritur për ne në çdo orë të ditës e natës.

Ne doja që simulatori ynë i qëndrueshmërisë të modelonte proceset që përputhen me topologjitë dhe ngarkesat që kanë çuar në mbingarkesa të infrastrukturës së Shopify në të kaluarën. Qëllimi kryesor i përdorimit të service mesh është se na nevojitet besueshmëri dhe qëndrueshmëri në nivelin e rrjetit, dhe është e rëndësishme për ne që service mesh të përballojë efektivisht ngarkesat që më parë kanë penguar funksionimin e shërbimeve.

Në thelb, simulatori i qëndrueshmërisë bazohet në një nod të punës që vepron si nod i service mesh. Nodet e punës mund të konfigurohen në mënyrë statike gjatë nisjes ose në mënyrë dinamike përmes REST API. Ne përdorim konfigurimin dinamik të nodëve të punës për të krijuar procese si teste regresive.

Ja një shembull i një procesi të tillë:

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

Në fund të procesit të punës studiojmë regjistrat dhe metrikat dhe kontrollojmë nëse testi është kaluar. Kështu mësojmë rreth performancës së service mesh dhe bëjmë një test regresiv për të kontrolluar supozimet tona për qëndrueshmërinë.

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

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

Ne konfiguruam disa nodë të punës 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ërkesat, presin 100 ms dhe redirektojnë kërkesat në irs-server.
irs-server: 3 replika, të cilat kthejnë 200/OK brenda 100 ms.

Me këtë konfigurim, mund të masim një rrjedhë të qëndrueshme të trafikut midis 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ë ardhura dhe të dalura).

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

Rezultatet

Panele menaxhimi

Fillimisht, studiojmë konsumimin e CPU.

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, se Linkerd. Sigurisht, gjithçka është vendosur si parametra të paracaktuar, dhe shumë burime procesori këtu konsumohet nga istio-telemetry (mund të çaktivizohet duke e hequr disa funksionalitete). Edhe pa këtë komponent, përsëri kemi më shumë se 100 miliardë, që do të thotë 4 herë më shumë, se Linkerd.

Proxy-të sidecar

Më pas kontrolluam përdorimin e proxy-ve. Këtu duhet të ketë një varësi lineare nga numri i kërkesave, por për çdo sidecar ka disa kostosh që ndikojnë në kurbën.

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

Rezultatet duken logjike, sepse proxy i klientit merr dy herë më shumë trafik, se proxy i loadgen: për çdo kërkesë të dalë nga loadgen ka një kërkesë të ardhur dhe një të dalë nga klienti.

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

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

Por përgjithësisht proxy-t Istio/Envoy konsumojnë kështu rreth 50% më shumë burime procesori, se Linkerd.

E njëjta 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 konsumohet pothuajse 60% më shumë burime procesori, se Linkerd.

Përfundimi

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

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

Burimi: habr.com