Die solide Leistung von verwalteten Kubernetes-Plattformen wird im Allgemeinen als selbstverständlich angesehen und wird kaum jemals in Frage gestellt. Allerdings könnte es Unterschiede in der Performance von Containern auf verschiedenen beliebten verwalteten Kubernetes-Plattformen geben. Ich wollte einen genaueren Blick darauf werfen und habe die beiden beliebtesten Kubernetes-Dienste ausgewählt, die wir bei Blueshoe für unsere Kunden nutzen: Amazon Elastic Kubernetes Service (EKS) und Google Kubernetes Engine (GKE).

EKS vs. GKE – und warum ist das wichtig?

Laut dieser Statistik von Februar 2020 haben 540 Befragte auf die Frage "Welche der folgenden Container-Orchestratoren verwenden Sie?" geantwortet:

Bitte beachte, dass die Auswahl mehrerer Antworten möglich war, daher sind die Gruppen nicht exklusiv. Die Zahlen haben sich wahrscheinlich seitdem etwas geändert, aber es ist offensichtlich, dass diese beiden sehr beliebte Optionen in der Welt des verwalteten Kubernetes sind. Die Zahlen entsprechen auch der Verteilung der von Blueshoe verwalteten Kubernetes-Plattformen bis heute.

Natürlich sollten wir die Analyse der Container-Runtime-Leistung mit diesen beiden Lösungen beginnen.

Aber warum?

Einerseits ist es einfach interessant festzustellen, wie diese beiden großen Player im Vergleich zueinander abschneiden. Auf der einen Seite hast du Amazon Web Services - den Riesen auf dem Markt der Hyperscaler. Und auf der anderen Seite gibt es Google - den Technologieriesen und Pionier von Kubernetes .

Aber noch wichtiger ist, dass es immer auf die Kosten ankommt. Wenn du bei vergleichbarem Preis 10% mehr Leistung bekommen kannst, möchten einige vielleicht die Portabilität von Kubernetes nutzen. Dabei geht es nicht um das Ökosystem oder potenziell angehängte Dienste (wie verwaltete Datenbanken oder Speicher), sondern um die reine Container-Runtime-Leistung. Ich wollte die Frage beantworten: "Mit welcher Geschwindigkeit läuft mein Code in einem ganz normalen Kubernetes-Cluster?". Und das ist, was ich gefunden habe:

Das Benchmark-Setup

Auf EKS habe ich einen Kubernetes-Cluster mit folgenden Spezifikationen erstellt:

Um diese Parameter so genau wie möglich anzupassen, habe ich einen Google Kubernetes Engine-Cluster mit folgenden Spezifikationen erstellt:

Beide Maschinentypen umfassen eine 4 vCPU-Maschine mit 16 GB RAM, basierend auf einem Intel-Prozessor. Der Kubernetes-Knoten, auf dem der Test ausgeführt wurde, war ausschließlich dem Test-Pod gewidmet und nur mit anderen "Standard"-Pods dieses verwalteten Kubernetes-Angebots gefüllt. Ich habe keine speziellen Konfigurationen verwendet, sondern einfach einen Cluster mit den voreingestellten Werten bestellt.

Wie man die Container-Runtime benchmarkt

Eines der Hauptziele bei der Durchführung einer Leistungsanalyse besteht darin, eine sehr einfache Reproduktion zu ermöglichen. Glücklicherweise sprechen wir über Kubernetes, was bedeutet, dass es nur eine Frage des Schreibens von Kubernetes-Konfigurationen und deren Anwendung auf den Cluster ist. Dennoch gibt es einige wichtige Dinge zu beachten:

Leider war es nicht gerade einfach, ein gutes Benchmark-Tool zu finden, das den Anforderungen entspricht, um die folgenden Teile zu benchmarken:

Ein recht häufig verwendetes Tool mit nur wenigen bekannten Schwächen ist sysbench. Mit etwa 5.000 Sternen auf GitHub und einer recht großen und aktiven Community könnte es für meine Anforderungen geeignet sein. Ein großer Pluspunkt ist die Erweiterbarkeit und die vielen integrierten komplexen Benchmark-Typen, wie z.B. Datenbank-Benchmarks usw.

Glücklicherweise hat jemand bei Severalnines bereits ein Container-Image für sysbench erstellt und es öffentlich zugänglich gemacht. Das Benchmark-Tool ist also einsatzbereit.

Um diesen Prozess zu vereinfachen und reproduzierbar zu machen, habe ich einen kleinen Test-Runner für sysbench gestartet. Dieses Tool plant das Benchmark im Cluster (mit einem Node-Selector), wartet auf den Abschluss des Jobs, analysiert das Ergebnis und erstellt eine Datei mit den Testergebnissen.

Ich habe den Code hier öffentlich gemacht. Er basiert auf Python und Poetry. Wenn du Poetry installiert hast, kannst du einfach 'poetry run benchmark' ausführen und es wird die Kapazität der CPU, des Arbeitsspeichers und des Dateisystems benchmarken.

Die Ergebnisse

Zusammenfassend lässt sich sagen, dass EKS in allen Metriken eine höhere Leistung bietet. Insbesondere die Datei-E/A-Leistung bei GKE ist ehrlich gesagt schlecht. Wir sprechen über 10% weniger Leistung bei der CPU, 9% weniger beim Arbeitsspeicher und eine große Lücke bei den Dateioperationen für einen Standard-Kubernetes-Cluster. Schauen wir uns die Ergebnisse genauer an.

CPU-Leistung

