Potrošnja CPU-a za Istio i Linkerd

Uvod

Unutra smo Shopify počeo je implementirati Istio kao servisnu mrežu. U principu, sve je u redu, osim jedne stvari: skupo je.

В objavljena mjerila za Istio kaže:

Sa Istio 1.1, proxy troši približno 0,6 vCPU-a (virtuelnih jezgara) na 1000 zahtjeva u sekundi.

Za prvi region u servisnoj mreži (2 proksija sa svake strane veze), imaćemo 1200 jezgara samo za proxy, po stopi od milion zahteva u sekundi. Prema Googleovom kalkulatoru troškova, ispada otprilike 40 USD mjesečno/jezgro za konfiguraciju n1-standard-64, odnosno samo ovaj region koštaće nas više od 50 hiljada dolara mesečno za milion zahteva u sekundi.

Ivan Sim (Ivan Sim) vizuelno porediti service mesh je kasnio prošle godine i obećao isto za memoriju i procesor, ali nije išlo:

Očigledno, values-istio-test.yaml će ozbiljno povećati CPU zahtjeve. Ako sam dobro uradio svoju matematiku, potrebno vam je otprilike 24 CPU jezgra za kontrolnu tablu i 0,5 CPU za svaki proxy. Nemam toliko. Ponoviću testove kada mi bude dodijeljeno više sredstava.

Želio sam da se lično uvjerim koliko je Istio učinak sličan drugom mrežnom servisu otvorenog koda: Linkerd.

Servisna instalacija mreže

Prije svega, instalirao sam ga u klaster 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!

Koristio sam SuperGloo jer olakšava pokretanje servisne mreže. Nisam morao puno da radim. SuperGloo ne koristimo u proizvodnji, ali je idealan za takav zadatak. Morao sam da koristim bukvalno nekoliko komandi za svaki servisni mesh. Koristio sam dva klastera za izolaciju - po jedan za Istio i Linkerd.

Eksperiment je sproveden na Google Kubernetes Engine-u. Koristio sam Kubernetes 1.12.7-gke.7 i skup čvorova n1-standard-4 sa automatskim skaliranjem čvorova (minimalno 4, maksimalno 16).

Zatim sam instalirao obje servisne mreže iz komandne linije.

Prvo povezano:

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

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

Petlja sudara je trajala nekoliko minuta, a zatim su se kontrolne ploče stabilizirale.

(Napomena: SuperGloo za sada podržava samo Istio 1.0.x. Ponovio sam eksperiment sa Istio 1.1.3, ali nisam primijetio nikakvu primjetnu razliku.)

Postavljanje Istio automatske implementacije

Da bi Istio instalirao Envoy za bočnu prikolicu, koristimo injektor bočne prikolice − MutatingAdmissionWebhook. Nećemo o tome govoriti u ovom članku. Samo da kažem da je ovo kontroler koji prati pristup svim novim podovima i dinamički dodaje sidecar i initContainer, koji je odgovoran za zadatke iptables.

Mi u Shopifyju smo napisali svoj vlastiti kontroler pristupa za implementaciju bočnih prikolica, ali za ovaj benchmark koristio sam kontroler koji dolazi s Istiom. Kontroler podrazumevano ubacuje prikolice kada postoji prečica u imenskom prostoru 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

Postavljanje automatske implementacije Linkerda

