So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Verkehrsmanagement

Redakteur – Dieser Beitrag ist Teil einer 10-teiligen Serie:

1. Reduzieren Sie die Komplexität mit produktionsreifem Kubernetes
2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Verkehrsmanagement (dieser Beitrag)
3. So verbessern Sie die Sichtbarkeit in Kubernetes
4. Sechs Möglichkeiten zur Sicherung von Kubernetes mit Traffic-Management-Tools
5. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Identifizieren Sie Ihre Anforderungen
6. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
7. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standard vs. Kommerziell
8. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller
9. So wählen Sie ein Service Mesh aus
10. Leistungstests für NGINX-Ingress-Controller in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können den kompletten Blogsatz auch als kostenloses E-Book herunterladen: Kubernetes vom Test zur Produktion bringen .

Dass ein Unternehmen moderne Technologien zur App-Entwicklung nicht erfolgreich einsetzt, lässt sich ganz einfach daran erkennen: Seine Kunden beschweren sich schnell in den sozialen Medien. Sie beschweren sich, wenn sie die neuste Veröffentlichung, die sich zum Binge-Watching eignet, nicht streamen können. Oder nutzen Sie unser Online-Banking. Oder tätigen Sie einen Kauf, weil die Zeit im Einkaufswagen abgelaufen ist.

Auch wenn sich Kunden nicht öffentlich beschweren, bedeutet das nicht, dass ihre schlechten Erfahrungen keine Konsequenzen haben. Einer unserer Kunden – ein großes Versicherungsunternehmen – teilte uns mit, dass es Kunden verliert, wenn seine Homepage nicht innerhalb von 3 Sekunden geladen wird.

Alle diese Benutzerbeschwerden über schlechte Leistung oder Ausfälle weisen auf einen gemeinsamen Schuldigen hin: die Ausfallsicherheit … oder das Fehlen derselben. Das Schöne an Microservices-Technologien – einschließlich Containern und Kubernetes – besteht darin, dass sie das Kundenerlebnis deutlich verbessern können, indem sie die Ausfallsicherheit Ihrer Apps erhöhen. Wie? Es dreht sich alles um die Architektur.

Ich erkläre den wesentlichen Unterschied zwischen monolithischen und Microservices-Architekturen gerne anhand der Analogie einer Weihnachtslichterkette. Wenn bei einer Lichterkette älteren Typs eine Glühbirne durchbrennt, wird die ganze Lichterkette dunkel. Wenn Sie die Glühbirne nicht austauschen können, ist das einzige, was sich als Dekoration mit der Lichterkette lohnt, das Innere Ihrer Mülltonne. Dieser alte Stil der Beleuchtung ist wie eine monolithische App, die ebenfalls eng gekoppelte Komponenten hat und ausfällt, wenn eine Komponente kaputt geht.

Doch sowohl die Beleuchtungsindustrie als auch die Softwareindustrie haben diesen wunden Punkt erkannt. Wenn in einer modernen Lichterkette eine Glühbirne kaputt geht, leuchten die anderen hell weiter, genauso wie eine gut konzipierte Microservices-App weiter funktioniert, selbst wenn eine Serviceinstanz ausfällt.

Kubernetes-Verkehrsmanagement

Container sind in Microservices-Architekturen eine beliebte Wahl, da sie sich ideal für die Erstellung einer Anwendung mit kleineren, diskreten Komponenten eignen – sie sind leicht, portabel und einfach skalierbar. Kubernetes ist der De-facto-Standard für die Container-Orchestrierung, es ist jedoch mit vielen Herausforderungen verbunden, Kubernetes produktionsreif zu machen . Ein Element, das sowohl Ihre Kontrolle über Kubernetes-Apps als auch deren Belastbarkeit verbessert, ist eine ausgereifte Verkehrsmanagementstrategie, mit der Sie Dienste statt Pakete steuern und Verkehrsmanagementregeln dynamisch oder mit der Kubernetes-API anpassen können. Während Verkehrsmanagement in jeder Architektur wichtig ist, sind für Hochleistungs-Apps zwei Verkehrsmanagementtools unverzichtbar: Verkehrskontrolle und Verkehrsaufteilung .