Der sysbench-Befehl zum Ausführen des CPU-Tests lautet: sysbench --test=cpu --time=60 run

Dieser Befehl führt den CPU-Benchmark eine Minute lang aus.

1) GKE vs. EKS: CPU-Ereignisse pro Sekunde

Sysbench erfasst die ausgeführten Schleifen (auch Ereignisse genannt) und berechnet alle Primzahlen bis zu einem bestimmten Parameter in einem bestimmten Zeitrahmen. Es zeigt an, wie viel CPU-Zeit dem Prozess gewährt wurde und wie schnell die Berechnung im Allgemeinen war.

Das Ergebnis zeigt einen schockierenden Unterschied von etwa 11% mehr Ereignissen auf EKS im Vergleich zu GKE. Da du für die Zeit deines Kubernetes-Knotens bezahlst, ist es entscheidend, dass in dieser Zeit möglichst viele Berechnungen durchgeführt werden.

2) GKE vs. EKS: CPU-Latenz

Sysbench erfasst die CPU-Latenz für ein angefordertes Ereignis. Es aggregiert die Ergebnisse und gibt die minimalen, maximalen, durchschnittlichen und 95. Perzentil-Werte zurück.

Wie du sehen kannst, ist die Leistung des containerd-basierten Runtimes von GKE nicht signifikant langsamer als der docker-basierte Runtime von EKS. Dennoch beträgt der Unterschied im 95. Perzentil etwa 2%. Dies kann auf die relativ kurze Laufzeit des Benchmarks und andere Faktoren zurückzuführen sein.

Speicherleistung

Der sysbench-Befehl zum Ausführen des Speichertests (RAM) lautet: sysbench --test=memory --memory-total-size=500G run

Dieser Befehl schreibt 500 Gigabyte in den Hauptspeicher und erfasst die Schreibgeschwindigkeit.

Auch hier ist GKE etwa 9% langsamer als der Container-Runtime von EKS, wenn es darum geht, viel in den Hauptspeicher zu schreiben. Auf einem EKS-Cluster kann dein Code potenziell mit 4,25 Gigabyte pro Sekunde in den RAM schreiben, während auf GKE dein Container nur mit 3,87 Gigabyte pro Sekunde schaufeln kann. Im Vergleich dazu läuft mein Laptop mit etwa 6,36 Gigabyte pro Sekunde. Daher ist keines der Ergebnisse überwältigend.

GKE vs EKS: Datei-E/A-Leistung

Die Ergebnisse zur Dateisystemleistung zeichnen ein besonders dramatisches Bild. Der sysbench-Befehl zum Ausführen des Dateitests lautet:

1) GKE vs EKS: Dateidurchsatz

Der Dateidurchsatz-Benchmark schreibt einfach eine Datei in das Dateisystem und liest eine künstliche Datei aus dem Dateisystem.

Die Schreib- und Leseleistung eines Containers, der auf EKS läuft, ist bei Lesevorgängen etwa 95% besser und bei Schreibvorgängen etwa 94% besser. Diese Metrik könnte relevant werden, wenn eine Anwendung Dateien aus dem temporären Speicher im Container schreibt und liest.

2) Datei-E/A-Latenz

Die Dateilatenz ist für beide Plattformen nahezu gleich. Persönlich würde ich der maximalen Latenz nicht allzu viel Bedeutung beimessen (diese kann von Lauf zu Lauf stark variieren), sondern eher das 95. Perzentil betrachten. Mit dieser Metrik übertrifft EKS GKE um eine Größenordnung.

3) Dateioperationen pro Sekunde

Die geringe Anzahl von Dateioperationen pro Sekunde auf GKE ist nur eine Folge der vorherigen Ergebnisse. Bitte beachte, dass diese Bewertungen zur Dateisystemleistung auf dem nativen Dateisystem des Containers ausgeführt werden. Es ist keine zusätzliche Storage Class an den Pod angehängt, auf dem der Benchmark läuft.

Abschließende Bemerkungen

Ich war etwas schockiert über die Ergebnisse nach dem Vergleich dieser beiden verwalteten Kubernetes-Plattformen und ihrer Container-Runtime-Leistung. Wie du sehen kannst, ist der Preis des GKE-Knotens in diesen Regionen etwa 22% niedriger als der entsprechende Preis bei AWS EKS. Das gleicht zumindest ein wenig den Unterschied in der Leistung aus, aber diese Fakten können die Entscheidung beeinflussen, wo eine containerisierte Workload in Zukunft platziert werden soll.

Beim Versuch, die Ergebnisse zu verstehen, stieß ich auf das Nitro-System von Amazon, eine Hardware-Technologie, die Amazon Web Service für ihre eigene Cloud-Computing-Plattform entwickelt hat. Sind diese Ergebnisse ein Beweis für die versprochenen Leistungsgewinne? Spielt der docker-basierte Container-Runtime von AWS dabei eine Rolle?

Bei Blueshoe arbeiten wir gerne mit der Google Cloud Platform, da wir sie im Allgemeinen als benutzerfreundlicher und übersichtlicher im Vergleich zur AWS-Konsole betrachten. Leistungsüberlegungen sind in der Tat sehr wichtig, aber es gibt auch andere wesentliche Kriterien bei der Auswahl eines verwalteten Kubernetes-Angebots. Bitte nimm diesen Benchmark auch mit einer Prise Salz, da es viele Konfigurationen gibt, die einen großen Einfluss auf die Gesamtsystemleistung haben können.

Fühle dich frei, folge mir auf LinkedIn oder trete unserem Discord bei.