Kubernetes-Netzwerk 101

NodePort, LoadBalancer, Ingress-Controller … oh je!

Wenn wir mit Kunden und der Community darüber sprechen, wie Kubernetes produktionsreif gemacht werden kann, lautet eine der häufigsten Fragen: Brauche ich einen Ingress-Controller? Die Antwort auf diese Frage ist selten ein einfaches Ja oder Nein, sondern erfordert vielmehr einige Informationen zu den unterschiedlichen Möglichkeiten, wie Sie Verkehr zu Ihren Pods leiten können. In diesem Blog behandeln wir die Grundlagen der Kubernetes-Netzwerktechnologie, damit Sie eine fundierte Entscheidung darüber treffen können, ob und wann Sie einen Ingress-Controller benötigen.

Kubernetes unterstützt mehrere mögliche Ansätze und Ebenen zum Weiterleiten von externem Datenverkehr an einen Pod – aber sie sind nicht alle gleich. Das Standardmodell ist kube-proxy , das eigentlich kein Proxy ist und nicht dafür ausgelegt ist, den Datenverkehr auszugleichen, APIs zu steuern oder das Serviceverhalten zu überwachen.

Glücklicherweise gibt es andere Möglichkeiten, externen Datenverkehr zu verwalten. Doch bevor wir fortfahren, werfen wir einen kurzen Blick auf die Kubernetes-Komponenten:

• Kubernetes-Bereitstellungen bestehen aus Knoten , bei denen es sich um physische oder virtuelle Maschinen handelt.
• Knoten schließen sich zu einem Cluster zusammen.
• Jeder Cluster verwaltet Pods , die den kleinsten gemeinsamen Nenner auf Netzwerk- und Infrastrukturebene in Kubernetes darstellen. Ein oder mehrere Pods bilden zusammen einen Dienst .
• In jedem Pod befinden sich ein oder mehrere Container (je nach Anwendungsgröße).

Kubernetes überwacht die Pods, aus denen ein Dienst besteht, und skaliert sie nach Bedarf, um sie den App-Anforderungen anzupassen. Aber wie bekommt man Verkehr zu den Pods? Hier kommen zwei Arten von Kubernetes-Objekten ins Spiel: Dienste und Ingress-Controller.

Was ist ein Kubernetes-Dienst?

Laut der Kubernetes-Dokumentation ist ein Dienst „eine abstrakte Möglichkeit, eine App verfügbar zu machen, die auf einer Reihe von Pods ausgeführt wird“. Ein Dienst verbindet Pods in einem Cluster oder Netzwerk von Containern, sodass ihr Standort auf einem bestimmten Knoten nicht relevant ist. Dies bedeutet, dass externer Datenverkehr zu bestimmten Pods umgeleitet werden kann, selbst wenn sich deren Standorte ändern oder wenn sie zerstört und neu gestartet werden. Auf diese Weise verhält sich ein Dienst ähnlich wie ein sehr einfacher Reverseproxy.

Es gibt mehrere Arten von Diensten und Dienstobjekttypen, die für die Weiterleitung externen Datenverkehrs in Kubernetes relevant sind. Sie werden oft miteinander verwechselt, haben aber tatsächlich ganz unterschiedliche Aufgaben. Es lohnt sich also, ihre Funktionen, Einsatzmöglichkeiten und Nachteile genauer unter die Lupe zu nehmen.

ClusterIP

ClusterIP ist der Standarddienst, der einen Dienst innerhalb von Kubernetes bereitstellt, auf den andere Dienste innerhalb des Clusters zugreifen können. Von außerhalb des Clusters ist der Zugriff nicht möglich. Die einzige Möglichkeit, einen ClusterIP-Dienst verfügbar zu machen, besteht in der Verwendung von etwas wie „kube-proxy“ , aber es gibt nur wenige Szenarien, in denen dies sinnvoll ist. Zu den wenigen Beispielen gehören der Zugriff auf einen Dienst auf Ihrem Laptop, das Debuggen eines Dienstes oder das Betrachten einiger Überwachungs- und Messdaten.

KnotenPort

Ein NodePort-Dienst öffnet einen bestimmten Port auf jedem Knoten im Cluster und leitet den gesamten Datenverkehr, der über diesen Port an den Knoten gesendet wird, an die entsprechende App weiter. Dies ist eine sehr einfache Möglichkeit, Datenverkehr zu Ihren Apps zu leiten, und sie weist in tatsächlichen Anwendungsfällen zur Datenverkehrsverwaltung viele Einschränkungen auf. Sie können nur einen Dienst pro NodePort haben und nur Ports im Bereich 30000 bis 32767 verwenden. 2768 Ports klingen zwar viel, aber in Organisationen, die Kubernetes in großem Maßstab betreiben, sind diese schnell erschöpft. Darüber hinaus verwendet NodePort Layer-4-Routingregeln und das Linux-Dienstprogramm iptables , das das Layer-7-Routing einschränkt.

Neben den Routing-Einschränkungen gibt es drei weitere große Nachteile bei der Verwendung von NodePort:

• Downstream-Clients müssen die IP-Adresse jedes Knotens kennen, um eine Verbindung mit ihm herzustellen. Dies wird problematisch, wenn sich die IP-Adresse des Knotens oder der Host der virtuellen Maschine ändert.

• NodePort kann den Datenverkehr nicht an mehrere IP-Adressen weiterleiten.

• Wie im Diagramm dargestellt, bietet NodePort keinen Lastausgleich innerhalb von Kubernetes-Clustern, sodass der Datenverkehr zufällig auf die Dienste verteilt wird. Dies kann zu einer Überlastung des Dienstes und einer Erschöpfung der Ports führen.

  

Lastenausgleich

Ein LoadBalancer-Dienst akzeptiert externen Datenverkehr, erfordert jedoch einen externen Load Balancer als Schnittstelle für diesen Datenverkehr. Dies unterstützt Layer-7-Routing (zu Pod-IP-Adressen), vorausgesetzt, der externe Load Balancer ist richtig abgestimmt und neu konfiguriert, um eine Zuordnung zu laufenden Pods zu ermöglichen. LoadBalancer ist eine der beliebtesten Möglichkeiten, Dienste extern verfügbar zu machen. Es wird am häufigsten in einer Cloud-Plattform verwendet und ist eine gute Wahl für kleine, statische Bereitstellungen.

Wenn Sie einen verwalteten Kubernetes-Dienst verwenden, erhalten Sie automatisch den vom Cloud-Anbieter ausgewählten Load Balancer. Beispielsweise können Sie auf der Google Cloud Platform mit dem Diensttyp „LoadBalancer“ einen Network Load Balancer hochfahren, während bei AWS der Application Load Balancer (ALB) der Standard ist. Jeder von Ihnen bereitgestellte Dienst erhält seine eigene öffentliche IP-Adresse, die den gesamten Datenverkehr weiterleitet, jedoch ohne Filterung oder Weiterleitung. Dies bedeutet, dass Sie nahezu jede Art von Datenverkehr senden können (HTTP, TCP/UDP, WebSocket usw.). Wenn Sie die Tools des Cloud-Anbieters nicht verwenden möchten, z. B. wenn Sie mehr Funktionalität oder ein plattformunabhängiges Tool benötigen, können Sie diese alternativ durch etwas wie F5 BIG-IP (als externen Load Balancer) und F5 Container Ingress Services (als Operator, der als Load Balancer fungiert) ersetzen. Weitere Erläuterungen zu diesem Muster finden Sie unter „Bereitstellen von BIG-IP und NGINX Ingress Controller in derselben Architektur“ in unserem Blog.

Die Verwendung von LoadBalancer zum Bereitstellen Ihrer Apps wird in dynamischen Umgebungen zu einer Herausforderung, in denen Ihre App-Pods skaliert werden müssen, um den sich ändernden Anforderungen gerecht zu werden. Da jeder Dienst eine eigene IP-Adresse erhält, muss eine beliebte App möglicherweise Hunderte oder sogar Tausende von IP-Adressen verwalten. In den meisten Fällen stellt der externe Lastenausgleich über NodePort eine Verbindung zu den Diensten her, wie im folgenden Diagramm dargestellt. Dadurch wird zwar eine gleichmäßige Verteilung des Datenverkehrs auf die Knoten gewährleistet, ein Lastenausgleich für die Dienste ist jedoch immer noch nicht möglich, sodass es weiterhin zu einer Überlastung der Dienste und einer Erschöpfung der Ports kommt.

Was ist ein Kubernetes Ingress Controller?

Laut der Kubernetes-Dokumentation sind „Controller Kontrollschleifen, die den Zustand Ihres Clusters überwachen und dann bei Bedarf Änderungen vornehmen oder anfordern. Jeder Controller versucht, den aktuellen Clusterzustand näher an den gewünschten Zustand zu bringen.“ Controller werden verwendet, um den Status in Kubernetes für viele Aufgaben zu verwalten: ordnungsgemäße Zuweisung von Ressourcen, Bestimmung von dauerhaftem Speicher und Verwaltung von Cron-Jobs.

Im Kontext des Routings ist ein Ingress-Controller die Möglichkeit, die Einschränkungen von NodePort und LoadBalancer zu überwinden.