Verkehrssteuerung

Unter Verkehrssteuerung (manchmal auch Verkehrsführung oder Verkehrsgestaltung genannt) versteht man die Kontrolle darüber, wohin der Verkehr fließt und wie er dorthin gelangt. Dies ist beim Ausführen von Kubernetes in der Produktion erforderlich, da Sie damit Ihre Infrastruktur und Apps vor Angriffen und Verkehrsspitzen schützen können. Zwei Techniken, die Sie in Ihren App-Entwicklungszyklus integrieren sollten, sind Ratenbegrenzung und Stromkreisunterbrechung .

• Anwendungsfall: Ich möchte Dienste vor zu vielen Anfragen schützen
  Lösung: Ratenbegrenzung

  Unabhängig davon, ob diese Angriffe böswillig (z. B. Brute-Force-Angriffe zum Erraten von Passwörtern oder DDoS-Angriffe) oder harmlos (z. B. Kunden, die zu einem Sonderangebot strömen) sind, kann eine hohe Anzahl von HTTP-Anfragen Ihre Dienste überlasten und zum Absturz Ihrer Apps führen. Durch die Ratenbegrenzung wird die Anzahl der Anfragen begrenzt, die ein Benutzer in einem bestimmten Zeitraum stellen kann. Anfragen können etwas so Einfaches wie eine GET -Anfrage für die Homepage einer Website oder eine POST- Anfrage für ein Anmeldeformular sein. Bei einem DDoS-Angriff können Sie beispielsweise mithilfe der Ratenbegrenzung die Rate eingehender Anfragen auf einen für echte Benutzer typischen Wert begrenzen.

• Anwendungsfall: Ich möchte kaskadierende Fehler vermeiden
  Lösung: Stromkreisunterbrechung

  Wenn ein Dienst nicht verfügbar ist oder eine hohe Latenz aufweist, kann es lange dauern, bis bei eingehenden Anforderungen eine Zeitüberschreitung auftritt und die Clients eine Fehlerantwort erhalten. Die langen Timeouts können möglicherweise einen kaskadierenden Fehler verursachen, bei dem der Ausfall eines Dienstes zu Timeouts bei anderen Diensten und schließlich zum Ausfall der gesamten Anwendung führt.

  Leistungsschalter verhindern kaskadierende Fehler, indem sie auf Dienstausfälle überwachen. Wenn die Anzahl der fehlgeschlagenen Anfragen an einen Dienst einen voreingestellten Schwellenwert überschreitet, wird der Leistungsschalter ausgelöst und gibt beim Eintreffen der Anfragen sofort eine Fehlerantwort an die Clients zurück. Dadurch wird der Datenverkehr vom Dienst effektiv gedrosselt.

  Der Leistungsschalter fängt für einen festgelegten Zeitraum weiterhin Anfragen ab und weist sie zurück, bevor er testweise eine begrenzte Anzahl von Anfragen durchlässt. Wenn diese Anfragen erfolgreich sind, stoppt der Leistungsschalter die Drosselung des Datenverkehrs. Andernfalls wird die Uhr zurückgesetzt und der Leistungsschalter lehnt Anfragen für die definierte Zeit erneut ab.

Verkehrsaufteilung

