Suorittimen kulutuksen vertailuarvo Istiolle ja Linkerdille

Esittely

Olemme sisällä Shopify aloitti Istion käyttöönoton palveluverkkona. Periaatteessa kaikki on hyvin, paitsi yksi asia: se on kallis.

В julkaistut vertailuarvot Istiolle se sanoo:

Istio 1.1:ssä välityspalvelin kuluttaa noin 0,6 vCPU:ta (virtuaalista ydintä) 1000 XNUMX pyyntöä sekunnissa.

Palveluverkon ensimmäisellä alueella (2 välityspalvelinta yhteyden molemmilla puolilla) meillä on 1200 ydintä vain välityspalvelimelle, miljoona pyyntöä sekunnissa. Googlen kustannuslaskurin mukaan se on noin 40 dollaria/kk/ydin konfiguroinnissa n1-standard-64, eli tämä alue yksin maksaa meille yli 50 tuhatta dollaria kuukaudessa miljoonasta pyynnöstä sekunnissa.

Ivan Sim (Ivan Sim) visuaalisesti vertailla Service mesh viivästyi viime vuonna ja lupasi samaa muistille ja prosessorille, mutta se ei toiminut:

Ilmeisesti Values-istio-test.yaml lisää CPU-pyyntöjä huomattavasti. Jos olen laskenut oikein, tarvitset noin 24 CPU-ydintä ohjauspaneeliin ja 0,5 CPU:ta kullekin välityspalvelimelle. Minulla ei ole niin paljon. Toistan testit, kun minulle on osoitettu lisää resursseja.

Halusin itse nähdä, kuinka samanlainen Istion suorituskyky on toisen avoimen lähdekoodin palveluverkon kanssa: Linkerd.

Huoltoverkkojen asennus

Ensinnäkin asensin sen klusteriin 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!

Käytin SuperGlooa, koska se tekee palveluverkon käynnistämisestä paljon helpompaa. Minun ei tarvinnut tehdä paljon. Emme käytä SuperGlooa tuotannossa, mutta se on ihanteellinen sellaiseen tehtävään. Jouduin käyttämään kirjaimellisesti pari komentoa jokaiselle palveluverkolle. Käytin kahta klusteria eristämiseen - yhtä Istiolle ja Linkerdille.

Kokeilu suoritettiin Google Kubernetes Enginellä. Käytin Kubernetesia 1.12.7-gke.7 ja joukko solmuja n1-standard-4 automaattisella solmun skaalauksella (vähintään 4, maksimi 16).

Sitten asensin molemmat palveluverkot komentoriviltä.

Ensimmäinen 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 |
+---------+--------------+---------+---------------------------+

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

Törmäyssilmukka kesti muutaman minuutin, ja sitten ohjauspaneelit vakiintuivat.

(Huomaa: SuperGloo tukee toistaiseksi vain Istio 1.0.x:ää. Toistin kokeen Istio 1.1.3:lla, mutta en huomannut mitään huomattavaa eroa.)

Istion automaattisen käyttöönoton määrittäminen

Käytämme sivuvaunun ruiskutussuutinta − saadaksemme Istion asentamaan sivuvaunun Envoyn MutatingAdmissionWebhook. Emme puhu siitä tässä artikkelissa. Sanon vain, että tämä on ohjain, joka valvoo kaikkien uusien podien pääsyä ja lisää dynaamisesti sivuvaunun ja initContainerin, joka vastaa tehtävistä iptables.

Me Shopifyssa kirjoitimme oman kulunohjaimen sivuvaunujen toteuttamiseen, mutta tähän vertailukohtaan käytin Istion mukana tulevaa ohjainta. Ohjain lisää sivuvaunut oletusarvoisesti, kun nimiavaruudessa on pikakuvake 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

Otetaan käyttöön automaattinen Linkerd-käyttöönotto

