Einleitung
Nach der Einführung von Kuberntes in der letzten Woche befassen wir uns diese Woche mit den Auswirkungen von Kubernetes auf Netzwerkadministratoren. In letzter Zeit gibt es ein großes Interesse an der Umstellung auf Microservice-Anwendungen. Ein kürzlich veröffentlichter O'Reilly-Bericht zeigt, dass mehr als 60 % der Befragten Microservices seit einem Jahr oder länger nutzen und fast ein Drittel (29 %) sagt, dass ihre Arbeitgeber einen Großteil ihrer Systeme auf Microservices umstellen oder implementieren. Obwohl sie für Microservices nicht unbedingt erforderlich sind, eignen sich containerisierte Architekturen hervorragend für Microservices, und in den meisten Fällen wird Kubernetes als Orchestrierungstool für die Verwaltung verwendet.
Die Vorteile der Umstellung sind klar benannt worden. Microservices helfen Entwicklern dabei, Anwendungen in einfacher zu verwaltende Komponenten aufzuteilen, Code-Abhängigkeiten zu minimieren, mehr Flexibilität in der Technologie zu bieten und die Wiederverwendbarkeit zu verbessern. Aus Sicht der Entwicklungs- und Betriebsabteilung ermöglicht dies eine schnellere und einfachere Bereitstellung neuer Funktionen, baut Barrieren für Aktualisierungen ab und ermöglicht eine einfache Skalierung von Anwendungen.
Aber was ist mit Netzwerkadministratoren? Die Bereitstellung von Anwendungen über Microservices verändert nicht nur die Art und Weise, wie die Anwendungen entwickelt und freigegeben werden, sondern wirkt sich auch darauf aus, wie der Datenverkehr der Endbenutzer die Anwendung erreicht - etwas, das für jeden Netzwerkadministrator von Interesse ist.
Wichtige Überlegungen für Netzwerkadministratoren.
In jedem Unternehmen erfordert die erfolgreiche Einführung von Microservices die Zustimmung aller Beteiligten, nicht zuletzt derjenigen, die für die Netzverfügbarkeit und die Erreichbarkeit von Anwendungen verantwortlich sind. Eine erfolgreiche Umstellung hängt daher davon ab, dass die Änderungen an diesen Aspekten der Anwendung vollständig verstanden werden. Um dies zu verstehen, müssen wir die Unterschiede im Anwendungsdesign vergleichen.
Vergleich der Anwendung
In der herkömmlichen (monolithischen) Infrastruktur laufen die Anwendungen auf verschiedenen Servern (virtuell, in der Cloud oder auf Hardware), und die Endpunkte der Anwendungen sind in der Regel die Server selbst (oder zumindest über eine eindeutige Portnummer auf einem Server bereitgestellt). Infolgedessen ist die Anzahl der Anwendungsendpunkte relativ konstant. Upgrades und Änderungen an diesen sind nicht allzu häufig und verursachen einige Verwaltungskosten, wie z. B. Wartungsfenster und/oder Verlust der Redundanz. Zusätzliche Server-Endpunkte werden hinzugefügt (vielleicht bei steigender Nachfrage), was jedoch nicht häufig vorkommt. Da die Anwendungen in sich geschlossen sind, wird außerdem der meiste Verkehr von den Clients zur Anwendung abgewickelt (allgemein als Nord-Süd-Datenverkehr bezeichnet), und es gibt weniger Verkehr von Anwendung zu Anwendung ("Ost-West-Datenverkehr") im Netz.
Im Fall von containerisierten Microservices ändern sich diese Eigenschaften. Anstatt mit Anwendungsservern gekoppelt zu sein, werden Anwendungen in Containern innerhalb von Kubernetes-Pods ausgeführt, die auf einem Cluster aus zwei oder mehr Knoten gehostet werden, und es besteht kaum eine Abhängigkeit zwischen der Anzahl der Knoten und der Anzahl der Pods. Die Anzahl der Container, die für eine Anwendung verwendet werden, kann sich regelmäßig ändern, und die automatische Skalierung ermöglicht es, diese Anzahl je nach Bedarf dynamisch zu erhöhen oder zu verringern. Änderungen an Anwendungen sind viel weniger umständlich, und neue Anwendungscontainer können bei Bedarf oder dynamisch neu erstellt und vernichtet werden. Da die Anwendungen aus vielen Microservices bestehen, wird außerdem ein großes Datenvolumen zwischen den Microservices gesendet, möglicherweise über verschiedene Knoten im Cluster (Ost-West-Verkehr).
Herausforderungen bei der Anwendungsbereitstellung
Die beschriebenen Änderungen bringen ihre eigenen Herausforderungen mit sich, wenn es darum geht, sicherzustellen, dass alle Benutzer jederzeit auf die Anwendungen zugreifen können. Bei herkömmlichen monolithischen Anwendungen ist ein Netzwerkadministrator in der Regel für die Bereitstellung einer Anwendung über einen Endpunkt verantwortlich, der in der Regel auf einem Load Balancer für die Anwendungsredundanz konfiguriert ist. Parallel dazu wird eine intelligente Zustandsprüfung durchgeführt, um sicherzustellen, dass der Datenverkehr nur an Server gesendet wird, die für die Bearbeitung von Anfragen verfügbar sind. Wenn Server nicht verfügbar sind, stellt die Redundanz sicher, dass die Anwendungsverfügbarkeit aufrechterhalten wird (zumindest bei einem allgemeinen Kapazitätsverlust), und die Fehlerbehebung/Eskalation wird ausgelöst, um die Gesamtverfügbarkeit zu gewährleisten. Anwendungen können durch SSL-Offloading und Caching optimiert werden, die normalerweise von einem Load-Balancer/Application Delivery Controller durchgeführt werden. Schließlich können Inhaltsregeln/Richtlinien konfiguriert werden, so dass bestimmter Datenverkehr an einen bestimmten Server gesendet wird, der in der Regel auf einem Pfad, Hostnamen oder Gerät basiert.
Bei Kubernetes beginnt die Anwendungsverfügbarkeit mit der Entscheidung, wie ein Dienst über eine Kubernetes-Dienstkonfiguration für externe Clients verfügbar gemacht wird. Hierfür gibt es eine Reihe von Diensttypen zur Auswahl. Einige Dienste müssen von externen Clients nicht zugänglich sein, wie z. B. Backend-Code, während andere zugänglich sein müssen, wie z. B. eine Frontend-Webseite. Es können auch Regeln zur Steuerung des Datenverkehrs beim Eintritt in den Kubernetes-Cluster definiert werden, die allgemein als Ingress-Richtlinie bezeichnet werden. Erweiterte Funktionen wie Caching und SSL-Offloading können dann entweder innerhalb oder außerhalb von Kubernetes konfiguriert werden. Da die Anwendung nun aus einer Reihe separater Microservices besteht, muss der Datenverkehr zwischen den Services berücksichtigt werden, der gemeinhin als Ost-West-Datenverkehr bezeichnet wird.
Die Herausforderungen von monolithischen Diensten und Microservices sind zwar unterschiedlich, aber kein Grund, sich entmutigen zu lassen. Mit Kemp Ingress Controller können sowohl monolithische als auch Microservice-Anwendungen über eine gemeinsame Schnittstelle nebeneinander verwaltet werden.
Zusammenfassung
Es ist klar, dass der Wechsel zu Kubernetes nicht nur Auswirkungen auf die Entwicklungsteams hat, sondern auch auf alle Funktionen, die für die Anwendungs- und Netzwerkverfügbarkeit verantwortlich sind. Die größte Auswirkung aller Änderungen ist vielleicht darin zu sehen, wie eine Anwendung von einem Kubernetes-Dienst bereitgestellt wird. Im nächsten Abschnitt sehen wir uns die verschiedenen Serviceoptionen an.
Um die Funktionalität des Kemp Ingress Controllers voll auszuschöpfen, klicken Sie hier...
Die Ingress-Controller-Serie
- WAS IST KUBERNETES?
- AUSWIRKUNGEN VON KUBERNETES AUF NETZWERKADMINISTRATOREN
- VERFÜGBARMACHEN VON KUBERNETES-DIENSTEN
- DER KEMP INGRESS CONTROLLER ERKLÄRT
- EIN HYBRIDER ANSATZ FÜR MICROSERVICES
Webinar
Weitere Informationen finden Sie in unserem Webinar: Integrating Kemp Load Balancing with Kubernetes.