Verkehrsaufteilung (manchmal auch Verkehrstest genannt) ist eine Unterkategorie der Verkehrskontrolle und bezieht sich auf den Vorgang der Kontrolle des Anteils des eingehenden Datenverkehrs, der an verschiedene Versionen einer Back-End-App geleitet wird, die gleichzeitig in einer Umgebung ausgeführt werden (normalerweise die aktuelle Produktionsversion und eine aktualisierte Version). Es ist ein wesentlicher Teil des App-Entwicklungszyklus, da es den Teams ermöglicht, die Funktionalität und Stabilität neuer Funktionen und Versionen zu testen, ohne die Kunden negativ zu beeinflussen. Nützliche Bereitstellungsszenarien sind Debug-Routing , Canary-Bereitstellungen , A/B-Tests und Blue-Green -Bereitstellungen. (In der Branche bestehen erhebliche Inkonsistenzen bei der Verwendung dieser vier Begriffe. Hier verwenden wir sie so, wie wir ihre Definitionen verstehen.)

• Anwendungsfall: Ich bin bereit, eine neue Version in der Produktion zu testen
  Lösung: Debug-Routing

  Angenommen, Sie haben eine Banking-App und möchten eine Funktion zur Kreditwürdigkeitsprüfung hinzufügen. Bevor Sie es mit Kunden testen, möchten Sie wahrscheinlich sehen, wie es in der Produktion funktioniert. Mit Debug-Routing können Sie es öffentlich bereitstellen und dennoch vor den tatsächlichen Benutzern „verbergen“, indem Sie nur bestimmten Benutzern den Zugriff erlauben, basierend auf Layer-7-Attributen wie Sitzungscookie, Sitzungs-ID oder Gruppen-ID. Sie können beispielsweise nur Benutzern den Zugriff erlauben, die über ein Administrator-Sitzungscookie verfügen. Ihre Anfragen werden an die neue Version mit der Kredit-Score-Funktion weitergeleitet, während alle anderen mit der stabilen Version weitermachen.

  

• Anwendungsfall: Ich muss sicherstellen, dass meine neue Version stabil ist
  Lösung: Canary-Bereitstellung

  Das Konzept des Kanarienvogeleinsatzes geht auf eine historische Bergbaupraxis zurück, bei der Bergleute einen in einem Käfig gehaltenen Kanarienvogel mit in ein Kohlebergwerk nahmen, um ihn frühzeitig vor giftigen Gasen zu warnen. Das Gas tötete zuerst den Kanarienvogel und dann die Bergleute, sodass diese der Gefahr schnell entkommen konnten. In der Welt der Apps wird keinem Vogel etwas zuleide getan! Canary-Bereitstellungen bieten eine sichere und flexible Möglichkeit, die Stabilität einer neuen Funktion oder Version zu testen. Bei einer typischen Canary-Bereitstellung wird mit einem großen Anteil (sagen wir 99 %) Ihrer Benutzer die stabile Version verwendet und eine kleine Gruppe (das andere 1 %) wird auf die neue Version verschoben. Wenn bei der neuen Version ein Fehler auftritt, z. B. durch Abstürze oder die Ausgabe von Fehlern an die Clients, können Sie die Testgruppe sofort wieder auf die stabile Version zurücksetzen. Wenn dies erfolgreich ist, können Sie die Benutzer entweder auf einmal oder (was häufiger vorkommt) in einer schrittweisen, kontrollierten Migration von der stabilen Version auf die neue umstellen.

  

• Anwendungsfall: Ich muss herausfinden, ob den Kunden eine neue Version besser gefällt als die aktuelle Version
  Lösung: A/B-Tests

  Nachdem Sie nun bestätigt haben, dass Ihre neue Funktion in der Produktion funktioniert, möchten Sie möglicherweise Kundenfeedback zum Erfolg der Funktion erhalten, basierend auf Key Performance Indicators (KPIs) wie der Anzahl der Klicks, der Anzahl wiederkehrender Benutzer oder expliziter Bewertungen. Beim A/B-Testen handelt es sich um ein branchenübergreifendes Verfahren zum Messen und Vergleichen des Benutzerverhaltens, um den relativen Erfolg verschiedener Produkt- oder App-Versionen beim gesamten Kundenstamm zu ermitteln. Bei einem typischen A/B-Test erhalten 50 % der Nutzer Version A (die aktuelle App-Version), während die restlichen 50 % Version B (die Version mit der neuen, aber stabilen Funktion) erhalten. Gewinner ist derjenige mit den insgesamt besseren KPIs.

  

