🥇CPU verbruik maatstaf vir Istio en Linkerd

Inleiding

Ons is in Shopify het Istio as 'n diensnetwerk begin ontplooi. In beginsel pas alles, behalwe een ding: dit is duur.

В gepubliseerde maatstawwe vir Istio sê dit:

Met Istio 1.1 verbruik die proxy ongeveer 0,6 vCPU's (virtuele kerns) per 1000 versoeke per sekonde.

Vir die eerste streek in die diensnetwerk (2 gevolmagtigdes aan elke kant van die verbinding), sal ons 1200 slegs-instaanbediener-kerne hê, gebaseer op een miljoen versoeke per sekonde. Google se kosterekenaar is ongeveer $40/maand/kern vir konfigurasie n1-standard-64, dit wil sê, hierdie streek alleen sal ons meer as 50 duisend dollar per maand kos vir 1 miljoen versoeke per sekonde.

Ivan Sim (Ivan Sim) duidelik vergelyk diensnetwerkvertragings verlede jaar en het dieselfde belowe vir geheue en verwerker, maar het misluk:

Blykbaar sal values-istio-test.yaml versoeke aan die verwerker ernstig verhoog. As ek reg getel het, benodig ek ongeveer 24 verwerkerkerne vir die beheerpaneel en 0,5 SVE vir elke instaanbediener. Ek het nie so baie nie. Ek sal die toetse herhaal wanneer meer hulpbronne aan my toegeken word.

Ek wou self sien hoe soortgelyk Istio se werkverrigting is aan 'n ander oopbron-diensnetwerk: Linkerd.

Diens gaas installasie

Eerstens het ek in die groep geïnstalleer 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!

Ek het SuperGloo gebruik omdat dit die selflaai van die diensnetwerk baie makliker maak. Ek moes nie veel doen nie. Ons gebruik nie SuperGloo in produksie nie, maar dit is perfek vir hierdie taak. Ek moes letterlik 'n paar opdragte op elke diensmaas toepas. Ek het twee isolasie-klusters gebruik - een elk vir Istio en Linkerd.

Die eksperiment is op die Google Kubernetes Engine uitgevoer. Ek het Kubernetes gebruik 1.12.7-gke.7 en noduspoel n1-standard-4 met outomatiese nodus-skaal (minimum 4, maksimum 16).

Toe het ek albei diensnetwerke vanaf die opdragreël geïnstalleer.

Linkerd eerste:

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

Dan 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 het 'n paar minute geneem, en toe het die beheerpanele gestabiliseer.

(Let wel: SuperGloo ondersteun tot dusver net Istio 1.0.x. Ek het die eksperiment met Istio 1.1.3 herhaal, maar het geen merkbare verskil opgemerk nie.)

Konfigureer Istio Outomatiese Ontplooiing

Om vir Istio syspan Envoy te installeer, gebruik ons die syspan-inspuiter − MutatingAdmissionWebhook. Ons sal nie in hierdie artikel daaroor praat nie. Ek kan net sê dat dit 'n kontroleerder is wat die toegang van alle nuwe peule monitor en dinamies 'n syspan en 'n initContainer byvoeg wat verantwoordelik is vir take iptables.

Ons by Shopify het ons eie toegangsbeheerder geskryf om syspan te implementeer, maar in hierdie maatstaf het ek die beheerder geneem wat by Istio kom. Die beheerder spuit syspan by verstek wanneer daar 'n etiket in die naamruimte is 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

Konfigureer Linkerd Outomatiese Ontplooiing

