Bessere Entscheidungen treffen mit Deep Service Insight vom NGINX Ingress Controller

Wir haben im Januar 2023 Version 3.0 des NGINX Ingress Controller mit einer Vielzahl wichtiger neuer Funktionen und erweiterter Funktionalität veröffentlicht. Eine neue Funktion, die Sie unserer Meinung nach besonders wertvoll finden werden, ist Deep Service Insight, verfügbar mit der NGINX Plus-Edition von NGINX Ingress Controller.

Deep Service Insight behebt eine Einschränkung, die eine optimale Funktionsweise verhindert, wenn ein Routing-Entscheidungssystem wie beispielsweise ein Load Balancer vor einem oder mehreren Kubernetes-Clustern sitzt. Das System hat nämlich keinen Zugriff auf Informationen zum Zustand einzelner Dienste, die in den Clustern hinter dem Ingress-Controller ausgeführt werden. Dadurch wird verhindert, dass der Datenverkehr nur an Cluster mit intakten Diensten weitergeleitet wird, was Ihre Benutzer potenziell Ausfällen und Fehlern aussetzt, wie404 Und500 .

Deep Service Insight behebt dieses Problem, indem es den Integritätsstatus von Back-End-Service-Pods (wie vom NGINX Ingress Controller erfasst) an einem dedizierten Endpunkt offenlegt, wo Ihre Systeme darauf zugreifen und ihn für bessere Routing-Entscheidungen verwenden können.

In diesem Beitrag werfen wir einen detaillierten Blick auf das durch Deep Service Insight gelöste Problem, erklären seine Funktionsweise in einigen gängigen Anwendungsfällen und zeigen, wie es konfiguriert wird.

Warum Deep Service Insights?

Die standardmäßigen Kubernetes-Aktivitäts-, Bereitschafts- und Starttests liefern Ihnen zwar einige Informationen zu den in Ihren Clustern ausgeführten Backend-Diensten, reichen jedoch nicht aus, um die Einblicke zu erhalten, die Sie benötigen, um in Ihrem gesamten Stack bessere Routing-Entscheidungen treffen zu können. Das Fehlen der richtigen Informationen wird umso problematischer, je komplexer Ihre Kubernetes-Bereitstellungen werden und je dringlicher Ihre Geschäftsanforderungen hinsichtlich unterbrechungsfreier Betriebszeit werden.

Ein gängiger Ansatz zur Verbesserung der Betriebszeit beim Skalieren Ihrer Kubernetes-Umgebung besteht darin, Lastenausgleichsmodule, DNS-Manager und andere automatisierte Entscheidungssysteme vor Ihren Clustern bereitzustellen. Aufgrund der Funktionsweise von Ingress-Controllern hat ein Load Balancer vor einem Kubernetes-Cluster jedoch normalerweise keinen Zugriff auf Statusinformationen zu den Diensten hinter dem Ingress-Controller im Cluster. Er kann lediglich überprüfen, ob die Ingress-Controller-Pods selbst fehlerfrei sind und Datenverkehr akzeptieren.

Der NGINX Ingress Controller verfügt dagegen über Informationen zur Dienstintegrität. Es überwacht bereits die Integrität der Upstream-Pods in einem Cluster, indem es regelmäßige passive Integritätsprüfungen für HTTP- , TCP- , UDP- und gRPC- Dienste sendet, die Reaktionsfähigkeit auf Anforderungen überwacht und erfolgreiche Antwortcodes und andere Metriken verfolgt. Anhand dieser Informationen wird entschieden, wie der Datenverkehr auf die Pods Ihrer Dienste verteilt wird, um ein konsistentes und vorhersehbares Benutzererlebnis zu gewährleisten. Normalerweise führt der NGINX Ingress Controller die ganze Magie unbemerkt im Hintergrund aus, und Sie denken vielleicht nie darüber nach, was unter der Haube passiert. Deep Service Insight bringt diese wertvollen Informationen an die Oberfläche, sodass Sie sie auf anderen Ebenen Ihres Stacks effektiver nutzen können.

Wie funktioniert Deep Service Insight?

Deep Service Insight steht für Dienste zur Verfügung, die Sie mit den benutzerdefinierten NGINX-Ressourcen VirtualServer und TransportServer (für HTTP bzw. TCP/UDP) bereitstellen. Deep Service Insight nutzt die NGINX Plus API, um Ihnen am speziell für Deep Service Insight vorgesehenen Endpunkt die Sicht des NGINX Ingress Controllers auf einzelne Pods eines Backend-Dienstes zu zeigen:

• Für VirtualServer – <IP_Adresse> :<Port> /Sonde/<Hostname>
• Für TransportServer – <IP_Adresse> :<Port> /probe/ts/<Dienstname>

Wo

• <IP_Adresse> gehört zum NGINX Ingress Controller
• <Anschluss> ist die Deep Service Insight-Portnummer (standardmäßig 9114)
• <hostname> ist der Domainname des Dienstes, den Sie im Feld spec.host der VirtualServer-Ressource festlegen
• <service_name> bezeichnet den Dienstnamen, den Sie im Feld spec.upstreams.service der TransportServer-Ressource angeben

Die Ausgabe enthält zwei Arten von Informationen:

1. Ein HTTP-Statuscode für den Hostnamen oder Dienstnamen:

   • 200 OK – Mindestens eine Schote ist gesund
   • 418 Ich bin eine Teekanne – Keine Kapseln sind gesund
   • 404 Nicht gefunden – Es gibt keine Pods, die dem angegebenen Hostnamen oder Dienstnamen entsprechen.

2. Drei Zähler für den angegebenen Hostnamen oder Dienstnamen:

   • Gesamtzahl der Serviceinstanzen (Pods)
   • Anzahl der Pods im aktiven (fehlerfreien) Zustand
   • Anzahl der Pods im fehlerhaften Zustand

Hier ist ein Beispiel, bei dem alle drei Pods für einen Dienst fehlerfrei sind:

HTTP/1.1 200 OKInhaltstyp: application/json; Zeichensatz=utf-8 Datum: Tag , TT Mo JJJJ hh : mm : ss TZ Inhalts-Länge: 32 {"Gesamt":3,"Nach oben":3,"Ungesund":0}

Weitere Einzelheiten finden Sie in der NGINX Ingress Controller -Dokumentation .

Sie können die Kriterien, mit denen der NGINX Ingress Controller die Gesundheit eines Pods bewertet, durch aktive Gesundheitsprüfungen weiter anpassen. Sie legen den Pfad und Port fest, an den die Gesundheitsprüfung gesendet wird, definieren die Anzahl der Fehlschläge innerhalb eines Zeitraums, nach denen ein Pod als nicht gesund gilt, geben den erwarteten Statuscode an und stellen Timeouts für Verbindungsaufbau oder Antwort sicher – und mehr. Fügen Sie das Feld Upstream.Healthcheck in die Ressource VirtualServer oder TransportServer ein.

Beispiel-Anwendungsfälle für Deep Service Insight

Ein Anwendungsfall, in dem Deep Service Insight besonders wertvoll ist, liegt vor, wenn ein Load Balancer den Datenverkehr an einen Dienst weiterleitet, der in zwei Clustern ausgeführt wird, beispielsweise aus Gründen der Hochverfügbarkeit. Innerhalb jedes Clusters verfolgt der NGINX Ingress Controller den Zustand der Upstream-Pods wie oben beschrieben. Wenn Sie Deep Service Insight aktivieren, werden Informationen zur Anzahl fehlerfreier und fehlerhafter Upstream-Pods auch auf einem dedizierten Endpunkt angezeigt. Ihr Routing-Entscheidungssystem kann auf den Endpunkt zugreifen und die Informationen verwenden, um den Anwendungsverkehr von fehlerhaften Pods zugunsten fehlerfreier Pods umzuleiten.

Das Diagramm veranschaulicht, wie Deep Service Insight in diesem Szenario funktioniert.

Sie können Deep Service Insight auch nutzen, wenn Sie Wartungsarbeiten an einem Cluster in einem Hochverfügbarkeitsszenario durchführen. Reduzieren Sie einfach die Anzahl der Pods für einen Dienst im Cluster, in dem Sie Wartungsarbeiten durchführen, auf Null. Der Mangel an fehlerfreien Pods wird automatisch am Deep Service Insight-Endpunkt angezeigt und Ihr Routing-Entscheidungssystem verwendet diese Informationen, um Datenverkehr an die fehlerfreien Pods im anderen Cluster zu senden. Sie erhalten effektiv ein automatisches Failover, ohne die Konfiguration am NGINX Ingress Controller oder am System ändern zu müssen, und Ihre Kunden erleben niemals eine Dienstunterbrechung.

Umfassende Serviceeinblicke ermöglichen

Um Deep Service Insight zu aktivieren, schließen Sie das Befehlszeilenargument -enable-service-insight in das Kubernetes-Manifest ein oder setzen Sie den Parameter serviceInsight.create auf true, wenn Sie Helm verwenden.