• Anwendungsfall: Ich möchte meine Benutzer ohne Ausfallzeiten auf eine neue Version migrieren
  Lösung: Blau‑Grün‑Bereitstellung

  Nehmen wir nun an, für Ihre Banking-App steht ein größerer Versionswechsel an … herzlichen Glückwunsch! In der Vergangenheit bedeuteten Versions-Upgrades für die Benutzer normalerweise Ausfallzeiten, da die alte Version heruntergefahren werden musste, bevor die neue Version in die Produktion überführt werden konnte. Doch im heutigen Wettbewerbsumfeld sind Ausfallzeiten für Upgrades für die meisten Benutzer inakzeptabel. Blue-Green-Bereitstellungen reduzieren die Ausfallzeiten für Upgrades erheblich oder eliminieren sie sogar. Behalten Sie einfach die alte Version (blau) in der Produktion und stellen Sie gleichzeitig die neue Version (grün) daneben in derselben Produktionsumgebung bereit.

  Die meisten Organisationen möchten nicht 100 % der Benutzer auf einmal von Blau auf Grün umstellen – denn was wäre, wenn die grüne Version ausfällt?! Die Lösung besteht in der Verwendung einer Canary-Bereitstellung, um Benutzer in den Schritten zu verschieben, die Ihrer Risikominderungsstrategie am besten entsprechen. Wenn die neue Version ein Desaster ist, können Sie alle Benutzer mit nur wenigen Tastenanschlägen problemlos auf die stabile Version zurücksetzen.

  

Wie NGINX helfen kann

Mit den meisten Ingress-Controllern und Service-Meshes können Sie eine erweiterte Verkehrssteuerung und -aufteilung durchführen. Welche Technologie Sie verwenden, hängt von Ihrer App-Architektur und Ihren Anwendungsfällen ab. Beispielsweise ist die Verwendung eines Ingress-Controllers in diesen drei Szenarien sinnvoll:

• Ihre Apps haben nur einen Endpunkt, wie bei einfachen Apps oder monolithischen Apps, die Sie in Kubernetes „gehoben und verschoben“ haben.
• In Ihrem Cluster findet keine Dienst-zu-Dienst- Kommunikation statt.
• Es gibt eine Service-zu-Service- Kommunikation, aber Sie verwenden noch kein Service-Mesh.

Wenn Ihre Bereitstellung so komplex ist, dass ein Service Mesh erforderlich ist, besteht ein gängiger Anwendungsfall darin, den Datenverkehr zwischen Diensten zum Testen oder Aktualisieren einzelner Microservices aufzuteilen. Beispielsweise möchten Sie möglicherweise eine Canary-Bereitstellung hinter Ihrem mobilen Front-End zwischen zwei verschiedenen Versionen Ihrer Geolokalisierungs-Microservice-API durchführen.

Allerdings kann das Einrichten der Verkehrsaufteilung mit einigen Ingress-Controllern und Service-Meshes aus verschiedenen Gründen zeitaufwändig und fehleranfällig sein:

• Ingress-Controller und Service-Meshes verschiedener Anbieter implementieren Kubernetes-Funktionen auf unterschiedliche Weise.
• Kubernetes ist nicht wirklich darauf ausgelegt, Layer-7-Verkehr zu verwalten und zu verstehen.
• Einige Ingress-Controller und Service-Meshes unterstützen kein anspruchsvolles Verkehrsmanagement.

Mit NGINX Ingress Controller und NGINX Service Mesh können Sie in Sekundenschnelle robuste Richtlinien für die Verkehrsweiterleitung und -aufteilung konfigurieren. Sehen Sie sich diese Livestream-Demo mit unseren Experten an und lesen Sie weiter, um zu erfahren, wie wir Ihnen mit einfacheren Konfigurationen, erweiterten Anpassungen und verbesserter Sichtbarkeit Zeit sparen.

