Einführung
Wir sind begann mit der Bereitstellung von Istio als Service Mesh. Im Prinzip ist alles in Ordnung, bis auf eines: ist es teuer.
В für Istio heißt es:
Mit Istio 1.1 verbraucht der Proxy etwa 0,6 vCPUs (virtuelle Kerne) pro 1000 Anfragen pro Sekunde.
Für die erste Region im Service Mesh (zwei Proxys auf jeder Seite der Verbindung) werden wir 2 Kerne allein für den Proxy haben, bei einer Rate von einer Million Anfragen pro Sekunde. Laut dem Kostenrechner von Google belaufen sich die Kosten für die Konfiguration auf etwa 1200 US-Dollar/Monat/Kern n1-standard-64Das heißt, allein diese Region wird uns mehr als 50 Dollar pro Monat für 1 Million Anfragen pro Sekunde kosten.
Ivan Sim () Service-Mesh-Verzögerungen im letzten Jahr und versprochen dasselbe für Speicher und Prozessor, aber es hat nicht geklappt:
Anscheinend wird „values-istio-test.yaml“ die CPU-Anforderungen erheblich erhöhen. Wenn ich richtig nachgerechnet habe, benötigen Sie etwa 24 CPU-Kerne für das Control Panel und 0,5 CPU für jeden Proxy. Ich habe nicht so viel. Ich werde die Tests wiederholen, wenn mir mehr Ressourcen zugewiesen werden.
Ich wollte selbst sehen, wie ähnlich die Leistung von Istio einem anderen Open-Source-Service-Mesh ist: .
Service-Mesh-Installation
Zuerst habe ich es in einem Cluster installiert :
$ 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!Ich habe SuperGloo verwendet, weil es das Bootstrapping des Service Mesh viel einfacher macht. Ich musste nicht viel tun. Wir verwenden SuperGloo nicht in der Produktion, aber es ist ideal für eine solche Aufgabe. Ich musste buchstäblich ein paar Befehle für jedes Service-Mesh verwenden. Ich habe zwei Cluster zur Isolierung verwendet – jeweils einen für Istio und Linkerd.
Das Experiment wurde auf Google Kubernetes Engine durchgeführt. Ich habe Kubernetes verwendet 1.12.7-gke.7 und ein Pool von Knoten n1-standard-4 mit automatischer Knotenskalierung (mindestens 4, höchstens 16).
Dann habe ich beide Service-Meshs über die Befehlszeile installiert.
Erster Link:
$ 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 |
+---------+------------+---------+---------------------------+Die Absturzschleife dauerte ein paar Minuten, dann stabilisierten sich die Kontrolltafeln.
(Hinweis: SuperGloo unterstützt derzeit nur Istio 1.0.x. Ich habe das Experiment mit Istio 1.1.3 wiederholt, konnte aber keinen merklichen Unterschied feststellen.)
Einrichten der automatischen Istio-Bereitstellung
Damit Istio den Sidecar Envoy installiert, verwenden wir den Sidecar-Injektor − MutatingAdmissionWebhook. Wir werden in diesem Artikel nicht darüber sprechen. Lassen Sie mich nur sagen, dass dies ein Controller ist, der den Zugriff aller neuen Pods überwacht und dynamisch einen Sidecar und einen InitContainer hinzufügt, der für Aufgaben verantwortlich ist iptables.
Wir bei Shopify haben unseren eigenen Zugriffscontroller geschrieben, um Sidecars zu implementieren, aber für diesen Benchmark habe ich den Controller verwendet, der mit Istio geliefert wird. Der Controller fügt standardmäßig Sidecars ein, wenn im Namespace eine Verknüpfung vorhanden ist 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 labeledEinrichten der automatischen Linker-Bereitstellung
Um die Linkerd-Sidecar-Einbettung einzurichten, verwenden wir Anmerkungen (ich habe sie manuell über hinzugefügt). 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-Fehlertoleranzsimulator
Wir haben einen Fehlertoleranzsimulator namens Istio entwickelt, um mit dem für Shopify einzigartigen Traffic zu experimentieren. Wir brauchten ein Tool zum Erstellen einer benutzerdefinierten Topologie, die einen bestimmten Teil unseres Servicediagramms darstellt und dynamisch konfiguriert wird, um bestimmte Arbeitslasten zu modellieren.
Die Infrastruktur von Shopify ist während Flash-Sales stark ausgelastet. Gleichzeitig Shopify . Großkunden warnen manchmal vor einem geplanten Flash-Sale. Andere führen sie zu jeder Tages- und Nachtzeit unerwartet für uns durch.
Wir wollten, dass unser Ausfallsicherheitssimulator Arbeitsabläufe modelliert, die den Topologien und Arbeitslasten entsprechen, die in der Vergangenheit die Infrastruktur von Shopify überfordert haben. Der Hauptzweck der Verwendung eines Service Mesh besteht darin, dass wir Zuverlässigkeit und Fehlertoleranz auf Netzwerkebene benötigen und es für uns wichtig ist, dass das Service Mesh die Lasten, die zuvor Dienste unterbrochen haben, effektiv bewältigt.
Das Herzstück des Fehlertoleranzsimulators ist ein Worker-Knoten, der als Service-Mesh-Knoten fungiert. Der Worker-Knoten kann statisch beim Start oder dynamisch über eine REST-API konfiguriert werden. Wir nutzen die dynamische Konfiguration von Worker-Knoten, um Workflows 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 Fehler
5xxauf dem Client.
Am Ende des Workflows untersuchen wir die Protokolle und Metriken und prüfen, ob der Test bestanden wurde. Auf diese Weise erfahren wir mehr über die Leistung unseres Service Mesh und führen einen Regressionstest durch, um unsere Annahmen zur Fehlertoleranz zu testen.
(Hinweis: Wir denken darüber nach, den Istio-Fehlertoleranzsimulator als Open Source bereitzustellen, sind aber noch nicht dazu bereit.)
Istio-Fehlertoleranzsimulator für Service-Mesh-Benchmark
Wir haben mehrere Arbeitsknoten des Simulators eingerichtet:
irs-client-loadgen: 3 Replikate, die 100 Anfragen pro Sekunde sendenirs-client.irs-client: 3 Replikate, die die Anfrage empfangen, 100 ms warten und die Anfrage weiterleitenirs-server.irs-server: 3 Replikate, die zurückkehren200/OKnach 100 ms.
Mit dieser Konfiguration können wir einen stabilen Verkehrsfluss zwischen 9 Endpunkten messen. Beiwagen rein irs-client-loadgen и irs-server 100 Anfragen pro Sekunde erhalten und irs-client — 200 (eingehend und ausgehend).
Wir verfolgen die Ressourcennutzung durch weil wir keinen Prometheus-Cluster haben.
Ergebnisse
Systemsteuerung
Zuerst haben wir den CPU-Verbrauch untersucht.
Linkerd-Bedienfeld ~22 Millicore
Istio-Bedienfeld: ~750 Millicore
Das Istio-Bedienfeld verbraucht ca 35-mal mehr CPU-Ressourcenals Linkerd. Natürlich ist alles standardmäßig installiert und istio-telemetry verbraucht hier viele Prozessorressourcen (es kann durch Deaktivieren einiger Funktionen deaktiviert werden). Wenn wir diese Komponente entfernen, erhalten wir immer noch mehr als 100 Millicores 4 mal mehrals Linkerd.
Sidecar-Proxy
Anschließend haben wir den Einsatz eines Proxys getestet. Es sollte eine lineare Beziehung zur Anzahl der Anfragen bestehen, aber für jeden Sidecar gibt es einen gewissen Overhead, der sich auf die Kurve auswirkt.
Linkerd: ~100 Millicores für irs-client, ~50 Millicores für irs-client-loadgen
Die Ergebnisse sehen logisch aus, da der Client-Proxy doppelt so viel Datenverkehr empfängt wie der Loadgen-Proxy: Für jede ausgehende Anfrage von Loadgen hat der Client eine eingehende und eine ausgehende.
Istio/Envoy: ~155 Millicores für irs-client, ~75 Millicores für irs-client-loadgen
Wir sehen ähnliche Ergebnisse für Istio-Beiwagen.
Aber im Allgemeinen verbrauchen Istio/Envoy-Proxys ca. 50 % mehr CPU-Ressourcenals Linkerd.
Wir sehen das gleiche Schema auf der Serverseite:
Link: ~50 Millicore für IRS-Server
Istio/Envoy: ~80 Millicore für IRS-Server
Auf der Serverseite wird Sidecar von Istio/Envoy genutzt ca. 60 % mehr CPU-Ressourcenals Linkerd.
Abschluss
Der Istio Envoy-Proxy verbraucht bei unserer simulierten Arbeitslast 50+ % mehr CPU als Linkerd. Das Linkerd-Kontrollfeld verbraucht deutlich weniger Ressourcen als Istio, insbesondere für die Kernkomponenten.
Wir denken immer noch darüber nach, wie wir diese Kosten senken können. Wenn Sie Ideen haben, teilen Sie diese bitte mit!
Source: habr.com