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 ist für Dienste verfügbar, die Sie mit den benutzerdefinierten Ressourcen NGINX VirtualServer und TransportServer bereitstellen (für HTTP bzw. TCP/UDP). Deep Service Insight verwendet die NGINX Plus-API, um die Ansicht des NGINX Ingress Controllers der einzelnen Pods in einem Backend-Dienst an einem dedizierten Endpunkt freizugeben, der nur für Deep Service Insight gilt:

• 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 Domänenname des Dienstes, wie in der spec.host Feld der VirtualServer-Ressource
• <Dienstname> ist der Name des Dienstes, wie in der Spezifikation.Upstreams.Service Feld in der TransportServer-Ressource

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, die der NGINX Ingress Controller verwendet, um zu entscheiden, ob ein Pod fehlerfrei ist, weiter anpassen, indem Sie aktive Integritätsprüfungen konfigurieren. Sie können den Pfad und den Port konfigurieren, an die die Integritätsprüfung gesendet wird, die Anzahl der fehlgeschlagenen Prüfungen, die innerhalb eines angegebenen Zeitraums erfolgen müssen, damit ein Pod als fehlerhaft betrachtet wird, den erwarteten Statuscode, Timeouts für die Verbindung oder den Empfang einer Antwort und mehr. Fügen Sie das Feld Upstream.Healthcheck in die VirtualServer- oder TransportServer- Ressource 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 von NGINX Ingress Controller mit Unterstützung für benutzerdefinierte NGINX-Ressourcen und Aktivierung von 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 Cafe-Anwendung bereitgestellt wurde (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 .