Aféierung
Mir sinn an ugefaang Istio als Service Mesh z'installéieren. Am Prinzip ass alles gutt, ausser eng Saach: et ass deier.
В fir Istio seet et:
Mat Istio 1.1 verbraucht de Proxy ongeféier 0,6 vCPUs (virtuell Kären) pro 1000 Ufroen pro Sekonn.
Fir déi éischt Regioun am Service Mesh (2 Proxyen op all Säit vun der Verbindung) wäerte mir 1200 Cores just fir de Proxy hunn, mat engem Taux vun enger Millioun Ufroen pro Sekonn. Geméiss dem Google Käschterechner funktionnéiert et ongeféier $ 40 / Mount / Kär fir Konfiguratioun n1-standard-64, dat ass, dës Regioun eleng wäert eis méi wéi 50 dausend Dollar pro Mount fir 1 Millioun Demanden pro Sekonn kaschten.
Ivan Sim () Service Mesh Verspéidungen d'lescht Joer a versprach datselwecht fir Erënnerung a Prozessor, awer et huet net geschafft:
Scheinbar wäert values-istio-test.yaml eescht CPU Demanden Erhéijung. Wann ech meng Mathematik richteg gemaach hunn, braucht Dir ongeféier 24 CPU Cores fir d'Kontrollpanel an 0,5 CPU fir all Proxy. Ech hunn net sou vill. Ech wäert d'Tester widderhuelen wann méi Ressourcen mir zougewisen ginn.
Ech wollt selwer kucken wéi d'Istio Leeschtung ähnlech ass mat engem aneren Open Source Service Mesh: .
Service Mesh gemaach Installatioun
Als éischt hunn ech et an engem Cluster installéiert :
$ 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!Ech hunn SuperGloo benotzt well et de Service Mesh bootstrapping vill méi einfach mécht. Ech hat net vill ze maachen. Mir benotzen SuperGloo net an der Produktioun, awer et ass ideal fir sou eng Aufgab. Ech hu wuertwiertlech e puer Kommandoe fir all Service Mesh ze benotzen. Ech hunn zwee Cluster fir Isolatioun benotzt - all eenzel fir Istio a Linkerd.
D'Experiment gouf op Google Kubernetes Engine duerchgefouert. Ech hunn Kubernetes benotzt 1.12.7-gke.7 an e Pool vu Wirbelen n1-standard-4 mat automatesch Node Skala (Minimum 4, maximal 16).
Duerno hunn ech béid Service Meshes vun der Kommandozeil installéiert.
Éischt verlinkt:
$ 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 |
+---------+--------------+---------+---------------------------+Dann 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 huet e puer Minutten gedauert, an dunn hunn d'Kontrollpanele stabiliséiert.
(Note: SuperGloo ënnerstëtzt nëmmen Istio 1.0.x fir de Moment. Ech hunn d'Experiment mat Istio 1.1.3 widderholl, awer hu kee merkbare Ënnerscheed gemierkt.)
Astellung Istio Automatesch Deployment
Fir Istio den Sidecar Envoy z'installéieren, benotze mir de Sidecar Injector - MutatingAdmissionWebhook. Mir wäerten net doriwwer an dësem Artikel schwätzen. Loosst mech just soen datt dëst e Controller ass deen den Zougang vun all neie Pods iwwerwaacht an dynamesch e Sidecar an initContainer bäidréit, dee fir Aufgaben verantwortlech ass iptables.
Mir bei Shopify hunn eisen eegenen Zougangscontroller geschriwwen fir Sidecars ëmzesetzen, awer fir dëse Benchmark hunn ech de Controller benotzt deen mat Istio kënnt. De Controller sprëtzt Sidecars par défaut wann et eng Ofkiirzung am Nummraum gëtt 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 labeledAutomatesch Linkerd Deployment opsetzen
Fir Linkerd Sidecar Embedding opzestellen, benotze mir Annotatiounen (ech hunn se manuell bäigefüügt 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 Feeler Toleranz Simulator
Mir hunn e Feelertoleranzsimulator mam Numm Istio gebaut fir mam Verkéier eenzegaarteg zu Shopify ze experimentéieren. Mir brauche en Tool fir eng personaliséiert Topologie ze kreéieren déi e spezifeschen Deel vun eiser Servicegrafik duerstellt, dynamesch konfiguréiert fir spezifesch Aarbechtsbelaaschtungen ze modelléieren.
Shopify d'Infrastruktur ass ënner schwéier Laascht wärend Flash Verkaf. Zur selwechter Zäit Shopify . Grouss Clientë warnen heiansdo iwwer e geplangte Flashverkaaf. Anerer féieren se onerwaart fir eis zu all Moment vum Dag oder Nuecht.
Mir wollten eise Widderstandssimulator Workflows modelléieren déi mat den Topologien an Aarbechtsbelaaschtunge passen déi Shopify seng Infrastruktur an der Vergaangenheet iwwerwältegt hunn. Den Haaptzweck fir e Service Mesh ze benotzen ass datt mir Zouverlässegkeet a Fehltoleranz um Netzwierkniveau brauchen, an et ass wichteg fir eis datt de Service Mesh effektiv mat Lasten këmmert déi virdru Servicer gestéiert hunn.
Am Häerz vum Feeler Toleranz Simulator ass en Aarbechter Node, deen als Service Mesh Node wierkt. Den Aarbechter Node kann statesch beim Startup oder dynamesch iwwer eng REST API konfiguréiert ginn. Mir benotzen dynamesch Konfiguratioun vun Aarbechternoden fir Workflows a Form vu Regressiounstester ze kreéieren.
Hei ass e Beispill vun esou engem Prozess:
- Mir starten 10 Serveren als
barService deen eng Äntwert zréckkënnt200/OKnach 100 ms. - Mir starten 10 Clienten - all schéckt 100 Demanden pro Sekonn un
bar. - All 10 Sekonnen ewechhuelen mir 1 Server a Monitor Feeler
5xxop de Client.
Um Enn vum Workflow ënnersicht mir d'Logbicher a Metriken a kontrolléieren ob den Test passéiert ass. Dëst ass wéi mir iwwer d'Leeschtung vun eisem Service Mesh léieren a lafen e Regressiounstest fir eis Viraussetzungen iwwer Feelertoleranz ze testen.
(Notiz: Mir denken drun den Istio Feeler Toleranz Simulator oppen ze kréien, awer si sinn nach net prett dat ze maachen.)
Istio Feeler Toleranz Simulator fir Service Mesh Benchmark
Mir setzen e puer Aarbechtsknoten vum Simulator op:
irs-client-loadgen: 3 replicas datt schécken 100 Demanden pro zweet proirs-client.irs-client: 3 Repliken déi d'Ufro kréien, waart 100ms a weiderginn d'Ufro unirs-server.irs-server: 3 replica datt zréck200/OKnach 100 ms.
Mat dëser Konfiguratioun kënne mir e stabile Verkéiersfloss tëscht 9 Endpunkte moossen. Sidecars an irs-client-loadgen и irs-server kréien 100 Demanden pro zweet, an irs-client - 200 (Entrée an eraus).
Mir verfollegen d'Ressourceverbrauch duerch well mir kee Prometheus-Cluster hunn.
Resultater
Kontrollpanelen
Als éischt hu mir den CPU Konsum iwwerpréift.
Linkerd Kontrollpanel ~ 22 Millicore
Istio Kontrollpanel: ~750 millicore
D'Istio Kontrollpanel benotzt ongeféier 35 Mol méi CPU Ressourcenwéi Linkerd. Natierlech gëtt alles par défaut installéiert, an d'Istio-Telemetrie verbraucht hei vill Prozessorressourcen (et kann ausgeschalt ginn andeems e puer Funktiounen auszeschalten). Wa mir dës Komponent ewechhuelen, kréie mir nach ëmmer méi wéi 100 Millicores, dat ass 4 Mol méiwéi Linkerd.
Sidecar Proxy
Mir hunn dunn d'Benotzung vun engem Proxy getest. Et soll eng linear Relatioun mat der Zuel vun Ufroen ginn, mä fir all sidecar do ass e puer overhead datt d'Kurve beaflosst.
Linkerd: ~100 millicores fir irs-Client, ~50 millicores fir irs-client-loadgen
D'Resultater kucken logesch aus, well de Client Proxy duebel sou vill Traffic kritt wéi de Loadgen Proxy: fir all erausginn Ufro vum Loadgen huet de Client een erakommen an een erausginn.
Istio / Envoy: ~155 millicores fir irs-Client, ~75 millicores fir irs-client-loadgen
Mir gesinn ähnlech Resultater fir Istio Sidecars.
Mä am Allgemengen, Istio / Envoy Proxy verbrauchen ongeféier 50% méi CPU Ressourcenwéi Linkerd.
Mir gesinn datselwecht Schema op der Server Säit:
Linkerd: ~50 millicore fir irs-Server
Istio / Envoy: ~80 millicore fir irs-Server
Pa Server Säit verbraucht sidecar Istio / Envoy ongeféier 60% méi CPU Ressourcenwéi Linkerd.
Konklusioun
Den Istio Envoy Proxy verbraucht 50+% méi CPU wéi Linkerd op eiser simuléierter Aarbechtslaascht. De Linkerd Kontrollpanel verbraucht vill manner Ressourcen wéi Istio, besonnesch fir d'Kärkomponenten.
Mir denken nach ëmmer drun, wéi mir dës Käschten erofsetzen. Wann Dir Iddien hutt, deelt w.e.g.!
Source: will.com