NGINX- und NGINX Plus-Ingress-Controller für Kubernetes-Lastausgleich

Das Ausführen und Verwalten von Microservices-Anwendungen in Containern in großem Maßstab über einen Maschinencluster hinweg ist eine anspruchsvolle Aufgabe. Kubernetes unterstützt Sie bei der Bewältigung dieser Herausforderung, indem es Ihnen eine leistungsstarke Lösung zur Container-Orchestrierung bietet. Es umfasst mehrere wichtige Funktionen, wie Fehlertoleranz, automatische Skalierung, fortlaufende Updates, Speicherung, Diensterkennung und Lastausgleich.

In diesem Blogbeitrag erklären wir, wie man NGINX Open Source oder NGINX Plus mit Ingress verwendet, dem integrierten Kubernetes-Load-Balancing-Framework für HTTP-Verkehr. Mit Ingress können Sie Regeln konfigurieren, die die Weiterleitung des externen Datenverkehrs zu den Diensten in Ihrem Kubernetes-Cluster steuern. Sie können jeden Load Balancer auswählen, der einen Ingress-Controller bereitstellt. Dabei handelt es sich um eine Software, die Sie in Ihrem Cluster bereitstellen, um Kubernetes und den Load Balancer zu integrieren. Hier zeigen wir Ihnen, wie Sie den Lastenausgleich für eine Microservices-Anwendung mit Ingress und den Ingress-Controllern konfigurieren, die wir für NGINX Plus und NGINX bereitstellen.

[Editor – Die zuvor separaten Controller für NGINX und NGINX Plus wurden zu einem einzigen Ingress-Controller für beide zusammengeführt.]

In diesem Blogbeitrag untersuchen wir nur das HTTP-Lastausgleichssystem für Kubernetes mit Ingress. Weitere Informationen zu anderen Optionen zum Lastenausgleich finden Sie unter „Lastenausgleich für Kubernetes-Dienste mit NGINX Plus“ in unserem Blog.

Notiz: Vollständige Anweisungen für die in diesem Blogbeitrag beschriebenen Verfahren finden Sie in unserem GitHub-Repository . Dieser Beitrag führt nicht durch jeden notwendigen Schritt, sondern bietet stattdessen Links zu diesen Anweisungen.

Ingress-Controller für NGINX und NGINX Plus

Bevor wir die Beispielanwendung bereitstellen und den Lastenausgleich dafür konfigurieren, müssen wir einen Lastenausgleich auswählen und den entsprechenden Ingress-Controller bereitstellen.

Ein Ingress-Controller ist eine Software, die einen bestimmten Load Balancer in Kubernetes integriert. Wir haben einen Ingress-Controller sowohl für NGINX Open Source als auch für NGINX Plus entwickelt, der jetzt in unserem GitHub-Repository verfügbar ist. Es gibt auch andere Implementierungen, die von Drittanbietern erstellt wurden. Weitere Informationen finden Sie auf der Seite „Ingress Controllers“ im GitHub-Repository für Kubernetes.

Vollständige Anweisungen zum Bereitstellen des NGINX- oder NGINX Plus-Ingress-Controllers in Ihrem Cluster finden Sie in unserem GitHub-Repository .

Die Beispiel-Microservices-Anwendung

Unsere Beispielanwendung ist eine typische Microservices- Webanwendung, die aus mehreren Diensten besteht, die jeweils separat bereitgestellt werden. Über die Anwendung mit dem Namen „Café “ können Sie entweder Tee über den Teeservice oder Kaffee über den Kaffeeservice bestellen. Deine Getränkepräferenz gibst du mit der URI deiner HTTP-Anfrage an: Mit URIs, die mit /tea enden, erhalten Sie Tee, und mit URIs, die mit /coffee enden, erhalten Sie Kaffee. Verbindungen zur Anwendung müssen mit SSL/TLS gesichert werden.

Das folgende Diagramm stellt die Anwendung konzeptionell dar, wobei der Load Balancer von NGINX Plus die wichtige Rolle spielt, Clientanforderungen an den entsprechenden Dienst weiterzuleiten und Clientverbindungen mit SSL/TLS zu sichern.