Es gibt zwei optionale Argumente, die Sie einschließen können, um den Endpunkt für Ihre Umgebung zu optimieren:

• -service-insight-listen-port <Anschluss> – Ändern Sie die Deep Service Insight-Portnummer von der Standardnummer 9114 (<Anschluss> ist eine Ganzzahl im Bereich 1024–65535). Das Helm-Äquivalent ist der Parameter serviceInsight.port .
• -service-insight-tls-string <geheim> – Ein Kubernetes-Geheimnis (TLS-Zertifikat und Schlüssel) für die TLS-Terminierung des Deep Service Insight-Endpunkts (<geheim> ist eine Zeichenfolge mit dem Format <Namespace>/<geheimer_Name>). Das Helm-Äquivalent ist der Parameter serviceInsight.secret .

Beispiel: Aktivieren Sie Deep Service Insight für die Cafe-Anwendung

Um Deep Service Insight in Aktion zu sehen, können Sie es für die Cafe-Anwendung aktivieren, die häufig als Beispiel in der NGINX Ingress Controller-Dokumentation verwendet wird.

1. Installieren Sie die NGINX Plus Edition des NGINX Ingress Controllers mit Unterstützung für benutzerdefinierte NGINX-Ressourcen und aktivieren Sie Deep Service Insight:

   • Wenn Sie Helm verwenden, setzen Sie den Parameter serviceInsight.create auf true .
   • Wenn Sie ein Kubernetes-Manifest (Bereitstellung oder DaemonSet) verwenden, schließen Sie das Argument -enable-service-insight in die Manifestdatei ein.

2. Überprüfen Sie, ob der NGINX Ingress Controller ausgeführt wird:

   $ kubectl get pods -n nginx-ingress NAME BEREIT … ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 … …  STATUS STARTET ALTER NEU ...  Läuft 0 9d

3. Stellen Sie die Cafe-Anwendung gemäß den Anweisungen in der README-Datei bereit.

4. Überprüfen Sie, ob die benutzerdefinierte NGINX VirtualServer-Ressource für die Anwendung Cafe bereitgestellt ist (die IP-Adresse wurde der Lesbarkeit halber weggelassen):

   $ kubectl get vs NAME STAAT HOST IP PORTS ALTER cafe Gültiges cafe.example.com ... [80,443] 7h1m

5. Überprüfen Sie, ob drei Upstream-Pods für den Cafe-Dienst unter cafe.example.com ausgeführt werden:

   $ kubectl get pods NAME BEREIT STATUS NEUSTART ALTER coffee-87cf76b96-5b85h 1/1 Läuft 0 7h39m coffee-87cf76b96-lqjrp 1/1 Läuft 0 7h39m tea-55bc9d5586-9z26v 1/1 Läuft 0 111m

6. Greifen Sie auf den Deep Service Insight-Endpunkt zu:

   $ locken -ich <NIC_IP_Adresse>:9114/probe/cafe.example.com

   Der 200 OK Der Antwortcode gibt an, dass der Dienst bereit ist, Datenverkehr anzunehmen (mindestens ein Pod ist fehlerfrei). In diesem Fall befinden sich alle drei Pods im Status „Up“.

   HTTP/1.1 200 OK Inhaltstyp: application/json; Zeichensatz=utf-8 Datum: Tag , TT Mo JJJJ hh : mm : ss TZ Inhalts-Länge: 32 {"Gesamt":3,"Nach oben":3,"Ungesund":0}

   Der 418 Ich bin A Teekanne Der Statuscode gibt an, dass der Dienst nicht verfügbar ist (alle Pods sind fehlerhaft).

   HTTP/1.1 418 Ich bin eine Teekanne. Inhaltstyp: application/json; Zeichensatz = utf-8 Datum: Tag , TT Mo JJJJ hh : mm : ss TZ Inhalts-Länge: 32 {"Gesamt":3,"Nach oben":0,"Ungesund":3}

   Der 404 Nicht Gefunden Der Statuscode zeigt an, dass unter dem angegebenen Hostnamen kein Dienst ausgeführt wird.

   HTTP/1.1 404 Nicht gefundenDatum: Tag , TT Mo JJJJ hh : mm : ss TZ Inhalts-Länge: 0

Ressourcen

Das vollständige Änderungsprotokoll für NGINX Ingress Controller Version 3.0.0 finden Sie in den Versionshinweisen .

Um NGINX Ingress Controller mit NGINX Plus und NGINX App Protect auszuprobieren, starten Sie noch heute Ihre 30-tägige kostenlose Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .