Istio Service Mesh Beiträge Serie

Wir starten eine Reihe von Beiträgen, in denen wir einige der vielen Funktionen des Istio Service Mesh in Verbindung mit Red Hat OpenShift und Kubernetes demonstrieren.



Teil eins, heute:

  • Erläutern wir das Konzept der Kubernetes-Beiwagencontainer und formulieren das Leitmotiv dieser Postserie: "Sie müssen an Ihrem Code nichts ändern . "
  • Stellen Sie sich das Wesentliche vor - die Routing-Regeln von Istio. Sie bilden alle anderen Funktionen von Istio, da Sie anhand der Regeln den Datenverkehr mithilfe der YAML-Dateien außerhalb des Dienstcodes an Microservices leiten können. Wir betrachten auch das Bereitstellungsschema für Canary Deployment. Neujahrsbonus - 10 interaktive Istio-Lektionen

Teil zwei wird Ihnen sagen:

  • Wie Istio Pool Ejection in Verbindung mit Circuit Breaker implementiert und demonstriert, wie Istio einen defekten oder schlecht funktionierenden Pod aus dem Auswuchtschema entfernt.
  • Und wir werden das Thema Leistungsschalter ab dem ersten Beitrag behandeln, wie Istio hier verwendet werden kann. Wir zeigen, wie Datenverkehr weitergeleitet und Netzwerkfehler mithilfe der YAML-Konfigurationsdateien und Terminalbefehle behandelt werden, ohne dass sich der Servicecode ändert.

Dritter Teil :

  • Eine Geschichte über Nachverfolgung und Überwachung, die bereits integriert sind oder Istio problemlos hinzugefügt werden können. Wir zeigen Ihnen, wie Sie Tools wie Prometheus, Jaeger und Grafana in Kombination mit der OpenShift-Skalierung verwenden, um Ihre Microservice-Architektur einfach zu verwalten.
  • Wir gehen von der Überwachung und Fehlerbehandlung über und führen sie absichtlich in das System ein. Mit anderen Worten, wir lernen, Fehler zu injizieren, ohne den Quellcode zu ändern, was aus Sicht des Tests sehr wichtig ist - denn wenn Sie den Code selbst ändern, besteht die Gefahr, dass zusätzliche Fehler eingefügt werden.

Im letzten Beitrag zum Istio Service Mesh:

  • Gehen wir weiter zur dunklen Seite. Genauer gesagt werden wir lernen, das Dark-Launch-Schema zu verwenden, wenn der Code direkt auf Produktionsdaten implementiert und getestet wird, ohne jedoch den Betrieb des Systems zu beeinträchtigen. Hier ist Istios Fähigkeit, Datenverkehr zu teilen, von Vorteil. Und die Möglichkeit, Tests an Live-Produktionsdaten durchzuführen, ohne die Leistung des Kampfsystems zu beeinträchtigen, ist der überzeugendste Weg, dies zu überprüfen.
  • Ausgehend von Dark Launch werden wir zeigen, wie Sie mit dem Canary Deployment-Modell Risiken reduzieren und die Inbetriebnahme von neuem Code vereinfachen können. Canary Deployment selbst ist keine Neuigkeit, aber mit Istio können Sie dieses Schema mit einfachen YAML-Dateien implementieren.
  • Abschließend zeigen wir, wie Sie mit Istio Egress den Zugriff auf Dienste für Benutzer außerhalb Ihrer Cluster ermöglichen, um die Funktionen von Istio bei der Arbeit mit dem Internet zu nutzen.

Also fing es an ...

Istio Überwachungs- und Steuerungstools - alles, was Sie zum Koordinieren von Mikrodiensten im Servicegitter benötigen.

Was ist das Istio-Servicenetz?


Ein Service-Grid implementiert Funktionen für eine Gruppe von Diensten, z. B. Verkehrsüberwachung, Zugriffskontrolle, Erkennung, Sicherheit, Fehlertoleranz und andere nützliche Dinge. Mit Istio können Sie all dies tun, ohne den Code der Dienste selbst zu ändern. Was ist das Geheimnis der Magie? Istio bindet an jeden Service seinen Proxy in Form eines Sidecar-Containers (Sidecar ist ein Motorrad-Kinderwagen), wonach der gesamte Datenverkehr zu diesem Service über einen Proxy geleitet wird, der anhand festgelegter Richtlinien entscheidet, wie, wann und ob dieser Datenverkehr den Service überhaupt erreichen soll. Mit Istio können auch fortgeschrittene DevOps-Techniken implementiert werden, z. B. kanarische Einsätze, Leistungsschalter, Fehlerinjektion und viele andere.

Wie Istio mit Containern und Kubernetes arbeitet


Das Istio-Service-Grid ist eine Sidecar-Implementierung von allem, was Sie zum Erstellen und Verwalten von Mikrodiensten benötigen: Überwachung, Nachverfolgung, Leistungsschalter, Routing, Lastausgleich, Fehlerinjektion, Wiederholungsversuche, Zeitüberschreitung, Spiegelung, Zugriffskontrolle, Geschwindigkeitsbegrenzungen und vieles mehr eine andere. Und obwohl es heutzutage viele Bibliotheken gibt, die diese Funktionen direkt im Code implementieren, können Sie mit Istio das Gleiche erreichen, ohne irgendetwas an Ihrem Code zu ändern.

Nach dem Beiwagenmodell läuft Istio in einem Linux-Container, der sich im selben Kubernetes- Pod mit einem kontrollierten Dienst befindet und Funktionen und Informationen gemäß einer bestimmten Konfiguration einspeist und extrahiert. Wir betonen, dass dies Ihre eigene Konfiguration ist und sich außerhalb Ihres Codes befindet. Daher wird der Code viel einfacher und kürzer.

Was noch wichtiger ist, die betriebliche Komponente von Microservices ist in diesem Fall in keiner Weise mit dem Code selbst verbunden, so dass ihr Betrieb sicher an IT-Spezialisten übertragen werden kann. In der Tat, warum sollte ein Entwickler für Leistungsschalter und Fehlerinjektion verantwortlich sein? Reagieren - ja, aber verarbeiten und erstellen? Wenn Sie all dies aus dem Code entfernen, können sich die Programmierer vollständig auf die Anwendungsfunktionalität konzentrieren. Und der Code selbst wird kürzer und einfacher.

Servicenetz


Istio, das Mikroservice-Management-Funktionen außerhalb seines Codes implementiert, ist das Konzept des Service Mesh-Service-Grids. Mit anderen Worten, es ist eine koordinierte Gruppe von einer oder mehreren Binärdateien, die ein Netzwerk von Netzwerkfunktionen bilden.

So arbeitet Istio mit Microservices


So funktionieren die Beiwagencontainer in Verbindung mit Kubernetes und Minishift aus der Vogelperspektive: Starten Sie eine Instanz von Minishift, erstellen Sie ein Projekt für Istio (nennen wir es „istio-system“), installieren Sie alle mit Istio zusammenhängenden Komponenten und führen Sie sie aus. Fügen Sie dann beim Erstellen von Projekten und Pods Konfigurationsinformationen zu Ihren Bereitstellungen hinzu, und Ihre Pods verwenden Istio. Ein vereinfachtes Diagramm sieht folgendermaßen aus:



Jetzt können Sie die Einstellungen von Istio ändern, um beispielsweise die Fehlerinjektion, die Unterstützung für Canary Deployment oder andere Funktionen von Istio zu organisieren, ohne den Code der Anwendungen selbst zu berühren. Angenommen, Sie möchten den gesamten Webdatenverkehr von Benutzern Ihres größten Kunden (Foo Corporation) auf eine neue Version der Site umleiten. Dazu erstellen Sie einfach eine Istio-Routing-Regel, die in der Benutzer-ID nach @ foocorporation.com sucht, und führen die entsprechende Umleitung durch. Für alle anderen Benutzer ändert sich nichts. In der Zwischenzeit testen Sie ruhig die neue Version der Website. Beachten Sie, dass Sie dafür keine Entwickler gewinnen müssen.

Und dafür müssen Sie teuer bezahlen?


Gar nicht. Istio arbeitet ziemlich schnell, es ist in Go geschrieben und erzeugt einen sehr kleinen Overhead. Darüber hinaus wird ein möglicher Verlust an Online-Produktivität durch eine Steigerung der Entwicklerproduktivität ausgeglichen. Zumindest theoretisch: Vergessen Sie nicht, dass Entwicklungszeit teuer ist. Was die Softwarekosten angeht, so handelt es sich bei Istio um Open-Source-Software, die Sie kostenlos herunterladen und verwenden können.

Lernen Sie selbst


Das Red Hat Developer Experience Team hat einen ausführlichen praktischen Leitfaden für Istio (in englischer Sprache) entwickelt. Es läuft unter Linux, MacOS und Windows, und der Code ist in Java und Node.js enthalten.

10 interaktive Lektionen zu Istio


Block 1 - Für Anfänger


Einführung in Istio
30 Minuten
Wir machen uns mit Service Mesh vertraut und lernen, wie man Istio im Kubernetes OpenShift-Cluster installiert.
Fangen Sie an

Bereitstellen von Microservices in Istio
30 Minuten
Wir verwenden Istio, um drei Microservices mit Spring Boot und Vert.x bereitzustellen.
Fangen Sie an

Block 2 - Mittelstufe


Überwachung und Verfolgung in Istio
60 Minuten
Wir untersuchen Istios integrierte Überwachungstools, benutzerdefinierte Metriken und OpenTracing über Prometheus und Grafana.
Fangen Sie an

Einfaches Routing in Istio
60 Minuten
Erfahren Sie, wie Sie das Routing in Istio mit einfachen Regeln verwalten.
Fangen Sie an

Erweiterte Routing-Regeln
60 Minuten
Einführung von intelligentem Istio-Routing, Zugriffskontrolle, Lastenausgleich und Geschwindigkeitsbegrenzung.
Fangen Sie an

Block 3 - Fortgeschrittener Benutzer


Fehlereinspritzung in Istio
60 Minuten
Wir untersuchen Failover-Szenarien in verteilten Anwendungen, verursachen HTTP-Fehler und Netzwerkverzögerungen und lernen, wie Sie mit Chaos Engineering die Umgebung wiederherstellen.
Fangen Sie an

Leistungsschalter bei Istio
30 Minuten
Installieren Sie Sie Siege für Stresstest-Sites und erfahren Sie, wie Sie die Ausfallsicherheit des Backends durch Wiederholungen, Leistungsschalter und Pool-Auswurf verbessern.
Fangen Sie an

Egress und Istio
10 Minuten
Wir verwenden die Egress-Routen, um Regeln für die Interaktion interner Services mit externen APIs und Services zu erstellen.
Fangen Sie an

Istio und Kiali
15 Minuten
Wir lernen, mit Kiali ein allgemeines Bild des Service-Grids zu erhalten und den Fluss von Anfragen und Daten zu untersuchen.
Fangen Sie an

Gegenseitiges TLS in Istio
15 Minuten
Wir erstellen Istio Gateway und VirtualService und untersuchen dann detailliert das gegenseitige TLS (mTLS) und seine Einstellungen.
Fangen Sie an

Block 3.1 - Tiefes Eintauchen: Istio Service Mesh für Microservices



Über was das Buch:
  • Was ist ein Servicegitter?
  • Das Istio-System und seine Rolle in der Microservice-Architektur.
  • Verwenden von Istio zur Lösung der folgenden Probleme:
    • Fehlertoleranz;
    • Routing
    • Chaostests;
    • Sicherheit;
    • Telemetriesammlung mit Tracing, Metriken und Grafana.


Buch herunterladen

Artikelserie zu Service Grids und Istio



Probieren Sie es aus


Diese Postenserie soll nicht zu einem tiefen Eintauchen in die Welt von Istio führen. Wir möchten Ihnen nur das Konzept selbst vorstellen und Sie vielleicht dazu inspirieren, Istio selbst auszuprobieren. Dies ist völlig kostenlos und Red Hat bietet alle notwendigen Tools, um OpenShift, Kubernetes, Linux-Container und Istio kennenzulernen: Red Hat Developer OpenShift Container Platform , unseren Istio-Leitfaden und andere Ressourcen auf unserer Microsite unter Service Mesh . Nicht aufschieben, noch heute anfangen!

Istio-Routing-Regeln: Wir leiten Serviceanfragen dorthin, wo wir sie benötigen


OpenShift und Kubernetes leiten Microservice- Aufrufe hervorragend an die richtigen Pods weiter. Dies ist eines der Ziele von Kubernetes - Routing und Load Balancing. Was aber, wenn Sie ein feineres und ausgefeilteres Routing benötigen? Zum Beispiel, um zwei Versionen eines Mikrodienstes gleichzeitig zu verwenden. Wie helfen die Istio-Routenregeln hier?

Routing-Regeln sind Regeln, die tatsächlich die Wahl der Route bestimmen. Auf jeder Ebene der Systemkomplexität bleibt das allgemeine Funktionsprinzip dieser Regeln einfach: Anforderungen werden basierend auf bestimmten Parametern und HTTP-Headerwerten weitergeleitet.
Schauen wir uns Beispiele an:

Kubernetes default: trivial "50 to 50"


In unserem Beispiel zeigen wir, wie zwei Versionen des Mikrodienstes in OpenShift gleichzeitig verwendet werden. Nennen wir sie v1 und v2. Jede Version läuft in einem eigenen Kubernetes-Pod und arbeitet standardmäßig mit gleichmäßigem Round-Robin-Routing. Jeder Pod erhält seinen Anteil an Anforderungen nach der Anzahl seiner Mikroservice-Instanzen, dh der Replikate. Mit Istio können Sie diesen Kontostand auch manuell ändern.

Angenommen, wir haben zwei Versionen unseres Empfehlungsdienstes auf OpenShift bereitgestellt, Empfehlung-v1 und Empfehlung-v2.
In Abb. Abbildung 1 zeigt, dass, wenn jeder Dienst in einer Instanz dargestellt wird, die Anforderungen gleichmäßig zwischen ihnen abgewechselt werden: 1-2-1-2- ... So funktioniert das Routing von Kubernetes standardmäßig:



Gewichtete Verteilung zwischen den Versionen


In Abb. Abbildung 2 zeigt, was passiert, wenn Sie die Anzahl der v2-Dienstreplikationen von eins auf zwei erhöhen (dies erfolgt mit dem Befehl oc scale --replicas = 2 deployment / recommended-v2). Wie Sie sehen, sind die Anforderungen zwischen v1 und v2 jetzt in eine Eins-zu-Drei-Beziehung unterteilt: 1-2-2-1-2-2-2- ...:



Ignoriere die Version mit Istio


Mit Istio ist es einfach, die Verteilung von Abfragen nach Bedarf zu ändern. Senden Sie beispielsweise den gesamten Datenverkehr nur mit der folgenden Istio-Yaml-Datei an Recommendation-v1:



Hierbei ist zu beachten: Die Schoten werden entsprechend der Beschriftung ausgewählt. In unserem Beispiel wird das Label v1 verwendet. Der Parameter „weight: 100“ bedeutet, dass 100% des Datenverkehrs an alle Pods des Dienstes weitergeleitet werden, die das Label v1 haben.

Verzeichnisverteilung zwischen Versionen (Canary Deployment)


Mithilfe des weight-Parameters können Sie den Datenverkehr zu beiden Pods leiten und dabei die Anzahl der in jedem Pod ausgeführten Microservice-Instanzen ignorieren. In diesem Beispiel leiten wir 90% des Datenverkehrs an v1 und 10% an v2 weiter:



Separates Routing für mobile Benutzer


Abschließend wird gezeigt, wie der Datenverkehr mobiler Benutzer zum v2-Dienst und der gesamte Rest zum v1-Dienst gezwungen werden kann. Dazu analysieren wir mit regulären Ausdrücken den Wert von user-agent im Anforderungsheader:



Jetzt sind Sie dran


Ein Beispiel mit regulären Ausdrücken zum Analysieren von Headern sollte Sie dazu motivieren, nach eigenen Optionen für die Anwendung von Istio-Routing-Regeln zu suchen. Darüber hinaus sind die Möglichkeiten hier sehr umfangreich, da die Werte der Header im Quellcode der Anwendungen gebildet werden können.

Und denk dran, Ops, nicht Dev


Alles, was wir in den obigen Beispielen gezeigt haben, geschieht ohne die geringsten Änderungen im Quellcode, außer in den Fällen, in denen es notwendig ist, spezielle Anforderungsheader zu bilden. Istio wird sowohl Entwicklern von Nutzen sein, die es beispielsweise in der Testphase einsetzen können, als auch Spezialisten für den Betrieb von IT-Systemen, die er in der Produktion maßgeblich unterstützen wird.

Wiederholen wir also das Leitmotiv dieser Reihe von Beiträgen: Sie müssen nichts an Ihrem Code ändern . Sie müssen keine neuen Bilder sammeln oder neue Container starten. All dies wird außerhalb des Codes implementiert.

Schalten Sie die Fantasie ein


Stellen Sie sich die Perspektiven der Überschriftenanalyse mit regulären Ausdrücken vor. Möchten Sie Ihren größten Kunden auf eine spezielle Version Ihrer Microservices umleiten? Einfach! Benötigen Sie eine separate Version für den Chrome-Browser? Kein Problem! Sie können den Verkehr nach fast allen Merkmalen leiten.

Probieren Sie es aus


Über Istio, Kubernetes und OpenShift zu lesen ist eine Sache, aber warum nicht mit eigenen Händen anfassen? Das Red Hat Developer Program- Team hat ein detailliertes Handbuch (in englischer Sprache) erstellt, mit dessen Hilfe Sie diese Technologien schnell beherrschen können. Das Handbuch ist ebenfalls zu 100% Open Source und daher öffentlich verfügbar. Die Datei funktioniert unter MacOS, Linux und Windows, und der Quellcode ist in Versionen in Java und node.js (Versionen in anderen Sprachen werden bald verfügbar sein). Öffnen Sie einfach das entsprechende Red Hat Developer Demo- Git-Repository in Ihrem Browser.

Im nächsten Beitrag: Wir arbeiten die Probleme schön aus


Heute haben Sie gesehen, wozu Istios Routing-Regeln in der Lage sind. Stellen Sie sich nun dasselbe vor, aber nur in Bezug auf die Fehlerbehandlung. Darüber werden wir im nächsten Beitrag sprechen.

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


All Articles