Linkerd-sivuvaunun upotuksen määrittämiseksi käytämme merkintöjä (lisäsin ne manuaalisesti: 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

Istion vikasieto-simulaattori

Rakensimme Istio-nimisen vikasieto-simulaattorin kokeillaksemme Shopifylle ainutlaatuista liikennettä. Tarvitsimme työkalun mukautetun topologian luomiseen, joka edustaisi tiettyä osaa palvelukaaviostamme ja joka on määritetty dynaamisesti mallintamaan tiettyjä työkuormia.

Shopifyn infrastruktuuri on kovassa kuormituksessa flash-myynnin aikana. Samaan aikaan Shopify suosittelee myyjiä pitämään tällaisia ​​myyntiä useammin. Suuret asiakkaat varoittavat joskus suunnitellusta flash-myynnistä. Toiset suorittavat niitä yllättäen meille milloin tahansa päivästä tai yöstä.

Halusimme joustavuussimulaattorimme mallintavan työnkulkuja, jotka vastaavat Shopifyn infrastruktuuria aiemmin ylikuormitettuja topologioita ja työkuormia. Palveluverkon käytön päätarkoitus on, että tarvitsemme luotettavuutta ja vikasietoisuutta verkkotasolla, ja meille on tärkeää, että palveluverkko kestää tehokkaasti kuormituksia, jotka ovat aiemmin häirinneet palveluita.

Vikasietoisuussimulaattorin ytimessä on työntekijäsolmu, joka toimii palveluverkkosolmuna. Työntekijäsolmu voidaan määrittää staattisesti käynnistyksen yhteydessä tai dynaamisesti REST API:n kautta. Käytämme työntekijäsolmujen dynaamista konfiguraatiota työnkulkujen luomiseen regressiotestien muodossa.

Tässä on esimerkki tällaisesta prosessista:

• Avaamme 10 palvelinta nimellä bar palvelua, joka palauttaa vastauksen 200/OK 100 ms jälkeen.
• Käynnistämme 10 asiakasta - jokainen lähettää 100 pyyntöä sekunnissa bar.
• 10 sekunnin välein poistamme yhden palvelimen ja valvomme virheitä 5xx asiakkaan päällä.

Työnkulun lopussa tarkastelemme lokit ja mittarit ja tarkistamme, läpäistiinkö testi. Tällä tavalla opimme huoltoverkkomme toimivuudesta ja suoritamme regressiotestin testataksemme oletuksiamme vikasietoisuudesta.

(Huom: Harkitsemme Istio-vikasietoisuussimulaattorin avointa hankintaa, mutta emme ole vielä valmiita siihen.)

Istio-vikasieto-simulaattori huoltoverkon vertailukohtaan

Asensimme simulaattorin useita toimivia solmuja:

• irs-client-loadgen: 3 kopiota, jotka lähettävät 100 pyyntöä sekunnissa irs-client.
• irs-client: 3 kopiota, jotka vastaanottavat pyynnön, odottavat 100 ms ja välittävät pyynnön osoitteeseen irs-server.
• irs-server: 3 kopiota, jotka palaavat 200/OK 100 ms jälkeen.

Tällä kokoonpanolla voimme mitata vakaan liikennevirran 9 päätepisteen välillä. Sivuvaunut sisään irs-client-loadgen и irs-server vastaanottaa 100 pyyntöä sekunnissa ja irs-client — 200 (saapuva ja lähtevä).

Seuraamme resurssien käyttöä läpi DataDogkoska meillä ei ole Prometheus-klusteria.

Tulokset

Ohjauspaneelit

Ensin tarkastelimme suorittimen kulutusta.

Linkerd ohjauspaneeli ~22 milliydintä

Istion ohjauspaneeli: ~750 milliydintä

Istion ohjauspaneeli käyttää n 35 kertaa enemmän prosessoriresurssejakuin Linkerd. Tietenkin kaikki on asennettu oletuksena, ja istio-telemetria kuluttaa täällä paljon prosessoriresursseja (se voidaan poistaa käytöstä poistamalla jotkut toiminnot käytöstä). Jos poistamme tämän komponentin, saamme silti yli 100 milliydintä 4 kertaa enemmänkuin Linkerd.

Sivuvaunun välityspalvelin

Testasimme sitten välityspalvelimen käyttöä. Pyyntöjen lukumäärän kanssa pitäisi olla lineaarinen suhde, mutta jokaisella sivuvaunulla on jonkin verran ylärajaa, joka vaikuttaa käyrään.

Linkerd: ~100 milliydintä irs-clientille, ~50 milliydintä irs-client-loadgenille

Tulokset näyttävät loogisilta, koska asiakasvälityspalvelin vastaanottaa kaksi kertaa niin paljon liikennettä kuin loadgen-välityspalvelin: jokaista lähtevää pyyntöä kohden, asiakkaalla on yksi saapuva ja yksi lähtevä.

Istio/Envoy: ~155 milliydintä irs-clientille, ~75 milliydintä irs-client-loadgenille

Näemme samanlaisia ​​tuloksia Istio-sivuvaunuilla.

Mutta yleensä Istio/Envoy-välityspalvelimet kuluttavat noin 50 % enemmän prosessoriresurssejakuin Linkerd.

Näemme saman kaavan palvelinpuolella:

Linkerd: ~50 milliydintä irs-palvelimelle

Istio/Envoy: ~80 milliydintä irs-palvelimelle

Palvelinpuolella kuluttaa sivuvaunu Istio/Envoy noin 60 % enemmän prosessoriresurssejakuin Linkerd.

Johtopäätös

Istio Envoy -välityspalvelin kuluttaa 50+% enemmän suoritinta kuin Linkerd simuloidulla työkuormallamme. Linkerd-ohjauspaneeli kuluttaa paljon vähemmän resursseja kuin Istio, etenkin ydinkomponenttien osalta.

Pohdimme edelleen, kuinka näitä kustannuksia alennetaan. Jos sinulla on ideoita, jaa!

Lähde: will.com