Lesen Sie hier den Beitrag von letzter Woche über die Auswirkungen von Kubernetes auf Netzwerkadministratoren.
Container-basierte Microservice-Anwendungen bieten Vorteile für die Entwicklung und den Betrieb von Anwendungen, und Kubernetes ist die beliebteste Plattform für die Container-Verwaltung und -Orchestrierung. Der Übergang zu dieser Anwendungsarchitektur bringt eine Reihe von Änderungen mit sich, die hier erläutert werden. Eine der wichtigsten Überlegungen für einen Netzwerkadministrator ist die Verwaltung und Aufrechterhaltung der Verfügbarkeit der Anwendung für die Benutzer und insbesondere der Verkehrsweg in den Kubernetes-Cluster, um die entsprechenden Microservices zu erreichen. Es gibt eine Reihe von Optionen, wie dies erreicht werden kann.
Lassen Sie uns zunächst die beiden wichtigsten Objekte in Kubernetes erwähnen – Deployments und Services.
Mit einem Deployment wird der gewünschte Zustand einer Anwendung definiert, einschließlich des zu verwendenden Images und der Anzahl der Instanzreplikate, die ausgeführt werden sollen. Sobald die Instanzen erstellt sind, überwacht ein Kubernetes Deployment Controller diese Instanzen kontinuierlich, um sicherzustellen, dass dieser Zustand beibehalten wird.
Ein Dienst hingegen ist die Art und Weise, wie Richtlinien für den Zugriff auf eine Anwendung definiert werden können. Da Microservices in der Regel bedeuten, dass eine Anwendung in viele Unterkomponenten aufgeteilt ist, können verschiedene Teile der Anwendung über unterschiedliche Servicetypen zugänglich gemacht werden, je nachdem, ob ein externer Zugriff erforderlich ist (z. B. eine Frontend-Webseitenkomponente) oder ob der Microservice nur für andere Microservices zugänglich ist (z. B. eine interne Datenbank).
Untersuchen wir die verschiedenen Diensttypen und wie das Routing des Datenverkehrs in den Kubernetes-Cluster erfolgt - eine wichtige Überlegung für jeden Netzwerkadministrator.
Cluster-IP ist der Standarddiensttyp. Damit wird der Dienst auf einer internen IP-Adresse innerhalb des Kubernetes-Clusters bereitgestellt. Dieser Diensttyp ist in der Regel nur von innerhalb des Kubernetes-Clusters erreichbar.
Dies ist natürlich nicht sinnvoll, wenn Sie einen Dienst für die externe Nutzung freigeben wollen. Betrachtet man jedoch eine Anwendung, die in viele Microservices unterteilt ist, so ist es sehr wahrscheinlich, dass eine große Anzahl von Services nur von anderen Microservices genutzt wird und daher keine externe Nutzung erforderlich ist.
Für Frontend-Dienste, die von außen erreichbar sein müssen, gibt es eine Reihe alternativer Optionen.
NodePort (KnotenPort)
NodePort erweitert den Typ Cluster-IP, indem es die interne IP-Adresse und Portnummer auf einen externen Port auf jedem Kubernetes-Knoten abbildet. Da es sich bei den Knoten um Server (virtuell oder Hardware) handelt, die außerhalb von Kubernetes geroutet werden können, können Benutzer einfach auf einen der Knoten am angegebenen Port zugreifen, um den Dienst zu nutzen. Jeder Knoten im Kubernetes-Cluster lauscht auf dem eindeutigen Port, der jedem "Node Port"-Dienst zugewiesen ist, und übersetzt empfangene Anfragen mithilfe von Network Address Translation (NAT) in die interne Cluster-IP.
NodePort birgt einige Herausforderungen. Erstens: Wenn Datenverkehr an einem NodePort ankommt, gibt es keine Garantie, dass eine Pod-Instanz für den Mikrodienst auf dem Knoten vorhanden ist, was bedeutet, dass der Datenverkehr möglicherweise über einen zweiten Knoten weitergeleitet werden muss. (Diese Knoten-Knoten-Weiterleitung kann durch die Einstellung von externalTrafficPolicy auf local verhindert werden, würde aber dazu führen, dass die Anfrage nicht beantwortet wird).
Eine weitere Herausforderung besteht darin, dass bei einer großen Anzahl von Webdiensten, wie sie häufig vorkommen, die Übersicht darüber, welcher Webdienst an welchem Port verfügbar ist, schwierig ist, da jeder Dienst eine eigene Portnummer benötigt und bekannte Ports wie 80/443 nicht mehrfach verwendet werden können.
NodePort-Optionen können verwendet werden, um die Effizienz der Datenverkehrslenkung zu erhöhen. Die LocalService-Richtlinie zwingt beispielsweise einen Knoten, nur dann Verkehr anzunehmen, wenn eine laufende Instanz des Dienstes auf dem Knoten enthalten ist, wodurch der Ost-West-Verkehr minimiert wird.
LoadBalancer
Das Problem der Veröffentlichung von Diensten auf bekannten Ports kann in vielen Kubernetes-Lösungen von Cloud-Anbietern mit unserem nächsten Diensttyp - LoadBalancer - gelöst werden. Wenn dies in der Service-Definition angegeben ist und der Cloud-Provider es unterstützt, wird ein externer Load Balancer in der Cloud erstellt und weist eine feste, externe IP zu, um den externen Zugriff zu ermöglichen. Dieser Load Balancer kann auf einem bekannten Port (80/443) veröffentlicht werden und verteilt den Datenverkehr über Nodeports, wobei die verwendeten internen Ports für den Benutzer verborgen bleiben.
Dies ist zwar eine nützliche Option, aber es gibt eine Reihe von Herausforderungen.
Zunächst einmal setzt der Typ Load-Balancer eine Cloud-Kubernetes-Plattform voraus, die den Typ Loadbalancer unterstützt. Zweitens können mehrere Cloud-Load-Balancer erstellt werden, da dies auf Service-Ebene erfolgt, was Kosten verursachen kann. Wenn eine Organisation nur über eine bestimmte öffentliche IP-Adresse verfügt, ist häufig ein Proxy vor dem/den dienstspezifischen Load-Balancer(n) erforderlich, um den Datenverkehr auf der Grundlage der verwendeten URL oder des Hostnamens an andere zu leiten. Wenn N Dienste zugänglich gemacht werden, sind N+1 Load-Balancer erforderlich, die möglicherweise nicht skalierbar sind.
Ingress-Controller
Um die Skalierbarkeitsprobleme des Typs Load Balancer zu lösen, gibt es den Ingress-Controller. Mit dem Ingress Controller kann ein einzelner Endpunkt mehreren Anwendungen zugeordnet werden. Dies geschieht durch die Konfiguration einer Ingress-Ressource in Kubernetes unter Verwendung des Hostnamens/der Pfade für die Weiterleitung des Datenverkehrs an bestimmte Dienste. Der Ingress Controller kann innerhalb von Kuberntes als Container oder extern zu Kubernetes implementiert werden.
Wenn der Ingress Controller als Container ausgeführt wird, bringt dies alle Vorteile der Containerisierung für den Ingress Controller mit sich. Der Ingress Controller selbst wird in der Regel als Typ Nodeport verfügbar gemacht, aber da er die Routingregeln für den Datenverkehr enthält, die von der Ingress-Ressource definiert werden, können mehrere Dienste einem einzelnen Port zugeordnet werden (z. B. 80/443). Ingress Controller können selbst hinter einem externen Load Balancer oder Reverse Proxy (nicht zu verwechseln mit dem oben definierten Servicetyp Load Balancer) platziert werden, der den Datenverkehr auf die Kubernetes-Knoten verteilt.
Der Ingress-Controller kann auch außerhalb des Kubernetes-Clusters ausgeführt werden, wie es der von Kemp Ingress Controller verwendete Ansatz ist. Bei diesem Ansatz werden die Regeln weiterhin in der Ingress-Ressource in Kubernetes definiert, aber ein externes Gerät erfüllt die Funktion, den Datenverkehr an die richtigen Pods auf dem richtigen Knoten weiterzuleiten. Dieser Ansatz erfordert möglicherweise eine gewisse Routenkonfiguration, um Datenverkehr an die richtigen Knoten zu senden, um bestimmte Pods zu erreichen, profitiert jedoch von einem effizienten Pfad für eingehenden Datenverkehr
Zusammenfassung
Im nächsten Abschnitt werden wir die Funktionalität des Ingress Controllers genauer untersuchen und die verschiedenen Optionen für diese bereitstellen.
Um die Funktionalität des Kemp Ingress Controllers voll auszuschöpfen, klicken Sie hier...
MIT KEMP
Weitere Informationen finden Sie in unserem bevorstehenden Webinar: Integrating Kemp Load Balancing with Kubernetes.