Mobile-Menu

Load Balancer und Open Source Gateway für Microservices MetalLB und Zuul für das Routing in Kubernetes

Von Thomas Joos |

Anbieter zum Thema

Fujitsu Technology Solutions GmbH
Datacenter One GmbH
Schwarz IT KG

Um Kubernetes-Umgebungen im Griff zu behalten, helfen Open-Source-Tools der CNCF. Thomas Joos stellt hier „MetalLB“ und „Zuul“ vor. Mit dem Load Balancer und dem Gateway lässt sich der Netzwerkverkehr in Microservices-Umgebungen optimal steuern, so der Autor.

„Zuul“ bezeichnet eine Dinosaurienart, die in etwas wie gezeichnet ausgesehen haben könnte. Zuul ist aber auch eine Figur aus dem Spielfilm „Ghost Busters“; der Torwächter von Gozer, ist ein Halbgott und Lakai von Gozer, dem Zerstörer.
„Zuul“ bezeichnet eine Dinosaurienart, die in etwas wie gezeichnet ausgesehen haben könnte. Zuul ist aber auch eine Figur aus dem Spielfilm „Ghost Busters“; der Torwächter von Gozer, ist ein Halbgott und Lakai von Gozer, dem Zerstörer.
(Bild: / CC BY )

Wer den Netzwerkverkehr in Kubernetes steuern will, braucht ein Tool für den Lastenausgleich und ein Gateway. Die beiden CNCF- und OpenStack-Projekte MetalLB und Zuul sind eine gute Alternative in Cloud-Umgebungen. Beim Einsatz eigener Kubernetes-Cluster auf Basis von Bare Metal, sind MetalLB und Zuul geradezu ideal.

MetalLB - Load Balancer für Kubernetes

MetalLB ist ein Open-Source-Projekt der CNCF. Der Network Load Balancer für Kubernetes unterstützt die wichtigsten Routing-Protokolle. Wenn in einer Microservices-Umgebung auf Basis von Kubernetes ein Lastenausgleich stattfinden soll, sind externe Loadbalancer notwendig, da Kubernetes selbst über keinen Lastenausgleich verfügt. Das gilt vor allem für Kubernetes Bare-Metal-Cluster.

Bei Cloud-Umgebungen setzen Unternehmen häufig auf Lösungen der Cloud-Anbieter (AWS, Azure). Wollen Admins den Netzwerklastenausgleich selbst steuern, ist MetalLB eine interessante Alternative. In Cloud-Umgebungen funktioniert MetalLB aktuell noch nicht, da die Umgebungen in den meisten Fällen nicht kompatibel sind. Das gilt zumindest für Azure, AWS und Google Cloud Platform. Bei Hetzner und OVH kann MetalLB zum Einsatz kommen.

In lokalen Umgebungen auf Basis von Bare-Metall ist der Betrieb von MetalLB in den meisten Fällen kein Problem. Auch bei der Installation in virtuellen Umgebungen oder private Clouds auf Basis von OpenShift, OpenStack, Proxmox, VMware und Vultr ist der Betrieb von MetalLB möglich.

Testen ist notwendig

MetalLB stellt eine Netzwerk-Load-Balancer-Implementierung dar, die sich in Standard-Netzwerkgeräten integrieren lässt. Für den Einsatz ist Kubernetes mit mindestens der Version 1.13 notwendig. Die Konfiguration des Clusters muss mit MetalLB zusammenpassen.

Da das Projekt noch in der Betaphase ist, sollte das in einer passenden Testumgebung geprüft werden. MetalLB benötigt für den Betrieb eigene IPv4-Adressen. Dazu kommt der Datenverkehr zum TCP/UDP-Port 7946. Dieser muss zwischen den Kubernetes-Clustern erlaubt sein, damit MetalLB die Daten verteilen kann.

Damit MetalLB funktioniert, muss der L2-Modus von MetalLB in der Umgebung unterstützt werden. MetalLB nutzt ARP, so dass ARP in der jeweiligen Umgebung so funktionieren muss, wie standardmäßig vorgesehen. Vor allem in Cloud-Plattformen wird ARP restriktiver konfiguriert, was die Sicherheit erhöht, aber die Zusammenarbeit mit MetalLB stört. MetalLB muss in der Lage sein die IP-Adressen des Clusters mit ARP zu erfassen.

MetalLB und Openshift OCP

