Referentna vrijednost potrošnje procesora za Istio i Linkerd

Uvod

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

В objavljena mjerila za Istio kaže:

Uz Istio 1.1, proxy troši približno 0,6 vCPU-a (virtualnih jezgri) na 1000 zahtjeva u sekundi.

Za prvu regiju u uslužnoj mreži (2 proxyja sa svake strane veze), imat ćemo 1200 jezgri samo za proxy, brzinom od milijun zahtjeva u sekundi. Prema Googleovom kalkulatoru troškova, to iznosi otprilike 40 USD mjesečno po jezgri za konfiguraciju n1-standard-64, odnosno samo ova regija koštat će nas više od 50 tisuća dolara mjesečno za 1 milijun zahtjeva u sekundi.

Ivan Sim (Ivan Sim) vizualno usporediti service mesh kasni prošle godine i obećao je isto za memoriju i procesor, ali nije uspjelo:

Očigledno će values-istio-test.yaml ozbiljno povećati CPU zahtjeve. Ako sam dobro izračunao, trebate otprilike 24 CPU jezgre za upravljačku ploču i 0,5 CPU za svaki proxy. Nemam toliko. Ponovit ću testove kada mi bude dodijeljeno više sredstava.

Htio sam se osobno uvjeriti koliko je izvedba Istia slična drugoj mreži servisa otvorenog koda: Linkerd.

Ugradnja servisne mreže

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

Upotrijebio sam SuperGloo jer olakšava pokretanje servisne mreže. Nisam morao puno raditi. SuperGloo ne koristimo u proizvodnji, ali je idealan za takav zadatak. Morao sam upotrijebiti doslovno nekoliko naredbi za svaku servisnu mrežu. Koristio sam dva klastera za izolaciju - po jedan za Istio i Linkerd.

Eksperiment je proveden na Google Kubernetes Engineu. Koristio sam Kubernetes 1.12.7-gke.7 i skup čvorova n1-standard-4 s automatskim skaliranjem čvorova (minimalno 4, maksimalno 16).

Zatim sam instalirao obje servisne mreže iz naredbenog retka.

Prvi povezivač:

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

Crash-loop je trajao nekoliko minuta, a zatim su se upravljačke ploče stabilizirale.

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

Postavljanje Istio automatske implementacije

Kako bi Istio ugradio Envoy s prikolicom, koristimo injektor za prikolice − MutatingAdmissionWebhook. Nećemo o tome u ovom članku. Samo da kažem da je ovo kontroler koji nadzire pristup svih novih mahuna i dinamički dodaje sidecar i initContainer, koji je odgovoran za zadatke iptables.

Mi u Shopifyu napisali smo vlastiti kontroler pristupa za implementaciju bočnih prikolica, ali za ovo mjerilo koristio sam kontroler koji dolazi s Istiom. Kontroler prema zadanim postavkama ubacuje prikolice kada postoji prečac u prostoru imena 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

Za postavljanje Linkerd sidecar ugradnje koristimo bilješke (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 Fault Tolerance Simulator

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

Infrastruktura Shopifyja pod velikim je opterećenjem tijekom brze prodaje. U isto vrijeme Shopify preporuča prodavačima da ovakve rasprodaje održavaju češće. Veliki kupci ponekad upozoravaju na planiranu brzu prodaju. Drugi ih provode neočekivano za nas u bilo koje doba dana i noći.

Željeli smo da naš simulator otpornosti modelira tijekove rada koji odgovaraju topologijama i radnim opterećenjima koja su u prošlosti opteretila Shopifyjevu infrastrukturu. Glavna svrha korištenja uslužnog mesha je da nam je potrebna pouzdanost i tolerancija na greške na mrežnoj razini, a važno nam je da se servisni mesh učinkovito nosi s opterećenjima koja su prethodno ometala usluge.

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

Evo primjera takvog procesa:

• Pokrećemo 10 poslužitelja kao bar usluga koja vraća odgovor 200/OK nakon 100 ms.
• Pokrećemo 10 klijenata - svaki šalje 100 zahtjeva u sekundi bar.
• Svakih 10 sekundi uklanjamo 1 poslužitelj i pratimo pogreške 5xx na klijentu.

Na kraju tijeka rada pregledavamo zapisnike i metriku i provjeravamo je li test prošao. Na taj način učimo o performansama naše servisne mreže i izvodimo regresijski test da testiramo svoje pretpostavke o toleranciji na greške.

(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

Postavili smo 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 100 ms i prosljeđuju zahtjev na irs-server.
• irs-server: 3 replike koje se vraćaju 200/OK nakon 100 ms.

Ovom konfiguracijom možemo mjeriti stabilan protok prometa između 9 krajnjih točaka. Prikolice unutra irs-client-loadgen и irs-server primati 100 zahtjeva u sekundi, i irs-client — 200 (dolazni i odlazni).

Pratimo korištenje resursa putem DataDogjer nemamo jato Prometej.

Nalazi

Upravljačke ploče

Prvo smo ispitali potrošnju procesora.

Upravljačka ploča Linkerda ~22 millicore

Istio upravljačka ploča: ~750 milicore

Upravljačka ploča Istio koristi približno 35 puta više CPU resursanego Linkerd. Naravno, sve je instalirano prema zadanim postavkama, a istio-telemetrija ovdje troši puno resursa procesora (može se onemogućiti isključivanjem nekih funkcija). Ako uklonimo ovu komponentu, i dalje dobivamo više od 100 milicore, tj 4 puta višenego Linkerd.

Sidecar proxy

Zatim smo testirali korištenje proxyja. Trebao bi postojati linearan odnos s brojem zahtjeva, ali za svaku prikolicu postoje neki dodatni troškovi koji utječu na krivulju.

Linkerd: ~100 millicores za irs-client, ~50 millicores 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 millicores za irs-client, ~75 millicores za irs-client-loadgen

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

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

Vidimo istu shemu na strani poslužitelja:

Linkerd: ~50 millicore za irs-poslužitelj

Istio/Envoy: ~80 millicore za irs-poslužitelj

Na strani poslužitelja, 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 od Linkerda na našem simuliranom radnom opterećenju. Upravljačka ploča Linkerd troši mnogo manje resursa nego Istio, posebno za osnovne komponente.

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

Izvor: www.habr.com