Wir beginnen eine Reihe von Beiträgen, in denen wir einige der vielen Möglichkeiten des Istio Service Mesh in Verbindung mit Red Hat OpenShift und Kubernetes demonstrieren.
Teil eins, heute:
- Wir erklären das Konzept der Sidecar-Container in Kubernetes und formulieren das Leitmotiv dieser Beitragsreihe: „Sie müssen nichts an Ihrem Code ändern“.
- Wir stellen das grundlegende Element von Istio vor – die Routing-Regeln. Auf diesen basieren alle anderen Möglichkeiten von Istio, da die Regeln es ermöglichen, den Traffic zu Microservices zu lenken, indem externe YAML-Dateien der Services verwendet werden. Außerdem betrachten wir das Schema für Canary Deployment. Als Neujahrsbonus gibt es 10 interaktive Sitzungen zu Istio.
Teil zwei, der bald erscheint, wird Ihnen erzählen:
- Wie Istio Pool Ejection in Kombination mit Circuit Breaker umsetzt und demonstriert, wie Istio in der Lage ist, nicht funktionierende oder schlecht funktionierende Pods aus dem Load-Balancing-Schema zu entfernen.
- Außerdem werden wir das Thema Circuit Breaker aus dem ersten Post betrachten, um zu sehen, wie wir dabei Istio nutzen können. Wir zeigen, wie man den Verkehr ohne jegliche Änderungen am Code der Services mit YAML-Konfigurationsdateien und Terminalbefehlen routiert und Netzwerfehler behandelt.
Teil drei:
- Ein Bericht über das Tracing und Monitoring, die bereits in Istio integriert oder leicht hinzuzufügen sind. Wir zeigen, wie man Tools wie Prometheus, Jaeger und Grafana in Kombination mit OpenShift-Skalierung einsetzt, um die Verwaltung der Microservice-Architektur mühelos zu gestalten.
- Wir gehen von Monitoring und Fehlerbehandlung dazu über, Fehler absichtlich ins System einzufügen. Mit anderen Worten, wir lernen, Fault Injection vorzunehmen, ohne den Quellcode zu ändern, was aus Testgründen sehr wichtig ist – denn wenn wir den Code dafür ändern, besteht das Risiko, zusätzliche Fehler einzuführen.
Schließlich im letzten Post zum Istio Service Mesh:
- Lass uns zur Dark Side übergehen. Genauer gesagt, lernen wir, wie man das Dark Launch-Schema verwendet, bei dem der Code bereitgestellt und direkt mit Produktionsdaten getestet wird, ohne den Betrieb des Systems zu beeinträchtigen. Hier kommt die Fähigkeit von Istio, den Traffic zu steuern, sehr gelegen. Die Möglichkeit, Tests mit echten Produktionsdaten durchzuführen, ohne den Betrieb des Live-Systems zu beeinflussen, ist der überzeugendste Weg, um sicherzustellen, dass alles funktioniert.
- Aufbauend auf Dark Launch zeigen wir, wie man das Canary Deployment-Modell anwendet, um Risiken zu reduzieren und die Einführung neuen Codes zu erleichtern. An sich ist das Canary Deployment längst keine Neuheit mehr, aber Istio ermöglicht es, dieses Schema einfach mit nicht komplizierten YAML-Dateien umzusetzen.
- Abschließend zeigen wir, wie man mit Istio Egress externen Services Zugang gewährt, damit die Funktionen von Istio beim Arbeiten mit dem Internet genutzt werden können.
Also, los geht's...
Das Monitoring- und Management-Toolkit von Istio – alles, was benötigt wird, um Mikrodienste im Service Mesh zu koordinieren. .
Was ist das Service Mesh Istio?
Das Servicenetzwerk bietet für Gruppen von Diensten Funktionen wie Traffic-Überwachung, Zugriffskontrolle, Erkennung, Sicherheit, Ausfallsicherheit und andere nützliche Aspekte. Istio ermöglicht all dies ohne geringste Änderungen am Code der Dienste selbst. Was ist das Geheimnis dieser Magie? Istio verbindet jeden Dienst mit einem Proxy in Form eines Sidecar-Containers, wodurch der gesamte Datenverkehr zu diesem Dienst über den Proxy geleitet wird, der gemäß den festgelegten Richtlinien entscheidet, wie, wann und ob dieser Verkehr überhaupt zum Dienst gelangen soll. Istio ermöglicht zudem die Umsetzung fortgeschrittener DevOps-Techniken wie Canary Deployments, Circuit Breakers, Fehlerinjektion und viele weitere.
Wie Istio mit Containern und Kubernetes arbeitet
Das Istio-Service-Netzwerk ist eine Sidecar-Implementierung von allem, was erforderlich ist, um Microservices zu erstellen und zu verwalten: Monitoring, Tracing, Circuit Breakers, Routing, Lastverteilung, Fehlereinführung, Wiederholungen, Zeitüberschreitungen, Spiegelungen, Zugriffskontrolle, Drosselung und vieles mehr. Und obwohl es heute zahlreiche Bibliotheken gibt, um diese Funktionen direkt im Code zu implementieren, können Sie mit Istio alles das Gleiche erreichen, ohne Ihren Code zu ändern.
Gemäß dem Sidecar-Modell wird Istio in einem Linux-Container ausgeführt, der sich in einem -Pod mit dem kontrollierten Service befindet und Funktionalität und Informationen gemäß der vorgegebenen Konfiguration injiziert (inject) und extrahiert (extract). Betonen wir, dass dies Ihre eigene Konfiguration ist, und sie lebt außerhalb Ihres Codes. Dadurch wird der Code erheblich einfacher und kürzer.
Es ist wichtig zu beachten, dass die operationale Komponente von Mikrodiensten nicht direkt mit dem Code verbunden ist, was bedeutet, dass deren Betrieb an IT-Spezialisten abgegeben werden kann. Warum sollte ein Entwickler für Circuit Breaker und Fault Injection verantwortlich sein? Reagieren – ja, aber deren Bearbeitung und Erstellung? Wenn all dies aus dem Code entfernt wird, können Programmierer sich vollständig auf die Anwendungsfunktionen konzentrieren. Außerdem wird der Code kürzer und einfacher.
Service Mesh
Istio, das Funktionen zur Verwaltung von Mikrodiensten außerhalb ihres Codes bereitstellt – das ist das Konzept des Service Mesh. Mit anderen Worten, es handelt sich um eine koordinierte Gruppe von einem oder mehreren Binärdateien, die ein Netzwerk von Funktionen bilden.
Wie Istio mit Mikrodiensten arbeitet
So funktioniert die Arbeit der Sidecar-Container in Verbindung mit und aus der Vogelperspektive: Sie starten eine Instanz von Minishift, erstellen ein Projekt für Istio (nennen wir es «istio-system»), installieren und starten alle mit Istio verbundenen Komponenten. Dann, während Sie Projekte und Pods erstellen, fügen Sie Konfigurationsinformationen zu Ihren Deployments hinzu, und Ihre Pods beginnen, Istio zu nutzen. Vereinfacht sieht das Diagramm so aus:
Jetzt können Sie die Einstellungen von Istio ändern, um zum Beispiel Fault Injection, Unterstützung oder andere Funktionen von Istio zu implementieren – und das alles ohne den Code der Anwendungen selbst zu berühren. Angenommen, Sie möchten den gesamten Webverkehr von den Nutzern Ihres größten Kunden (Foo Corporation) auf die neue Version der Website umleiten. Dazu müssen Sie nur eine Istio-Routingregel erstellen, die nach @foocorporation.com in der Benutzer-ID sucht und die entsprechende Umleitung durchführt. Für alle anderen Benutzer ändert sich nichts. Währenddessen können Sie in Ruhe die neue Version der Website testen. Und beachten Sie, dass hierfür keine Entwickler eingebunden werden müssen.
Und muss man dafür viel bezahlen?
Keineswegs. Istio funktioniert ziemlich schnell, es ist geschrieben in und erzeugt nur einen minimalen Overhead. Außerdem wird der mögliche Verlust an Online-Performance durch die steigende Produktivität der Entwickler ausgeglichen. Zumindest in der Theorie: Vergessen Sie nicht, dass die Arbeitszeit der Entwickler teuer ist. Was die Softwarekosten betrifft, so ist Istio eine Open-Source-Software, die kostenlos bezogen und verwendet werden kann.
Lernen Sie selbst
Das Team der Red Hat Developer Experience Team hat einen vertieften praktischen Kurs zu Istio (in Englisch) entwickelt. Er läuft unter Linux, MacOS und Windows, und der Code ist in Varianten für Java und Node.js verfügbar.
10 interaktive Lektionen zu Istio
Block 1 – Für Einsteiger
Einführung in Istio
30 Minuten
Lernen Sie das Service Mesh kennen und erfahren Sie, wie man Istio in einem Kubernetes-Cluster auf OpenShift installiert.
Bereitstellung von Mikrodiensten in Istio
30 Minuten
Wir verwenden Istio, um drei Mikrodienste mit Spring Boot und Vert.x bereitzustellen.
Block 2 – Fortgeschrittene
Überwachung und Tracing in Istio
60 Minuten
Wir lernen die integrierten Überwachungsfunktionen von Istio kennen, konfigurieren Metriken sowie OpenTracing über Prometheus und Grafana.
Einfache Routen in Istio
60 Minuten
Wir lernen, wie man das Routing in Istio mit einfachen Regeln verwaltet.
Erweiterte Routing-Regeln
60 Minuten
Lernen Sie intelligente Routing-Methoden in Istio kennen, einschließlich Zugangskontrolle, Lastverteilung und Geschwindigkeitsbegrenzung.
Block 3 – erfahrener Benutzer
Fault Injection in Istio
60 Minuten
Wir untersuchen Szenarien zur Fehlerbehandlung in verteilten Anwendungen, indem wir HTTP-Fehler und Netzwerkverzögerungen erzeugen und Chaos Engineering anwenden, um die Umgebung wiederherzustellen.
Circuit Breaker in Istio
30 Minuten
Wir installieren Siege für Lasttests von Websites und lernen, die Ausfallsicherheit des Backends mit Wiederholungen, Circuit Breakern und Pool-Ejection zu gewährleisten.
Egress und Istio
10 Minuten
Wir verwenden Egress-Routen, um Interaktionsregeln zwischen internen Diensten und externen APIs und Diensten zu erstellen.
Istio und Kiali
15 Minuten
Wir lernen, Kiali zu nutzen, um einen Gesamtüberblick über das Service Mesh zu erhalten und Anfragen sowie Datenflüsse zu analysieren.
Mutual TLS in Istio
15 Minuten
Wir erstellen ein Istio Gateway und einen VirtualService und untersuchen dann ausführlich Mutual TLS (mTLS) und seine Konfigurationen.
Block 3.1 – Vertiefung: Istio Service Mesh für Microservices
Worum es in dem Buch geht:
- Was ist ein Service Mesh?
- Das System Istio und seine Rolle in der Microservices-Architektur.
- Einsatz von Istio zur Lösung folgender Aufgaben:
- Fehlertoleranz;
- Routing;
- Chaos-Test.
- Sicherheit;
- Telemetriesammlung mit Trace-Tools, Metriken und Grafana.
Artikelreihe zu Service Meshes und Istio
Versuchen Sie es selbst
Diese Reihe von Beiträgen hat nicht das Ziel, ein tiefes Eintauchen in die Welt von Istio zu bieten. Wir möchten Sie einfach mit dem Konzept vertrautmachen und vielleicht dazu anregen, Istio selbst auszuprobieren. Das ist völlig kostenlos, und Red Hat stellt alle notwendigen Werkzeuge zur Verfügung, um mit OpenShift, Kubernetes, Linux-Containern und Istio zu beginnen, nämlich: , und andere Ressourcen auf unserem . Verzögern Sie nicht, starten Sie noch heute!
Istio-Routing-Regeln: Leiten Sie Service-Anfragen dorthin, wo sie benötigt werden
und bewältigen hervorragend die Anfragen an wir auf die benötigten Pods zu. Das ist eines der Hauptziele von Kubernetes – Routing und Lastverteilung. Was ist, wenn Sie eine feinere und ausgeklügelte Routing-Lösung benötigen? Zum Beispiel, um gleichzeitig zwei Versionen eines Mikrodienstes zu verwenden. Wie können dabei die Istio Routing-Regeln helfen?
Routing-Regeln sind die Regeln, die die Auswahl des Routers bestimmen. Unabhängig von der Komplexität des Systems bleibt das grundlegende Prinzip dieser Regeln einfach: Anfragen werden basierend auf bestimmten Parametern und HTTP-Header-Werten geroutet.
Schauen wir uns Beispiele an:
Kubernetes standardmäßig: triviales „50 zu 50“
In unserem Beispiel zeigen wir, wie man in OpenShift zwei Versionen eines Mikrodienstes gleichzeitig nutzen kann, die wir v1 und v2 nennen. Jede Version läuft in ihrem eigenen Kubernetes-Pod, und standardmäßig wird hier eine gleichmäßig verteilte Round-Robin-Routing verwendet. Jeder Pod erhält seinen Anteil an Anfragen basierend auf der Anzahl seiner Mikrodienstinstanzen, anders gesagt, der Repliken. Istio hingegen ermöglicht es, dieses Gleichgewicht manuell zu ändern.
Angenommen, wir haben zwei Versionen unseres Empfehlungssystems, recommendation-v1 und recommendation-v2, auf OpenShift bereitgestellt.
In Abb. 1 ist zu sehen, dass, wenn jeder Dienst in einem Exemplar dargestellt wird, die Anfragen gleichmäßig zwischen ihnen alternieren: 1-2-1-2-… So funktioniert das Routing von Kubernetes standardmäßig:
Gewichtete Verteilung zwischen den Versionen
In Abb. 2 sehen wir, was passiert, wenn die Anzahl der Replikate des Dienstes v2 von eins auf zwei erhöht wird (das erreicht man mit dem Befehl oc scale —replicas=2 deployment/recommendation-v2). Wie zu erkennen ist, teilen sich die Anfragen zwischen v1 und v2 nun im Verhältnis „eins zu drei“: 1-2-2-1-2-2-…:
Version mit Istio ignorieren
Istio ermöglicht es, die Verteilung der Anfragen nach unseren Bedürfnissen zu ändern. Zum Beispiel, um den gesamten Verkehr nur auf recommendation-v1 mit der folgenden Istio-YAML-Datei zu leiten:
Hier sollte man darauf achten: Pods werden gemäß den Labels ausgewählt. In unserem Beispiel wird das Label v1 verwendet. Der Parameter „weight: 100“ bedeutet, dass 100 % des Verkehrs auf alle Pods des Dienstes geleitet werden, die das Label v1 haben.
Richtungsweisende Verteilung zwischen den Versionen (Canary Deployment)
Weiterhin kann der Parameter weight genutzt werden, um den Traffic auf beide Pods zu leiten, unabhängig von der Anzahl der Instanzen der Mikrodienste, die in jedem von ihnen ausgeführt werden. Zum Beispiel leiten wir hier 90% des Traffics zu v1 und 10% zu v2:
Separate Routenführung für mobile Nutzer
Abschließend zeigen wir, wie man den Traffic von mobilen Nutzern gezielt auf den Dienst v2 und alle anderen auf v1 leitet. Dazu analysieren wir mithilfe regulärer Ausdrücke den Wert des User-Agent im Header der Anfrage:
Jetzt sind Sie an der Reihe
Ein Beispiel mit regulären Ausdrücken zur Analyse von Headern sollte Sie inspirieren, eigene Varianten von Istio-Routing-Regeln zu finden. Die Möglichkeiten sind hier sehr vielfältig, da die Header-Werte im Quellcode der Anwendungen gestaltet werden können.
Und denken Sie daran, dass Ops, nicht Dev
Alles, was wir in den obigen Beispielen gezeigt haben, wird ohne die geringsten Änderungen am Quellcode durchgeführt, es sei denn, es müssen spezielle Anfrageheader erstellt werden. Istio ist sowohl für Entwickler von Nutzen, die es beispielsweise in der Testphase verwenden können, als auch für IT-Systemadministratoren, die damit im Produktionsumfeld erheblich unterstützt werden.
Lassen Sie uns das Hauptthema dieser Beitragsreihe wiederholen: Sie müssen Ihren Code nicht ändern. Es ist nicht notwendig, neue Images zu erstellen oder neue Container zu starten. All dies wird außerhalb des Codes umgesetzt.
Schalten Sie Ihre Fantasie ein
Stellen Sie sich nur vor, welche Möglichkeiten die Analyse von Headern mit regulären Ausdrücken eröffnet. Möchten Sie Ihren größten Kunden auf eine spezielle Version Ihrer ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Versuchen Sie es selbst
Über Istio, Kubernetes und OpenShift zu lesen, ist das eine, aber warum nicht alles selbst ausprobieren? Das Team Wir haben ein ausführliches Handbuch (auf Englisch) erstellt, das Ihnen hilft, diese Technologien so schnell wie möglich zu beherrschen. Das Handbuch ist ebenfalls zu 100 % Open Source und somit öffentlich verfügbar. Die Datei funktioniert unter macOS, Linux und Windows, und der Quellcode ist in Java und node.js verfügbar (bald auch in anderen Sprachen). Öffnen Sie einfach das entsprechende Git-Repository in Ihrem Browser. .
Im nächsten Beitrag: Wir lösen Probleme elegant.
Heute haben Sie gesehen, was die Routing-Regeln von Istio leisten können. Stellen Sie sich nun vor, dass dasselbe auf die Fehlerverarbeitung angewendet wird. Genau darüber werden wir im nächsten Beitrag berichten.
Quelle: habr.com