Ein Ingress-Controller wird zum Konfigurieren und Verwalten externer Interaktionen mit Pods verwendet, die einem bestimmten Dienst zugeordnet sind. Ingress-Controller sind so konzipiert, dass sie dynamisches Layer-7-Routing als erstklassig behandeln. Dies bedeutet, dass Ingress-Controller eine weitaus feinere Kontrolle und Verwaltung mit weniger Aufwand ermöglichen. Mit einem Ingress-Controller können Sie nicht nur den eingehenden Datenverkehr steuern, sondern auch Leistungsmesswerte auf Serviceebene bereitstellen und ihn als Teil einer Sicherheitsrichtlinie verwenden. Ingress-Controller verfügen über viele Funktionen herkömmlicher externer Lastenausgleichsmodule, wie etwa TLS-Terminierung, die Handhabung mehrerer Domänen und Namespaces und natürlich die Lastverteilung im Datenverkehr. Ingress-Controller können den Datenverkehr pro Anfrage statt pro Dienst ausgleichen. Dies bietet eine nützlichere Ansicht des Layer-7-Datenverkehrs und eine weitaus bessere Möglichkeit, SLAs durchzusetzen.

Und es gibt noch einen weiteren Bonus! Ingress-Controller können auch Egress-Regeln durchsetzen, die ausgehenden Datenverkehr von bestimmten Pods nur zu bestimmten externen Diensten zulassen, oder sicherstellen, dass der Datenverkehr mithilfe von mTLS gegenseitig verschlüsselt wird. Die Anforderung von mTLS ist von entscheidender Bedeutung für die Bereitstellung regulierter Dienste in Branchen wie dem Gesundheitswesen, dem Finanzwesen, der Telekommunikation und der öffentlichen Verwaltung – und es ist eine Schlüsselkomponente einer End-to-End -Verschlüsselungsstrategie (E2EE). Die Steuerung des ausgehenden Datenverkehrs über dasselbe Tool vereinfacht auch die Anwendung der Geschäftslogik auf Dienste. Es ist viel einfacher, geeignete Ressourcenregeln einzurichten, wenn Ein- und Ausgang in derselben Steuerebene verknüpft sind.

Das folgende Diagramm zeigt, wie ein Ingress-Controller die Komplexität für den Client reduziert, da dieser die IP-Adresse oder den Port eines Dienstes nicht mehr kennen muss. Eine Verteilung des Datenverkehrs auf die Dienste ist gewährleistet. Einige Ingress-Controller unterstützen mehrere Lastausgleichsalgorithmen für mehr Flexibilität und Kontrolle.

Bereitstellen eines Load Balancers mit einem Ingress Controller

Wie wir unter „Bereitstellen eines BIG-IP- und NGINX-Ingress-Controllers in derselben Architektur“ erläutern, gibt es in vielen Organisationen Anwendungsfälle, die vom Bereitstellen eines externen Load Balancers mit einem Ingress-Controller (oder in den meisten Fällen mehreren Ingress-Controller-Instanzen) profitieren. Dies kommt insbesondere dann häufig vor, wenn Unternehmen Kubernetes skalieren oder in Umgebungen mit hoher Compliance arbeiten müssen. Die Tools werden normalerweise von verschiedenen Teams verwaltet und für unterschiedliche Zwecke verwendet:

• Lastenausgleich (oder ADC):

  • Eigentümer: Ein NetOps- (oder vielleicht SecOps-)Team
  • Anwendungsfall: Außerhalb von Kubernetes als einziger öffentlicher Endpunkt für Dienste und Apps, die an Benutzer außerhalb des Clusters bereitgestellt werden. Wird als allgemeineres Gerät verwendet, das die Sicherheit verbessern und eine Netzwerkverwaltung auf höherer Ebene ermöglichen soll.

• Ingress-Controller:

  • Eigentümer: Ein Platform Ops- oder DevOps-Team
  • Anwendungsfall: Innerhalb von Kubernetes für eine feinkörnige Lastverteilung des Nord-Süd-Verkehrs (HTTP2, HTTP/HTTPS, SSL/TLS-Terminierung, TCP/UDP, WebSocket, gRPC), API-Gateway-Funktionen sowie zentralisierte Sicherheit und Identität.

Dieses Diagramm zeigt den Load Balancer, der die Verteilung des Datenverkehrs auf mehrere Cluster übernimmt, wobei die Cluster über Ingress-Controller verfügen, um eine gleichmäßige Verteilung auf die Dienste sicherzustellen.

Nächste Schritte

Wenn Sie das alles gelesen haben und sich immer noch am Kopf kratzen, sehen Sie sich das Webinar der Linux Foundation „Warum Sie einen Ingress-Controller benötigen und wie Sie einen auswählen“ an. Experten von NGINX geben darin eine Einführung in die Kubernetes-Netzwerke, tauchen tief in Ingress-Controller ein und diskutieren die Ingress-Controller-Landschaft.

Weitere Informationen zur Verwendung eines Ingress-Controllers und zur Auswahl des Controllers, der Ihren Anforderungen am besten entspricht, finden Sie im Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Identifizieren Sie Ihre Anforderungen in unserem Blog.