Anbieter zum Thema

Kubermatic

Yorizon GmbH & Co. KG

Einführung von Load Balancern, die tauglich für Multi-Tenant sind

KubeLB ist ein Beispiel für einen multi-tenant-fähigen Load Balancer. Es handelt sich um eine software-basierte Plattform, um Anwendungen der nächsten Generation mit integrierter Analytik bereitzustellen, die sichere, zuverlässige und skalierbare Netzwerkdienste für Cloud-Anwendungen bietet. Das Herzstück von KubeLB besteht aus einer revolutionären, auf SDN-(Software Defined Networking)-Prinzipien basierenden Architektur, die die Datenebene von der Steuerungsebene trennt: Dies bedeutet eine Branchenneuheit für Application Delivery Controller und Load Balancer.

KubeLB ermöglicht die nahtlose Skalierung von Services, um Anwendungen innerhalb und zwischen Rechenzentren und Cloud-Standorten bereitzustellen, wobei die Verwaltung und Steuerung zentral erfolgt. Der Load Balancer funktioniert als Service, so dass mehrere Nutzer die gleiche Software verwenden können. Er erkennt die komplette Nutzerumgebung und handelt dementsprechend.

Vorteile verteilter Architektur

Die von den leistungsstarken Cilium- und Envoy-Elementen eingerichteten und verteilten Load Balancer stellen umfassende Services für die Bereitstellung von Anwendungen wie zum Beispiel Load Balancing, Beschleunigung und Sicherheit von Anwendungen bereit. Cilium und Envoy können mit Anwendungen innerhalb von und über Cloud-Standorten hinweg zusammengelegt und für eine höhere Leistung kombiniert werden.

Indem die umfangreichen Services der Daten-, Kontroll- und Management-Ebenen von KubeLB verwendet werden, können Cilium und Envoy in der Nähe der Microservices der Anwendung platziert und zusammengefasst werden, um eine höhere Performance und schnellere Client-Reaktionen zu erzielen. Die integrierten Daten-Kollektoren erfassen End-to-End-Timing, Metriken und Protokolle für jede Transaktion zwischen Benutzer und Anwendung. Sie liefern damit verwertbare Erkenntnisse über die Erfahrung der End-User, die Performance der Anwendungen, die Auslastung der Infrastruktur und anomale Verhaltensweisen, die dann für eine verbesserte Architektur der bereitgestellten Anwendungen verwendet werden können.

Bereitstellung von Anwendungen auf Basis von Analytics

Wenn die Nachfrage nach einer bestimmten Microservice-Anwendung steigt, ermöglicht die verteilte Architektur von KubeLB die automatische Skalierung der KubeLB Service Engines ohne menschliches Eingreifen. Die KubeLB-Engines überwachen ständig die Transportmuster jeder Microservice-Anwendung. Wenn ein (einstellbarer) Schwellenwert erreicht wird, bewältigen die neu skalierten Cilium- und Envoy-Elemente die steigende Verkehrslast problemlos. Darüber hinaus können die internen Analytic Engines auf der Grundlage der Umgebungslast einen Trigger senden, um die Anwendungen im Backend-Microservice-Bereich hoch- oder herunterzuskalieren.

Schließlich ermöglicht die verteilte Microservices-Architektur, dass Cilium und Envoy, die mit jedem Microservice verbunden sind, unabhängig von anderen Microservices skaliert werden können.

1. Elastische Skalierung
Die Elastic-Datenebene von „KubeLB” kann dynamisch hoch und runtergefahren werden, um die Real-Time-Anforderungen von microservice-basierten Anwendungen über Hunderte von Anwendern und Tausende von Anwendungen hinweg zu erfüllen. Cilium und Envoy ermöglichen es, Netzwerkservices für jeden Microservice individuell zu skalieren, sei es nach oben oder nach unten („out/in” oder „up/down”).

2. Affinität der Anwendungen
Cilium und Envoy werden in der Nähe von Microservice-Anwendungen eingerichtet, um eine optimale Performance der Anwendungen und minimale Verkehrsbelastungen im Netzwerk zu gewährleisten. Unabhängig davon, ob sich Microservices auf einem einzigen physischen Server, auf verschiedenen Servern, aber in einem einzigen Rechenzentrum oder sogar in verschiedenen Rechenzentren befinden, erkennen und positionieren sich Cilium und Envoy automatisch in der größtmöglichen Nähe zu jedem Microservice.

3. Isolierung von Dataplanes-für Mieter und Anwendungen
Um die gemeinsame Verwendung von Appliances zwischen geschäftskritischen Anwendungen zu vermeiden, werden Mandanten und Anwendungen ihre eigenen Service Engines zur Isolierung der Datenebene zugewiesen. Dadurch wird das Problem der „noisy neighbours“ beseitigt, bei denen ein unberechenbarer Microservice oder Mandant die Leistung einer benachbarten Anwendung beeinträchtigen könnte. KubeLBs dedizierte Micro Load Balancer pro Mandant liefern echte mandantenfähige Anwendungs-Services.

4. Programmierbarkeit
Alle Interaktionen mit dem KubeLB-Controller erfolgen über native Kubernetes-APIs, die eine direkte Integration mit Kubectl ermöglichen. Tools für DevOps-Automatisierung wie zum Beispiel Crossplane, Terraform oder Ansible werden ebenfalls direkt unterstützt.