Um die Anwendung in Ihrem Cluster bereitzustellen, folgen Sie den Anweisungen in unserem GitHub-Repository .

Konfigurieren des Kubernetes-Lastausgleichs über Ingress

Unsere Café- App erfordert vom Load Balancer zwei Funktionen:

• Routing basierend auf der Anforderungs-URI (auch pfadbasiertes Routing genannt)
• SSL/TLS-Terminierung

Um den Lastenausgleich mit Ingress einzurichten, legen Sie Regeln in einer Ingress-Ressource fest. Die Regeln bestimmen, wie Sie externen Datenverkehr an die Dienste in Ihrem Cluster weiterleiten.

In der Ressource definieren Sie mehrere virtuelle Server, jeweils für unterschiedliche Domainnamen. Ein virtueller Server entspricht meist einer einzelnen Microservices-Anwendung, die im Cluster läuft. Für jeden Server können Sie:

• Geben Sie mehrere pfadbasierte Regeln an. Der Datenverkehr wird basierend auf der Anforderungs-URI an verschiedene Dienste in einer Anwendung gesendet.
• Richten Sie die SSL/TLS-Terminierung ein, indem Sie auf ein SSL/TLS-Zertifikat und einen Schlüssel verweisen.

Eine ausführlichere Erklärung zu Ingress mit Beispielen finden Sie auf der Ingress-Dokumentationsseite .

Hier finden Sie die Ingress-Ressource (cafe‑ingress.yaml) für die cafe-App:

Bei zeilenweiser Betrachtung sehen wir:

• In Zeile 4 geben wir der Ressource den Namen cafe‑ingress.

• In den Zeilen 6–9 richten wir die SSL/TLS-Terminierung ein:

  • In Zeile 9 verweisen wir auf eine Secret-Ressource mit dem Namen cafe‑secret. Diese Ressource enthält das SSL/TLS-Zertifikat und den Schlüssel und Sie müssen sie vor der Ingress-Ressource bereitstellen.
  • In Zeile 8 wenden wir das Zertifikat und den Schlüssel auf unseren virtuellen Server cafe.example.com an.
• In Zeile 11 definieren wir einen virtuellen Server mit dem Domänennamen cafe.example.com .

• In den Zeilen 13–21 definieren wir zwei pfadbasierte Regeln:

  • Die in den Zeilen 14–17 definierte Regel weist den Load Balancer an, die Anfragen mit der URI /tea auf die Container des TEA -Dienstes zu verteilen, der unter dem Namen tea‑svc im Cluster bereitgestellt wird.
  • Die in den Zeilen 18 bis 21 definierte Regel weist den Load Balancer an, die Anfragen mit der URI /coffee auf die Container des Coffee -Dienstes zu verteilen, der unter dem Namen coffee-svc im Cluster bereitgestellt wird.
  • Beide Regeln weisen den Load Balancer an, die Anfragen auf Port 80 des entsprechenden Dienstes zu verteilen.

Wie Sie die Ingress- und Secret-Ressourcen im Cluster bereitstellen, erfahren Sie ausführlich in unserem GitHub-Repository.

Testen der Anwendung

Nachdem wir den NGINX Plus Ingress-Controller, unsere Anwendung, die Ingress-Ressource und die Secret-Ressource eingerichtet haben, können Sie die App testen.

Wenn wir eine TEA-Anfrage mit der URI /tea stellen, sehen wir im Browser eine vom TEA- Dienst generierte Seite.

Wir hoffen, dass Sie nicht allzu enttäuscht sind, dass Ihnen beim Tee- und Kaffeeservice keine tatsächlichen Getränke, sondern lediglich Informationen zu den Behältern, in denen diese abgefüllt werden, und Einzelheiten zu Ihrem Wunsch serviert werden. Dazu gehören der Hostname und die IP-Adresse des Containers, die Anforderungs-URI und die Client-IP-Adresse. Jedes Mal, wenn wir die Seite aktualisieren, erhalten wir eine Antwort von einem anderen Container.

