Einführung
Wir bei wir haben mit der Bereitstellung von Istio als Service-Mesh begonnen. Im Prinzip sind wir mit allem zufrieden, außer mit einer Sache: es ist teuer.
Im für Istio wird gesagt:
Mit Istio 1.1 verbraucht der Proxy etwa 0,6 vCPU (virtuelle Kerne) pro 1000 Anfragen pro Sekunde.
Für die erste Region im Service-Mesh (mit 2 Proxys auf jeder Seite der Verbindung) benötigen wir 1200 Kerne nur für die Proxys, basierend auf einer Million Anfragen pro Sekunde. Laut Googles Kostenschätzer ergibt sich ein Preis von etwa 40 $/Monat/Kern für die Konfiguration n1-standard-64, das heißt, diese Region wird uns mehr als 50.000 Dollar pro Monat für 1 Million Anfragen pro Sekunde kosten.
Ivan Sim () Offenbar wird die values-istio-test.yaml die Prozessoranfragen erheblich erhöhen. Wenn ich alles richtig gerechnet habe, benötigt man etwa 24 Prozessorkerne für das Kontrollpanel und 0,5 CPU für jeden Proxy. So viele habe ich nicht. Ich werde die Tests wiederholen, wenn mir mehr Ressourcen zugewiesen werden.
Ich wollte selbst sehen, wie die Leistungen von Istio im Vergleich zu einem anderen Open-Source-Service-Mesh sind:
Installation des Service-Mesh .
Zuerst habe ich im Cluster installiert
$ supergloo init installiere supergloo version 0.3.12 verwende Chart-URI https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz configmap/sidecar-injection-resources erstellt serviceaccount/supergloo erstellt serviceaccount/discovery erstellt serviceaccount/mesh-discovery erstellt clusterrole.rbac.authorization.k8s.io/discovery erstellt clusterrole.rbac.authorization.k8s.io/mesh-discovery erstellt clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding erstellt clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding erstellt clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding erstellt deployment.extensions/supergloo erstellt deployment.extensions/discovery erstellt deployment.extensions/mesh-discovery erstellt Installation erfolgreich! :
Ich habe SuperGloo verwendet, weil es den Einstieg in das Service-Mesh erheblich vereinfacht. Ich musste fast nichts tun. In der Produktion verwenden wir SuperGloo nicht, aber für eine solche Aufgabe ist es perfekt geeignet. Ich musste buchstäblich nur ein paar Befehle für jedes Service-Mesh ausführen. Ich habe zwei Cluster zur Isolation verwendet – eines für Istio und eines für Linkerd.Das Experiment wurde auf Google Kubernetes Engine durchgeführt. Ich verwendete Kubernetes
1.12.7-gke.7 und ein Node-Pool n1-standard-4 mit automatischer Skalierung der Nodes (mindestens 4, maximal 16). Danach habe ich beide Service-Mesh über die Kommandozeile installiert.
Zuerst Linkerd:
Zuerst Linkerd:
$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Ausstehend | aktiviert: true |
| | | | version: stable-2.3.0 |
| | | | namespace: linkerd |
| | | | mtls aktiviert: true |
| | | | auto inject aktiviert: true |
+---------+--------------+---------+---------------------------+Dann Istio:
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+------------+---------+---------------------------+
| istio | Istio Mesh | Ausstehend | aktiviert: true |
| | | | version: 1.0.6 |
| | | | namespace: istio-system |
| | | | mtls aktiviert: true |
| | | | auto inject aktiviert: true |
| | | | grafana aktiviert: true |
| | | | prometheus aktiviert: true |
| | | | jaeger aktiviert: true |
+---------+------------+---------+---------------------------+Der Crash-Loop dauerte mehrere Minuten, und dann stabilisierten sich die Steuerungsfelder.
(Hinweis. SuperGloo unterstützt derzeit nur Istio 1.0.x. Ich habe das Experiment mit Istio 1.1.3 wiederholt, aber keinen spürbaren Unterschied festgestellt.)
Einrichtung der automatischen Injektion für Istio
Um Istio zu ermöglichen, den Envoy-Sidecar zu installieren, verwenden wir den Sidecar-Injektor — MutatingAdmissionWebhook. Wir werden hier nicht weiter darauf eingehen. Ich sage nur, dass es sich um einen Controller handelt, der den Zugriff auf alle neuen Pods überwacht und dynamisch einen Sidecar und einen InitContainer hinzufügt, der für die Aufgaben verantwortlich ist. iptables.
Wir bei Shopify haben unseren eigenen Zugriff-Controller für die Injektion von Sidecars geschrieben, aber in diesem Benchmark habe ich den Controller verwendet, der mit Istio geliefert wird. Der Standard-Controller injiziert Sidecars, wenn im Namespace ein Label vorhanden ist istio-injection: enabled:
$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev etikettiert
$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev etikettiertEinrichtung der automatischen Injektion für Linkerd
Um die Injektion von Sidecars für Linkerd einzurichten, verwenden wir Anmerkungen (ich habe sie manuell über kubectl edit):
metadata:
annotations:
linkerd.io/inject: enabled$ k edit ns irs-server-dev
namespace/irs-server-dev bearbeitet
$ 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: AktivSimulationsprogramm für Ausfallsicherheit von Istio
Wir haben einen Ausfallsicherheitssimulator für Istio entwickelt, um mit traffic-spezifischen Anfragen für Shopify zu experimentieren. Wir benötigten ein Werkzeug, um eine beliebige Topologie zu erstellen, die einen bestimmten Teil des Graphen unseres Dienstes mit dynamischen Konfigurationen repräsentiert, um spezifische Arbeitslasten zu modellieren.
Die Infrastruktur von Shopify wird während von Flash-Verkäufen stark belastet. Shopify empfiehlt, solche Verkäufe häufiger durchzuführen. Große Kunden kündigen manchmal geplante Flash-Verkäufe an. Andere führen sie unerwartet zu jeder Tages- und Nachtzeit durch.
Wir wollten, dass unser Ausfallsicherheitssimulator Arbeitsabläufe modelliert, die den Topologien und Arbeitslasten entsprechen, die in der Vergangenheit zu einer Überlastung der Infrastruktur von Shopify geführt haben. Das Hauptziel der Verwendung eines Service Mesh ist, dass wir Zuverlässigkeit und Ausfallsicherheit auf Netzwerkebene benötigen, und es ist wichtig, dass das Service Mesh effizient mit den Lasten umgeht, die in der Vergangenheit den Betrieb von Diensten gestört haben.
Im Mittelpunkt des Ausfallsicherheitssimulators steht ein Arbeitsknoten, der als Knoten des Service Mesh fungiert. Der Arbeitsknoten kann entweder statisch beim Start konfiguriert oder dynamisch über die REST-API eingerichtet werden. Wir verwenden die dynamische Konfiguration von Arbeitsknoten, um Arbeitsabläufe in Form von Regressionstests zu erstellen.
Hier ist ein Beispiel für einen solchen Prozess:
- Wir starten 10 Server als
barDienst, der eine Antwort zurückgibt200/OKnach 100 ms. - Wir starten 10 Clients – jeder sendet 100 Anfragen pro Sekunde an
bar. - Alle 10 Sekunden entfernen wir 1 Server und überwachen die Fehler
5xxauf dem Client.
Am Ende des Arbeitsablaufs analysieren wir die Protokolle und Metriken und überprüfen, ob der Test bestanden wurde. So erfahren wir mehr über die Leistung unseres Service Mesh und führen einen Regressionstest durch, um unsere Annahmen über die Ausfallsicherheit zu überprüfen.
(Hinweis: Wir ziehen in Betracht, den Quellcode des Ausfallsicherheitssimulators für Istio zu veröffentlichen, sind aber dazu noch nicht bereit.)
Ausfallsicherheitssimulator für Istio zur Bewertung des Service Mesh
Wir konfigurieren mehrere Arbeitsknoten des Simulators:
irs-client-loadgen: 3 Replikate, die jeweils 100 Anfragen pro Sekunde anirs-client.irs-client: 3 Replikate, die die Anfrage empfangen, 100 ms warten und die Anfrage anirs-server.irs-server: 3 Replikate, die zurückgeben200/OKnach 100 ms.
Mit dieser Konfiguration können wir einen stabilen Datenverkehrsfluss zwischen 9 Endpunkten messen. Die Sidecars erhalten irs-client-loadgen und irs-server 100 Anfragen pro Sekunde, während irs-client - 200 (eingehend und ausgehend).
Wir überwachen die Ressourcennutzung über , da wir keinen Prometheus-Cluster haben.
Ergebnisse
Verwaltungspanels
Zuerst haben wir den CPU-Verbrauch untersucht.
Linkerd-Dashboard ~22 Milliarden
Istio-Dashboard: ~750 Milliarden
Das Istio-Dashboard verbraucht ungefähr 35-mal mehr CPU-Ressourcen, als Linkerd. Natürlich ist alles standardmäßig eingestellt, und viele CPU-Ressourcen werden hier von istio-telemetry verbraucht (dies kann deaktiviert werden, indem man auf einige Funktionen verzichtet). Selbst wenn wir diese Komponente entfernen, bleiben es immer noch über 100 Milliarden, das heißt 4-mal mehr, als bei Linkerd.
Sidecar-Proxys
Dann haben wir die Proxy-Nutzung untersucht. Hier sollte es eine lineare Abhängigkeit von der Anzahl der Anfragen geben, aber für jedes Sidecar gibt es einige Overheads, die die Kurve beeinflussen.
Linkerd: ~100 Milliarden für irs-client, ~50 Milliarden für irs-client-loadgen
Die Ergebnisse erscheinen logisch, da der Client-Proxy doppelt so viel Verkehr erhält wie der Loadgen-Proxy: Auf jede ausgehende Anfrage von Loadgen entfällt eine eingehende und eine ausgehende Anfrage vom Client.
Istio/Envoy: ~155 Milliarden für irs-client, ~75 Milliarden für irs-client-loadgen
Wir sehen ähnliche Ergebnisse für die Istio-Sidecars.
Insgesamt verbrauchen die Proxys von Istio/Envoy ungefähr 50% mehr CPU-Ressourcen, als Linkerd.
Das gleiche Muster sehen wir auf der Serverseite:
Linkerd: ~50 Milliarden für irs-server
Istio/Envoy: ~80 Milliarden für irs-server
Auf der Serverseite verbraucht das Sidecar Istio/Envoy ungefähr 60% mehr CPU-Ressourcen, als Linkerd.
Fazit
Der Istio Envoy-Proxy verbraucht über 50% mehr CPU als Linkerd bei unserer simulierten Arbeitslast. Das Linkerd-Dashboard verbraucht deutlich weniger Ressourcen als Istio, insbesondere bei den Hauptkomponenten.
Wir denken immer noch darüber nach, wie wir diese Kosten senken können. Wenn Sie Ideen haben, teilen Sie sie mit uns!
Quelle: habr.com
