{"id":34366,"date":"2019-10-31T21:57:56","date_gmt":"2019-10-31T18:57:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd\/"},"modified":"2019-10-31T21:57:56","modified_gmt":"2019-10-31T18:57:56","slug":"benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmark des CPU-Verbrauchs f\u00fcr Istio und Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmark<\/p>\n

<\/p>\n

Einf\u00fchrung<\/h2>\n

<\/p>\n

Bei Shopify<\/a><\/noindex> haben mit der Bereitstellung von Istio als Service Mesh begonnen. Im Grunde sind wir zufrieden, au\u00dfer in einer Hinsicht: es ist teuer<\/strong>.<\/p>\n

<\/p>\n

In ver\u00f6ffentlichten Benchmarks<\/a><\/noindex> f\u00fcr Istio wird gesagt:<\/p>\n

<\/p>\n

Mit Istio 1.1 verbraucht der Proxy etwa 0,6 vCPU (virtuelle Kerne) pro 1000 Anfragen pro Sekunde.<\/p><\/blockquote>\n

F\u00fcr die erste Region im Service Mesh (2 Proxys auf jeder Seite der Verbindung) werden wir 1200 Kerne nur f\u00fcr den Proxy ben\u00f6tigen, basierend auf einer Million Anfragen pro Sekunde. Laut dem Kostensch\u00e4tzer von Google kostet das etwa 40 $\/Monat\/Kern f\u00fcr die Konfiguration n1-standard-64<\/code>, was bedeutet, dass diese Region uns \u00fcber 50.000 Dollar pro Monat f\u00fcr 1 Million Anfragen pro Sekunde kosten wird.<\/p>\n

<\/p>\n

Ayven Sim (Ivan Sim<\/a><\/noindex>) hat anschaulich die<\/a><\/noindex> Latenzen des Service Mesh im letzten Jahr verglichen und dasselbe f\u00fcr Speicher und CPU versprochen, aber das hat nicht geklappt:<\/p>\n

<\/p>\n

Offensichtlich wird die values-istio-test.yaml die CPU-Anfragen erheblich erh\u00f6hen. Wenn ich alles richtig gerechnet habe, ben\u00f6tige ich etwa 24 CPU-Kerne f\u00fcr das Control Panel und 0,5 CPU f\u00fcr jeden Proxy. So viele habe ich nicht. Ich werde die Tests wiederholen, wenn mir mehr Ressourcen zugewiesen werden.<\/p><\/blockquote>\n

Ich wollte selbst sehen, wie vergleichbar die Leistungsdaten von Istio mit einem anderen Open-Source-Service-Mesh sind: Linkerd<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Installation von Service Mesh<\/h3>\n

<\/p>\n