Om Linkerd-syspan-inspuiting op te stel, gebruik ons aantekeninge (ek het dit handmatig bygevoeg via 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 Failover Simulator

Ons het die Istio failover-simulator gemaak om te eksperimenteer met verkeer wat uniek is aan Shopify. Ons het 'n instrument nodig gehad om 'n pasgemaakte topologie te skep wat 'n spesifieke deel van ons diensgrafiek sou verteenwoordig, dinamies gekonfigureer om spesifieke werkladings te modelleer.

Shopify se infrastruktuur is onder swaar las tydens flitsverkope. Terselfdertyd, Shopify moedig verkopers aan om sulke verkope meer gereeld te hou. Groot kliënte word soms gewaarsku oor 'n beplande blitsverkoping. Ander spandeer dit onverwags vir ons op enige tyd van die dag of nag.

Ons wou hê dat ons failover-simulator werkvloeie moet modelleer wat ooreenstem met die topologieë en werkladings wat die Shopify-infrastruktuur in die verlede oorweldig het. Die hoofdoel van die gebruik van 'n diensnetwerk is dat ons betroubaarheid en fouttoleransie op netwerkvlak nodig het, en dit is vir ons belangrik dat die diensnetwerk effektief kan hanteer met vragte wat voorheen dienste ontwrig het.

Die kern van die failover-simulator is 'n werkersnodus wat as 'n diensnetwerknodus dien. Die werkernodus kan staties gekonfigureer word by opstart of dinamies via die REST API. Ons gebruik dinamiese werkernodusinstelling om werkvloeie in die vorm van regressietoetse te skep.

Hier is 'n voorbeeld van so 'n proses:

Ons begin 10 bedieners as bar diens wat 'n antwoord gee 200/OK na 100 ms.
Ons begin 10 kliënte - elkeen stuur 100 versoeke per sekonde na bar.
Elke 10 sekondes verwyder ons 1 bediener, monitor foute 5xx op die kliënt.

Aan die einde van die werkstroom ondersoek ons die logs en statistieke en kyk of die toets geslaag het. Dit is hoe ons leer oor die werkverrigting van ons diensnetwerk en 'n regressietoets uitvoer om ons fouttoleransie-aannames te toets.

(Let wel: Ons oorweeg oopbron vir die Istio Failover Simulator, maar is nog nie gereed om dit te doen nie.)

Istio fouttoleransie-simulator vir diensmaasmaatstaf

Ons stel verskeie werker nodusse van die simulator op:

irs-client-loadgen: 3 replikas wat 100 versoeke per sekonde stuur na irs-client.
irs-client: 3 replikas wat 'n versoek ontvang wag 100ms en herlei die versoek na irs-server.
irs-server: 3 replikas wat terugkeer 200/OK na 100 ms.

Met hierdie konfigurasie kan ons 'n stabiele verkeersvloei tussen 9 eindpunte meet. Syspan in irs-client-loadgen и irs-server ontvang 100 versoeke per sekonde, en irs-client — 200 (inkomende en uitgaande).

Ons volg hulpbrongebruik deur DataDogwant ons het nie 'n Prometheus-kluster nie.

Bevindinge

Beheerpanele

Ons het eers na SVE-verbruik gekyk.

Linkerd beheerpaneel ~22 millidrama

Istio Beheerpaneel: ~750 mNy

Die Istio-beheerpaneel gebruik ongeveer 35 keer meer SVE-hulpbronneas Linkerd. Natuurlik is alles by verstek gestel, en istio-telemetrie verbruik hier baie SVE-hulpbronne (dit kan gedeaktiveer word deur sommige funksies af te wys). As jy hierdie komponent verwyder, kry jy steeds meer as 100 milli-kern, dit wil sê 4 keer meeras Linkerd.

sidecar proxy

Ons het toe die gebruik van 'n instaanbediener nagegaan. Daar behoort 'n lineêre verband te wees met die aantal versoeke, maar vir elke syspan is daar 'n bietjie oorhoofse koste wat die kurwe beïnvloed.

Linkerd: ~100 millicores vir irs-kliënt, ~50 millicores vir irs-client-loadgen

Die resultate lyk logies, want die kliënt-instaanbediener ontvang twee keer soveel verkeer as die loadgen-instaanbediener: vir elke uitgaande versoek van loadgen het die kliënt een inkomende en een uitgaande versoek.

Istio/Envoy: ~155 millicores vir irs-kliënt, ~75 millicores vir irs-client-loadgen

Ons sien soortgelyke resultate vir die Istio-syspan.

Maar oor die algemeen verbruik Istio/Gesant-gevolmagtigdes ongeveer 50% meer SVE-hulpbronneas Linkerd.

Ons sien dieselfde skema aan die bedienerkant:

Linkerd: ~50 millicores vir IRS-bediener

Istio/Envoy: ~80 millicores vir irs-bediener

Bedienerkantsyspan Istio/Gesant verbruik ongeveer 60% meer SVE-hulpbronneas Linkerd.

Gevolgtrekking

Die Istio Envoy-instaanbediener verbruik 50+% meer SVE as Linkerd op ons gesimuleerde werklading. Die Linkerd-kontrolepaneel verbruik baie minder hulpbronne as Istio, veral vir die hoofkomponente.

Ons dink nog oor hoe om hierdie koste te verminder. As jy idees het, deel asseblief!

Bron: will.com

SVE-verbruik maatstaf vir Istio en Linkerd