NGINX- und NGINX Plus-Ingress-Controller für Kubernetes-Load-Balancing

NGINX | 05. Dezember 2016

Die skalierbare Ausführung und Verwaltung von Microservices-Anwendungen in Containern über einen Cluster von Rechnern hinweg ist eine anspruchsvolle Aufgabe. Kubernetes hilft Ihnen bei der Bewältigung dieser Herausforderung, indem es Ihnen eine leistungsstarke Lösung für die Container-Orchestrierung bietet. Sie umfasst mehrere wichtige Funktionen wie Fehlertoleranz, automatische Skalierung, fortlaufende Updates, Speicher, Diensterkennung und Lastverteilung.

In diesem Blogbeitrag erklären wir, wie Sie NGINX Open Source oder NGINX Plus mit Ingress, dem integrierten Kubernetes-Framework für den Lastenausgleich von HTTP-Datenverkehr, verwenden. Mit Ingress können Sie Regeln konfigurieren, die die Weiterleitung von externem Datenverkehr an die Dienste in Ihrem Kubernetes-Cluster steuern. Sie können einen beliebigen Load Balancer wählen, der einen Ingress-Controller bereitstellt. Dabei handelt es sich um 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 von uns für NGINX Plus und NGINX bereitgestellten Ingress-Controllern konfigurieren.

[Redaktion – Die zuvor getrennten Controller für NGINX und NGINX Plus wurden zu einem gemeinsamen Ingress-Controller für beide zusammengeführt.]

In diesem Blogbeitrag befassen wir uns ausschließlich mit dem HTTP-Lastenausgleich für Kubernetes mit Ingress. Weitere Informationen zu anderen Optionen für den Lastenausgleich finden Sie im Beitrag „Lastenausgleich für Kubernetes-Dienste mit NGINX Plus“ in unserem Blog.

Hinweis: Eine vollständige Anleitung zu den in diesem Blogbeitrag beschriebenen Verfahren finden Sie in unserem GitHub-Repository. Dieser Beitrag geht nicht auf jeden erforderlichen Schritt ein, sondern enthält Links zu den entsprechenden Anleitungen.

Ingress-Controller für NGINX und NGINX Plus

Bevor wir die Beispielanwendung bereitstellen und den Lastenausgleich dafür konfigurieren, müssen wir einen Load Balancer 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 von Drittanbietern. Weitere Informationen finden Sie auf der Seite Ingress Controllers im GitHub-Repository für Kubernetes.

Eine vollständige Anleitung zur Bereitstellung des NGINX- oder NGINX Plus Ingress-Controllers in Ihrem Cluster finden Sie in unserem GitHub-Repository.

Die Beispielanwendung mit Microservices

Unsere Beispielanwendung ist eine typische Microservices-Webanwendung, die aus mehreren separat bereitgestellten Diensten besteht. In der Anwendung namens cafe können Sie entweder Tee über den Dienst tea oder Kaffee über den Dienst coffee bestellen. Ihre Getränkeauswahl geben Sie über den URI Ihrer HTTP-Anfrage an: Bei URIs, die auf /tea enden, erhalten Sie Tee, und bei URIs, die auf /coffee enden, erhalten Sie Kaffee. Verbindungen zur Anwendung müssen mit SSL/TLS abgesichert werden.

Das folgende Diagramm stellt die Anwendung schematisch dar. Dabei übernimmt der NGINX Plus-Load-Balancer die wichtige Aufgabe, Clientanfragen an den entsprechenden Dienst weiterzuleiten und zugleich die Clientverbindungen mit SSL/TLS abzusichern.

Die mit den NGINX- und NGINX Plus-Ingress-Controllern bereitgestellte Beispiel-Microservices-Anwendung „cafe“ veranschaulicht den Kubernetes-Lastenausgleich

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

Konfigurieren des Kubernetes-Lastenausgleichs über Ingress

Unsere Café-App benötigt zwei Funktionen des Load Balancers:

  • Routing basierend auf dem Anfrage-URI (auch als „pfadbasiertes Routing“ bezeichnet)
  • SSL/TLS-Terminierung

Um den Lastenausgleich mit Ingress zu konfigurieren, definieren Sie Regeln in einer Ingress-Ressource. Die Regeln legen fest, wie externer Datenverkehr an die Dienste in Ihrem Cluster weitergeleitet wird.

In der Ressource können Sie mehrere virtuelle Server definieren, jeweils für einen anderen Domänennamen. Ein virtueller Server entspricht in der Regel einer einzelnen Microservices-Anwendung, die im Cluster bereitgestellt ist. Für jeden Server können Sie:

  • Geben Sie mehrere pfadbasierte Regeln an. Der Datenverkehr wird basierend auf dem Anfrage-URI an verschiedene Dienste in einer Anwendung weitergeleitet.
  • 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 ist die Ingress-Ressource (cafe‑ingress.yaml) für die Anwendung cafe:

Codebeispiel wird geladen…

Wenn wir den Code Zeile für Zeile untersuchen, sehen wir Folgendes:

  • In Zeile 4 nennen wir die Ressource „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 zugehörigen Schlüssel und muss vor der Ingress-Ressource bereitgestellt werden.
    • 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 Domainnamen 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 dem URI /tea auf die Container des Dienstes tea zu verteilen, der unter dem Namen tea‑svc im Cluster bereitgestellt ist.
    • Die in den Zeilen 18–21 definierte Regel weist den Load Balancer an, die Anfragen mit dem URI /coffee auf die Container des Dienstes coffee zu verteilen, der unter dem Namen coffee‑svc im Cluster bereitgestellt ist.
    • Beide Regeln weisen den Load Balancer an, die Anfragen an Port 80 des jeweiligen Dienstes zu verteilen.