5. Aktive Redundanz N-Way

KubeLB verwendet Redundanzprinzipien von skalierbaren Rechenzentren im Web und bietet N-Way Active-Active-Redundanz sowie Active-Active- und Active-Standby-Verfügbarkeitsoptionen.

Erforderliche Umgebung für echte software-defined Netzwerke

Was sind die erforderlichen Schritte, um Anwendungen für die Aufgaben moderner Rechenzentren zu entwickeln? Jede Gruppe von Cilium und Envoy kann mit einem bestimmten Mandanten verknüpft werden, so dass in einer mandantenfähigen Umgebung der Datenverkehr für eine bestimmte Anwendung auf seine Cilium- und Envoy-Gruppe beschränkt ist. KubeLB kann mehrere Gruppen von Cilium und Envoy verwalten. Der rollenbasierte Mechanismus für die Zugriffskontrolle von Kubernetes stellt sicher, dass Benutzer, die bei einem bestimmten Mandanten angemeldet sind, nur seine besonderen Details sehen können.

Schritt Nr. 1
Bei der Architektur muss es eine vollständige und echte Trennung von Kontroll- und Datenebene innerhalb des ADC geben. Dies muss auch die Möglichkeit enthalten, die Ressourcen der Datenebene dynamisch über verschiedene Plattformen der Hardware und öffentlichen oder privaten Clouds zu verteilen – und zwar genau so, wie die Microservices der Anwendungen organisiert sind.

Schritt Nr. 2
ADCs müssen das Konzept der „Anwendungsaffinität“ umsetzen, das auf dem App-World-Konzept der „Prozessor-Affinität“ basiert, bei dem Ressourcen für bestimmte Funktionen ausgerichtet und verteilt werden. Dieser Ansatz bietet zwei wesentliche Vorteile: Erstens verbessert der Microservice die Reaktionszeit der Anwendung, indem er die ADC-Ressourcen nebeneinander platziert. Zweitens ermöglicht diese enge Ausrichtung (Affinität) der ADC-Ressourcen eine automatische Verwaltung des Lebenszyklus von Microservices ohne manuelle Eingriffe. Dies reduziert die Komplexität des Managements erheblich.

Schritt Nr. 3
Er besteht darin, die Unabhängigkeit der Datenebene (Isolation) zu erreichen, um die Mandantenfähigkeit umzusetzen – insbesondere in Cloud-Umgebungen. Dies entspricht der Art und Weise, wie Microservices unabhängig voneinander betrieben und geändert werden können, ohne andere Microservices zu stören oder den „noisy neighbor“-Effekt in Gang zu setzen.

Schritt Nr. 4
Hierbei geht es um die Umsetzung der Self-Service-Programmierbarkeit und um die Effizienzversprechen von SDN (Software-Defined Networking). Die meisten, wenn nicht sogar alle ADC-Anbieter unterstützen heute REST (Representational State Transfer), das Protokoll der Wahl bei Hyperscale-Web-Diensten. Doch nur durch eine echte Trennung von Kontroll- und Datenebene und die vollständige Zentralisierung der Kontrollfunktionen kann der ADC das wirkliche Versprechen von SDN erfüllen, indem er eine Eins-zu-Eins-Kommunikation zwischen seinem Controller und den Kontrollelementen der Anwendung über RESTful APIs ermöglicht.

Zusammenfassung

Die Architektur, mit der Anwendungen heute entwickelt werden, hat sich von zweckgebundenem, monolithischem („shrink-wrapped“) Code und entsprechenden Produkten hin zu einer eng zusammenhängenden Sammlung modularer und wiederverwendbarer Microservices entwickelt. Es scheint so zu sein, als ob App-Entwickler dazu übergegangen sind, einen gemeinsamen Satz von Lego-Bausteinen zu verwenden, um eine beliebige Anzahl von web-basierten Anwendungen zu bauen, die nur durch ihre Vorstellungskraft begrenzt sind. Die Umstellung auf die Entwicklung von Microservice-Apps bedeutet für Netzwerk-Teams, dass ihre bisherigen Annahmen zu Verkehrsmustern, Skalierung von Load Balancing und Service-Anforderungen nicht mehr gültig sind.

Ein höheres Maß an netzwerkweiter Intelligenz und eine neue Architektur für die Bereitstellung von Anwendungen, die die Microservice-Apps widerspiegelt, sind erforderlich. Elastisch skalierbare Load Balancer mit einer verteilten Datenebene verteilen, bedienen und skalieren Anwendungen über verschiedene Standorte vor Ort und in der Cloud. Die verteilte Datenebene ermöglicht es den Kunden, eine Anwendungsaffinität auf der Ebene der Microservices von Anwendungen zu erreichen und damit die Gesamtleistung der Anwendungen erheblich zu verbessern.

Darüber hinaus erlaubt die saubere Trennung der Ebenen auch die Schaffung einer einheitlichen, zentralisierten Steuerungsebene. Sie verringert erheblich die betriebliche Komplexität, die mit der Integration, dem Betrieb und der Verwaltung jeder einzelnen ADC-Appliance an verschiedenen Standorten verbunden ist.

(ID:50108944)