Dies ist ein Update zu meinem vorherigen Benchmark , der jetzt auf Kubernetes 1.14 mit der aktuellen Version von CNI für April 2019 ausgeführt wird.
Zunächst möchte ich dem Cilium-Team danken: Die Jungs haben mir geholfen, die Metriküberwachungsskripte zu überprüfen und zu reparieren.
Was hat sich seit November 2018 geändert?
Folgendes hat sich seitdem geändert (bei Interesse):
Flannel bleibt die schnellste und einfachste Schnittstelle von CNI, unterstützt jedoch keine Netzwerkrichtlinien und keine 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! Die Produktivität ist jedoch zurückgegangen.
In Calico müssen Sie die maximale Paketgröße (MTU) für eine bessere Leistung noch manuell konfigurieren. Calico bietet zwei CNI-Installationsoptionen, sodass Sie auf ein separates ETCD-Repository verzichten können:
- Statusspeicher in der Kubernetes-API als Datenspeicher (Clustergröße <50 Knoten);
- Statusspeicher in der Kubernetes-API als Datenspeicher mit dem Typha-Proxy, um die K8S-API zu entlasten (Clustergröße> 50 Knoten).
Calico kündigt zusätzlich zu Istio Richtlinienunterstützung auf Anwendungsebene für die Sicherheit auf Anwendungsebene an.
Cilium unterstützt jetzt die Verschlüsselung! Cilium bietet Verschlüsselung mit IPSec-Tunneln und bietet eine Alternative zum verschlüsselten WeaveNet-Netzwerk. WeaveNet ist jedoch mit aktivierter Verschlüsselung schneller als Cilium.
Dank des eingebauten ETCD-Operators ist Cilium jetzt einfacher bereitzustellen.
Das Cilium-Team hat versucht, das Gewicht seines CNI zu senken, um den Speicherverbrauch und die CPU-Kosten zu senken, aber die Konkurrenten sind immer noch leichter.
Benchmark-Kontext
Der Benchmark wird auf drei nicht virtualisierten Supermicro-Servern mit einem 10-GB-Supermicro-Switch ausgeführt. 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 wird unter Ubuntu 18.04 LTS mit Docker 18.09.2 (der Standardversion von Docker in dieser Version) installiert.
Um die Reproduzierbarkeit zu verbessern, haben wir beschlossen, den Master immer auf dem ersten Knoten einzurichten, den Serverteil des Benchmarks auf dem zweiten Server und den Clientteil auf dem dritten zu platzieren. Dafür verwenden wir NodeSelector in Kubernetes-Bereitstellungen.
Die Benchmark-Ergebnisse werden auf einer solchen Skala beschrieben:
Auswahl von CNI als Benchmark
Dies ist ein Nur-CNI-Benchmark aus der Liste im Abschnitt zum Erstellen eines Master-Clusters mit kubeadm in der offiziellen Kubernetes-Dokumentation. Von CNI 9 nehmen wir nur 6: Wir schließen diejenigen aus, die schwierig zu installieren sind und / oder ohne Dokumentationskonfiguration nicht funktionieren (Romana, Contiv-VPP und JuniperContrail / TungstenFabric).
Wir werden die folgenden CNIs vergleichen:
- Calico v3.6
- Canal v3.6 (im Wesentlichen ein Flanell für das Netzwerk + Calico als Firewall)
- Cilium 1.4.2
- Flanell 0.11.0
- Kube-Router 0.2.5
- WeaveNet 2.5.1
Installation
Je einfacher die Installation von CNI ist, desto besser wird unser erster Eindruck sein. Alle CNI aus dem Benchmark sind sehr einfach zu installieren (mit einem oder zwei Teams).
Wie gesagt, der Server und der Switch sind mit aktivierten Jumbo-Frames konfiguriert (wir haben MTU 9000 installiert). Wir würden uns freuen, wenn CNI die MTU anhand der Adaptereinstellungen automatisch ermitteln würde. Dies wurde jedoch nur von Cilium und Flanell behandelt. Der Rest des CNI hat Anforderungen an GitHub, eine automatische MTU-Erkennung hinzuzufügen. Wir werden diese jedoch 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 der falschen MTU? Dieses Diagramm zeigt den Unterschied zwischen WeaveNet mit aktivierten Standard-MTU- und Jumbo-Frames:
Wie sich MTU auf die Bandbreite auswirkt
Wir haben herausgefunden, wie wichtig MTU für die Leistung ist, und jetzt wollen wir sehen, wie unsere CNIs dies automatisch erkennen:
CNI erkennt MTU automatisch
Die Grafik zeigt, dass Sie MTU für Calico, Canal, Kube-Router und WeaveNet konfigurieren müssen, um eine optimale Leistung zu erzielen. Cilium und Flannel selbst konnten die MTU ohne Einstellungen korrekt bestimmen.
Sicherheit
Wir werden die CNI-Sicherheit in zwei Aspekten vergleichen: der Fähigkeit, die übertragenen Daten zu verschlüsseln, und der Implementierung von Kubernetes-Netzwerkrichtlinien (gemäß realen Tests, nicht gemäß der Dokumentation).
Nur zwei CNIs verschlüsseln Daten: Cilium und WeaveNet. Die WeaveNet- Verschlüsselung wird aktiviert, indem das Verschlüsselungskennwort als CNI-Umgebungsvariable festgelegt wird. Die beschriebene WeaveNet- Dokumentation ist kompliziert, aber alles wird einfach gemacht. Die Cilium- Verschlüsselung wird durch Befehle, durch Erstellen von Kubernetes-Geheimnissen und durch Ändern von daemonSet konfiguriert (etwas komplizierter als in WeaveNet, aber Cilium verfügt über schrittweise Anweisungen ).
Bei der Implementierung der Netzwerkrichtlinie waren Calico, Canal, Cilium und WeaveNet hier erfolgreich, wo Sie die Ingress- und Egress-Regeln konfigurieren können. Für Kube-Router gibt es nur Regeln für Ingress, während Flannel überhaupt keine Netzwerkrichtlinien hat.
Hier sind die allgemeinen Ergebnisse:
Benchmark-Ergebnisse für Sicherheitsfunktionen
Leistung
Dieser Benchmark zeigt den durchschnittlichen Durchsatz für mindestens drei Läufe jedes Tests. Wir testen die Leistung von TCP und UDP (mit iperf3), realen Anwendungen, z. B. HTTP (mit Nginx und Curl) oder FTP (mit vsftpd und Curl) und schließlich den Betrieb von Anwendungen mit Verschlüsselung auf Basis des SCP-Protokolls (mit Client und Server) OpenSSH).
Für alle Tests haben wir einen Bare-Metal-Benchmark (grüne Linie) erstellt, um die CNI-Leistung mit der nativen Netzwerkleistung zu vergleichen. Hier verwenden wir die gleiche Skala, aber Farbe:
- Gelb = sehr gut
- Orange = gut
- Blau = so lala
- Rot = schlecht
Wir werden keine falsch konfigurierten CNIs verwenden und nur die Ergebnisse für CNIs mit der richtigen MTU anzeigen. (Hinweis: Cilium berücksichtigt MTU fälschlicherweise, wenn die Verschlüsselung aktiviert ist. Daher müssen Sie MTU in Version 1.4 manuell auf 8900 reduzieren. In der nächsten Version 1.5 erfolgt dies automatisch.)
Hier sind die Ergebnisse:
TCP-Leistung
Alle CNIs schnitten im TCP-Benchmark gut ab. Verschlüsselte CNIs liegen weit zurück, da Verschlüsselung teuer ist.
UDP-Leistung
Auch hier geht es allen CNI gut. Verschlüsselte CNIs zeigten fast das gleiche Ergebnis. Cilium liegt leicht hinter seinen Konkurrenten, aber es macht nur 2,3% Bare-Metal aus, sodass das Ergebnis nicht schlecht ist. Vergessen Sie nicht, dass nur Cilium und Flannel die MTU selbst korrekt bestimmt haben. Dies sind ihre Ergebnisse ohne zusätzliche Konfiguration.
Wie wäre es mit einer echten Bewerbung? Wie Sie sehen, ist die Gesamtleistung bei HTTP etwas geringer als bei TCP. Selbst wenn Sie HTTP mit TCP verwenden, haben wir im TCP-Benchmark iperf3 so konfiguriert, dass ein langsamer Start vermieden wird. Dies wirkt sich auf den HTTP-Benchmark aus. Hier wurde alles gut gemacht. Der Kube-Router hat einen klaren Vorteil, und WeaveNet zeigte sich nicht von der besten Seite: etwa 20% schlechter als Bare-Metal. Cilium und WeaveNet mit Verschlüsselung sehen sehr traurig aus.
Bei FTP, einem anderen TCP-basierten Protokoll, sind die Ergebnisse unterschiedlich. Flanell- und Kube-Router kommen zurecht, während Calico, Canal und Cilium etwas zurückliegen und etwa 10% langsamer arbeiten als Bare-Metal. WeaveNet hält nicht mit bis zu 17% Schritt, aber WeaveNet mit Verschlüsselung liegt 40% vor verschlüsseltem Cilium.
Mit SCP können Sie sofort sehen, was uns die SSH-Verschlüsselung kostet. Fast alle CNIs tun dies und WeaveNet bleibt wieder zurück. Cilium und WeaveNet mit Verschlüsselung werden aufgrund der doppelten Verschlüsselung (SSH + CNI) voraussichtlich am schlechtesten abschneiden.
Hier ist eine Übersichtstabelle mit den Ergebnissen:
Ressourcenverbrauch
Vergleichen wir nun, wie CNI unter hoher Last Ressourcen verbraucht (während der Übertragung über TCP 10 Gbit / s). In Leistungstests vergleichen wir CNI mit Bare Metal (grüne Linie). Um Ressourcen zu verbrauchen, zeigen wir reine Kubernetes (violette Linie) ohne CNI an und sehen, wie viele zusätzliche Ressourcen CNI verbraucht.
Beginnen wir mit der Erinnerung. Hier ist der Durchschnittswert für den Hostspeicher (ohne Puffer und Cache) in MB während der Übertragung.
Speicherverbrauch
Flanell- und Kube-Router zeigten hervorragende Ergebnisse - nur 50 MB. Calico und Canal haben jeweils 70. WeaveNet verbraucht deutlich mehr als der Rest - 130 MB, während Cilium bis zu 400 MB verbraucht.
Lassen Sie uns nun die CPU-Auslastung überprüfen. Bemerkenswert : Im Diagramm sind nicht Prozentsätze, sondern pro Mille, dh 38 ppm für „bloßes Eisen“, 3,8%. Hier sind die Ergebnisse:
CPU-Verbrauch
Calico, Canal, Flannel und Kube-Router nutzen die CPU sehr effizient - nur 2% mehr als Kubernetes ohne CNI. WeaveNet liegt mit zusätzlichen 5% weit zurück, gefolgt von Cilium - 7%.
Hier ist eine Zusammenfassung des Ressourcenverbrauchs:
Zusammenfassung
Tabelle mit allen Ergebnissen:
Allgemeine Benchmark-Ergebnisse
Fazit
Im letzten Teil werde ich meine subjektive Meinung zu den Ergebnissen äußern. Denken Sie daran, dass dieser Benchmark nur den Durchsatz einer Verbindung auf einem sehr kleinen Cluster (3 Knoten) testet. Dies gilt nicht für große Cluster (<50 Knoten) oder parallele Verbindungen.
Ich empfehle die Verwendung der folgenden CNIs je nach Szenario:
- Sie haben Knoten mit einer geringen Menge an Ressourcen in Ihrem Cluster (mehrere GB RAM, mehrere Kerne) und benötigen keine Sicherheitsfunktionen - wählen Sie Flanell . Dies ist einer der wirtschaftlichsten CNIs. Und es ist kompatibel mit einer Vielzahl von Architekturen (amd64, arm, arm64 usw.). Darüber hinaus ist dies eine von zwei CNI (die zweite ist Cilium), mit denen die MTU automatisch ermittelt werden kann, sodass Sie nichts konfigurieren müssen. Kube-Router ist ebenfalls geeignet, aber nicht so Standard und Sie müssen die MTU manuell konfigurieren.
- Wenn Sie das Netzwerk aus Sicherheitsgründen verschlüsseln müssen, verwenden Sie WeaveNet . Vergessen Sie nicht, die Größe der MTU anzugeben, wenn Sie Jumbo-Frames verwenden, und aktivieren Sie die Verschlüsselung, indem Sie ein Kennwort über eine Umgebungsvariable angeben. Vergessen Sie jedoch besser die Leistung - dies ist die Verschlüsselungsgebühr.
- Für den normalen Gebrauch empfehle ich Calico . Dieses CNI wird häufig in verschiedenen Kubernetes-Bereitstellungstools (Kops, Kubespray, Rancher usw.) verwendet. Denken Sie wie bei WeaveNet daran, die MTU in ConfigMap zu konfigurieren, wenn Sie Jumbo-Frames verwenden. Es ist ein multifunktionales Tool, das hinsichtlich Ressourcenverbrauch, Produktivität und Sicherheit effektiv ist.
Und schließlich rate ich Ihnen, die Entwicklung von Cilium zu verfolgen. Dieses CNI hat ein sehr aktives Team, das hart an seinem Produkt arbeitet (Funktionen, Ressourceneinsparung, Produktivität, Sicherheit, Clusterverteilung ...) und sehr interessante Pläne hat.
Visuelles Diagramm für CNI Choice