Da bismo postavili Linkerd sidecar embedding, koristimo napomene (dodao sam ih ručno putem 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 simulator tolerancije grešaka

Napravili smo simulator tolerancije grešaka pod nazivom Istio kako bismo eksperimentirali sa prometom jedinstvenim za Shopify. Trebao nam je alat za kreiranje prilagođene topologije koja bi predstavljala određeni dio našeg grafa usluge, dinamički konfiguriran za modeliranje specifičnih radnih opterećenja.

Shopify-jeva infrastruktura je pod velikim opterećenjem tokom flash prodaje. Istovremeno, Shopify preporučuje prodavcima da češće održavaju takve prodaje. Veliki kupci ponekad upozoravaju na planiranu rasprodaju. Drugi ih provode neočekivano za nas u bilo koje doba dana ili noći.

Željeli smo da naš simulator otpornosti modelira tokove rada koji odgovaraju topologijama i radnim opterećenjima koja su u prošlosti preplavila Shopify infrastrukturu. Osnovna svrha korištenja servisne mreže je da nam je potrebna pouzdanost i tolerancija grešaka na nivou mreže, a važno nam je da se servisna mreža efikasno nosi sa opterećenjima koja su prethodno poremetila usluge.

U srcu simulatora tolerancije grešaka je radni čvor, koji djeluje kao servisni mrežni čvor. Radni čvor se može konfigurirati statički pri pokretanju ili dinamički putem REST API-ja. Koristimo dinamičku konfiguraciju radnih čvorova za kreiranje radnih tokova u obliku regresijskih testova.

Evo primjera takvog procesa:

• Pokrećemo 10 servera kao bar servis koji vraća odgovor 200/OK nakon 100 ms.
• Pokrećemo 10 klijenata - svaki šalje 100 zahtjeva u sekundi bar.
• Svakih 10 sekundi uklanjamo 1 server i pratimo greške 5xx na klijenta.

Na kraju toka rada ispitujemo evidencije i metrike i provjeravamo da li je test prošao. Na ovaj način učimo o performansama naše servisne mreže i izvodimo regresijski test kako bismo testirali naše pretpostavke o toleranciji grešaka.

(Napomena: Razmišljamo o otvorenom izvoru Istio simulatora tolerancije grešaka, ali još nismo spremni za to.)

Istio simulator tolerancije grešaka za benchmark servisne mreže

Postavljamo nekoliko radnih čvorova simulatora:

• irs-client-loadgen: 3 replike koje šalju 100 zahtjeva u sekundi po irs-client.
• irs-client: 3 replike koje primaju zahtjev, čekaju 100ms i prosljeđuju zahtjev na irs-server.
• irs-server: 3 replike koje se vraćaju 200/OK nakon 100 ms.

Sa ovom konfiguracijom možemo mjeriti stabilan tok prometa između 9 krajnjih tačaka. Bočne prikolice irs-client-loadgen и irs-server primati 100 zahtjeva u sekundi, i irs-client — 200 (dolazni i odlazni).

Pratimo korištenje resursa kroz DataDogjer nemamo Prometejev klaster.

Rezulʹtaty

Upravljačke ploče

Prvo smo ispitali potrošnju procesora.

Linkerd kontrolni panel ~22 milicore

Istio kontrolni panel: ~750 milicore

Upravljačka ploča Istio koristi približno 35 puta više CPU resursanego Linkerd. Naravno, sve je instalirano po defaultu, a istio-telemetrija ovdje troši dosta procesorskih resursa (može se onemogućiti onemogućavanjem nekih funkcija). Ako uklonimo ovu komponentu, i dalje ćemo dobiti više od 100 miligrama, tj 4 puta višenego Linkerd.

Sidecar proxy

Zatim smo testirali upotrebu proxyja. Trebao bi postojati linearni odnos sa brojem zahtjeva, ali za svaku prikolicu postoje neki dodatni troškovi koji utiču na krivulju.

Linkerd: ~100 milicore za IRS-client, ~50 milicore za IRS-client-loadgen

Rezultati izgledaju logično, jer klijentski proxy prima dvostruko više prometa od loadgen proxyja: za svaki odlazni zahtjev od loadgena, klijent ima jedan dolazni i jedan odlazni.

Istio/Envoy: ~155 milicore za IRS-client, ~75 milicore za IRS-client-loadgen

Vidimo slične rezultate za Istio bočne prikolice.

Ali općenito, Istio/Envoy proksiji troše približno 50% više CPU resursanego Linkerd.

Vidimo istu šemu na strani servera:

Linkerd: ~50 milicore za IRS-server

Istio/Envoy: ~80 milicore za IRS-server

Na strani servera, sidecar Istio/Envoy troši približno 60% više CPU resursanego Linkerd.

zaključak

Istio Envoy proxy troši 50+% više CPU-a nego Linkerd na našem simuliranom radnom opterećenju. Linkerd kontrolni panel troši mnogo manje resursa nego Istio, posebno za osnovne komponente.

Još uvijek razmišljamo o tome kako smanjiti ove troškove. Ako imate ideje, podijelite ih!

izvor: www.habr.com