Heute werfen wir einen Blick unter die Haube unserer Kubernetes-Lösung MetaKube. Unsere Experten erklären, warum die Ablösung von OpenVPN mit Konnectivity für mehr Performance in den Clustern sorgt und wie sie vorgegangen sind.
Was hat OpenVPN damit zu tun und warum haben wir es abgelöst?
Dafür ist es gut zu wissen, dass sich IP-Adressen im privaten Netzwerk, in dem sich die Compute Nodes eines MetaKube Clusters befinden, über das Internet oder von der MetaKube Core Infrastruktur gar nicht erreichen lassen. Einige API-Requests sind aber auf die direkte Kommunikation mit Kubelet auf den Compute Nodes oder anderen Adressen im Cluster angewiesen. Aus diesem Grund wird aus dem Cluster ein „reverse“ Tunnel zur SysEleven Infrastruktur aufgebaut. Dabei haben unsere Experten bislang auf die VPN-Lösung “OpenVPN” gesetzt. Entsprechender Traffic wurde verschlüsselt und über den Tunnel umgeleitet.
OpenVPN gilt als Industriestandard, d.h. es ist ausgereift und etabliert. Dennoch hat uns diese Lösung in puncto Stabilität, Performance und Wartbarkeit noch nicht ganz zufrieden gestellt.
In der OpenSource Community waren wir nicht die Einzigen mit dem Problem. So hat die offizielle Kubernetes “Special Interest Group” (SIG) “api-machinery” ein Projekt ins Leben gerufen, welches genau dieses Problem lösen soll und zudem noch auf Kubernetes zugeschnitten ist. Diese Lösung nennt sich “API Server Network Proxy” oder auch “Konnectivity”.
Der Unterschied zwischen OpenVPN und Konnectivity
Der größte Unterschied der beiden Technologien ist, auf welcher Ebene des Netzwerkstacks sie agieren.
OpenVPN transportiert transparent über einen Tunnel IP-Packets (Layer 3) zwischen den Netzen und gewährleistet so die sichere Übermittlung von API-Requests. Mit Konnectivity hingegen verwendet der API-Server statt einer TCP-Verbindung einen Tunnel, den der Konnectivity Server bereitstellt. Das bietet zwei entscheidende Vorteile:
Das Errorhandling, Metriken und Logs in den involvierten Komponenten kann mit Bezug auf den Kontext der einzelnen Requests umgesetzt werden. Diese Information ginge sonst verloren, wenn die Pakete aller Verbindungen den gleichen Tunnel verwenden.
Konnectivityserver und -client können horizontal skaliert werden und sind somit hochverfügbar und ausfallsicher. Auch das war mit OpenVPN nicht möglich.
Und nicht nur das! Auch in puncto Bandbreite ist diese weitaus besser. Das ist vor allem zwei Aspekten zuzuschreiben:
Konnectivity kommt ohne “Encapsulation” aus und multiplext sogar mehrere Requests auf die Tunnel, was TCP-Verbindungen spart. OpenVPN basiert hingegen auf “TCP over TCP”, das bedeutet, dass sich kleine Verbindungsprobleme, wie z.B. Retransmissions, verheerend auf die Gesamtperformance und -stabilität auswirken.
Konnectivity läuft im Gegensatz zu OpenVPN multi-threaded, welches das Sizing der Komponenten einfacher macht. Bei größeren Clustern und damit Last mussten wir bei OpenVPN die Probleme teilweise mit Ressourcen überkompensieren.
Wie steht es um die Kompatibilität und Wartbarkeit?
Obwohl Konnectivity explizit für Kubernetes entworfen wurde, ist es lose zum API-Server gekoppelt und somit werden Abhängigkeiten geschickt vermieden. Konnectivity implementiert lediglich eine Abstraktion, die der API-Server wiederum nutzt. Beide Projekte können somit weitestgehend unabhängig voneinander entwickelt werden.
Als offizielles Kubernetes Projekt ist zu erwarten, dass zukünftige Updates für Konnectivity stabil und kompatibel sind, zugleich aber schnell released werden.
Too good to be true? Gibt es irgendwelche Downsides?
Die kurze Antwort: Nein.
Die lange Antwort:
Um mögliche Fehlerquellen vor der Implementierung bei unseren Kunden auszuräumen, haben wir Konnectivity ausgiebig auf funktionale und nichtfunktionale Anforderungen getestet. Die Migration haben wir inkl. Rollback für alle verfügbaren Kubernetesversionen und unterschiedliche Cluster-Konfigurationen oft durchgespielt. Erfreulicherweise gab es nichts, was nicht schnell erkannt und behoben werden konnte. Das Versprechen von Konnectivity nach besserer Performance, mehr Stabilität und besserer Wartbarkeit ging voll auf!
Insgesamt konnten wir die Bandbreite um ein Vierfaches steigern und frühere OpenVPN-Probleme gehören endlich der Vergangenheit an, somit sind keine ähnlichen Probleme mehr aufgetaucht.
Für MetaKube-Nutzer haben sich nur Kleinigkeiten im Cluster geändert, u.a. ist im kube-system Namespace kein “openvpn-client” Pod mehr, sondern stattdessen zwei “konnectivity-agent” Pods. Zudem läuft der Metrics Server jetzt im Cluster.
Für alle, die noch weitere Informationen zum Thema Konnectivity haben möchten, hier eine kurze Liste an hilfreichen Links:
Unsere eigene Dokumentation:
https://docs.syseleven.de/metakube/de/documentation/konnectivity
Kubernetes API machinery SIG proposal: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1281-network-proxy#proposal
Github project: https://github.com/kubernetes-sigs/apiserver-network-proxy
Wenn Du mehr über MetaKube erfahren möchtest, dann melde Dich zu einem kostenfreien Test für 30 Tage an: syseleven.de/metakube-testen