Zuerst habe ich im Cluster SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstalliere SuperGloo Version 0.3.12\nverwende Chart-URI https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources erstellt\nserviceaccount\/supergloo erstellt\nserviceaccount\/discovery erstellt\nserviceaccount\/mesh-discovery erstellt\nclusterrole.rbac.authorization.k8s.io\/discovery erstellt\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery erstellt\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding erstellt\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding erstellt\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding erstellt\ndeployment.extensions\/supergloo erstellt\ndeployment.extensions\/discovery erstellt\ndeployment.extensions\/mesh-discovery erstellt\nInstallation erfolgreich!<\/code><\/pre>\n
<\/p>\n
Ich habe SuperGloo verwendet, da es die initiale Einrichtung von Service Mesh erheblich vereinfacht. Ich musste fast nichts tun. In der Produktion nutzen wir SuperGloo nicht, aber f\u00fcr diese Aufgabe ist es perfekt geeignet. Ich musste lediglich ein paar Befehle f\u00fcr jedes Service Mesh anwenden. Ich habe zwei Cluster zur Isolation verwendet \u2014 jeweils eines f\u00fcr Istio und Linkerd.<\/p>\n
<\/p>\n
Das Experiment fand auf Google Kubernetes Engine statt. Ich habe Kubernetes 1.12.7-gke.7<\/code> und einen Node-Pool n1-standard-4<\/code> mit automatischer Skalierung der Nodes (mindestens 4, maximal 16).<\/p>\n
<\/p>\n
Dann habe ich beide Service Mesh \u00fcber die Kommandozeile installiert.<\/p>\n
<\/p>\n
Zuerst Linkerd:<\/p>\n
<\/p>\n
$ supergloo install linkerd --name linkerd\n+---------+--------------+---------+---------------------------+\n| INSTALL |     TYPE     | STATUS  |          DETAILS          |\n+---------+--------------+---------+---------------------------+\n| linkerd | Linkerd Mesh | Ausstehend | aktiviert: true             |\n|         |              |         | version: stable-2.3.0     |\n|         |              |         | namespace: linkerd        |\n|         |              |         | mtls aktiviert: true        |\n|         |              |         | automatische Injektion aktiviert: true |\n+---------+--------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Dann Istio:<\/p>\n
<\/p>\n
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true\n+---------+------------+---------+---------------------------+\n| INSTALL |    TYPE    | STATUS  |          DETAILS          |\n+---------+------------+---------+---------------------------+\n| istio   | Istio Mesh | Ausstehend | aktiviert: true             |\n|         |            |         | version: 1.0.6            |\n|         |            |         | namespace: istio-system   |\n|         |            |         | mtls aktiviert: true        |\n|         |            |         | automatische Injektion aktiviert: true |\n|         |            |         | grafana aktiviert: true     |\n|         |            |         | prometheus aktiviert: true  |\n|         |            |         | jaeger aktiviert: true      |\n+---------+------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Der Crash-Loop dauerte einige Minuten, und danach stabilisierten sich die Panels.<\/p>\n
<\/p>\n
(Hinweis: SuperGloo unterst\u00fctzt derzeit nur Istio 1.0.x. Ich habe das Experiment mit Istio 1.1.3 wiederholt, aber keinen sp\u00fcrbaren Unterschied bemerkt.)<\/em><\/p>\n
<\/p>\n
Einrichtung der automatischen Injektion f\u00fcr Istio<\/h3>\n
<\/p>\n
Um Istio zur Installation des Envoy-Sidecars zu bringen, verwenden wir den Sidecar-Injector \u2014 MutatingAdmissionWebhook<\/code>. Dar\u00fcber werden wir in diesem Artikel nicht sprechen. Ich m\u00f6chte nur erw\u00e4hnen, dass dies ein Controller ist, der den Zugriff auf alle neuen Pods \u00fcberwacht und dynamisch Sidecars und InitContainer hinzuf\u00fcgt, die f\u00fcr bestimmte Aufgaben verantwortlich sind. iptables<\/code>.<\/p>\n
<\/p>\n
Bei Shopify haben wir unseren eigenen Zugriffscontroller f\u00fcr die Einf\u00fchrung von Sidecars geschrieben, aber in diesem Benchmark habe ich den Controller verwendet, der mit Istio geliefert wird. Der Standard-Controller implementiert Sidecars, wenn im Namensraum ein Label vorhanden ist, istio-injection: enabled<\/code>:<\/p>\n
<\/p>\n
$ kubectl label namespace irs-client-dev istio-injection=enabled\nnamespace\/irs-client-dev gelabelt\n\n$ kubectl label namespace irs-server-dev istio-injection=enabled\nnamespace\/irs-server-dev gelabelt<\/code><\/pre>\n
<\/p>\n
Einrichtung der automatischen Einf\u00fchrung von Linkerd<\/h3>\n
<\/p>\n
Um die Einf\u00fchrung von Linkerd-Sidecars einzurichten, verwenden wir Annotations (ich habe sie manuell \u00fcber kubectl edit<\/code>):<\/p>\n
<\/p>\n
metadata:\n  annotations:\n    linkerd.io\/inject: enabled<\/code><\/pre>\n
<\/p>\n
$ k edit ns irs-server-dev \nnamespace\/irs-server-dev bearbeitet\n\n$ k get ns irs-server-dev -o yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  annotations:\n    linkerd.io\/inject: enabled\n  name: irs-server-dev\nspec:\n  finalizers:\n  - kubernetes\nstatus:\n  phase: Active<\/code><\/pre>\n
<\/p>\n
Istio-Fehlertoleranz-Simulator<\/h3>\n
<\/p>\n
Wir haben einen Istio-Ausfallsimulations-Simulator entwickelt, um mit dem f\u00fcr Shopify typischen Traffic zu experimentieren. Wir ben\u00f6tigten ein Werkzeug, um beliebige Topologien zu erstellen, die einen bestimmten Teil des Graphen unseres Services mit dynamischen Einstellungen abbilden, um spezifische Arbeitslasten zu simulieren.<\/p>\n
<\/p>\n
Die Infrastruktur von Shopify steht w\u00e4hrend Flash-Sales unter hoher Belastung. Dar\u00fcber hinaus empfiehlt Shopify den Verk\u00e4ufern, solche Verk\u00e4ufe h\u00e4ufiger durchzuf\u00fchren. Gro\u00dfe Kunden k\u00fcndigen manchmal geplante Flash-Sales an. Andere f\u00fchren sie unerwartet zu jeder Tages- und Nachtzeit durch.<\/a><\/noindex>Wir wollten, dass unser Ausfallsimulations-Simulator die Arbeitsabl\u00e4ufe modelliert, die den Topologien und Arbeitslasten entsprechen, die in der Vergangenheit zu \u00dcberlastungen der Shopify-Infrastruktur gef\u00fchrt haben. Das Hauptziel bei der Verwendung eines Service Mesh ist, dass wir Zuverl\u00e4ssigkeit und Ausfallsicherheit auf Netzwerkebene ben\u00f6tigen, und es ist wichtig, dass das Service Mesh effektiv mit den Lasten umgeht, die zuvor die Funktionalit\u00e4t der Services beeintr\u00e4chtigt haben.<\/p>\n
<\/p>\n
Wir wollten, dass unser Ausfallsimulations-Simulator die Arbeitsabl\u00e4ufe modelliert, die den Topologien und Arbeitslasten entsprechen, die in der Vergangenheit zu \u00dcberlastungen der Shopify-Infrastruktur gef\u00fchrt haben. Das Hauptziel bei der Verwendung eines Service Mesh ist, dass wir Zuverl\u00e4ssigkeit und Ausfallsicherheit auf Netzwerkebene ben\u00f6tigen, und es ist wichtig, dass das Service Mesh effektiv mit den Lasten umgeht, die zuvor die Funktionalit\u00e4t der Services beeintr\u00e4chtigt haben.<\/p>\n
<\/p>\n
Der Kern des Ausfallsimulationssystems ist ein Arbeitsknoten, der als Knoten im Service Mesh fungiert. Der Arbeitsknoten kann statisch beim Start konfiguriert oder dynamisch \u00fcber die REST-API eingestellt werden. Wir verwenden die dynamische Konfiguration von Arbeitsknoten, um Workflows in Form von Regressionstests zu erstellen.<\/p>\n
<\/p>\n
Hier ist ein Beispiel f\u00fcr einen solchen Prozess:<\/p>\n
<\/p>\n