Einfachere Konfiguration mit NGINX Ingress-Ressourcen und der SMI-Spezifikation

Diese NGINX-Funktionen erleichtern die Konfiguration:

• NGINX-Ingress-Ressourcen für NGINX-Ingress-Controller – Während die standardmäßige Kubernetes-Ingress-Ressource die Konfiguration von SSL/TLS-Terminierung, HTTP-Lastausgleich und Layer-7-Routing vereinfacht, enthält sie nicht die Art von Anpassungsfunktionen, die für Circuit Breaking, A/B-Tests und Blue-Green-Bereitstellung erforderlich sind. Stattdessen müssen Nicht-NGINX-Benutzer Anmerkungen, ConfigMaps und benutzerdefinierte Vorlagen verwenden, denen allesamt eine feinkörnige Kontrolle fehlt, die unsicher, fehleranfällig und schwierig zu verwenden sind.

  Der NGINX Ingress Controller verfügt über NGINX Ingress-Ressourcen als Alternative zur Standard-Ingress-Ressource (die er ebenfalls unterstützt). Sie bieten einen nativen, typsicheren und eingerückten Konfigurationsstil, der die Implementierung des Ingress-Lastausgleichs vereinfacht. NGINX‑Ingress‑Ressourcen bieten einen zusätzlichen Vorteil für bestehende NGINX‑Benutzer: Sie erleichtern die Umwidmung von Lastausgleichskonfigurationen aus Nicht‑Kubernetes‑Umgebungen, sodass alle Ihre NGINX‑Lastenausgleichsmodule dieselben Konfigurationen verwenden können.

• NGINX Service Mesh mit SMI – NGINX Service Mesh implementiert das Service Mesh Interface (SMI), eine Spezifikation , die eine Standardschnittstelle für Service Meshes auf Kubernetes mit typisierten Ressourcen wie TrafficSplit , TrafficTarget und HTTPRouteGroup definiert. Durch die Verwendung standardmäßiger Kubernetes-Konfigurationsmethoden ermöglichen NGINX Service Mesh und die NGINX SMI-Erweiterungen die einfache Bereitstellung von Richtlinien zur Verkehrsaufteilung, wie z. B. die Canary-Bereitstellung, mit minimaler Unterbrechung des Produktionsverkehrs. So definieren Sie beispielsweise eine Canary-Bereitstellung mit NGINX Service Mesh:

  API-Version: split.smi-spec.io/v1alpha2kind: TrafficSplit
  Metadaten:
  Name: target-ts
  Spezifikation:
  Dienst: target-svc
  Backends:
  - Dienst: target-v1-0
  Gewicht: 90
  - Dienst: Ziel-v2-0
  Gewicht: 10

  Unser Tutorial „Bereitstellungen mit Verkehrsaufteilung “ führt durch Beispielbereitstellungsmuster, die Verkehrsaufteilung nutzen, darunter Canary- und Blue-Green-Bereitstellungen.

Anspruchsvollere Verkehrssteuerung und -aufteilung mit erweiterten Anpassungen

Diese NGINX-Funktionen erleichtern die Steuerung und Aufteilung des Datenverkehrs auf komplexe Weise:

• Der Schlüssel‑Wert‑Speicher für Canary‑Bereitstellungen – Wenn Sie A/B‑Tests oder Blue‑Green‑Bereitstellungen durchführen, möchten Sie den Datenverkehr möglicherweise in bestimmten Schritten auf die neue Version umstellen, z. B. 0 %, 5 %, 10 %, 25 %, 50 % und 100 %. Bei den meisten Tools ist dies ein sehr manueller Prozess, da Sie den Prozentsatz bearbeiten und die Konfigurationsdatei für jede Erhöhung neu laden müssen. Angesichts dieses Aufwands entscheiden Sie sich möglicherweise, das Risiko einzugehen und direkt von 5 % auf 100 % zu gehen. Mit der auf NGINX Plus basierenden Version von NGINX Ingress Controller können Sie jedoch den Schlüssel-Wert-Speicher nutzen, um die Prozentsätze zu ändern, ohne dass ein Neuladen erforderlich ist .