Damit MetalLB mit Umgebungen wie „Openhift“ von Red Hat funktioniert, sind teilweise Änderungen in der Umgebung notwendig. Diese sollten vor der Implementierung ausreichend getestet werden. Zunächst benötigt MetalLB die notwendigen Rechte für die Netzwerkkommunikation im Cluster. Auch die Pod-UIDs müssen in Openshift angepasst werden, damit MetalLB als Loadbalancer zum Einsatz kommen kann.

Es ist problemlos möglich, Kubernetes-Cluster auf OpenStack-VMs zu betreiben und MetalLB als Load Balancer einzusetzen. Auch hier muss der ARP-Spoofing-Schutz von OpenStack deaktiviert werden, wenn der L2-Modus zum Einsatz kommen soll. Außerdem muss der Schutz auf allen VMs deaktiviert sein, auf denen Kubernetes mit MetalLB zusammenarbeiten soll.

Netflix Zuul - L7-Gateway für dynamisches Routing und Monitoring

Bei Netflix Zuul handelt es sich um eine Open-Source-Anwendung für das dynamische Routen und Überwachen von Netzwerkverkehr in Kubernetes. Zuul ist grundsätzlich ein Edge-Service, der für die Netflix-API entwickelt wurde. Er kommt bei Netflix mittlerweile auf vielen Systemen zum Einsatz.

Zuul ist das zentrale Framework, das die Ausführung der verschiedenen Filter steuert und auch Informationen von den Filtern und den durchgeführten Aktionen erhält. Die Filter werden mit Groovy geschrieben. Grundsätzlich unterstützt Zuul aber auch viele andere Programmiersprachen, die JVMs unterstützen.

Basis von Zuul sind verschiedene Filter, die während der Weiterleitung von HTTP-Anfragen und -Antworten Aktionen durchführen. Admins und Entwickler können Filter und Aktionen flexibel steuern. Außerdem ist es möglich die Reihenfolge der Filter und Aktionen zu steuern. Ein Beispiel für einen solchen Filter sieht folgendermaßen aus:

class DeviceDelayFilter extends ZuulFilter { def static Random rand = new Random() @Override String filterType() { return 'pre' } @Override int filterOrder() { return 5 } @Override boolean shouldFilter() { return RequestContext.getRequest(). getParameter("deviceType")?equals("BrokenDevice"):false } @Override Object run() { sleep(rand.nextInt(20000)) // Sleep for a random number of // seconds between [0-20] }}Zuul

Die Zuul-Architektur im Überblick

Es gibt bereits verschiedene Standardfiltertypen. Dazu gehören Pre, Routing, Post und Error. Pre-Filter werden vor der Weiterleitung an die Quelle ausgeführt. Dabei kann es sich zum Beispiel um die Authentifizierung von Anfragen handeln.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Die „Zuul“-Architektur im Überblick.
Die „Zuul“-Architektur im Überblick.
(Bild: Netflix Techblog)

Routing-Filter steuern die Weiterleitung der Anfrage an die Quelle. Hier wird die ursprüngliche HTTP-Anfrage erstellt und mit Apache Http-Client oder Netflix Ribbon gesendet. Post-Filter werden ausgeführt, nachdem die Anfrage an die Quelle weitergeleitet wurde. Treten Fehler in den verschiedenen Phasen auf, führt Zuul Error-Filter aus.

Neben der Nutzung solcher Standard-Filter ist es auch problemlos möglich, eigene Filter zu definieren. Hier bietet Zuul auch einen STATIC-Typ, der eine Antwort innerhalb von Zuul erzeugt, anstatt die Anfrage an die Quelle weiterzuleiten.

Eine der Stärken von Zuul besteht darin, dass die Software Filter während der Laufzeit hinzufügen, ändern und kompilieren kann. Das ermöglicht das sehr schnelle Ändern des Systemverhaltens in einer Kubernetes-Umgebung. In großen Umgebungen ist das sinnvoll, wenn die einzelnen Dienste stark belastet ist, aber dennoch schnell reagieren sollen. Es lassen sich im laufenden Betrieb jederzeit Filter hinzufügen und ändern.

* Der Autor Thomas Joos ist IT-Berater und Verfasser zahlreichen Fachbücher und -artikel. Auf DataCenter-Insider füllt er seinen eigenen Blog mit Tipps und Tricks für Admins: „Toms Admin-Blog“

Artikelfiles und Artikellinks

(ID:47580042)

Weiterführende Inhalte