Wir beginnen eine Reihe von Posts, in denen wir einige der zahlreichen Möglichkeiten des Istio Service Mesh in Kombination mit Red Hat OpenShift und Kubernetes demonstrieren werden.
Erster Teil, heute:
- Wir erklären das Konzept der Sidecar-Container in Kubernetes und formulieren das Leitmotiv dieser Post-Serie: „Sie müssen nichts an Ihrem Code ändern“.
- Lassen Sie uns das grundlegende Element von Istio vorstellen – die Routing-Regeln. Darauf basieren alle anderen Funktionen von Istio, da diese Regeln es ermöglichen, den Verkehr zu Mikroservices zu leiten, wobei externe YAML-Dateien für die Dienste verwendet werden. Wir betrachten auch das Schema des Canary Deployments. Ein Neujahrsbonus – 10 interaktive Kurse zu Istio.
Der zweite Teil, der bald erscheinen wird, erzählt Ihnen:
- Wie Istio Pool Ejection in Verbindung mit Circuit Breaker implementiert und zeigt, wie Istio einen nicht funktionierenden oder schlecht funktionierenden Pod aus dem Load-Balancing-Schema entfernen kann.
- Außerdem werden wir das Thema Circuit Breaker aus dem ersten Post betrachten, um zu sehen, wie Istio hier eingesetzt werden kann. Wir zeigen, wie man den Verkehr ohne geringste Änderungen im Code der Dienste routiert und Netzwerfehler mit YAML-Konfigurationsdateien und Terminalbefehlen behandelt.
Dritter Teil:
- Ein Bericht über Tracing und Monitoring, die bereits in Istio integriert sind oder einfach hinzugefügt werden können. Wir zeigen, wie man Tools wie Prometheus, Jaeger und Grafana in Verbindung mit der Skalierung von OpenShift nutzt, um die Verwaltung der Mikroservice-Architektur mühelos zu gestalten.
- Wir gehen von Monitoring und Fehlerbehandlung dazu über, solche absichtlich ins System einzuführen. Anders gesagt, wir lernen, Fault Injection ohne Änderungen am Quellcode durchzuführen, was aus Testperspektive sehr wichtig ist – denn wenn man dafür den Code ändern muss, besteht das Risiko, zusätzliche Fehler einzuführen.
Schließlich, im letzten Post über das Istio Service Mesh:
- Gehen wir zur Dunklen Seite über. Genauer gesagt, wir lernen, das Dark Launch Schema zu nutzen, bei dem der Code direkt auf Produktionsdaten implementiert und getestet wird, ohne die Systemfunktionalität zu beeinträchtigen. Hier ist es sehr nützlich, dass Istio den Verkehr trennt. Und die Möglichkeit, Tests an echten Produktionsdaten durchzuführen, ohne die Funktionsweise des Betriebssystems zu beeinflussen, ist der überzeugendste Weg zur Validierung.
- Basierend auf dem Dark Launch zeigen wir, wie man das Canary Deployment-Modell nutzen kann, um Risiken zu minimieren und die Einführung neuer Codes zu vereinfachen. Das Canary Deployment selbst ist keineswegs neu, aber Istio ermöglicht diese Methode lediglich mit Hilfe einfacher YAML-Dateien.
- Abschließend zeigen wir, wie wir mit Istio Egress den Zugriff auf Dienste für die Nutzer außerhalb Ihrer Cluster ermöglichen, um die Vorteile von Istio bei der Arbeit mit dem Internet zu nutzen.
Los geht's…
Die Überwachungs- und Verwaltungswerkzeuge von Istio – alles, was Sie für die Koordinierung von Microservices in einem Servicenetzwerk benötigen .
Was ist das Istio Service Mesh?
Das Service Mesh bietet einer Gruppe von Diensten Funktionen wie Verkehrsüberwachung, Zugriffskontrolle, Entdeckung, Sicherheit, Fehlertoleranz und viele andere nützliche Dinge. Istio ermöglicht all dies, ohne geringste Änderungen am Code der Dienste selbst vorzunehmen. Was ist das Geheimnis? Istio fügt jedem Dienst seinen Proxy in Form eines Sidecar-Containers hinzu (Sidecar – Beiwagen für Motorräder), sodass der gesamte Verkehr zu diesem Dienst über den Proxy läuft, der basierend auf festgelegten Richtlinien entscheidet, wie, wann und ob dieser Verkehr den Dienst erreichen soll. Istio bietet auch die Möglichkeit, fortgeschrittene DevOps-Techniken wie Canary Deployments, Circuit Breakers, Fehlereinspritzung und viele andere umzusetzen.
Wie Istio mit Containern und Kubernetes funktioniert
Das Istio Service Mesh ist eine Sidecar-Implementierung alles dessen, was zur Erstellung und Verwaltung von Microservices erforderlich ist: Überwachung, Tracierung, Circuit Breakers, Routing, Lastverteilung, Fehlereinspritzung, Wiederholungen, Timeouts, Spiegelung, Zugriffskontrolle, Drosselung und vieles mehr. Und obwohl es heute viele Bibliotheken gibt, um diese Funktionen direkt im Code zu implementieren, können Sie mit Istio all das Gleiche erhalten, ohne Ihren Code zu ändern.
Entsprechend dem Sidecar-Modell wird Istio in einem Linux-Container ausgeführt, der sich in einem -Pod mit dem kontrollierten Dienst befindet und Funktionalitäten sowie Informationen gemäß der festgelegten Konfiguration injiziert (inject) und extrahiert (extract). Wir betonen, dass dies Ihre eigene Konfiguration ist, die unabhängig von Ihrem Code lebt. Daher wird der Code erheblich einfacher und kürzer.
Was ebenfalls wichtig ist, ist, dass die operative Komponente von Mikrodiensten in keiner Weise mit dem Code selbst verbunden ist, was bedeutet, dass ihre Betrieb an IT-Spezialisten übertragen werden kann. Tatsächlich, warum sollte ein Entwickler für Circuit Breaker und Fault Injection verantwortlich sein? Reagieren – ja, aber sie zu verarbeiten und zu erstellen? Wenn all dies aus dem Code entfernt wird, können sich Programmierer vollständig auf die Anwendungsfunktionalität konzentrieren. Und der Code selbst wird kürzer und einfacher.
Service-Mesh
Istio, das Funktionen zur Verwaltung von Mikrodiensten außerhalb ihres Codes implementiert – das ist das Konzept des Service-Mesh. Anders gesagt, es handelt sich um eine koordinierte Gruppe von einer oder mehreren Binärdateien, die ein Netzwerk von Netzwerkfunktionen bilden.
Wie Istio mit Mikrodiensten arbeitet
So sieht die Arbeit der Sidecar-Container in Verbindung mit und aus der Vogelperspektive aus: 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 Konfigurationsdetails in Ihre Deployments ein, und Ihre Pods beginnen, Istio zu verwenden. Vereinfacht dargestellt sieht das Diagramm so aus:
Jetzt können Sie die Einstellungen von Istio ändern, um beispielsweise Fault Injection, Unterstützung oder andere Funktionen von Istio zu organisieren – und das alles ohne den Code der Anwendungen 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 reicht es aus, eine Istio-Routenregel zu erstellen, die nach @foocorporation.com im Benutzeridentifikator sucht und die entsprechende Umleitung vornimmt. Für alle anderen Benutzer ändert sich nichts. Und in der Zwischenzeit können Sie die neue Version der Website in Ruhe testen. Und beachten Sie, dass dafür keine Entwickler hinzugezogen werden müssen.
Und muss dafür teuer bezahlt werden?
Keineswegs. Istio arbeitet ziemlich schnell, es ist in und erzeugt nur sehr geringen Overhead. Außerdem wird ein möglicher Verlust an Online-Leistung durch einen Anstieg der Entwicklerproduktivität ausgeglichen. Zumindest in der Theorie: Vergessen Sie nicht, dass die Zeit der Entwickler kostbar ist. Was die Softwarekosten angeht, so ist Istio eine Open-Source-Software, die kostenlos erhältlich ist und verwendet werden kann.
Eigne dir selbst an
Das Red Hat Developer Experience Team hat ein tiefgehendes praktisches zu Istio (in Englisch) entwickelt. Es funktioniert auf Linux, MacOS und Windows, und der Code ist in Varianten für Java und Node.js verfügbar.
10 interaktive Einheiten zu Istio
Block 1 — Für Anfänger
Einführung in Istio
30 Minuten
Wir lernen die Service Mesh kennen und installieren Istio im OpenShift Kubernetes-Cluster.
Bereitstellung von Microservices in Istio
30 Minuten
Wir nutzen Istio, um drei Microservices mit Spring Boot und Vert.x bereitzustellen.
Block 2 – Mittleres Niveau
Monitoring und Tracing in Istio
60 Minuten
Wir untersuchen die integrierten Monitoring-Tools von Istio, konfigurierbare Metriken sowie OpenTracing über Prometheus und Grafana.
Einfache Routensteuerung in Istio
60 Minuten
Wir lernen, die Routingsteuerung in Istio mit einfachen Regeln zu verwalten.
Erweiterte Routingregeln
60 Minuten
Wir lernen die intelligente Routensteuerung in Istio, Zugriffsmanagement, Lastenverteilung und Ratenbegrenzung kennen.
Block 3 – Fortgeschrittene Benutzer
Fehlereinspeisung in Istio
60 Minuten
Wir untersuchen die Szenarien zur Fehlerbehandlung in verteilten Anwendungen, indem wir HTTP-Fehler und Netzwerkverzögerungen erzeugen und Chaos-Engineering für die Wiederherstellung der Umgebung anwenden.
Circuit Breaker in Istio
30 Minuten
Wir installieren Siege für das Lasttest von Websites und lernen, die Ausfallsicherheit des Backends mit Wiederholungen, Circuit Breaker und Pool-Ejection sicherzustellen.
Egress und Istio
10 Minuten
Wir verwenden Egress-Routen, um Regeln für die Interaktion interner Dienste mit 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 die Anfragen- und Datenströme zu analysieren.
Mutual TLS in Istio
15 Minuten
Wir erstellen ein Istio-Gateway und einen VirtualService und untersuchen dann detailliert Mutual TLS (mTLS) und dessen Konfigurationen.
Block 3.1 — Vertiefung: Istio Service Mesh für Microservices
Worüber das Buch handelt:
- Was ist ein Service Mesh.
- Das System Istio und seine Rolle in der Microservices-Architektur.
- Einsatz von Istio zur Lösung folgender Aufgaben:
- Ausfallsicherheit;
- Routing;
- Chaos-Testing;
- Sicherheit;
- Die Erfassung von Telemetriedaten mit Hilfe von Traceing, Metriken und Grafana.
Serie von Artikeln zu Service Meshes und Istio
Versuchen Sie es selbst
Diese Reihe von Beiträgen verfolgt nicht das Ziel, tief in die Welt von Istio einzutauchen. Wir möchten Sie lediglich mit dem Konzept vertraut machen und vielleicht dazu anregen, Istio selbst auszuprobieren. Das kann völlig kostenlos geschehen, und Red Hat stellt alle notwendigen Werkzeuge zur Verfügung, um OpenShift, Kubernetes, Linux-Container und Istio zu erlernen, darunter: , und weitere Ressourcen auf unserem . Zögern Sie nicht, starten Sie noch heute!
Routing-Regeln in Istio: wir leiten Service-Anfragen dorthin, wo sie gebraucht werden
und bewältigen hervorragend die Aufgabe, Anfragen an an die richtigen Pods weiterzuleiten. Das ist eines der Ziele von Kubernetes – Routing und Lastenverteilung. Was ist jedoch, wenn Sie eine feinere und ausgefeiltere Routing-Lösung benötigen? Zum Beispiel, um gleichzeitig zwei Versionen eines Mikrodienstes zu verwenden. Wie können hier die Istio Routing-Regeln helfen?
Routing-Regeln sind die Regeln, die festlegen, wie eine Route ausgewählt wird. Unabhängig vom Schwierigkeitsgrad des Systems bleibt der grundlegende Arbeitsprinzip dieser Regeln einfach: Anfragen werden basierend auf bestimmten Parametern und HTTP-Headerwerten weitergeleitet.
Sehen wir uns Beispiele an:
Kubernetes Standard: trivialer „50 zu 50“
In unserem Beispiel zeigen wir, wie man in OpenShift gleichzeitig zwei Versionen eines Mikrodienstes verwenden kann, die wir v1 und v2 nennen. Jede Version läuft in ihrem eigenen Kubernetes-Pod, und standardmäßig wird hier eine gleichmäßig balancierte Round-Robin-Routing (evenly balanced round robin routing) verwendet. Jeder Pod erhält seinen Anteil an Anfragen basierend auf der Anzahl der Instanzen seines Mikrodienstes, mit anderen Worten, der Replikate. Istio ermöglicht jedoch, dieses Gleichgewicht manuell zu ändern.
Angenommen, wir haben in OpenShift zwei Versionen unseres Empfehlungsdienstes bereitgestellt, recommendation-v1 und recommendation-v2.
In Abbildung 1 ist zu sehen, dass, wenn jeder Dienst in einer Instanz dargestellt wird, die Anfragen gleichmäßig zwischen ihnen wechseln: 1-2-1-2-… So funktioniert das Routing von Kubernetes standardmäßig:
Gewichtete Verteilung zwischen den Versionen
In Abb. 2 wird gezeigt, was passiert, wenn die Anzahl der Replikate des Dienstes v2 von einem auf zwei erhöht wird (dies geschieht mit dem Befehl oc scale —replicas=2 deployment/recommendation-v2). Wie wir sehen, teilen sich die Anfragen zwischen v1 und v2 jetzt im Verhältnis „eins zu drei“: 1-2-2-1-2-2-…:
Version ignorieren mit Istio
Istio ermöglicht es, die Verteilung der Anfragen auf die gewünschte Weise zu ändern. Zum Beispiel kann der gesamte Datenverkehr nur an recommendation-v1 mit der folgenden Istio-YAML-Datei gesendet werden:
Hier sollten Sie auf Folgendes achten: Die Pods werden gemäß den Labels ausgewählt. In unserem Beispiel verwenden wir das Label v1. Der Parameter „weight: 100“ bedeutet, dass 100% des Datenverkehrs an alle Pods des Dienstes weitergeleitet werden, die das Label v1 haben.
Direktive Verteilung zwischen den Versionen (Canary Deployment)
Darüber hinaus kann der Datenverkehr mithilfe des Parameters Gewicht auf beide Pods gelenkt werden, wobei die Anzahl der Instanzen der Mikrodienste ignoriert wird, die in jedem von ihnen ausgeführt werden. Zum Beispiel lenken wir hier direkt 90% des Datenverkehrs an v1 und 10% an v2:
Getrennte Weiterleitung mobiler Benutzer
Abschließend zeigen wir, wie der Datenverkehr mobiler Benutzer gezielt an den Dienst v2 geleitet wird, während alle anderen an v1 geleitet werden. Dazu analysieren wir den Wert des user-agent im Anfrageheader mithilfe regulärer Ausdrücke:
Jetzt sind Sie an der Reihe
Ein Beispiel mit regulären Ausdrücken zur Analyse von Headern sollte Sie dazu anregen, nach eigenen Möglichkeiten zur Anwendung von Istio-Routing-Regeln zu suchen. Zumal die Möglichkeiten hier sehr umfangreich sind, da Headerwerte im Anwendungscode gebildet werden können.
Und denken Sie daran, dass Ops, nicht Dev
Alles, was wir in den obigen Beispielen gezeigt haben, geschieht ohne geringste Änderungen am Anwendungscode, mit Ausnahme der Fälle, in denen spezielle Anfrageheader gebildet werden müssen. Istio wird sowohl Entwicklern nützlich sein, die es beispielsweise in der Testphase anwenden können, als auch IT-Betriebsfachleuten, die in der Produktion sehr davon profitieren werden.
Also wiederhole ich das Leitmotiv dieser Beitragsreihe: Sie müssen nichts an Ihrem Code ändern. Es ist nicht erforderlich, neue Images zu erstellen oder neue Container zu starten. All das wird außerhalb des Codes realisiert.
Lassen Sie Ihrer Fantasie freien Lauf
Stellen Sie sich vor, welche Möglichkeiten die Analyse von Überschriften 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 hat einen detaillierten Leitfaden (auf Englisch) vorbereitet, der Ihnen hilft, diese Technologien so schnell wie möglich zu erlernen. Das Handbuch ist ebenfalls zu 100 % Open Source, daher ist es öffentlich zugänglich. Die Datei funktioniert auf macOS, Linux und Windows, und der Quellcode ist in Varianten für Java und node.js verfügbar (bald werden auch Versionen in anderen Sprachen folgen). Öffnen Sie einfach das entsprechende Git-Repository in Ihrem Browser. .
Im nächsten Beitrag: Wir lösen Probleme auf elegante Weise
Heute haben Sie gesehen, wozu die Istio-Routing-Regeln fähig sind. Jetzt stellen Sie sich das Gleiche vor, aber in Bezug auf Fehlerbehandlung. Genau darüber werden wir im nächsten Beitrag sprechen.
Quelle: habr.com
