Benchmarking av CPU-användning för Istio och Linkerd

Introduktion

En kort historia om containrar: från chroot till Kubernetes Shopify Vi har påbörjat implementeringen av Istio som en service mesh. I princip är allt bra, förutom en sak: det är dyrt.

I offentliggjorda benchmarkar för Istio sägs det:

Med Istio 1.1 använder proxyn ungefär 0,6 vCPU (virtuella kärnor) per 1000 förfrågningar per sekund.

För den första regionen i service mesh (med 2 proxys på varje sida av anslutningen) kommer vi att behöva 1200 kärnor bara för proxys, baserat på en miljon förfrågningar per sekund. Enligt Googles kostnadskalkylator blir det ungefär $40/månad/kärna för konfigurationen n1-standard-64, vilket betyder att denna region kommer att kosta oss mer än 50 000 dollar per månad för 1 miljon förfrågningar per sekund.

Ivan Sim (Ivan Sim) illustrerade tydligt fördröjningarna i service mesh förra året och lovade samma sak för minne och CPU, men det blev inte så:

Till synes kommer values-istio-test.yaml att kraftigt öka belastningen på processorn. Om jag räknat rätt, behövs ungefär 24 CPU-kärnor för kontrollpanelen och 0,5 CPU för varje proxy. Jag har inte så många. Jag kommer att upprepa testerna när jag får fler resurser.

Jag ville själv se hur Istios prestanda jämförs med en annan open-source service mesh: Linkerd.

Installation av service mesh

Först installerade jag i klustret SuperGloo:

$ 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 förenklar initialiseringen av service mesh avsevärt. Jag behövde knappt göra någonting. I produktion använder vi inte SuperGloo, men för en sådan uppgift passar det perfekt. Jag var tvungen att köra bokstavligt talat ett par kommandon för varje service mesh. Jag använde två kluster för isolering – ett för Istio och ett för Linkerd.

Experimentet genomfördes på Google Kubernetes Engine. Jag använde Kubernetes 1.12.7-gke.7 och en nodpool n1-standard-4 med automatisk skalning av noder (minimum 4, maximum 16).

Sedan installerade jag båda service mesh från kommandoraden.

Först 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 |
+---------+--------------+---------+---------------------------+

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      |
+---------+------------+---------+---------------------------+

Crash-loop tog en minut, men kontrolpanelet stabiliserede sig efterfølgende.

(Bemærk: SuperGloo understøtter kun Istio 1.0.x i øjeblikket. Jeg gentog eksperimentet med Istio 1.1.3, men så ingen mærkbar forskel.)

Konfiguration af automatisk injektion af Istio

For at få Istio til at installere sidecar Envoy bruger vi en sidecar-injektor — MutatingAdmissionWebhook. Vi vil ikke diskutere dette i denne artikel. Jeg vil blot sige, at det er en controller, der overvåger adgangen for alle nye pod'e og dynamisk tilføjer sidecar og initContainer, der er ansvarlig for opgaverne iptables.

Vi i Shopify har skrevet vores egen adgangscontroller til injektion af sidecar, men i denne benchmark brugte jeg den controller, der følger med Istio. Standardcontrolleren injicerer sidecar, når der er et label i navnerummet 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 labeled

Konfiguration af automatisk injektion af Linkerd

