Inledning
Vi är inne började distribuera Istio som ett servicenät. I princip är allt bra, förutom en sak: det är dyrt.
В för Istio står det:
Med Istio 1.1 förbrukar proxyn cirka 0,6 vCPU:er (virtuella kärnor) per 1000 förfrågningar per sekund.
För den första regionen i servicenätet (2 proxyservrar på varje sida av anslutningen) kommer vi att ha 1200 kärnor bara för proxyn, med en hastighet av en miljon förfrågningar per sekund. Enligt Googles kostnadskalkylator verkar det vara cirka 40 USD/månad/kärna för konfiguration n1-standard-64, det vill säga, bara denna region kommer att kosta oss mer än 50 tusen dollar per månad för 1 miljon förfrågningar per sekund.
Ivan Sim () service mesh förseningar förra året och lovade samma sak för minne och processor, men det fungerade inte:
Uppenbarligen kommer values-istio-test.yaml att på allvar öka CPU-förfrågningar. Om jag har räknat ut korrekt behöver du cirka 24 CPU-kärnor för kontrollpanelen och 0,5 CPU för varje proxy. Jag har inte så mycket. Jag kommer att upprepa testerna när mer resurser tilldelas mig.
Jag ville själv se hur lik Istios prestanda är till en annan öppen källkodstjänstnät: .
Servicenätinstallation
Först och främst installerade jag det i ett 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!Jag använde SuperGloo eftersom det gör bootstrapping av servicenätet mycket enklare. Jag behövde inte göra mycket. Vi använder inte SuperGloo i produktionen, men den är idealisk för en sådan uppgift. Jag var tvungen att använda bokstavligen ett par kommandon för varje servicenät. Jag använde två kluster för isolering - ett vardera för Istio och Linkerd.
Experimentet utfördes på Google Kubernetes Engine. Jag använde Kubernetes 1.12.7-gke.7 och en pool av noder n1-standard-4 med automatisk nodskalning (minst 4, max 16).
Sedan installerade jag båda servicenäten från kommandoraden.
Första länkad:
$ 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 |
+---------+--------------+---------+---------------------------+Sedan 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 |
+---------+------------+---------+---------------------------+Krockslingan tog några minuter och sedan stabiliserades kontrollpanelerna.
(Obs: SuperGloo stöder bara Istio 1.0.x för närvarande. Jag upprepade experimentet med Istio 1.1.3, men märkte ingen märkbar skillnad.)
Konfigurera Istio Automatic Deployment
För att få Istio att installera sidovagnen Envoy använder vi sidovagnsinjektorn − MutatingAdmissionWebhook. Vi kommer inte att prata om det i den här artikeln. Låt mig bara säga att detta är en kontroller som övervakar åtkomsten av alla nya pods och dynamiskt lägger till en sidovagn och initContainer, som ansvarar för uppgifter iptables.
Vi på Shopify skrev vår egen åtkomstkontroll för att implementera sidovagnar, men för detta riktmärke använde jag kontrollern som följer med Istio. Styrenheten injicerar sidovagnar som standard när det finns en genväg i namnutrymmet 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 labeledStälla in automatisk Linkerd-distribution
För att ställa in Linkerd sidovagnsinbäddning använder vi kommentarer (jag lade till dem manuellt 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
Vi byggde en feltoleranssimulator som heter Istio för att experimentera med trafik som är unik för Shopify. Vi behövde ett verktyg för att skapa en anpassad topologi som skulle representera en specifik del av vår tjänstegraf, dynamiskt konfigurerad för att modellera specifika arbetsbelastningar.
Shopifys infrastruktur är under stor belastning under flashförsäljning. Samtidigt Shopify . Stora kunder varnar ibland för en planerad blixtförsäljning. Andra utför dem oväntat för oss när som helst på dagen eller natten.
Vi ville att vår resilienssimulator skulle modellera arbetsflöden som matchar topologierna och arbetsbelastningarna som har överväldigat Shopifys infrastruktur tidigare. Huvudsyftet med att använda ett servicenät är att vi behöver tillförlitlighet och feltolerans på nätverksnivå, och det är viktigt för oss att servicenätet effektivt klarar belastningar som tidigare störde tjänster.
I hjärtat av feltoleranssimulatorn finns en arbetarnod, som fungerar som en servicenätnod. Arbetarnoden kan konfigureras statiskt vid start eller dynamiskt via ett REST API. Vi använder dynamisk konfiguration av arbetarnoder för att skapa arbetsflöden i form av regressionstester.
Här är ett exempel på en sådan process:
- Vi lanserar 10 servrar som
bartjänst som returnerar ett svar200/OKefter 100 ms. - Vi lanserar 10 klienter - var och en skickar 100 förfrågningar per sekund till
bar. - Var 10:e sekund tar vi bort 1 server och övervakar fel
5xxpå klienten.
I slutet av arbetsflödet undersöker vi loggarna och mätvärdena och kontrollerar om testet gick igenom. På så sätt lär vi oss om prestandan för vårt servicenät och kör ett regressionstest för att testa våra antaganden om feltolerans.
(Obs: Vi funderar på att öppna Istio-feltoleranssimulatorn, men är inte redo att göra det ännu.)
Istio feltoleranssimulator för benchmark för servicenät
Vi ställer in flera arbetsnoder för simulatorn:
irs-client-loadgen: 3 repliker som skickar 100 förfrågningar per sekund perirs-client.irs-client: 3 repliker som tar emot begäran, vänta 100ms och vidarebefordra förfrågan tillirs-server.irs-server: 3 repliker som återkommer200/OKefter 100 ms.
Med denna konfiguration kan vi mäta ett stabilt trafikflöde mellan 9 slutpunkter. Sidovagnar in irs-client-loadgen и irs-server ta emot 100 förfrågningar per sekund, och irs-client — 200 (inkommande och utgående).
Vi spårar resursanvändning genom eftersom vi inte har ett Prometheus-kluster.
Resultat
Kontrollpaneler
Först undersökte vi CPU-förbrukningen.
Linkerd kontrollpanel ~22 millicore
Istio kontrollpanel: ~750 millicore
Istio-kontrollpanelen använder ca 35 gånger mer CPU-resurserän Linkerd. Naturligtvis är allt installerat som standard, och istio-telemetri förbrukar mycket processorresurser här (det kan inaktiveras genom att inaktivera vissa funktioner). Om vi tar bort den här komponenten får vi fortfarande mer än 100 millikärnor, alltså 4 gånger merän Linkerd.
Sidecar proxy
Vi testade sedan användningen av en proxy. Det bör finnas ett linjärt samband med antalet förfrågningar, men för varje sidovagn finns det viss overhead som påverkar kurvan.
Linkerd: ~100 millicores för irs-klient, ~50 millicores för irs-client-loadgen
Resultaten ser logiska ut, eftersom klientproxyn får dubbelt så mycket trafik som loadgen-proxyn: för varje utgående begäran från loadgen har klienten en inkommande och en utgående.
Istio/Envoy: ~155 millicores för irs-client, ~75 millicores för irs-client-loadgen
Vi ser liknande resultat för Istio sidvagnar.
Men i allmänhet konsumerar Istio/Envoy-ombud cirka 50 % mer CPU-resurserän Linkerd.
Vi ser samma schema på serversidan:
Linkerd: ~50 millicore för irs-server
Istio/Envoy: ~80 millikärnor för irs-server
På serversidan förbrukar sidovagnen Istio/Envoy cirka 60 % mer CPU-resurserän Linkerd.
Slutsats
Istio Envoy-proxyn förbrukar 50+ % mer CPU än Linkerd på vår simulerade arbetsbelastning. Linkerds kontrollpanel förbrukar mycket mindre resurser än Istio, särskilt för kärnkomponenterna.
Vi funderar fortfarande på hur vi ska kunna minska dessa kostnader. Om du har idéer, dela gärna!
Källa: will.com