• Stromkreisunterbrechung mit NGINX Ingress Controller – Ausgefeilte Stromkreisunterbrecher sparen Zeit und verbessern die Belastbarkeit, indem sie Fehler und Failover schneller erkennen und sogar benutzerdefinierte, formatierte Fehlerseiten für fehlerhafte Upstreams aktivieren. Beispielsweise könnte ein Leistungsschalter für einen Suchdienst so konfiguriert werden, dass er einen korrekt formatierten, aber leeren Satz von Suchergebnissen zurückgibt. Um dieses Niveau an Komplexität zu erreichen, verwendet die auf NGINX Plus basierende Version des NGINX Ingress Controller aktive Integritätsprüfungen , die den Zustand Ihrer TCP- und UDP-Upstream-Server proaktiv überwachen. Da die Überwachung in Echtzeit erfolgt, ist es weniger wahrscheinlich, dass Ihre Kunden auf Apps stoßen, die Fehler zurückgeben.

• Stromkreisunterbrechung mit NGINX Service Mesh – Die Spezifikation des Stromkreisunterbrechers von NGINX Service Mesh verfügt über drei benutzerdefinierte Felder:

  • Fehler – Die Anzahl der Fehler, bevor der Stromkreis auslöst
  • timeoutSeconds – Das Zeitfenster, innerhalb dessen Fehler auftreten können, bevor der Stromkreis ausgelöst wird, sowie die Zeit, die gewartet werden muss, bevor der Stromkreis geschlossen wird
  • Fallback – Der Name und Port des Kubernetes-Dienstes, zu dem der Datenverkehr umgeleitet wird, nachdem der Circuit unterbrochen wurde.

  Während Fehler und Timeout-Sekunden Standardfunktionen zum Unterbrechen von Leistungsschaltern sind, steigert Fallback die Ausfallsicherheit noch weiter, da Sie dadurch einen Backup-Server definieren können. Wenn die Antworten Ihres Backup-Servers eindeutig sind, können sie ein früher Hinweis auf Probleme in Ihrem Cluster sein, sodass Sie sofort mit der Fehlerbehebung beginnen können.

Interpretieren Sie die Ergebnisse der Verkehrsaufteilung mit Dashboards

Sie haben Ihre Verkehrsaufteilung implementiert... und nun? Es ist Zeit, das Ergebnis zu analysieren. Dies kann der schwierigste Teil sein, da vielen Organisationen wichtige Erkenntnisse zur Leistung ihres Kubernetes-Verkehrs und ihrer Apps fehlen. NGINX erleichtert das Gewinnen von Erkenntnissen mit dem NGINX Plus-Dashboard und vorgefertigten Grafana-Dashboards, die vom Prometheus Exporter bereitgestellte Metriken visualisieren. Weitere Informationen zum Verbessern der Sichtbarkeit zum Gewinnen von Erkenntnissen finden Sie in unserem Blog unter „So verbessern Sie die Sichtbarkeit in Kubernetes“ .

Microservices meistern mit NGINX

Der auf NGINX Plus basierende NGINX Ingress Controller ist als kostenlose 30-Tage-Testversion verfügbar und umfasst NGINX App Protect zum Schutz Ihrer containerisierten Apps.

Um NGINX Ingress Controller mit NGINX Open Source auszuprobieren, können Sie den Quellcode der Version erhalten oder einen vorgefertigten Container von DockerHub herunterladen.

Das stets kostenlose NGINX Service Mesh steht unter f5.com zum Download bereit.