Einleitung
In früheren Blogs haben wir Kubernetes und Microservices vorgestellt und ihre Auswirkungen auf den Netzwerkbetrieb erörtert. Wir haben uns auch angesehen, wie Dienste veröffentlicht werden können und wie Kemp Ingress Controller dazu verwendet werden kann, auch neben monolithischen Anwendungen.
In unserem letzten Blog der Reihe werfen wir einen Blick auf die Auswirkungen, die der Umstieg auf eine Microservice-Anwendungsarchitektur auf Workflows haben kann, insbesondere im Hinblick auf die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) zwischen Entwicklungs- und Netzwerkbetriebsteams.
Aufrechterhaltung der erforderlichen Netzwerksteuerung
Bei der herkömmlichen monolithischen Anwendungsbereitstellung werden den Entwicklern in der Regel bestimmte Endpunkte zugewiesen, auf denen die Anwendungen gehostet werden, und sie kümmern sich um die Erstellung, Aktualisierung und Freigabe neuer Versionen in halbjährlichen Abständen. Die Teams für den Netzbetrieb konzentrieren sich darauf, die Erreichbarkeit dieser Anwendungen zu gewährleisten. In der Regel befassen sie sich mit der zugrunde liegenden Netzwerkinfrastruktur, einschließlich Aufgaben der Anwendungsbereitstellung wie Load-Balancing. SSL-Offloading und -Zertifikate, Zugriffsmanagement und Hostnamen- oder URL-basiertes Traffic-Routing. In dieser Organisationsstruktur arbeiten Entwicklung und Netzbetrieb Hand in Hand, und wenn Änderungen erforderlich sind, werden gemeinsame Arbeitsabläufe befolgt (Änderungsanträge usw.). Dies gewährleistet klare Abgrenzungen zwischen den Teams.
Mit dem Übergang zu Microservices ändert sich die Art und Weise, wie Entwicklungsteams Anwendungen erstellen und freigeben, in mehrfacher Hinsicht. In der Regel (und das ist ein großer Vorteil von Microservices) werden die Anwendungen häufiger aktualisiert und geändert. Die Netzwerkinfrastruktur ändert sich jedoch nicht auf die gleiche Weise oder mit der gleichen Häufigkeit. Was sich ändert, ist die Art und Weise, wie die Veröffentlichung von Anwendungen erfolgt, und diese ist in der Regel mehr auf die Entwicklungs-Workflows als auf die Workflows des Netzwerkbetriebs ausgerichtet. Dies kann eine Herausforderung darstellen, wenn es darum geht, die für den Netzbetrieb erforderliche Kontrolle aufrechtzuerhalten und gleichzeitig die fluide Web-Architektur von Microservices zu nutzen.
Wie können wir in dieser Architektur verhindern, dass Entwicklungsteams für alle Aktualisierungen die Genehmigung von Change Requests von Network Operations einholen müssen. Und gleichzeitig verhindern, dass Entwicklerteams die Kontrolle über die Netzwerkinfrastruktur haben?
Wie verhindern wir, dass Dev-Teams für alle Updates von Network Operations die Genehmigung von Change Requests einholen müssen, verhindern aber gleichzeitig, dass Dev-Teams die Kontrolle über die Netzwerkinfrastruktur haben?
Ein gängiger Ansatz ist der Wechsel zu Dev-Ops-Teams, die alle Aspekte der Anwendung verwalten, und viele der vorhandenen empfohlenen Strategien für Microservices gehen von dieser flachen Dev-Ops-Teamstruktur aus. Die Realität für viele Unternehmen ist jedoch, dass es aufgrund regulatorischer Anforderungen oder bei personellen Diskrepanzen nicht machbar oder wünschenswert ist, auf dieses Modell umzusteigen.
Dienstmodus für Microservices
Für das beschriebene Problem unterstützt Kemp Ingress Controller einen eingeschränkten Servicemodus für die Veröffentlichung von Microservice-Anwendungen. Mit dem Dienstmodus können Netzwerkbetriebsteams Entwicklungsteams die Möglichkeit geben, ihre Anwendung mithilfe von Kubernetes zu veröffentlichen, ohne ihnen Zugriff und Kontrolle über die zugrunde liegende Netzwerkinfrastruktur zu geben. Das Entwicklungsteam definiert keine Ingress-Ressource, sondern wird über den Kemp LoadMaster verwaltet.
Der Arbeitsablauf ist recht einfach
- LoadMaster ist mit dem Kemp Ingress Controller in den Kubernetes-Cluster integriert und der Service-Modus ist aktiviert
- Entwicklungsteam: Anfordern eines neuen Anwendungsendpunkts für die Veröffentlichung
- Network Operation: Erstellen einen Endpunkt (virtuellen Dienst) auf externem LoadMaster
- Network Operations: weist die ID davon dem Entwicklungsteam zu
- Entwicklungsteam: markiert und kommentiert diese ID
Von diesem Zeitpunkt an können alle Änderungen an dieser eigentlichen Anwendung vorgenommen werden, ohne dass eine Interaktion zwischen den Teams erforderlich ist, einschließlich der Skalierung der Anwendung. Die Vorteile des oben genannten Ansatzes bestehen darin, dass die Aspekte der Anwendung wie IP-Adresse, Port, Zugriffsverwaltung und Web Application Firewall alle von den Network Operations Teams gesteuert werden können, während das Entwicklungsteam alle internen Anwendungsaspekte verwalten kann. Wenn die Anwendungen hochskaliert werden, skaliert der LoadMaster ebenfalls automatisch.
Ingress-Modus
Kemp Ingress Controller unterstützt nicht nur den Service-Modus, sondern auch den Ingress-Modus, in dem Regeln und Anmerkungen von den Entwicklungsteams definiert werden können. Dieser Modus entspricht dem typischen Ingress-Controller-Betrieb in der Kubernetes.
Die Unterstützung beider Modi sorgt für Flexibilität und ermöglicht einen nahtlosen, kontrollierten Übergang zur Bereitstellung von Microservice-Anwendungen.
Schlussfolgerung
Bei der Umstellung auf die Bereitstellung von Microservice-Anwendungen müssen die Teamstrukturen und die Rollen der Netzwerkinfrastruktur berücksichtigt werden. Durch die Anpassung einer Lösung, die sowohl die Flexibilität von Microservices für Entwickler als auch die getrennte Kontrolle der Netzwerkinfrastruktur ermöglicht, wie sie der Kemp Ingress Controller Service-Modus bietet, kann diese Herausforderung gemeistert werden. Um die volle Funktionalität des Kemp Ingress Controllers zu nutzen, lesen 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.
