Einleitung
In unseren vorherigen Blogs haben wir Kubernetes und die Herausforderungen, die es für Netzwerkadministratoren mit sich bringt, erläutert und die verschiedenen Mechanismen beschrieben, um Kubernetes-Dienste für den Benutzerzugriff verfügbar zu machen. Es ist klar, dass es eine Reihe von Optionen gibt. In diesem Blog werfen wir einen genaueren Blick auf die Ingress Controller-Komponente und einige Auswahlmöglichkeiten bei der Implementierung.
Ingress Resource v Ingress Controller
Zunächst einmal ist es wichtig, zwischen der Ingress-Ressource und dem Ingress-Controller zu unterscheiden, wenn es um Ingress geht. Die Ingress-Ressource definiert, wie der Datenverkehr beim Eintritt in Kubernetes behandelt werden soll, während der Ingress-Controller die von dieser Ressource definierten Aktionen ausführt. Das folgende Diagramm veranschaulicht die beiden Komponenten.
Eingehende Ressource
Im Folgenden finden Sie ein Beispiel für eine Eingangsressource, die im YAML-Format definiert ist:
# kemp-ingress.yaml apiVersion: extensions/v1beta1 kind: Ingress Metadaten: name: kemp-ingress Annotationen: "kubernetes.io/ingress.class": "kempLB" "kemp.ax/vsip": "10.151.0.234" "kemp.ax/vsport": "80" "kemp.ax/vsprot": "tcp" "kemp.ax/vsname": "InboundKubernetesVs" spec: rules: - host: guest.kemp.ax http: Pfade: - Pfad: /guestinput backend: serviceName: guestfront servicePort: 80 - host: vote.kemp.ax http: Pfade: - Pfad: /voteinput Backend: serviceName: votefront servicePort: 80
Diejenigen, die mit Kubernetes vertraut sind, werden feststellen, dass die Definition einer Ingress-Ressource der eines Kubernetes-Dienstes ähnelt und die Abschnitte Metadata und Spec enthält. Der Unterschied besteht darin, dass der Ingress Regeln enthält, die definieren, wie der Datenverkehr beim Betreten von Kubernetes gehandhabt werden soll. In diesem Beispiel sollten übereinstimmende guest.kemp.ax/guestinput an den Gastfront-Dienst gesendet werden, und Datenverkehr, der vote.kemp.ax/voteinput entspricht , sollten an den votefront-Dienst gesendet werden.
Es ist wichtig zu wissen, dass das Erstellen einer eingehenden Ressource allein keinen Unterschied bei der Verarbeitung des Datenverkehrs verursacht. Damit dies realisiert werden kann, muss ein Ingress Controller vorhanden sein, der das Definierte auch tatsächlich umsetzt.
Eingehender Controller
Die Aufgabe des Eingangscontrollers besteht darin, die Definition in der Eingangsressource in die Tat umzusetzen. Dies wird erreicht, indem der eingehende Datenverkehr untersucht und auf der Grundlage der definierten Regeln Anfragen angemessen verwaltet werden (z. B. Verteilung an die richtigen Pods). Um sicherzustellen, dass der Anwendungszugriff optimiert ist, sollte er Vorteile wie Persistenz und Planung bieten. Neben der Verteilung des Datenverkehrs kann ein Ingress Controller erweiterte Funktionen wie SSL/TLS-Offloading, Web Application Firewall, Zugriffsverwaltung, Caching und Ratenbegrenzung ausführen, um nur einige zu nennen.
Für diejenigen, die mit dem Load Balancing traditioneller "monolithischer" Anwendungen vertraut sind, wird dies bekannt klingen. Ein Load Balancer verteilt den Datenverkehr auf "Real Server", während ein Ingress Controller auf die Service Pods verteilt. Ein Ingress-Controller unterscheidet sich durch die Art und Weise, wie Intelligenz integriert wird, um sicherzustellen, dass der Datenverkehr immer an einen verfügbaren Endpunkt weitergeleitet wird. Beim monolithischen Lastenausgleich sind die Zielserver relativ statisch, und die Zustandsprüfung stellt sicher, dass nicht leistungsfähige Server aus der Rotation genommen werden. Da der Ingress Controller innerhalb des Orchestrators (Kubernetes) definiert ist, funktioniert er etwas anders, da Kubernetes die Service-Pods orchestriert (bei Bedarf löscht und neu erstellt) und der Ingress Controller sich anpasst, um Datenverkehr an alle vorhandenen Pods zu senden.
Während der traditionelle Lastenausgleich und der eingehende Lastenausgleich also ähnlich sind, unterscheiden sie sich in der Art und Weise, wie Änderungen an Anwendungsendpunkten gehandhabt werden. Kemp Ingress Controller ermöglicht beide Betriebsmodi und bietet alle erweiterten Dienste von LoadMaster zusammen mit der dynamischen Ingress Controller-Funktionalität.
Containerisierter Ingress-Controller?
Abhängig von den Einstellungen kann der Ingress Controller als Sammlung von Containern implementiert werden, die von Kubernetes verwaltet werden, oder als externe Ressource außerhalb von Kubernetes. Werfen wir einen Blick auf diese beiden Optionen.
Containerisierter Eingangsregler
Das Ausführen von containerisierten Ingress Controller-Instanzen bringt alle Vorteile der Containerisierung mit sich und ermöglicht die Bereitstellung über mehrere Container in einem Kubernetes-Cluster (in der Regel als einzelner Nodeport-Dienst verfügbar).
Da ein Ingress-Controller auf mehreren Kubernetes-Knoten verfügbar ist, ist es üblich, dass ein externer Load Balancer verwendet wird, um den Datenverkehr auf zwei Ebenen auf diese zu verteilen. Einige Eingangscontroller enthalten Funktionen zum automatischen Aktualisieren dieses externen Load Balancers als Reaktion auf Änderungen in den Eingangscontroller-Containern. Dieser wird manchmal auch als "External Load Balancer" bezeichnet, da er sich außerhalb von Kubernetes befindet.
Ein potenzielles Problem bei einem zweistufigen Ansatz besteht darin, dass er zu unnötigem "doppeltem Lastausgleich" führen kann. Müssen wir wirklich einen Lastenausgleich über die Knoten durchführen, nur damit ein containerisierter Ingress-Controller dann auf Pods innerhalb des Clusters verteilt werden kann? Wie veranschaulicht werden kann, kann dies zu unnötigem knotenübergreifendem Datenverkehr führen (allgemein als Ost-West-Verkehr bezeichnet)
Ein weiteres Problem, das berücksichtigt werden sollte, besteht darin, dass bei hohem Datenverkehrsaufkommen möglicherweise intensive Rechenressourcen für Aufgaben wie SSL/TLS-Offloading erforderlich sind, und diese können besser auf einem dedizierten "Kernel-Space"-Gerät (extern) bereitgestellt werden als auf einer containerisierten User-Space-Anwendung, die möglicherweise nicht die gleichen Leistungsfähigkeiten aufweist.
Nicht containerisierter/externer Eingang
Bei Kemp Ingress Controller besteht der gewählte Ansatz darin, die Rolle des externen Load Balancers und des Ingress-Controllers in einem auszuführen und eine saubere Lösung bereitzustellen. Sobald die richtigen Routen für Pod-Netzwerke konfiguriert wurden (falls erforderlich), ermöglicht dies eine effiziente Verarbeitung des Datenverkehrs und reduziert auch die Anzahl der Entitäten, die verwaltet werden müssen. Dies hat den zusätzlichen Vorteil, dass ein einziger LoadMaster sowohl für die Verwaltung von Microservices als auch von monolithischen Service-Endpunkten verwendet werden kann – unerlässlich, wenn es um eine reibungslose Migration von Anwendungen auf eine Microservice-Architektur geht.
Service-Modus
Eine letzte Herausforderung beim Ingress-Management ist die Zuweisung von Endpunkten an separate Teams. Für eine Dev-Ops-Organisation ist das Konzept des Ingress Controllers einfach zu implementieren, da ein einzelnes Team sowohl für den Betrieb als auch für die Entwicklung einer Anwendung verantwortlich ist. In anderen Organisationsstrukturen ist dies nicht der Fall. Ein Network Operations-Team benötigt möglicherweise eine strenge Kontrolle über die Netzwerkendpunkte und wäre im Idealfall in der Lage, Teams für Kubernetes-Anwendungen dedizierte Endpunkte zuzuweisen, ohne die volle Kontrolle zu delegieren. Kemp Ingress Controller fügt die Option "Service Mode" für die effiziente Delegierung von Endpunkten für Kubernetes-Anwendungen hinzu. (Dies geschieht neben dem normalen "Ingress Controller"-Betrieb des "Ingress Mode")
Im Dienstmodus kann einem bestimmten Kubernetes-Dienst mithilfe von Anmerkungen eine dedizierte LoadMaster-VM-ID zugewiesen werden, und jedes Hoch- und Herunterskalieren wird automatisch auf den virtuellen Dienst angewendet.
Zusammenfassung
Der Ingress-Controller ist eine wichtige Komponente für die Bereitstellung von Microservice-Anwendungen. Ingress Controller erfüllen viele der Funktionen eines herkömmlichen Load Balancers mit automatischer Anpassung an Änderungen in Ziel-Pods, wie sie von Kubernetes orchestriert werden. Mit Kemp Ingress Controller kann der LoadMaster verwendet werden, um die Rolle des Ingress Controllers auszuführen. Dies ermöglicht ein effizientes Routing des Datenverkehrs und gleichzeitig flexible Bereitstellungsoptionen neben monolithischen Anwendungen.
Im nächsten Blog werden wir uns ansehen, wie sowohl monolithische als auch Microservice-Anwendungen zusammen mit Kemp Ingress Controller auf LoadMaster verwaltet werden können.
Um die Funktionalität des Kemp Ingress Controllers in vollem Umfang zu nutzen, klicken Sie hier...
Die Ingress Controller-Serie
- WAS IST KUBERNETES?
- AUSWIRKUNGEN VON KUBERNETES AUF NETZWERKADMINISTRATOREN
- BEREITSTELLEN VON KUBERNETES-DIENSTEN
- DER KEMP INGRESS CONTROLLER ERKLÄRT
- EIN HYBRIDER ANSATZ FÜR MICROSERVICES MIT KEMP