Eine vollständige Anleitung zur Bereitstellung der Ingress- und Secret-Ressourcen im Cluster finden Sie in unserem GitHub-Repository.

Anwendung testen

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

Wenn wir eine Anfrage für Tee mit dem URI /tea senden, wird im Browser eine vom Dienst tea generierte Seite angezeigt.

Der mit den NGINX- und NGINX Plus-Ingress-Controllern für den Kubernetes-Lastenausgleich bereitgestellte Beispiel-Microservice „tea“ gibt eine Indexseite mit Anfragedetails zurück

Wir hoffen, Sie sind nicht allzu enttäuscht, dass die Dienste tea und coffee Ihnen keine echten Getränke servieren, sondern Informationen über die Container, in denen sie ausgeführt werden, sowie Details zu Ihrer Anfrage liefern. Dazu gehören der Hostname und die IP-Adresse des Containers, der Anfrage-URI und die IP-Adresse des Clients. Bei jeder Aktualisierung der Seite erhalten wir eine Antwort von einem anderen Container.

Wir können auch eine Verbindung zum NGINX Plus-Dashboard für die Live-Aktivitätsüberwachung herstellen und dort Echtzeitmetriken zum Lastenausgleich von NGINX Plus und jedem Container unserer Anwendung einsehen.

Das Dashboard zur Live-Aktivitätsüberwachung von NGINX Plus zeigt, wie NGINX Plus die Anfragen zwischen den Microservices in der Beispielanwendung „cafe“ verteilt, die mit den Ingress-Controllern von NGINX und NGINX Plus für den Kubernetes-Lastenausgleich bereitgestellt wird.

Ingress-Controller-Erweiterungen

Ingress bietet grundlegende Funktionen für den HTTP-Lastenausgleich. Häufig sind die Anforderungen Ihrer Anwendungen an den Lastenausgleich jedoch komplexer und werden daher von Ingress nicht unterstützt. Um einige dieser Anforderungen zu erfüllen, haben wir den Ingress-Controller um mehrere Erweiterungen ergänzt. So können Sie weiterhin Kubernetes-Ressourcen zur Konfiguration des Lastenausgleichs nutzen (anstatt den Load Balancer direkt konfigurieren zu müssen) und zugleich von erweiterten Lastenausgleichsfunktionen profitieren.

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

Darüber hinaus bieten wir einen Mechanismus, mit dem Sie die NGINX-Konfiguration anpassen können. Dazu werden Kubernetes-Ressourcen wie ConfigMaps oder Annotationen verwendet. Beispielsweise können Sie die Werte der Direktiven proxy_connect_timeout oder proxy_read_timeout anpassen.

Wenn Ihre Anforderungen an die Lastverteilung über die von Ingress und unseren Erweiterungen unterstützten Funktionen hinausgehen, empfehlen wir einen anderen Ansatz für die Bereitstellung und Konfiguration von NGINX Plus, bei dem der Ingress-Controller nicht verwendet wird. Lesen Sie Lastverteilung für Kubernetes-Dienste mit NGINX Plus in unserem Blog, um mehr zu erfahren.

Vorteile von NGINX Plus mit dem Controller

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

  • Stabilität in einer hochdynamischen Umgebung – Jedes Mal, wenn sich die Anzahl der Pods von Diensten ändert, die über Ingress bereitgestellt werden, muss der Ingress-Controller die NGINX- oder NGINX Plus-Konfiguration entsprechend aktualisieren. Bei NGINX Open Source müssen Sie die Konfigurationsdatei manuell ändern und die Konfiguration neu laden. Bei NGINX Plus können Sie die dynamische Neukonfiguration-API verwenden, um die Konfiguration zu aktualisieren, ohne die Konfigurationsdatei neu zu laden. Dadurch werden ein potenziell erhöhter Speicherverbrauch und eine Überlastung des Gesamtsystems vermieden, die auftreten können, wenn die Konfiguration sehr häufig neu geladen wird.
  • Echtzeitstatistiken – NGINX Plus bietet erweiterte Echtzeitstatistiken, auf die Sie entweder über eine API oder über das integrierte Dashboard zugreifen können. So erhalten Sie Einblicke in die Leistung von NGINX Plus und Ihren Anwendungen.
  • Sitzungspersistenz – Wenn Sie die Sitzungspersistenz aktivieren, stellt NGINX Plus mithilfe der Sticky-Cookie-Methode sicher, dass alle Anfragen desselben Clients immer an denselben Backend-Container weitergeleitet werden.

Zusammenfassung

Kubernetes bietet integrierten HTTP-Lastenausgleich, um externen Datenverkehr mithilfe von Ingress an die Dienste im Cluster weiterzuleiten. NGINX und NGINX Plus lassen sich in den Kubernetes-Lastenausgleich integrieren, unterstützen sämtliche Ingress-Funktionen und bieten darüber hinaus Erweiterungen für zusätzliche Lastenausgleichsanforderungen.

Wenn Sie NGINX Plus und den Ingress Controller ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.


Teilen
Schlagwörter: F5 NGINX, 2016, Tech

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.