Introducere
Noi suntem in a început să implementeze Istio ca o plasă de servicii. În principiu, totul este bine, cu excepția unui singur lucru: este scump.
В pentru Istio spune:
Cu Istio 1.1, proxy-ul consumă aproximativ 0,6 vCPU (nuclee virtuale) la 1000 de solicitări pe secundă.
Pentru prima regiune din rețeaua de servicii (2 proxy-uri pe fiecare parte a conexiunii), vom avea 1200 de nuclee doar pentru proxy, la o rată de un milion de solicitări pe secundă. Conform calculatorului de costuri de la Google, se pare că este de aproximativ 40 USD/lună/core pentru configurare n1-standard-64, adică doar această regiune ne va costa mai mult de 50 de mii de dolari pe lună pentru 1 milion de cereri pe secundă.
Ivan Sim () rețeaua de serviciu a întârziat anul trecut și a promis același lucru pentru memorie și procesor, dar nu a funcționat:
Aparent, values-istio-test.yaml va crește serios cererile CPU. Dacă mi-am făcut calculele corect, aveți nevoie de aproximativ 24 de nuclee CPU pentru panoul de control și 0,5 CPU pentru fiecare proxy. Nu am atât de multe. Voi repeta testele când îmi vor fi alocate mai multe resurse.
Am vrut să văd personal cât de asemănătoare este performanța Istio cu o altă rețea de servicii open source: .
Service instalare ochiuri
În primul rând, l-am instalat într-un cluster :
$ 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!Am folosit SuperGloo pentru că face bootstrapping-ul rețelei de serviciu mult mai ușor. Nu a trebuit să fac mare lucru. Nu folosim SuperGloo în producție, dar este ideal pentru o astfel de sarcină. A trebuit să folosesc literalmente câteva comenzi pentru fiecare rețea de serviciu. Am folosit două grupuri pentru izolare - câte unul pentru Istio și Linkerd.
Experimentul a fost realizat pe Google Kubernetes Engine. Am folosit Kubernetes 1.12.7-gke.7 și un bazin de noduri n1-standard-4 cu scalare automată a nodurilor (minim 4, maxim 16).
Apoi am instalat ambele rețele de serviciu din linia de comandă.
Prima legătură:
$ 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 |
+---------+--------------+---------+---------------------------+Apoi 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 |
+---------+------------+---------+---------------------------+Bucla de accident a durat câteva minute, apoi panourile de control s-au stabilizat.
(Notă: SuperGloo acceptă doar Istio 1.0.x deocamdată. Am repetat experimentul cu Istio 1.1.3, dar nu am observat nicio diferență notabilă.)
Configurarea Istio Automatic Deployment
Pentru ca Istio să instaleze sidecarul Envoy, folosim injectorul sidecar − MutatingAdmissionWebhook. Nu vom vorbi despre asta în acest articol. Permiteți-mi doar să spun că acesta este un controler care monitorizează accesul tuturor podurilor noi și adaugă dinamic un sidecar și un initContainer, care este responsabil pentru sarcini iptables.
Noi, cei de la Shopify, am scris propriul nostru controler de acces pentru a implementa sidecar-uri, dar pentru acest benchmark am folosit controlerul care vine cu Istio. Controlerul injectează sidecar-uri în mod implicit când există o comandă rapidă în spațiul de nume 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 labeledConfigurarea implementării automate Linkerd
Pentru a configura încorporarea Linkerd sidecar, folosim adnotări (le-am adăugat manual prin 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: ActiveSimulator de toleranță la erori Istio
Am construit un simulator de toleranță la erori numit Istio pentru a experimenta traficul unic pentru Shopify. Aveam nevoie de un instrument pentru a crea o topologie personalizată care să reprezinte o anumită porțiune a graficului nostru de servicii, configurată dinamic pentru a modela sarcini de lucru specifice.
Infrastructura Shopify este supusă unei sarcini grele în timpul vânzărilor flash. În același timp, Shopify . Clienții mari avertizează uneori despre o vânzare flash planificată. Alții le conduc pe neașteptate pentru noi la orice oră din zi sau din noapte.
Ne-am dorit ca simulatorul nostru de reziliență să modeleze fluxuri de lucru care se potrivesc cu topologiile și sarcinile de lucru care au copleșit infrastructura Shopify în trecut. Scopul principal al utilizării unei rețele de servicii este că avem nevoie de fiabilitate și toleranță la erori la nivel de rețea și este important pentru noi ca rețeaua de servicii să facă față în mod eficient sarcinilor care au întrerupt anterior serviciile.
În centrul simulatorului de toleranță la erori este un nod de lucru, care acționează ca un nod de plasă de serviciu. Nodul de lucru poate fi configurat static la pornire sau dinamic printr-un API REST. Utilizăm configurația dinamică a nodurilor de lucru pentru a crea fluxuri de lucru sub formă de teste de regresie.
Iată un exemplu de astfel de proces:
- Lansăm 10 servere ca
barserviciu care returnează un răspuns200/OKdupă 100 ms. - Lansăm 10 clienți - fiecare trimite 100 de solicitări pe secundă către
bar. - La fiecare 10 secunde eliminăm 1 server și monitorizăm erorile
5xxasupra clientului.
La sfârșitul fluxului de lucru, examinăm jurnalele și valorile și verificăm dacă testul a trecut. În acest fel, aflăm despre performanța rețelei noastre de servicii și rulăm un test de regresie pentru a testa ipotezele noastre despre toleranța la erori.
(Notă: ne gândim la sursă deschisă pentru simulatorul de toleranță la erori Istio, dar nu suntem încă pregătiți să facem acest lucru.)
Simulator de toleranță la erori Istio pentru benchmarkul rețelei de service
Am configurat mai multe noduri de lucru ale simulatorului:
irs-client-loadgen: 3 replici care trimit 100 de cereri pe secundă perirs-client.irs-client: 3 replici care primesc cererea, așteaptă 100 ms și înaintează cererea cătreirs-server.irs-server: 3 replici care revin200/OKdupă 100 ms.
Cu această configurație, putem măsura un flux de trafic stabil între 9 puncte finale. Sidecar-uri înăuntru irs-client-loadgen и irs-server primi 100 de solicitări pe secundă și irs-client — 200 (la intrare și la ieșire).
Urmărim utilizarea resurselor prin intermediul pentru că nu avem un cluster Prometeu.
Constatări
Panouri de control
În primul rând, am examinat consumul procesorului.
Panou de control Linkerd ~22 millicore
Panou de control Istio: ~750 millicore
Panoul de control Istio utilizează aproximativ De 35 de ori mai multe resurse CPUdecât Linkerd. Desigur, totul este instalat implicit, iar istio-telemetria consumă o mulțime de resurse de procesor aici (poate fi dezactivat prin dezactivarea unor funcții). Dacă eliminăm această componentă, obținem totuși mai mult de 100 de milicore, adică De 4 ori mai multdecât Linkerd.
Proxy Sidecar
Apoi am testat utilizarea unui proxy. Ar trebui să existe o relație liniară cu numărul de solicitări, dar pentru fiecare sidecar există o suprasarcină care afectează curba.
Linkerd: ~100 milicore pentru irs-client, ~50 milicore pentru irs-client-loadgen
Rezultatele par logice, deoarece proxy-ul client primește de două ori mai mult trafic decât proxy-ul loadgen: pentru fiecare cerere de ieșire de la loadgen, clientul are o intrare și una care iese.
Istio/Envoy: ~155 milicore pentru irs-client, ~75 milicore pentru irs-client-loadgen
Vedem rezultate similare pentru sidecars Istio.
Dar, în general, proxy-urile Istio/Envoy consumă cu aproximativ 50% mai multe resurse CPUdecât Linkerd.
Vedem aceeași schemă pe partea de server:
Linkerd: ~50 millicore pentru serverul irs
Istio/Envoy: ~80 milicore pentru serverul irs
Pe partea de server, sidecar Istio/Envoy consumă cu aproximativ 60% mai multe resurse CPUdecât Linkerd.
Concluzie
Proxy-ul Istio Envoy consumă cu 50% mai mult procesor decât Linkerd pe volumul nostru de lucru simulat. Panoul de control Linkerd consumă mult mai puține resurse decât Istio, în special pentru componentele de bază.
Încă ne gândim cum să reducem aceste costuri. Dacă aveți idei, vă rugăm să împărtășiți!
Sursa: www.habr.com