Geekly articles weekly

Zurück zu Microservices mit Istio. Teil 2



Hinweis perev. : Der erste Teil dieser Reihe war der Einführung von Istio und seiner Demonstration in Aktion gewidmet. Jetzt werden wir über komplexere Aspekte der Konfiguration und Verwendung dieses Dienstnetzes sprechen, insbesondere über fein abgestimmtes Routing und Netzwerkverkehrsmanagement.

Wir erinnern Sie auch daran, dass der Artikel Konfigurationen (Manifeste für Kubernetes und Istio) aus dem Istio-Mastery- Repository verwendet.

Verkehrsmanagement


Mit Istio werden im Cluster neue Funktionen angezeigt, die Folgendes bieten:

  • Dynamisches Abfrage-Routing : Kanarische Rollouts, A / B-Tests;
  • Lastausgleich : einfach und konsistent, basierend auf Hashes;
  • Wiederherstellung im Herbst : Zeitüberschreitungen, Wiederholungsversuche, Leistungsschalter;
  • Fehlereingabe : Verzögerungen, Unterbrechung von Anforderungen usw.

In der Fortsetzung des Artikels werden diese Funktionen als Beispiel für die ausgewählte Anwendung gezeigt und neue Konzepte werden vorgestellt. Das erste derartige Konzept sind DestinationRules (d. H. Regeln über den Empfänger von Verkehr / Anfragen - ca. Übersetzung) , mit denen wir A / B-Tests aktivieren.

A / B-Tests: Zielregeln in der Praxis


A / B-Tests werden in Fällen verwendet, in denen es zwei Versionen der Anwendung gibt (normalerweise unterscheiden sie sich optisch) und wir nicht 100% sicher sind, welche die Benutzerinteraktion verbessern wird. Daher starten wir beide Versionen gleichzeitig und sammeln Metriken.

Führen Sie den folgenden Befehl aus, um die zweite Version des Frontends bereitzustellen, die zum Demonstrieren von A / B-Tests erforderlich ist:

 $ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml deployment.extensions/sa-frontend-green created

Das Bereitstellungsmanifest für die "grüne Version" unterscheidet sich in zwei Punkten:

  1. Das Bild basiert auf einem anderen Tag - istio-green ,
  2. Pods haben eine version: green Etikett.

Da beide Bereitstellungen über die Bezeichnung app: sa-frontend verfügen, werden Anforderungen, die vom virtuellen Dienst sa-external-services an den sa-frontend Dienst weitergeleitet werden, an alle seine Instanzen umgeleitet und die Last mithilfe des Round-Robin-Algorithmus verteilt . Dies führt zu folgender Situation:


Angeforderte Dateien nicht gefunden

Diese Dateien wurden nicht gefunden, da sie in verschiedenen Versionen der Anwendung unterschiedlich aufgerufen werden. Stellen wir sicher, dass:

 $ curl --silent http://$EXTERNAL_IP/ | tr '"' '\n' | grep main /static/css/main.c7071b22.css /static/js/main.059f8e9c.js $ curl --silent http://$EXTERNAL_IP/ | tr '"' '\n' | grep main /static/css/main.f87cd8c9.css /static/js/main.f7659dbb.js

Dies bedeutet, dass index.html , in dem eine Version statischer Dateien angefordert wird, vom Load Balancer an Pods mit einer anderen Version gesendet werden kann, in denen solche Dateien aus offensichtlichen Gründen nicht vorhanden sind. Damit die Anwendung funktioniert, müssen wir daher eine Einschränkung festlegen : " Dieselbe Version der Anwendung, die index.html angegeben hat, muss auch nachfolgende Anforderungen bedienen ."

Wir werden das Ziel mit einem konsistenten Hash-basierten Lastausgleich (Consistent Hash Loadbalancing) erreichen . In diesem Fall werden Anforderungen von einem Client an dieselbe Backend-Instanz gesendet , für die eine vordefinierte Eigenschaft verwendet wird, z. B. ein HTTP-Header. Implementiert mit DestinationRules.

Zielregeln


Nachdem VirtualService eine Anforderung an den gewünschten Dienst gesendet hat , können wir mithilfe von DestinationRules die Richtlinien festlegen, die auf den für Instanzen dieses Dienstes bestimmten Datenverkehr angewendet werden:


Istio Resource Traffic Management

Hinweis : Die Auswirkungen von Istio-Ressourcen auf den Netzwerkverkehr werden hier vereinfacht dargestellt. Um genau zu sein, trifft Envoy die Entscheidung, an welche Instanz die Anforderung gesendet werden soll, in dem in CRD konfigurierten Ingress Gateway.

Mithilfe der Zielregeln können wir den Lastenausgleich so konfigurieren, dass konsistente Hashes verwendet werden und Antworten von derselben Dienstinstanz für denselben Benutzer garantiert werden. Die folgende Konfiguration ermöglicht dies ( destinationrule-sa-frontend.yaml ), um dies zu erreichen:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: sa-frontend spec: host: sa-frontend trafficPolicy: loadBalancer: consistentHash: httpHeaderName: version # 1

1 - Der Hash wird basierend auf dem Inhalt des HTTP- version generiert.

Wenden Sie die Konfiguration mit dem folgenden Befehl an:

 $ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml destinationrule.networking.istio.io/sa-frontend created

Führen Sie nun den folgenden Befehl aus und stellen Sie sicher, dass Sie die Dateien erhalten, die Sie benötigen, wenn Sie den version angeben:

 $ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' '\n' | grep main

Hinweis : Um dem Titel verschiedene Werte hinzuzufügen und die Ergebnisse direkt im Browser zu testen, können Sie diese Erweiterung für Chrome verwenden (oder diese für Firefox - ca. Transl.) .

Im Allgemeinen bietet DestinationRules mehr Optionen im Bereich des Lastausgleichs. Weitere Informationen finden Sie in der offiziellen Dokumentation .

Bevor wir VirtualService weiter untersuchen, entfernen wir die „grüne Version“ der Anwendung und die entsprechende Regel in Verkehrsrichtung, indem wir die folgenden Befehle ausführen:

 $ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml deployment.extensions “sa-frontend-green” deleted $ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml destinationrule.networking.istio.io “sa-frontend” deleted

Spiegeln: Virtuelle Dienste in der Praxis


Shadowing ("Shielding") oder Mirroring ("Mirroring") wird in den Fällen verwendet, in denen wir eine Änderung in der Produktion testen möchten, ohne die Endbenutzer zu beeinträchtigen. Dazu duplizieren wir ("Mirror") Anforderungen für die zweite Instanz, in der die erforderlichen Änderungen vorgenommen werden. und schauen Sie sich die Konsequenzen an. Einfach ausgedrückt, dies ist der Zeitpunkt, an dem Ihr (a) Kollege das kritischste Problem auswählt und eine Pull-Anfrage in Form eines so großen Schmutzklumpens stellt, dass niemand ihm tatsächlich eine Bewertung geben kann.

Um dieses Szenario in Aktion zu testen, erstellen Sie eine zweite Instanz von SA-Logic mit Fehlern ( buggy ), indem Sie den folgenden Befehl ausführen:

 $ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml deployment.extensions/sa-logic-buggy created

Und jetzt führen wir den Befehl aus, um sicherzustellen, dass alle Instanzen mit app=sa-logic Beschriftungen mit den entsprechenden Versionen haben:

 $ kubectl get pods -l app=sa-logic --show-labels NAME READY LABELS sa-logic-568498cb4d-2sjwj 2/2 app=sa-logic,version=v1 sa-logic-568498cb4d-p4f8c 2/2 app=sa-logic,version=v1 sa-logic-buggy-76dff55847-2fl66 2/2 app=sa-logic,version=v2 sa-logic-buggy-76dff55847-kx8zz 2/2 app=sa-logic,version=v2

Der sa-logic zielt auf Pods mit der Bezeichnung app=sa-logic , sodass alle Anforderungen auf alle Instanzen verteilt werden:



... aber wir möchten, dass Anfragen an Instanzen mit Version v1 gerichtet und an Instanzen mit Version v2 gespiegelt werden:



Dies erreichen wir durch den VirtualService in Kombination mit der DestinationRule, wobei die Regeln die Teilmengen und Routen des VirtualService zu einer bestimmten Teilmenge bestimmen.

Definieren von Teilmengen in Zielregeln


Teilmengen werden durch die folgende Konfiguration definiert ( sa-Logik-Teilmengen- Zielregel.yaml ):

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: sa-logic spec: host: sa-logic # 1 subsets: - name: v1 # 2 labels: version: v1 # 3 - name: v2 labels: version: v2

  1. Der host fest, dass diese Regel nur für Fälle gilt, in denen die Route zum sa-logic .
  2. Die Namen der Teilmengen werden beim Weiterleiten an Instanzen der Teilmenge verwendet.
  3. Eine Bezeichnung definiert die Schlüssel-Wert-Paare, mit denen Instanzen übereinstimmen müssen, um Teil einer Teilmenge zu werden.

Wenden Sie die Konfiguration mit dem folgenden Befehl an:

 $ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml destinationrule.networking.istio.io/sa-logic created

Nachdem die Teilmengen definiert sind, können Sie VirtualService so konfigurieren, dass die Regeln auf Anforderungen an sa-logic angewendet werden, sodass:

  1. Weitergeleitet an eine Teilmenge von v1 ,
  2. In eine Teilmenge von v2 gespiegelt.

Das folgende Manifest ermöglicht es Ihnen, Ihren Plan zu erreichen ( sa-Logik-Teilmengen-Shadowing-vs. Yaml ):

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 mirror: host: sa-logic subset: v2

Hier ist keine Erklärung erforderlich. Schauen Sie sich also die Aktion an:

 $ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml virtualservice.networking.istio.io/sa-logic created

Fügen Sie die Last hinzu, indem Sie diesen Befehl aufrufen:

 $ while true; do curl -v http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}'; \ sleep .8; done

Schauen wir uns die Ergebnisse in Grafana an, wo wir sehen können, dass die fehlerhafte Version bei ~ 60% der Anfragen abstürzt, aber keiner dieser Abstürze betrifft Endbenutzer, da sie einen funktionierenden Dienst haben.


Erfolg der Antworten verschiedener Versionen des Sa-Logic-Dienstes

Hier haben wir zum ersten Mal gesehen, wie VirtualService auf die Gesandten unserer Dienste angewendet wird: Wenn die sa-web-app eine Anfrage an sa-logic , durchläuft sie den Sidecar Envoy, der über VirtualService so konfiguriert ist, dass die Anfrage an die Teilmenge v1 und den Spiegel weitergeleitet wird eine Anforderung an eine Teilmenge von v2 des sa-logic .

Ich weiß: Sie hatten bereits Zeit zu denken, dass virtuelle Dienste einfach sind. Im nächsten Abschnitt erweitern wir diese Ansicht durch die Tatsache, dass sie auch wirklich großartig sind.

Kanarische Brötchen


Canary Deployment ist der Prozess der Einführung einer neuen Version einer Anwendung für eine kleine Anzahl von Benutzern. Es wird verwendet, um sicherzustellen, dass es keine Probleme bei der Veröffentlichung gibt, und erst danach, da es bereits von seiner ausreichenden (Veröffentlichungs-) Qualität überzeugt ist, um es einem größeren Publikum zugänglich zu machen.

Um die Einführung von Kanarienvögeln zu demonstrieren, werden wir weiterhin mit einer Teilmenge von buggy in sa-logic .

Verschwenden wir keine Zeit damit und senden Sie sofort 20% der Benutzer mit Fehlern an die Version (dies wird unseren kanarischen Rollout darstellen) und die restlichen 80% an den normalen Service. Wenden Sie dazu den folgenden VirtualService an ( sa-Logik-Teilmengen-Kanarienvogel-vs.yaml ):

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 weight: 80 # 1 - destination: host: sa-logic subset: v2 weight: 20 # 1

1 ist das Gewicht, das den Prozentsatz der Anforderungen bestimmt, die an den Empfänger oder eine Teilmenge des Empfängers gesendet werden.

Aktualisieren Sie die vorherige VirtualService-Konfiguration für sa-logic folgenden Befehl:

 $ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml virtualservice.networking.istio.io/sa-logic configured

... und sofort sehen, dass ein Teil der Anfragen abstürzt:

 $ while true; do \ curl -i http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}' \ --silent -w "Time: %{time_total}s \t Status: %{http_code}\n" \ -o /dev/null; sleep .1; done Time: 0.153075s Status: 200 Time: 0.137581s Status: 200 Time: 0.139345s Status: 200 Time: 30.291806s Status: 500

VirtualServices aktivieren kanarische Rollouts: In diesem Fall haben wir die möglichen Folgen von Problemen auf 20% der Benutzer reduziert. Großartig! In jedem Fall können wir, wenn wir uns unseres Codes nicht sicher sind (mit anderen Worten, immer ...), Spiegelung und kanarische Rollouts verwenden.

Zeitüberschreitungen und Wiederholungen


Aber nicht immer sind Fehler im Code. In der Liste der " 8 Fehler beim verteilten Rechnen " erscheint in erster Linie die falsche Meinung, dass "das Netzwerk zuverlässig ist". In Wirklichkeit ist das Netzwerk nicht zuverlässig, und aus diesem Grund benötigen wir Zeitüberschreitungen und Wiederholungsversuche .

Zur Demonstration werden wir weiterhin dieselbe Version von sa-logic ( buggy ) verwenden und die Unzuverlässigkeit des Netzwerks mit zufälligen Fehlern simulieren.

Lassen Sie unseren Service mit Fehlern eine Chance von 1/3 für eine zu lange Antwort haben, 1/3 für einen Abschluss mit einem internen Serverfehler und 1/3 für eine erfolgreiche Seitenrückgabe.

Um die Folgen solcher Probleme zu mildern und das Leben der Benutzer zu verbessern, können wir:

  1. Fügen Sie eine Zeitüberschreitung hinzu, wenn der Dienst länger als 8 Sekunden antwortet.
  2. Wiederholen Sie den Vorgang, wenn die Anforderung fehlschlägt.

Für die Implementierung verwenden wir die folgende Ressourcendefinition ( sa-Logik-Wiederholungs-Timeouts-vs.yaml ):

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 weight: 50 - destination: host: sa-logic subset: v2 weight: 50 timeout: 8s # 1 retries: attempts: 3 # 2 perTryTimeout: 3s # 3

  1. Das Zeitlimit für die Anforderung ist auf 8 Sekunden festgelegt.
  2. Wiederholte Anforderungsversuche werden dreimal durchgeführt.
  3. Und jeder Versuch wird als erfolglos angesehen, wenn die Antwortzeit 3 ​​Sekunden überschreitet.

Wir haben also eine Optimierung erreicht, da der Benutzer nicht länger als 8 Sekunden warten muss und wir drei neue Versuche unternehmen werden, um bei Fehlern eine Antwort zu erhalten, was die Wahrscheinlichkeit einer erfolgreichen Antwort erhöht.

Wenden Sie die aktualisierte Konfiguration mit dem folgenden Befehl an:

 $ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml virtualservice.networking.istio.io/sa-logic configured

Und überprüfen Sie in den Grafiken von Grafana, ob die Anzahl der erfolgreichen Antworten abgelaufen ist:


Verbesserungen in der Statistik erfolgreicher Antworten nach dem Hinzufügen von Zeitüberschreitungen und Wiederholungsversuchen

Bevor Sie mit dem nächsten Abschnitt fortfahren (oder besser gesagt mit dem nächsten Teil des Artikels, da in diesem praktischen Abschnitt keine weiteren Experimente durchgeführt werden - ca. Übersetzen) , löschen Sie sa-logic-buggy und VirtualService, indem Sie die folgenden Befehle ausführen:

 $ kubectl delete deployment sa-logic-buggy deployment.extensions “sa-logic-buggy” deleted $ kubectl delete virtualservice sa-logic virtualservice.networking.istio.io “sa-logic” deleted

Leistungsschalter- und Schottmuster


Wir sprechen über zwei wichtige Muster in der Microservice-Architektur, mit denen Sie Selbstheilungsdienste erzielen können.

Der Leistungsschalter („Leistungsschalter“) wird verwendet, um Anforderungen an eine als fehlerhaft eingestufte Instanz eines Dienstes zu stoppen und wiederherzustellen, während Clientanforderungen an fehlerfreie Instanzen dieses Dienstes umgeleitet werden (wodurch sich der Prozentsatz erfolgreicher Antworten erhöht). (Hinweis: Eine detailliertere Beschreibung des Musters finden Sie beispielsweise hier .)

Bulkhead ("Partition") isoliert Servicefehler von der Niederlage des gesamten Systems. Beispielsweise ist Dienst B unterbrochen, und ein anderer Dienst (der Client von Dienst B) stellt eine Anforderung an Dienst B, wodurch er seinen Thread-Pool verbraucht und andere Anforderungen nicht bedienen kann (selbst wenn sie nicht mit Dienst B zusammenhängen). (Hinweis: Eine detailliertere Beschreibung des Musters finden Sie beispielsweise hier .)

Ich werde die Details zur Implementierung dieser Muster weglassen, da sie in der offiziellen Dokumentation leicht zu finden sind, und ich möchte wirklich die Authentifizierung und Autorisierung zeigen, die im nächsten Teil des Artikels erörtert werden.

PS vom Übersetzer


Lesen Sie auch in unserem Blog:

Source: https://habr.com/ru/post/de440378/

More articles:


All Articles