For at konfigurere injektion af sidecar i Linkerd bruger vi annoteringer (jeg tilføjede dem manuelt 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: Active

Simulator for fejltolerance med Istio

Vi har skapat en simuleringsmodell för tillförlitlighet med Istio för att experimentera med trafik unik för Shopify. Vi behövde ett verktyg för att skapa en godtycklig topologi som skulle representera en viss del av grafen av vår tjänst med dynamisk konfiguration för att modellera specifika arbetsbelastningar.

Shopifys infrastruktur står inför hög belastning under flash-försäljningar. Under dessa perioder rekommenderar Shopify att säljare ofta genomför sådana försäljningar. Stora kunder informerar ibland i förväg om en planerad flash-försäljning. Andra genomför dem oväntat för oss när som helst på dygnet.

Vi ville att vår simuleringsmodell för tillförlitlighet skulle modellera arbetsflöden som matchar de topologier och arbetsbelastningar som tidigare lett till överbelastning av Shopifys infrastruktur. Huvudsyftet med att använda service mesh är att vi behöver tillförlitlighet och redundans på nätverksnivå, och det är viktigt för oss att service mesh hanterar belastningar som tidigare har påverkat tjänsternas drift.

I grunden för simuleringsmodellen för tillförlitlighet finns en arbetsnod som fungerar som en nod i service mesh. Arbetsnoden kan ställas in statiskt vid start eller dynamiskt via REST API. Vi använder dynamisk konfiguration av arbetsnoder för att skapa arbetsflöden i form av regressiva tester.

Här är ett exempel på en sådan process:

• Vi startar 10 servrar som bar en tjänst som returnerar svaret 200/OK efter 100 ms.
• Vi startar 10 klienter — varje skickar 100 förfrågningar per sekund till bar.
• Var 10:e sekund tar vi bort 1 server och övervakar fel 5xx på klienten.

I slutet av arbetsprocessen granskar vi loggar och metrik och kontrollerar om testet har passerat. På så sätt lär vi oss om prestandan hos vår service mesh och genomför ett regressivt test för att kontrollera våra antaganden om tillförlitlighet.

(Observera. Vi överväger att öppna källkoden för simuleringsmodellen för tillförlitlighet med Istio, men vi är inte redo för det ännu.)

Simuleringsmodell för tillförlitlighet med Istio för benchmark av service mesh

Vi konfigurerar flera arbetsnoder för simulatorn:

• irs-client-loadgen: 3 repliker som skickar 100 förfrågningar per sekund till irs-client.
• irs-client: 3 repliker som tar emot förfrågan, väntar 100 ms och vidarebefordrar förfrågan till irs-server.
• irs-server: 3 repliker som returnerar 200/OK efter 100 ms.

Med denna konfiguration kan vi mäta en stabil trafikström mellan 9 slutpunkter. Sidecar:er i irs-client-loadgen och irs-server får 100 förfrågningar per sekund, och irs-client — 200 (in- och utgående).

Vi spårar resursanvändningen genom DataDog, eftersom vi inte har en Prometheus-kluster.

Resultat

Kontrollpaneler

Först tittade vi på CPU-konsumtionen.

Linkerd kontrollpanel ~22 miljarder

Istio kontrollpanel: ~750 miljarder

Istio kontrollpanelen använder ungefär 35 gånger fler processorresurser, än Linkerd. Självklart är allt inställt på standard, och mycket av processorresurserna här används av istio-telemetry (det kan stängas av genom att avstå från vissa funktioner). Om man tar bort denna komponent får man fortfarande mer än 100 miljarder, dvs 4 gånger mer, än Linkerd.

Sidecar proxy

Sedan kontrollerade vi proxy-användningen. Här bör det finnas ett linjärt beroende av antalet förfrågningar, men för varje sidecar finns det vissa overhead-kostnader som påverkar kurvan.

Linkerd: ~100 miljarder för irs-client, ~50 miljarder för irs-client-loadgen

Resultaten verkar logiska, eftersom client-proxyn får dubbel så mycket trafik som loadgen-proxyn: för varje utgående begäran från loadgen finns det en ingående och en utgående begäran mot client.

Istio/Envoy: ~155 miljarder för irs-client, ~75 miljarder för irs-client-loadgen

Vi ser liknande resultat för Istio sidecar:er.

Men generellt sett konsumerar Istio/Envoy-proxyn ungefär 50% fler processorresurser, än Linkerd.

Samma mönster ser vi på serversidan:

Linkerd: ~50 miljarder för irs-server

Istio/Envoy: ~80 miljarder för irs-server

På serversidan konsumerar Istio/Envoy sidecar ungefär 60% fler processorresurser, än Linkerd.

Slutsats

Istio Envoy-proxyn konsumerar över 50% mer CPU än Linkerd, på vår simulerade arbetsbelastning. Linkerd kontrollpanelen konsumerar mycket mindre resurser än Istio, särskilt när det kommer till kärnkomponenterna.

Vi funderar fortfarande på hur vi kan minska dessa kostnader. Har du några idéer, dela gärna med dig!

Källa: habr.com