Introductie
Wij zijn in begonnen met het inzetten van Istio als een servicemesh. In principe is alles in orde, behalve één ding: het is duur.
В voor Istio staat er:
Met Istio 1.1 verbruikt de proxy ongeveer 0,6 vCPU's (virtuele cores) per 1000 verzoeken per seconde.
Voor de eerste regio in de service mesh (2 proxy's aan elke kant van de verbinding) hebben we 1200 cores alleen voor de proxy, met een snelheid van één miljoen verzoeken per seconde. Volgens de kostencalculator van Google komt dit neer op ongeveer $ 40/maand/core voor configuratie n1-standard-64Dat wil zeggen dat deze regio alleen al ons meer dan 50 dollar per maand kost voor 1 miljoen verzoeken per seconde.
Ivan Sim () service mesh vertragingen vorig jaar en beloofde hetzelfde voor geheugen en processor, maar het werkte niet:
Blijkbaar zal value-istio-test.yaml de CPU-aanvragen aanzienlijk verhogen. Als ik het goed heb berekend, heb je ongeveer 24 CPU-kernen nodig voor het controlepaneel en 0,5 CPU voor elke proxy. Ik heb niet zoveel. Ik zal de tests herhalen wanneer er meer middelen aan mij worden toegewezen.
Ik wilde zelf zien hoe vergelijkbaar de prestaties van Istio zijn met een andere open source service mesh: .
Service mesh-installatie
Allereerst heb ik het in een cluster geïnstalleerd :
$ 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 heb SuperGloo gebruikt omdat het het opstarten van de service mesh veel eenvoudiger maakt. Ik hoefde niet veel te doen. We gebruiken SuperGloo niet in de productie, maar het is ideaal voor een dergelijke taak. Ik moest letterlijk een paar opdrachten gebruiken voor elke servicemesh. Ik heb twee clusters gebruikt voor isolatie: één voor Istio en Linkerd.
Het experiment werd uitgevoerd op Google Kubernetes Engine. Ik heb Kubernetes gebruikt 1.12.7-gke.7 en een pool van knooppunten n1-standard-4 met automatische knooppuntschaling (minimaal 4, maximaal 16).
Vervolgens installeerde ik beide servicemeshes vanaf de opdrachtregel.
Eerste 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 duurde een paar minuten en daarna stabiliseerden de bedieningspanelen.
(Opmerking: SuperGloo ondersteunt voorlopig alleen Istio 1.0.x. Ik herhaalde het experiment met Istio 1.1.3, maar merkte geen merkbaar verschil.)
Automatische implementatie van Istio instellen
Om Istio de zijspan Envoy te laten installeren, gebruiken we de zijspaninjector − MutatingAdmissionWebhook. We zullen er in dit artikel niet over praten. Laat ik zeggen dat dit een controller is die de toegang van alle nieuwe pods bewaakt en dynamisch een zijspan en initContainer toevoegt, die verantwoordelijk is voor taken iptables.
Wij bij Shopify hebben onze eigen toegangscontroller geschreven om zijspannen te implementeren, maar voor deze benchmark heb ik de controller gebruikt die bij Istio wordt geleverd. De controller injecteert standaard zijspannen als er een snelkoppeling in de naamruimte staat 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 labeledAutomatische Linkerd-implementatie instellen
Om de zijspan-inbedding van Linkerd in te stellen, gebruiken we annotaties (ik heb ze handmatig toegevoegd 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 fouttolerantiesimulator
We hebben een fouttolerantiesimulator gebouwd, Istio genaamd, om te experimenteren met verkeer dat uniek is voor Shopify. We hadden een tool nodig om een aangepaste topologie te creëren die een specifiek deel van onze servicegrafiek zou vertegenwoordigen, dynamisch geconfigureerd om specifieke werklasten te modelleren.
De infrastructuur van Shopify wordt zwaar belast tijdens flash-verkopen. Tegelijkertijd Shopify . Grote klanten waarschuwen soms voor een geplande flash-sale. Anderen voeren ze op elk moment van de dag of nacht onverwacht voor ons uit.
We wilden dat onze veerkrachtsimulator workflows zou modelleren die passen bij de topologieën en werklasten die de infrastructuur van Shopify in het verleden hebben overweldigd. Het belangrijkste doel van het gebruik van een service mesh is dat we betrouwbaarheid en fouttolerantie op netwerkniveau nodig hebben, en het is belangrijk voor ons dat de service mesh effectief omgaat met belastingen die voorheen de services verstoorden.
Het hart van de fouttolerantiesimulator wordt gevormd door een werkknooppunt, dat fungeert als een servicemesh-knooppunt. Het werkknooppunt kan statisch worden geconfigureerd bij het opstarten of dynamisch via een REST API. We gebruiken dynamische configuratie van werkknooppunten om workflows te creëren in de vorm van regressietests.
Hier is een voorbeeld van een dergelijk proces:
- We lanceren 10 servers als
barservice die een antwoord retourneert200/OKna 100 ms. - We lanceren 10 clients - elk verzendt 100 verzoeken per seconde naar
bar. - Elke 10 seconden verwijderen we 1 server en monitoren we fouten
5xxop de cliënt.
Aan het einde van de workflow onderzoeken we de logs en statistieken en controleren we of de test is geslaagd. Op deze manier leren we over de prestaties van onze service mesh en voeren we een regressietest uit om onze aannames over fouttolerantie te testen.
(Opmerking: we overwegen de Istio-fouttolerantiesimulator open source te maken, maar zijn hier nog niet klaar voor.)
Istio-fouttolerantiesimulator voor service mesh-benchmark
We hebben verschillende werkende knooppunten van de simulator opgezet:
irs-client-loadgen: 3 replica's die 100 verzoeken per seconde per verzendenirs-client.irs-client: 3 replica's die het verzoek ontvangen, wachten 100 ms en sturen het verzoek door naarirs-server.irs-server: 3 replica's die terugkeren200/OKna 100 ms.
Met deze configuratie kunnen we een stabiele verkeersstroom tussen 9 eindpunten meten. Zijspannen erin irs-client-loadgen и irs-server 100 verzoeken per seconde ontvangen, en irs-client — 200 (inkomend en uitgaand).
We volgen het gebruik van hulpbronnen via omdat we geen Prometheus-cluster hebben.
Bevindingen
Controle panelen
Eerst hebben we het CPU-verbruik onderzocht.
Linkerd-bedieningspaneel ~22 millicore
Istio-bedieningspaneel: ~750 millicore
Het Istio-bedieningspaneel gebruikt ongeveer 35 keer meer CPU-bronnendan Linkerd. Natuurlijk is alles standaard geïnstalleerd, en istio-telemetrie verbruikt hier veel processorbronnen (het kan worden uitgeschakeld door sommige functies uit te schakelen). Als we dit onderdeel verwijderen, krijgen we nog steeds meer dan 100 millicores 4 keer meerdan Linkerd.
Zijspan-proxy
Vervolgens hebben we het gebruik van een proxy getest. Er zou een lineaire relatie moeten zijn met het aantal verzoeken, maar voor elke zijspan is er enige overhead die de curve beïnvloedt.
Linkerd: ~100 millicores voor irs-client, ~50 millicores voor irs-client-loadgen
De resultaten zien er logisch uit, omdat de client-proxy twee keer zoveel verkeer ontvangt als de loadgen-proxy: voor elk uitgaand verzoek van loadgen heeft de client één inkomend en één uitgaand verzoek.
Istio/Envoy: ~155 millicores voor irs-client, ~75 millicores voor irs-client-loadgen
Soortgelijke resultaten zien we voor Istio zijspannen.
Maar over het algemeen consumeren Istio/Envoy-proxy's ongeveer 50% meer CPU-bronnendan Linkerd.
We zien hetzelfde schema aan de serverkant:
Linkerd: ~50 millicore voor irs-server
Istio/Envoy: ~80 millicore voor irs-server
Aan de serverkant verbruikt zijspan Istio/Envoy ongeveer 60% meer CPU-bronnendan Linkerd.
Conclusie
De Istio Envoy-proxy verbruikt 50+% meer CPU dan Linkerd op onze gesimuleerde werklast. Het Linkerd-configuratiescherm verbruikt veel minder bronnen dan Istio, vooral voor de kerncomponenten.
We denken er nog over na hoe we deze kosten kunnen verlagen. Als je ideeën hebt, deel ze dan!
Bron: www.habr.com