Ynlieding
Wy binne yn begon Istio yn te setten as in servicemesh. Yn prinsipe is alles goed, útsein ien ding: it is djoer.
В foar Istio stiet:
Mei Istio 1.1 konsumearret de proxy sawat 0,6 vCPU's (firtuele kearnen) per 1000 fersiken per sekonde.
Foar de earste regio yn 'e tsjinstmesh (2 proxy's oan elke kant fan' e ferbining), sille wy 1200 kearnen hawwe allinich foar de proxy, mei in taryf fan ien miljoen oanfragen per sekonde. Neffens de kostenberekkener fan Google wurket it sawat $ 40 / moanne / kearn foar konfiguraasje n1-standard-64, dat is, dizze regio allinich kostet ús mear as 50 tûzen dollar per moanne foar 1 miljoen oanfragen per sekonde.
Ivan Sim () tsjinst mesh fertragingen ferline jier en tasein itselde foar ûnthâld en prosessor, mar it wurke net:
Blykber, values-istio-test.yaml sil serieus fergrutsje CPU fersiken. As ik myn wiskunde goed dien haw, moatte jo sawat 24 CPU-kearnen foar it kontrôlepaniel en 0,5 CPU foar elke proxy nedich hawwe. Ik haw net safolle. Ik sil de tests werhelje as mear middels my wurde tawiisd.
Ik woe foar mysels sjen hoe ferlykber de prestaasjes fan Istio binne oan in oare iepen boarne-tsjinstmesh: .
Service mesh ynstallaasje
Earst haw ik it ynstalleare yn in kluster :
$ 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!Ik brûkte SuperGloo om't it bootstrapping fan it tsjinstmesh folle makliker makket. Ik hoegde net folle te dwaan. Wy brûke SuperGloo net yn produksje, mar it is ideaal foar sa'n taak. Ik moast letterlik in pear kommando's brûke foar elke tsjinstmesh. Ik brûkte twa klusters foar isolaasje - elk ien foar Istio en Linkerd.
It eksperimint waard útfierd op Google Kubernetes Engine. Ik brûkte Kubernetes 1.12.7-gke.7 en in pool fan knopen n1-standard-4 mei automatyske node skaalfergrutting (minimum 4, maksimum 16).
Dan haw ik beide tsjinstmeshes ynstalleare fanút de kommandorigel.
Earste 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 |
+---------+--------------+---------+---------------------------+Dan 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 |
+---------+------------+---------+---------------------------+De crash-loop duorre in pear minuten, en doe stabilisearren de kontrôlepanielen.
(Opmerking: SuperGloo stipet allinich Istio 1.0.x foar no. Ik haw it eksperimint mei Istio 1.1.3 werhelle, mar fernaam gjin merkber ferskil.)
It ynstellen fan Istio automatyske ynset
Om Istio de sidecar Envoy te ynstallearjen, brûke wy de sidecar-injector - MutatingAdmissionWebhook. Wy sille der net oer prate yn dit artikel. Lit my gewoan sizze dat dit in kontrôler is dy't de tagong fan alle nije pods kontrolearret en dynamysk in sidecar en initContainer tafoegje, dy't ferantwurdlik is foar taken iptables.
Wy by Shopify skreaunen ús eigen tagongscontroller om sidecars te ymplementearjen, mar foar dizze benchmark brûkte ik de controller dy't komt mei Istio. De controller injects sidecars standert as der in fluchtoets yn de nammeromte 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 labeledIt ynstellen fan automatyske Linkerd-ynset
Om Linkerd-sidecar-ynbedding yn te stellen, brûke wy annotaasjes (ik haw se manuell tafoege fia 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
Wy bouden in fouttolerânsje-simulator neamd Istio om te eksperimintearjen mei ferkear unyk foar Shopify. Wy hiene in ark nedich om in oanpaste topology te meitsjen dy't in spesifyk diel fan ús tsjinstgrafyk soe fertsjintwurdigje, dynamysk konfigureare om spesifike wurklasten te modellearjen.
De ynfrastruktuer fan Shopify is ûnder swiere lêst by flashferkeap. Tagelyk Shopify . Grutte klanten warskôgje soms foar in plande flitsferkeap. Oaren fiere se ûnferwachts foar ús op elk momint fan 'e dei of nacht.
Wy woenen dat ús resiliency-simulator workflows modelleart dy't oerienkomme mei de topologyen en workloads dy't de ynfrastruktuer fan Shopify yn it ferline hawwe oerweldige. It wichtichste doel fan it brûken fan in tsjinst mesh is dat wy nedich betrouberens en skuld tolerânsje op it netwurk nivo, en it is wichtich foar ús dat de tsjinst mesh effektyf omgaat mei loads dy't earder fersteurd tsjinsten.
Yn it hert fan 'e fouttolerânsje-simulator is in arbeiderknooppunt, dy't fungearret as in tsjinstmeshknooppunt. It wurkknooppunt kin statysk ynsteld wurde by it opstarten of dynamysk fia in REST API. Wy brûke dynamyske konfiguraasje fan wurkknooppunten om workflows te meitsjen yn 'e foarm fan regressiontests.
Hjir is in foarbyld fan sa'n proses:
- Wy lansearje 10 tsjinners as
bartsjinst dy't in antwurd jout200/OKnei 100 ms. - Wy lansearje 10 kliïnten - elk stjoert 100 fersiken per sekonde nei
bar. - Elke 10 sekonden ferwiderje wy 1 tsjinner en kontrolearje flaters
5xxop de klant.
Oan 'e ein fan' e workflow ûndersiikje wy de logs en metriken en kontrolearje oft de test slagge. Op dizze manier learje wy oer de prestaasjes fan ús tsjinstmesh en fiere in regressiontest út om ús oannames oer fouttolerânsje te testen.
(Opmerking: wy tinke oan it iepenjen fan de Istio-fouttolerânsje-simulator, mar binne noch net ree om dat te dwaan.)
Istio-fouttolerânsje-simulator foar benchmark foar servicemesh
Wy sette ferskate wurkknooppunten fan 'e simulator yn:
irs-client-loadgen: 3 replika's dy't stjoere 100 fersiken per sekonde perirs-client.irs-client: 3 replika's dy't it fersyk ûntfange, wachtsje 100ms en stjoer it fersyk troch neiirs-server.irs-server: 3 replika's dy't weromkomme200/OKnei 100 ms.
Mei dizze konfiguraasje kinne wy in stabile ferkearsstream mjitte tusken 9 einpunten. Sidecars yn irs-client-loadgen и irs-server ûntfange 100 fersiken per sekonde, en irs-client - 200 (ynkommende en útgeande).
Wy track boarne gebrûk troch om't wy gjin Prometheus-kluster hawwe.
Resultaten
Control panielen
Earst ûndersochten wy it CPU-konsumpsje.
Linkerd kontrôlepaniel ~22 millicore
Istio kontrôlepaniel: ~750 millicore
It Istio-kontrôlepaniel brûkt sawat 35 kear mear CPU boarnenas Linkerd. Fansels is alles standert ynstalleare, en istio-telemetry ferbrûkt hjir in protte prosessorboarnen (it kin útskeakele wurde troch guon funksjes út te skeakeljen). As wy dizze komponint fuortsmite, krije wy noch mear as 100 millicores, dat is 4 kear mearas Linkerd.
Sidecar proxy
Wy testen doe it gebrûk fan in proxy. D'r moat in lineêre relaasje wêze mei it oantal oanfragen, mar foar elke sidecar is d'r wat overhead dy't de kromme beynfloedet.
Linkerd: ~100 millicores foar irs-client, ~50 millicores foar irs-client-loadgen
De resultaten lykje logysk, om't de clientproxy twa kear safolle ferkear ûntfangt as de loadgen proxy: foar elke útgeande oanfraach fan loadgen hat client ien ynkommende en ien útgeande.
Istio / Envoy: ~155 millicores foar irs-client, ~75 millicores foar irs-client-loadgen
Wy sjogge ferlykbere resultaten foar Istio sidecars.
Mar yn 't algemien konsumearje Istio / Envoy-proxies likernôch 50% mear CPU boarnendan Linkerd.
Wy sjogge itselde skema op 'e serverkant:
Linkerd: ~50 millicore foar irs-tsjinner
Istio / Envoy: ~80 millicore foar irs-tsjinner
Oan de tsjinner kant konsumearret sidecar Istio / Envoy likernôch 60% mear CPU boarnendan Linkerd.
konklúzje
De Istio Envoy-proxy verbruikt 50+% mear CPU dan Linkerd op ús simulearre wurkdruk. It Linkerd-kontrôlepaniel ferbrûkt folle minder boarnen dan Istio, benammen foar de kearnkomponinten.
Wy tinke noch oer hoe't wy dizze kosten ferminderje kinne. As jo ideeën hawwe, diel dan asjebleaft!
Boarne: www.habr.com