Introduzione
Simu in hà cuminciatu à implementà Istio cum'è una rete di serviziu. In principiu, tuttu hè bè, fora di una cosa: hè caru.
В per Istio si dice:
Cù Istio 1.1, u proxy consuma circa 0,6 vCPU (cores virtuali) per 1000 richieste per seconda.
Per a prima regione in a rete di serviziu (2 proxies in ogni latu di a cunnessione), averemu 1200 core solu per u proxy, à un ritmu di un milione di richieste per seconda. Sicondu a calculatrice di costu di Google, hè di circa $ 40 / mese / core per a cunfigurazione n1-standard-64, vale à dì, sta regione sola ci costarà più di 50 mila dollari per mese per 1 milione di richieste per seconda.
Ivan Sim () i ritardi di a rete di serviziu l'annu passatu è prumessu u listessu per a memoria è u processatore, ma ùn hà micca travagliatu:
Apparentemente, values-istio-test.yaml aumenterà seriamente e richieste di CPU. Se aghju fattu a mo matematica currettamente, avete bisognu di circa 24 core CPU per u pannellu di cuntrollu è 0,5 CPU per ogni proxy. Ùn aghju micca tantu. Ripeteraghju e teste quandu più risorse sò attribuite à mè.
Vuliu vede per mè cumu u rendiment di Istio hè simile à un altru mesh di serviziu di fonte aperta: .
Installazione di rete di serviziu
Prima di tuttu, aghju stallatu in un cluster :
$ 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!Aghju utilizatu SuperGloo perchè rende assai più faciule l'avvio di a rete di serviziu. Ùn aghju micca bisognu di fà assai. Ùn avemu micca aduprà SuperGloo in a produzzione, ma hè ideale per una tale attività. Aviu avutu aduprà literalmente un paru di cumandamenti per ogni maglia di serviziu. Aghju utilizatu dui clusters per l'isolamentu - unu per Istio è Linkerd.
L'esperimentu hè statu fattu nantu à Google Kubernetes Engine. Aghju utilizatu Kubernetes 1.12.7-gke.7 è una piscina di nodi n1-standard-4 cù scaling node automaticu (minimu 4, massimu 16).
Allora aghju installatu e duie maglie di serviziu da a linea di cummanda.
Primu 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 |
+---------+--------------+---------+---------------------------+Allora 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 |
+---------+------------+---------+---------------------------+U crash-loop hà pigliatu uni pochi di minuti, è dopu i pannelli di cuntrollu stabilizzavanu.
(Nota: SuperGloo supporta solu Istio 1.0.x per avà. Aghju ripetutu l'esperimentu cù Istio 1.1.3, ma ùn aghju micca nutatu nisuna differenza notevuli.)
Configurazione di Istio Automatic Deployment
Per fà chì Istio installà u sidecar Envoy, usemu l'injector sidecar - MutatingAdmissionWebhook. Ùn parlemu micca in questu articulu. Lasciami dì solu chì questu hè un controller chì monitorizza l'accessu di tutti i novi pods è aghjunghje dinamicamente un sidecar è initContainer, chì hè rispunsevule per i travaglii. iptables.
Avemu à Shopify hà scrittu u nostru propiu controller d'accessu per implementà sidecars, ma per questu benchmark aghju utilizatu u controller chì vene cun Istio. U controller injects sidecars per automaticamente quandu ci hè un shortcut in u namespace 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 labeledConfigurazione di l'implementazione automatica di Linkerd
Per cunfigurà l'incrustazione di Linkerd sidecar, usemu annotazioni (l'aghju aghjustatu manualmente 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: ActiveIstio Fault Tolerance Simulator
Avemu custruitu un simulatore di tolleranza di difetti chjamatu Istio per sperimentà u trafficu unicu à Shopify. Avemu bisognu di un strumentu per creà una topulugia persunalizata chì rapprisenta una parte specifica di u nostru graficu di serviziu, cunfigurata dinamicamente per modellà carichi di travagliu specifichi.
L'infrastruttura di Shopify hè sottu carica pesante durante a vendita flash. À u listessu tempu, Shopify . I grandi clienti à volte avvisanu di una vendita flash prevista. L'altri li conducenu inaspettatamente per noi in ogni mumentu di u ghjornu o di a notte.
Vulemu chì u nostru simulatore di resilienza modella i flussi di travagliu chì currispondenu à e topologie è carichi di travagliu chì anu sopraffattu l'infrastruttura di Shopify in u passatu. U scopu principale di utilizà una rete di serviziu hè chì avemu bisognu di affidabilità è di tolleranza di difetti à u livellu di a rete, è hè impurtante per noi chì a rete di serviziu copre in modu efficace i carichi chì anu disturbatu i servizii prima.
À u core di u simulatore di tolleranza di difetti hè un nodu di travagliu, chì agisce cum'è un nodu di rete di serviziu. U nodu di u travagliu pò esse cunfiguratu staticamente à l'iniziu o dinamicamente via una API REST. Utilizemu a cunfigurazione dinamica di i nodi di u travagliu per creà flussi di travagliu in forma di teste di regressione.
Eccu un esempiu di tali prucessu:
- Lanciamu 10 servitori cum'è
barserviziu chì torna una risposta200/OKdopu à 100 ms. - Lancemu 10 clienti - ognunu manda 100 richieste per seconda à
bar. - Ogni 10 seconde sguassemu 1 servitore è monitoremu l'errori
5xxnantu à u cliente.
À a fine di u flussu di travagliu, esaminemu i logs è e metriche è verificate se a prova hà passatu. In questu modu imparemu nantu à u rendiment di a nostra rete di serviziu è eseguimu una prova di regressione per pruvà e nostre ipotesi nantu à a tolleranza di difetti.
(Nota: Pensemu à l'approvvigionamentu apertu u simulatore di tolleranza à i difetti Istio, ma ùn sò micca pronti à fà cusì.)
Simulatore di tolleranza di errore Istio per u benchmark di rete di serviziu
Avemu stallatu parechji nodi di travagliu di u simulatore:
irs-client-loadgen: 3 repliche chì mandanu 100 richieste per seconda perirs-client.irs-client: 3 repliche chì ricevenu a dumanda, aspettate 100 ms è trasmette a dumanda àirs-server.irs-server: 3 repliche chì tornanu200/OKdopu à 100 ms.
Cù sta cunfigurazione, pudemu misurà un flussu stabile di trafficu trà 9 endpoints. Sidecars in irs-client-loadgen и irs-server riceve 100 richieste per seconda, è irs-client - 200 (entrante è in uscita).
Seguimu l'usu di e risorse attraversu perchè ùn avemu micca un cluster Prometheus.
Risultati
Pannelli di cuntrollu
Prima, avemu esaminatu u cunsumu di CPU.
Pannello di cuntrollu Linkerd ~ 22 millicore
Pannellu di cuntrollu Istio: ~ 750 millicore
U pannellu di cuntrollu Istio usa circa 35 volte più risorse di CPUchè Linkerd. Di sicuru, tuttu hè stallatu per difettu, è istio-telemetria cunsuma assai risorse di processore quì (pò esse disattivatu da disattivà alcune funzioni). Se sguassemu stu cumpunente, avemu sempre più di 100 millicores, vale à dì 4 volte di piùchè Linkerd.
Proxy Sidecar
Dopu avemu pruvatu l'usu di un proxy. Ci deve esse una relazione lineale cù u nùmeru di dumande, ma per ogni sidecar ci hè qualchì overhead chì affetta a curva.
Linkerd: ~ 100 millicores per irs-client, ~ 50 millicores per irs-client-loadgen
I risultati sembranu lògichi, perchè u proxy di u cliente riceve duie volte più trafficu di u proxy loadgen: per ogni dumanda in uscita da loadgen, u cliente hà una entrata è una in uscita.
Istio/Envoy: ~155 millicores per irs-client, ~75 millicores per irs-client-loadgen
Avemu vistu risultati simili per i sidecars Istio.
Ma in generale, i proxy Istio / Envoy consumanu circa 50% più risorse CPUchè Linkerd.
Avemu vistu u listessu schema da u latu di u servitore:
Linkerd: ~ 50 millicore per irs-server
Istio/Envoy: ~ 80 millicore per irs-server
Da u latu di u servitore, sidecar Istio / Envoy cunsuma circa 60% più risorse CPUchè Linkerd.
cunchiusioni
U proxy Istio Envoy consuma 50+% più CPU di Linkerd nantu à a nostra carica di travagliu simulata. U pannellu di cuntrollu Linkerd cunsuma assai menu risorse cà Istio, in particulare per i cumpunenti core.
Pensemu sempre à cumu riduce sti costi. Sì avete idee, per piacè sparte!
Source: www.habr.com