Das ist mein Update , das jetzt auf Kubernetes 1.14 mit der neuesten CNI-Version (Stand April 2019) läuft.
Zunächst möchte ich dem Cilium-Team danken: Die Jungs haben mir geholfen, die Skripte zur Metriküberwachung zu überprüfen und zu korrigieren.
Was sich seit November 2018 geändert hat
Folgendes hat sich seitdem geändert (falls Sie interessiert sind):
Flannel bleibt die schnellste und einfachste CNI-Schnittstelle, unterstützt jedoch immer noch keine Netzwerkrichtlinien und Verschlüsselung.
Romana wird nicht mehr unterstützt, daher haben wir es aus dem Benchmark entfernt.
WeaveNet unterstützt jetzt Netzwerkrichtlinien für Ingress und Egress! Aber die Produktivität ist zurückgegangen.
In Calico müssen Sie die maximale Paketgröße (MTU) noch manuell konfigurieren, um die beste Leistung zu erzielen. Calico bietet zwei Optionen zur Installation von CNI, sodass Sie auf ein separates ETCD-Repository verzichten können:
- Speichern des Status in der Kubernetes-API als Datenspeicher (Clustergröße < 50 Knoten);
- Speichern des Status in der Kubernetes-API als Datenspeicher mit einem Typha-Proxy, um die K8S-API zu entlasten (Clustergröße > 50 Knoten).
Calico hat Unterstützung angekündigt zusätzlich zu Istio für Sicherheit auf Anwendungsebene.
Cilium unterstützt jetzt Verschlüsselung! Cilium bietet Verschlüsselung mit IPSec-Tunneln und bietet eine Alternative zum verschlüsselten WeaveNet-Netzwerk. Aber WeaveNet ist mit aktivierter Verschlüsselung schneller als Cilium.
Dank des integrierten ETCD-Operators ist Cilium jetzt einfacher bereitzustellen.
Das Cilium-Team hat versucht, durch Reduzierung des Speicherverbrauchs und der CPU-Kosten etwas von seinem CNI zu sparen, aber seine Konkurrenten sind immer noch leichter.
Benchmark-Kontext
Der Benchmark wird auf drei nicht virtualisierten Supermicro-Servern mit einem 10-GB-Supermicro-Switch ausgeführt. Die Server werden über passive DAC-SFP+-Kabel direkt mit dem Switch verbunden und im selben VLAN mit Jumbo-Frames (MTU 9000) konfiguriert.
Kubernetes 1.14.0 installiert auf Ubuntu 18.04 LTS mit Docker 18.09.2 (die Standard-Docker-Version in dieser Version).
Um die Reproduzierbarkeit zu verbessern, haben wir uns entschieden, den Master immer auf dem ersten Knoten zu konfigurieren, den Serverteil des Benchmarks auf dem zweiten Server und den Clientteil auf dem dritten zu platzieren. Dazu verwenden wir NodeSelector in Kubernetes-Bereitstellungen.
Wir werden die Benchmark-Ergebnisse auf der folgenden Skala beschreiben:
Auswahl eines CNI für einen Benchmark
Dies ist nur ein Benchmark für CNI aus der Liste im Abschnitt Weitere Informationen finden Sie in der offiziellen Kubernetes-Dokumentation. Von den 9 CNIs nehmen wir nur 6: Wir schließen diejenigen aus, die schwierig zu installieren sind und/oder gemäß der Dokumentation nicht ohne Konfiguration funktionieren (Romana, Contiv-VPP und JuniperContrail/TungstenFabric).
Wir werden die folgenden CNIs vergleichen:
- Calico v3.6
- Canal v3.6 (im Wesentlichen Flannel für Netzwerke + Calico als Firewall)
- Cilium 1.4.2
- Flanell 0.11.0
- Kube-Router 0.2.5
- WeaveNet 2.5.1
Einstellung
Je einfacher die Installation des CNI ist, desto besser wird unser erster Eindruck sein. Alle CNIs aus dem Benchmark sind sehr einfach zu installieren (mit ein oder zwei Befehlen).
Wie bereits erwähnt, sind die Server und der Switch mit aktivierten Jumbo-Frames konfiguriert (wir haben die MTU auf 9000 eingestellt). Wir würden uns freuen, wenn CNI die MTU anhand der Konfiguration der Adapter automatisch ermitteln würde. Dies gelang jedoch nur Cilium und Flannel. Die übrigen CNIs haben auf GitHub Anfragen, die automatische MTU-Erkennung hinzuzufügen, aber wir werden sie manuell konfigurieren, indem wir die ConfigMap für Calico, Canal und Kube-Router ändern oder eine Umgebungsvariable für WeaveNet übergeben.
Was ist das Problem mit falscher MTU? Dieses Diagramm zeigt den Unterschied zwischen WeaveNet mit aktivierter Standard-MTU und Jumbo-Frames:
Wie wirkt sich MTU auf den Durchsatz aus?
Wir haben gesehen, wie wichtig die MTU für die Leistung ist. Sehen wir uns nun an, wie unsere CNIs sie automatisch ermitteln:
CNI erkennt MTU automatisch
Die Grafik zeigt, dass Sie die MTU für Calico, Canal, Kube-Router und WeaveNet für eine optimale Leistung konfigurieren müssen. Cilium und Flannel konnten die MTU ohne Einstellungen selbst korrekt ermitteln.
Sicherheit
Wir werden die CNI-Sicherheit in zwei Aspekten vergleichen: der Fähigkeit, übertragene Daten zu verschlüsseln und der Implementierung von Kubernetes-Netzwerkrichtlinien (basierend auf echten Tests, nicht auf Dokumentation).
Nur zwei CNIs verschlüsseln Daten: Cilium und WeaveNet. Verschlüsselung WeaveNet aktiviert, indem das Verschlüsselungskennwort als CNI-Umgebungsvariable festgelegt wird. IN WeaveNet beschreibt es kompliziert, aber alles ist einfach gemacht. Verschlüsselung Wimper konfiguriert durch Befehle, durch das Erstellen von Kubernetes-Geheimnissen und durch die Änderung des DaemonSets (etwas komplizierter als in WeaveNet, aber Cilium hat Schritt-für-Schritt-Anleitung). ).
Was die Umsetzung der Netzwerkpolitik angeht, ist ihnen das gelungen Calico, Canal, Cilium und WeaveNet, in dem Sie Ingress- und Egress-Regeln konfigurieren können. Für Kube-Router Es gibt Regeln nur für Ingress und Flanell Es gibt überhaupt keine Netzwerkrichtlinien.
Hier die Gesamtergebnisse:
Ergebnisse des Sicherheitsleistungs-Benchmarks
Leistung
Dieser Benchmark zeigt den durchschnittlichen Durchsatz über mindestens drei Durchläufe jedes Tests. Wir testen die Leistung von TCP und UDP (mit iperf3), echten Anwendungen wie HTTP (mit Nginx und Curl) oder FTP (mit vsftpd und Curl) und schließlich die Anwendungsleistung mit SCP-basierter Verschlüsselung (mit Client und Server OpenSSH).
Für alle Tests haben wir einen Bare-Metal-Benchmark (grüne Linie) durchgeführt, um die CNI-Leistung mit der nativen Netzwerkleistung zu vergleichen. Hier verwenden wir den gleichen Maßstab, aber in Farbe:
- Gelb = sehr gut
- Orange = gut
- Blau = mittelmäßig
- Rot = schlecht
Wir berücksichtigen keine falsch konfigurierten CNIs und zeigen nur Ergebnisse für CNIs mit der richtigen MTU an. (Hinweis: Cilium berechnet die MTU nicht korrekt, wenn Sie die Verschlüsselung aktivieren. Daher müssen Sie die MTU in Version 8900 manuell auf 1.4 reduzieren. Die nächste Version, 1.5, erledigt dies automatisch.)
Hier sind die Ergebnisse:
TCP-Leistung
Alle CNIs schnitten im TCP-Benchmark gut ab. CNI mit Verschlüsselung hinkt weit hinterher, da Verschlüsselung teuer ist.
UDP-Leistung
Auch hier geht es allen CNIs gut. CNI mit Verschlüsselung zeigte fast das gleiche Ergebnis. Cilium liegt etwas hinter der Konkurrenz, macht aber nur 2,3 % Bare-Metal aus, also ist das kein schlechtes Ergebnis. Vergessen Sie nicht, dass nur Cilium und Flannel die MTU selbst korrekt ermittelt haben, und dies sind ihre Ergebnisse ohne zusätzliche Konfiguration.
Wie wäre es mit einer echten Bewerbung? Wie Sie sehen, ist die Gesamtleistung für HTTP etwas geringer als für TCP. Selbst wenn Sie HTTP mit TCP verwenden, haben wir iperf3 im TCP-Benchmark konfiguriert, um einen langsamen Start zu vermeiden, der sich auf den HTTP-Benchmark auswirken würde. Hier haben alle einen guten Job gemacht. Der Kube-Router hat einen klaren Vorteil, aber WeaveNet schnitt nicht gut ab: etwa 20 % schlechter als Bare-Metal. Cilium und WeaveNet mit Verschlüsselung sehen wirklich traurig aus.
Bei FTP, einem anderen TCP-basierten Protokoll, variieren die Ergebnisse. Flannel und Kube-Router erledigen den Job, aber Calico, Canal und Cilium liegen etwas zurück und sind etwa 10 % langsamer als Bare-Metal. WeaveNet liegt bis zu 17 % zurück, aber verschlüsseltes WeaveNet liegt 40 % vor verschlüsseltem Cilium.
Mit SCP können wir sofort sehen, wie viel uns die SSH-Verschlüsselung kostet. Fast allen CNIs geht es gut, aber WeaveNet hinkt erneut hinterher. Cilium und WeaveNet mit Verschlüsselung sind aufgrund der doppelten Verschlüsselung (SSH + CNI) voraussichtlich die schlechtesten.
Hier ist eine Übersichtstabelle mit den Ergebnissen:
Ressourcenverbrauch
Vergleichen wir nun, wie CNI unter hoher Auslastung Ressourcen verbraucht (während der TCP-Übertragung, 10 Gbit/s). In Leistungstests vergleichen wir CNI mit Bare-Metal (grüne Linie). Für den Ressourcenverbrauch zeigen wir reines Kubernetes (lila Linie) ohne CNI und sehen, wie viele zusätzliche Ressourcen CNI verbraucht.
Beginnen wir mit der Erinnerung. Hier ist der Durchschnittswert für den RAM der Knoten (ohne Puffer und Cache) in MB während der Übertragung.
Speicherverbrauch
Flannel und Kube-Router zeigten hervorragende Ergebnisse – nur 50 MB. Calico und Canal haben jeweils 70. WeaveNet verbraucht deutlich mehr als die anderen – 130 MB und Cilium sogar 400.
Lassen Sie uns nun den CPU-Zeitverbrauch überprüfen. Bemerkenswert: Das Diagramm zeigt keine Prozentsätze, sondern ppm, d. h. 38 ppm für „blankes Eisen“ sind 3,8 %. Hier sind die Ergebnisse:
CPU-Verbrauch
Calico, Canal, Flannel und Kube-Router sind sehr CPU-effizient – nur 2 % mehr als Kubernetes ohne CNI. WeaveNet liegt mit zusätzlichen 5 % weit zurück, gefolgt von Cilium mit 7 %.
Hier ist eine Zusammenfassung des Ressourcenverbrauchs:
Ergebnisse
Tabelle mit allen Ergebnissen:
Allgemeine Benchmark-Ergebnisse
Abschluss
Im letzten Teil werde ich meine subjektive Meinung zu den Ergebnissen äußern. Denken Sie daran, dass dieser Benchmark nur den Durchsatz einer einzelnen Verbindung auf einem sehr kleinen Cluster (3 Knoten) testet. Dies gilt nicht für große Cluster (<50 Knoten) oder parallele Verbindungen.
Ich empfehle je nach Szenario die Verwendung der folgenden CNIs:
- Haben Sie in Ihrem Cluster Knoten mit wenigen Ressourcen (mehrere GB RAM, mehrere Kerne) und Sie benötigen keine Sicherheitsfunktionen – wählen Sie Flanell. Dies ist eines der kostengünstigsten CNIs. Und es ist mit einer Vielzahl von Architekturen kompatibel (amd64, arm, arm64 usw.). Darüber hinaus ist dies einer von zwei CNIs (der andere ist Cilium), der die MTU automatisch ermitteln kann, sodass Sie nichts konfigurieren müssen. Der Kube-Router ist ebenfalls geeignet, entspricht jedoch nicht dem Standard und Sie müssen die MTU manuell konfigurieren.
- Wenn nötig das Netzwerk verschlüsseln Nehmen Sie zur Sicherheit mit WeaveNet. Vergessen Sie nicht, die MTU-Größe anzugeben, wenn Sie Jumbo-Frames verwenden, und aktivieren Sie die Verschlüsselung, indem Sie über eine Umgebungsvariable ein Passwort angeben. Aber es ist besser, die Leistung zu vergessen – das sind die Kosten der Verschlüsselung.
- für normaler Gebrauch Советую Kattun. Dieses CNI wird häufig in verschiedenen Kubernetes-Bereitstellungstools (Kops, Kubespray, Rancher usw.) verwendet. Stellen Sie wie bei WeaveNet sicher, dass Sie die MTU in ConfigMap konfigurieren, wenn Sie Jumbo-Frames verwenden. Es handelt sich um ein multifunktionales Tool, das hinsichtlich Ressourcenverbrauch, Leistung und Sicherheit effizient ist.
Und schließlich rate ich Ihnen, die Entwicklung zu verfolgen Wimper. Dieses CNI verfügt über ein sehr aktives Team, das viel an seinem Produkt arbeitet (Funktionen, Ressourceneinsparungen, Leistung, Sicherheit, Clustering ...) und sehr interessante Pläne hat.
Visuelles Diagramm zur CNI-Auswahl
Source: habr.com