Wir können uns auch mit dem Dashboard zur Live-Aktivitätsüberwachung von NGINX Plus verbinden und in Echtzeit Kennzahlen zum Lastenausgleich von NGINX Plus und jedem Container unserer Anwendung anzeigen.

Ingress Controller-Erweiterungen

Ingress bietet grundlegende HTTP-Lastenausgleichsfunktionen. Oft sind die Lastenausgleichsbedürfnisse Ihrer Anwendungen jedoch komplexer und gehen über das hinaus, was Ingress unterstützt. Um diesen Anforderungen gerecht zu werden, haben wir den Ingress-Controller mit mehreren Erweiterungen ausgestattet. So profitieren Sie weiterhin von der Kubernetes-Basis zur Konfiguration des Lastenausgleichs, ohne direkt den Load Balancer anpassen zu müssen, und nutzen gleichzeitig fortschrittliche Lastenausgleichsfunktionen.

Eine vollständige Liste der verfügbaren Erweiterungen finden Sie in unserem GitHub-Repository .

Wir stellen Ihnen außerdem einen Mechanismus bereit, mit dem Sie die NGINX-Konfiguration über Kubernetes-Ressourcen anpassen können, sei es über Config Maps oder Annotations. So haben Sie beispielsweise die Möglichkeit, Werte der Direktiven proxy_connect_timeout oder proxy_read_timeout individuell zu gestalten.

Wenn Ihre Anforderungen an den Lastausgleich über die von Ingress und unseren Erweiterungen unterstützten Anforderungen hinausgehen, empfehlen wir einen anderen Ansatz zur Bereitstellung und Konfiguration von NGINX Plus, bei dem der Ingress-Controller nicht verwendet wird. Lesen Sie in unserem Blog den Artikel „Load Balancing Kubernetes Services mit NGINX Plus“, um mehr zu erfahren.

Vorteile des NGINX Plus mit dem Controller

Mit NGINX Plus bietet der Ingress-Controller zusätzlich zu den Vorteilen von NGINX die folgenden:

• Stabilität in einer hochdynamischen Umgebung – Jedes Mal, wenn sich die Anzahl der über Ingress bereitgestellten Service-Pods ändert, muss der Ingress-Controller die NGINX- oder NGINX Plus-Konfiguration aktualisieren, um die Änderungen widerzuspiegeln. Bei NGINX Open Source müssen Sie die Konfigurationsdatei manuell ändern und die Konfiguration neu laden. Mit NGINX Plus können Sie die API zur dynamischen Neukonfiguration verwenden, um die Konfiguration zu aktualisieren, ohne die Konfigurationsdatei neu zu laden. Dadurch wird eine mögliche erhöhte Speichernutzung und eine allgemeine Überlastung des Systems verhindert, die durch sehr häufiges Neuladen der Konfiguration auftreten kann.
• Echtzeitstatistiken – NGINX Plus bietet erweiterte Echtzeitstatistiken , auf die Sie entweder über eine API oder über das integrierte Dashboard zugreifen können. Dies kann Ihnen Einblicke in die Leistung von NGINX Plus und Ihren Anwendungen geben.
• Sitzungspersistenz – Wenn Sie die Sitzungspersistenz aktivieren, stellt NGINX Plus sicher, dass alle Anfragen desselben Clients mithilfe der Sticky-Cookie -Methode immer an denselben Backend-Container weitergeleitet werden.

Zusammenfassung

Kubernetes bietet integriertes HTTP-Lastausgleich, um externen Datenverkehr mit Ingress an die Dienste im Cluster weiterzuleiten. NGINX und NGINX Plus lassen sich in den Kubernetes-Lastausgleich integrieren, bieten vollständige Unterstützung für Ingress-Funktionen und stellen außerdem Erweiterungen bereit, um erweiterte Lastausgleichsanforderungen zu unterstützen.

Um NGINX Plus und den Ingress-Controller auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .