Container-Lastverteilung am Beispiel Kubermatic Cloud-native Load Balancing – Ohne „Multi-Tenant” nur die Hälfte wert

Anbieter zum Thema

Kubermatic

Yorizon GmbH & Co. KG

Mit der wachsenden Beliebtheit von Microservices und Cloud-native Technologien wächst auch deren Komplexität – speziell, wenn Service Provider Dienste rund um Container, Kubernetes und Co. anbieten. Und dann kommen Load Balancer ins Spiel, die helfen können, die Komplexität zu reduzieren.

Im Laufe der Jahre hat sich die Anwendungsarchitektur von Systemen für Client Server von service-orientierten bis hin zu Cloud-native Microservices entwickelt. Diese Verbesserungen haben erhebliche Auswirkungen auf die Methoden der Anwendungsentwicklung und die Ansätze für Skalierbarkeit, Sicherheit und vor allem für die Bereitstellung von Anwendungen auf Seite der Kunden. Leider ist der aktuelle Stand der ADC-Lösungen (Application Delivery Controller), auch bekannt als Load Balancer, unzureichend.

Die Nachfrage nach Services hat sich weiterentwickelt, und was früher nur einen einzigen Dienst erforderte, nimmt heute gleich mehrere verschiedene Services in Anspruch. In dieser neuen Ära der Service-Explosion wird es für IT-Teams immer schwieriger, das Lifecycle-Management von Anwendungen effektiv zu handhaben: Wenn moderne ADC-Lösungen nicht auf Microservices ausgerichtet sind und über entsprechende Automatisierung verfügen, die über APIs, Automatisierungs- und Orchestrierungs-Frameworks zur Bereitstellung, Konfiguration und Verwaltung dieser Microservices zur Verfügung stehen, können neue Probleme auftreten.

Die folgende Darstellung beschreibt, wie sich Anwendungsarchitekturen entwickelt haben und wie verteilte Microservices die betrieblichen Auswirkungen von Microservices drastisch reduzieren können, die auf entsprechenden Strukturen aufgebaut sind.

Die monolithische Architektur und ihre Nachteile

Seit den Anfängen der Entwicklung von Web-Anwendungen bestand die vorherrschende Architektur von Anwendungen für Unternehmen darin, alle Komponenten der Anwendung auf der Server-Seite in einer einzigen Einheit zusammen zu fassen. Zahlreiche Java-Anwendungen für Unternehmen bestehen zum Beispiel oft aus einer einzigen WAR-(Web Application Archive)- oder EAR-(Enterprise Applicatio Archive)-Datei.

Man stelle sich die Entwicklung eines Online-Shops vor, der Kundenbestellungen annimmt, den Bestand und das verfügbare Guthaben prüft und den Versand abwickelt: Diese Anwendung besteht aus verschiedenen Komponenten, darunter das StoreFront UI (User Interface), die für die Benutzeroberfläche verantwortlich ist, und Diensten, die für die Verwaltung des Produktkatalogs, die Bearbeitung von Bestellungen und die Verwaltung von Kundenkonten zuständig sind. Diese Services verwenden ein gemeinsames Domänenmodell, das Produkt, Bestellung und Kunde umfasst. Trotz ihres logisch modularen Aufbaus wird die Anwendung als Monolith bereitgestellt. Und eine einzelne WAR-Datei wird zum Beispiel auf einem Web-Container wie Tomcat in Java ausgeführt.

Diese sogenannte monolithische Architektur hat mehrere Vorteile: Die Entwicklung monolithischer Anwendungen ist einfach, da IDEs (Integrated Dev Environments) und andere Entwicklungs-Tools auf die Erstellung einer einzigen Anwendung ausgerichtet sind. Auch das Testen und Bereitstellen der Systeme ist einfach, da alles in einer einzigen Anwendung vorhanden ist. Dieser Ansatz funktioniert gut für relativ kleine Anwendungen. Wenn es jedoch um komplexe Systeme geht, lässt sich die monolithische Architektur nur mühsam umsetzen. Es können auch Probleme auftreten, wenn mit neuen Technologien experimentiert wird und diese integriert werden sollen.

So erfordert zum Beispiel der Versuch, ein neues Infrastruktur-Framework zu entwickeln, häufig das Neuschreiben der gesamten Anwendung, was riskant und zugleich unpraktisch ist. Die zu Beginn des Projekts getroffenen technologischen Entscheidungen werden deshalb in der Regel festgeschrieben. Außerdem ist die Skalierung einzelner Teile der Anwendung schwierig, wenn nicht gar unmöglich, da der gesamte Anwendungs-Code innerhalb der Prozesse auf dem Server abläuft. Um neue Änderungen an einer Anwendungskomponente durchzuführen, muss man die gesamte monolithische Anwendung ausführen und bereitstellen. Dies kann komplex, risikoreich und zeitaufwändig sein, da die Koordination vieler Entwickler erforderlich ist und zu langen Testzyklen führen kann.

In Fällen, in denen ein Service erhebliche Memory-Ressourcen benötigt und ein anderer CPU-intensiv ist, muss bei der Bereitstellung des Servers ausreichend Memory- und CPU-Kapazität zugewiesen werden, um die Grundlast für jeden Dienst zu bewältigen. Die dafür erforderlichen Kosten können schnell ansteigen, insbesondere wenn jeder Server erhebliche Mengen an CPU und RAM benötigt. Die Situation wird weiter verschärft, wenn Load Balancing zur horizontalen Skalierung der Anwendung eingesetzt wird. Mit anderen Worten: Die monolithische Architektur kann nicht so einfach skaliert werden, um große, langlebige Anwendungen zu unterstützen. Eine große, monolithische Anwendung kann schnell zu einer Art von empfindlichem Kartenhaus werden, in dem ein Fehler in einem kleinen Teil der Anwendung das gesamte System zum Einsturz bringen kann.

Die Cloud-native und auf Microservices gestützte Architektur löst Probleme auf

Die Cloud-native, auf Microservices basierende Architektur ist darauf ausgelegt, die Probleme der monolithischen Architektur aufzulösen. Die Services, die in der monolithischen Anwendungsarchitektur beschrieben sind, werden in verschiedene Dienste zerlegt und unabhängig voneinander auf separaten Hosts bereitgestellt. Jeder Microservice ist für eine bestimmte Geschäftsfunktion zugewiesen und umfasst nur die für diese spezielle Geschäftsfunktion wesentlichen Prozesse. Diese Architektur verwendet Tools wie zum Beispiel Kubernetes, ArgoCD, Fux und andere Cloud-native Projekte.

1) Jeder Service ist relativ klein und besitzt eine für Entwickler verständliche Code-Basis. Dies steigert die Produktivität der Entwickler, da man sich nur noch auf eine Teilmenge der Anwendung konzentrieren muss. Die IDE ist effizienter, und das Ausführen und Testen der Anwendung ist weniger zeitaufwändig.

2) Da jeder Service isoliert werden kann und nicht von anderen Diensten abhängig ist, können Entwickler isoliert an einer bestimmten Aufgabe arbeiten, ohne von anderen Teams oder vereinzelten Gruppen innerhalb einer Organisation abhängig zu sein. Dies macht die kontinuierliche Entwicklung, Testverfahren und Bereitstellung einfach und besonders attraktiv.

3) Der größte Vorteil dieser Architektur, die sich auf alle verschiedenen, isolierten Gruppen innerhalb eines Unternehmens auswirkt (Entwickler, Betrieb und Management), besteht in der Möglichkeit, Faktoren wie zum Beispiel die Skalierungsprozesse, die zugrunde liegende Hardware und die Anforderungen an Ressourcen wie CPU, GPU oder Speicherintensität pro Service zu konfigurieren. Dies kann den Durchsatz dieser Anwendungen erheblich steigern und gleichzeitig die anfallenden Kosten senken.

Skalierung von Microservices entlang der Achsen X, Y und Z

Die gängigste Darstellung der Skalierung einer Anwendung ist der „Scale Cube“, ein dreidimensionales Skalierbarkeitsmodell, das durch das Buch „The Art of Scalability“ bekannt wurde. Das Modell der Skalierbarkeit verwendet die drei Dimensionen der X-Achse, der Y-Achse und der Z-Achse:

• 1. Skalierung entlang der X-Achse: Bei der horizontalen Skalierung werden mehrere Kopien der gesamten Anwendung mit einem Load Balancer ausgeführt. Jede Instanz der Anwendung wird als horizontales Slice bezeichnet. Dies ist die häufigste Form der Skalierung für Web-Anwendungen.

• 2. Skalierung auf der Y-Achse: Bei der vertikalen Skalierung wird die Anwendung in verschiedene Segmente aufgeteilt, die jeweils auf einem separaten Rechner laufen. Dies ist die häufigste Form der Skalierung für Microservices.

• 3. Skalierung auf der Z-Achse: Bei dieser auch als funktionale Aufgliederung bezeichneten Methode wird die Anwendung ebenfalls in verschiedene Segmente aufgeteilt, wobei jeder Teil auf einem separaten Rechner ausgeführt wird. Dies ist ebenfalls besonders häufig für Microservices.

Das Aufkommen von Tools zur Erstellung von Containern und Orchestrierungs-Tools

Mit der zunehmenden Verbreitung von Microservices tauchten Tools wie Docker, Docker Swarm und Kubernetes auf, um die Bereitstellung und Skalierung zu vereinfachen. Docker revolutionierte die Container-Erstellung und ermöglichte konsistente Umgebungen für Entwicklung und Produktion. Docker Swarm baute dann darauf auf, indem es natives Clustering und Orchestrierung bereitstellte und die Skalierung auf der X- und der Y-Achse für einfachere Anwendungen anbot.

Die Technologie von Kubernetes hat diese Fähigkeiten weiterentwickelt und bietet jetzt robuste Orchestrierung, Management und Skalierbarkeit für komplexe, verteilte Architekturen von Microservices. Mit seinen leistungsstarken Funktionen wie zum Beispiel automatischer Skalierung, Self-Healing und fortlaufenden Updates wurden viele Herausforderungen im Zusammenhang mit der Bereitstellung und Verwaltung von Microservices in großem Maßstab bewältigt. Dies hat Kubernetes zur branchenweit führenden Plattform für die Bereitstellung und Verwaltung von Microservices gemacht.

Herausforderungen im Umgang mit Kubernetes

Kubernetes vereinfacht zwar die Orchestrierung und Verwaltung von containerisierten Anwendungen erheblich, bringt aber auch neue Herausforderungen mit sich, insbesondere in Multi-Cluster- und Multi-Tenant-Umgebungen. Kubernetes bietet Schnittstellen für das Layer-4- und Layer-7-Load Balancing in Form von Services und Ingresses. Diese bieten jedoch nur begrenzte Möglichkeiten und hängen vom Cloud-Anbieter oder Ingress-Anbieter ab, um sie vollständig zu implementieren. Dadurch ist man bei fortgeschrittenen Funktionen wie Traffic Splitting, Traffic Shaping und Beobachtbarkeit auf den jeweiligen Anbieter angewiesen.

Die Verwaltung des Netzwerkverkehrs, die Gewährleistung der Sicherheit von Anwendungen und die Aufrechterhaltung einer hohen Performance bei verschiedenen Clustern und Clouds können komplex und ressourcen-intensiv sein. Traditionelle Load Balancer weisen oft Schwierigkeiten dabei auf, mit der Dynamik von Microservices Schritt zu halten, was zu Ineffizienzen und erhöhtem betrieblichen Aufwand führt. Diese Herausforderungen verdeutlichen den Bedarf an einer verbesserten Lösung zur effektiven Verwaltung der Datenebene und zur optimierten Bereitstellung von Anwendungen in Cloud-nativen Umgebungen.

Da die Anwendungen im Laufe der Zeit immer komplexer und umfangreicher werden, können einige geschäftskritische Anwendungen besondere Multi-Cluster erforderlich machen. Um diese Herausforderungen in den Griff zu bekommen, haben Unternehmen damit begonnen, Architekturen von Multi-Kubernetes-Clustern einzuführen. Durch die Bereitstellung mehrerer Kubernetes-Cluster in verschiedenen Regionen, Verfügbarkeitszonen oder bei verschiedenen Cloud-Anbietern erreichten die Unternehmen dann eine höhere Fehlertoleranz, eine bessere Performance und eine erhöhte Einhaltung von Vorschriften.

Dies brachte wiederum neue Herausforderungen mit sich wie zum Beispiel die Verwaltung verschiedener Cluster, die Sicherstellung konsistenter Richtlinien und die Bereitstellung einer nahtlosen Kommunikation zwischen Anwendungen, die auf mehreren Clustern gehostet werden. Kubernetes verfügt nicht von Haus aus über diese Fähigkeiten und erfordert deshalb den Einsatz von zusätzlichen Tools, um diese Anforderungen in den Griff zu bekommen.

Lesen Sie weiter, welche Vorteile die Einführung von Multi-Tenant-fähigen Load Balancern mit sich bringt.

(ID:50108944)