Introducció
Estem a va començar a desplegar Istio com a malla de servei. En principi, tot està bé, excepte una cosa: és car.
В per a Istio diu:
Amb Istio 1.1, el servidor intermediari consumeix aproximadament 0,6 vCPU (nuclis virtuals) per cada 1000 sol·licituds per segon.
Per a la primera regió de la malla de servei (2 servidors intermediaris a cada costat de la connexió), tindrem 1200 nuclis només per al servidor intermediari, a un ritme d'un milió de sol·licituds per segon. Segons la calculadora de costos de Google, la configuració és d'aproximadament 40 dòlars/mes/nucli n1-standard-64, és a dir, només aquesta regió ens costarà més de 50 mil dòlars al mes per 1 milió de sol·licituds per segon.
Ivan Sim () La malla de servei es va retardar l'any passat i va prometre el mateix per a la memòria i el processador, però no va funcionar:
Aparentment, values-istio-test.yaml augmentarà seriosament les sol·licituds de CPU. Si he fet les matemàtiques correctament, necessiteu aproximadament 24 nuclis de CPU per al tauler de control i 0,5 CPU per a cada proxy. No en tinc gaire. Repetiré les proves quan em destinin més recursos.
Volia veure per mi mateix com de semblant és el rendiment d'Istio a una altra malla de servei de codi obert: .
Instal·lació de malla de servei
En primer lloc, el vaig instal·lar en un clúster :
$ 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!Vaig utilitzar SuperGloo perquè facilita molt l'arrencada de la malla de servei. No vaig haver de fer gran cosa. No utilitzem SuperGloo en producció, però és ideal per a aquesta tasca. Vaig haver d'utilitzar literalment un parell d'ordres per a cada malla de servei. Vaig utilitzar dos clústers per aïllar-los: un per a Istio i Linkerd.
L'experiment es va dur a terme a Google Kubernetes Engine. Vaig utilitzar Kubernetes 1.12.7-gke.7 i un grup de nodes n1-standard-4 amb escalat automàtic de nodes (mínim 4, màxim 16).
A continuació, vaig instal·lar les dues malles de servei des de la línia d'ordres.
Primer 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 |
+---------+--------------+---------+---------------------------+Aleshores 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 |
+---------+------------+---------+---------------------------+El bucle d'accident va trigar uns minuts i després els panells de control es van estabilitzar.
(Nota: SuperGloo només admet Istio 1.0.x de moment. Vaig repetir l'experiment amb Istio 1.1.3, però no vaig notar cap diferència notable.)
Configuració del desplegament automàtic d'Istio
Per fer que Istio instal·li el sidecar Envoy, utilitzem l'injector sidecar − MutatingAdmissionWebhook. No en parlarem en aquest article. Permeteu-me dir que es tracta d'un controlador que supervisa l'accés de tots els pods nous i afegeix dinàmicament un sidecar i un initContainer, que és responsable de les tasques. iptables.
A Shopify vam escriure el nostre propi controlador d'accés per implementar sidecars, però per a aquest punt de referència vaig utilitzar el controlador que ve amb Istio. El controlador injecta sidecars per defecte quan hi ha una drecera a l'espai de noms 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 labeledConfiguració del desplegament automàtic de Linkerd
Per configurar la incrustació del sidecar de Linkerd, utilitzem anotacions (les vaig afegir manualment mitjançant 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: ActiveSimulador de tolerància a errors Istio
Hem creat un simulador de tolerància a errors anomenat Istio per experimentar amb el trànsit exclusiu de Shopify. Necessitàvem una eina per crear una topologia personalitzada que representés una part específica del nostre gràfic de servei, configurada dinàmicament per modelar càrregues de treball específiques.
La infraestructura de Shopify està sota una gran càrrega durant les vendes flash. Al mateix temps, Shopify . Els clients grans de vegades adverteixen sobre una venda flash planificada. Altres els condueixen de manera inesperada per nosaltres a qualsevol hora del dia o de la nit.
Volíem que el nostre simulador de resiliència modelés fluxos de treball que coincideixen amb les topologies i les càrregues de treball que han desbordat la infraestructura de Shopify en el passat. L'objectiu principal d'utilitzar una malla de servei és que necessitem fiabilitat i tolerància a errors a nivell de xarxa, i és important per a nosaltres que la malla de servei faci front eficaçment a les càrregues que anteriorment interrompien els serveis.
Al cor del simulador de tolerància a fallades hi ha un node de treball, que actua com a node de malla de servei. El node de treball es pot configurar de manera estàtica a l'inici o dinàmicament mitjançant una API REST. Utilitzem la configuració dinàmica dels nodes de treball per crear fluxos de treball en forma de proves de regressió.
Aquí teniu un exemple d'aquest procés:
- Llancem 10 servidors com
barservei que retorna una resposta200/OKdesprés de 100 ms. - Llancem 10 clients, cadascun envia 100 sol·licituds per segon a
bar. - Cada 10 segons eliminem 1 servidor i monitoritzem els errors
5xxsobre el client.
Al final del flux de treball, examinem els registres i les mètriques i comprovem si la prova ha passat. D'aquesta manera aprenem sobre el rendiment de la nostra malla de servei i fem una prova de regressió per provar les nostres hipòtesis sobre la tolerància a errors.
(Nota: estem pensant en l'obtenció del simulador de tolerància a errors d'Istio, però encara no estem preparats per fer-ho).
Simulador de tolerància a errors Istio per a la referència de malla de servei
Hem configurat diversos nodes de treball del simulador:
irs-client-loadgen: 3 rèpliques que envien 100 peticions per segon perirs-client.irs-client: 3 rèpliques que reben la sol·licitud, esperen 100 ms i reenvien la sol·licitud airs-server.irs-server: 3 rèpliques que tornen200/OKdesprés de 100 ms.
Amb aquesta configuració, podem mesurar un flux de trànsit estable entre 9 punts finals. Sidecars dins irs-client-loadgen и irs-server rebre 100 peticions per segon i irs-client — 200 (entrants i sortints).
Fem un seguiment de l'ús dels recursos perquè no tenim un clúster de Prometeu.
Troballes
Quadres de control
Primer, vam examinar el consum de CPU.
Panell de control de Linkerd ~ 22 millicores
Tauler de control Istio: ~750 millicore
El tauler de control Istio utilitza aproximadament 35 vegades més recursos de CPUque Linkerd. Per descomptat, tot s'instal·la per defecte, i la telemetria istio consumeix molts recursos del processador aquí (es pot desactivar desactivant algunes funcions). Si eliminem aquest component, encara obtenim més de 100 mil·licores, és a dir 4 vegades mésque Linkerd.
Proxy sidecar
Després vam provar l'ús d'un proxy. Hi hauria d'haver una relació lineal amb el nombre de peticions, però per a cada sidecar hi ha alguna sobrecàrrega que afecta la corba.
Linkerd: ~ 100 milicores per a irs-client, ~ 50 milicores per a irs-client-loadgen
Els resultats semblen lògics, perquè el servidor intermediari del client rep el doble de trànsit que el servidor intermediari de loadgen: per cada sol·licitud de sortida de loadgen, el client té una d'entrada i una de sortida.
Istio/Envoy: ~155 milicores per a irs-client, ~75 milicores per a irs-client-loadgen
Veiem resultats similars per als sidecars Istio.
Però, en general, els proxies Istio/Envoy consumeixen aproximadament un 50% més de recursos de CPUque Linkerd.
Veiem el mateix esquema al costat del servidor:
Linkerd: ~ 50 millicores per al servidor irs
Istio/Envoy: ~80 millicores per al servidor irs
Al costat del servidor, el sidecar Istio/Envoy consumeix aproximadament un 60% més de recursos de CPUque Linkerd.
Conclusió
El servidor intermediari Istio Envoy consumeix un 50% més de CPU que Linkerd a la nostra càrrega de treball simulada. El tauler de control de Linkerd consumeix molts menys recursos que Istio, especialment per als components bàsics.
Encara estem pensant com reduir aquests costos. Si teniu idees, compartiu-ho!
Font: www.habr.com