Dark Launch in Istio: geheime Dienste

„Gefahr ist mein zweiter Name“, sagte Austin Powers, ein Mensch von internationalem Rätselcharakter. Doch was bei Superagenten und Geheimdiensten geschätzt wird, ist keineswegs geeignet für die Computerwelt, wo Langeweile weit besser als Gefahr ist.

Und Istio zusammen mit OpenShift und Kubernetes macht die Bereitstellung von Mikrodiensten zu einer wirklich langweiligen und vorhersehbaren Angelegenheit – und das ist großartig. Darüber und über vieles mehr werden wir im vierten und letzten Beitrag der Istio-Serie sprechen.

Wenn Langeweile richtig ist

In unserem Fall entsteht Langeweile nur in der letzten Phase, wenn man nur noch dasitzen und den Prozess beobachten kann. Doch dafür muss alles vorher eingerichtet werden, und hier erwartet euch viel Interessantes.

Beim Bereitstellen einer neuen Version eurer Software sollte man alle Möglichkeiten zur Risikominderung in Betracht ziehen. Die parallele Nutzung ist eine sehr effektive und bewährte Testmethode, und Istio erlaubt es, dafür den „Geheimdienst“ (eine für Außenstehende unsichtbare Version eures Mikrodienstes) zu nutzen, ohne in das Produktionssystem einzugreifen. Dafür gibt es sogar einen speziellen Begriff – „Dark Launch“, der wiederum durch die Funktion mit dem nicht weniger geheimnisvollen Namen „Traffic-Mirroring“ aktiviert wird.

Beachte, dass im ersten Satz des vorherigen Absatzes der Begriff „Bereitstellung“ (deploy) und nicht „Veröffentlichung“ (release) verwendet wird. Ihr solltet tatsächlich in der Lage sein, euren Mikrodienst so oft zu deployen – und natürlich auch zu nutzen – wie ihr möchtet. Dieser Dienst sollte in der Lage sein, Traffic zu empfangen und zu verarbeiten, Ergebnisse auszugeben, sowie Protokolle zu schreiben und überwacht zu werden. Aber der Dienst selbst muss dafür nicht in die Produktion gehen. Bereitstellung und Veröffentlichung von Software sind nicht immer dasselbe. Bereitstellungen könnt ihr jederzeit vornehmen, wann immer ihr wollt, während eine Veröffentlichung erst dann erfolgt, wenn ihr endgültig bereit seid.

Die Organisation von Langeweile ist interessant

Seht euch die folgende Istio-Routing-Regel an, die alle HTTP-Anfragen an den Mikrodienst recommendation v1 leitet (alle Beispiele stammen von Istio Tutorial GitHub repo), während sie gleichzeitig auf den Mikrodienst recommendation v2 gespiegelt werden:

Beachtet das Label mirror: unten im Screenshot – genau das legt das Traffic-Mirroring fest. Ja, so einfach ist das!

Das Ergebnis dieser Regel wird sein, dass Ihr Produktionssystem (v1) weiterhin ankommende Anfragen verarbeitet, diese jedoch asynchron auf v2 gespiegelt werden, d. h. es werden vollständige Duplikate an v2 gesendet. So können Sie v2 unter realen Bedingungen – mit echten Daten und Traffic – testen, ohne in den Betrieb des Produktionssystems einzugreifen. Macht dies die Testorganisation zu einer Langeweile? Ja, definitiv. Aber es wird interessant umgesetzt.

Wir fügen etwas Dramatik hinzu

Bitte beachten Sie, dass im Code von v2 Situationen berücksichtigt werden müssen, in denen ankommende Anfragen zu Datenänderungen führen können. Die Anfragen werden leicht und transparent gespiegelt, aber die Wahl der Verarbeitung im Test bleibt Ihnen überlassen – und das ist schon etwas aufregend.

Lassen Sie uns einen wichtigen Punkt wiederholen

Ein geheimes Starten mit Verkehrsspiegelung (Dark Launch/Request Mirroring) kann durchgeführt werden, ohne den Code zu berühren.

Nahrung für den Gedanken

Was wäre, wenn beim Spiegeln der Anfragen ein Teil davon nicht an v1, sondern an v2 gesendet wird? Zum Beispiel ein Prozent aller Anfragen oder nur Anfragen einer bestimmten Benutzergruppe. Und dann, während Sie sehen, wie v2 funktioniert, schrittweise alle Anfragen auf die neue Version übertragen. Oder umgekehrt alles auf v1 zurückführen, wenn mit v2 etwas schiefgeht. Es scheint, als würde dies als Canary Deployment ("canary deployment") bezeichnet. Der Begriff stammt aus dem Bergbau, und hätte er russischen Ursprung, würde er wahrscheinlich auf Katzen) hinweisen, und jetzt werden wir das näher betrachten.

Canary Deployment in Istio: Vereinfachung des Rollouts

Vorsichtig und schrittweise

Die Grundidee des Canary Deployment-Modells ist äußerst einfach: Bei der Einführung einer neuen Version Ihrer Software (in unserem Fall – Mikroservice) gewähren Sie zunächst einer kleinen Gruppe von Benutzern Zugriff. Wenn alles gut läuft, erweitern Sie diese Gruppe langsam, bis die neue Version beginnt Probleme zu verursachen, oder – falls das nicht eintritt – schließlich alle Benutzer auf sie übertragen. Durch einen durchdachten und schrittweisen Rollout der neuen Version und die kontrollierte Umstellung der Benutzer können die Risiken verringert und das Feedback maximiert werden.

Natürlich erleichtert Istio das Canary Deployment, indem es mehrere gute Optionen für die intelligente Anfragenrouten anbietet. Und ja, all das kann gemacht werden, ohne Ihren Quellcode zu berühren.

Browser filtern

Eines der einfachsten Routing-Kriterien ist die Weiterleitung basierend auf dem Browser. Angenommen, Sie möchten, dass nur Anfragen aus Safari auf v2 geleitet werden. So geht es:

Wenden wir diese Routing-Regel an und dann mit dem Befehl curl werden wir in einer Schleife echte Anfragen an den Microservice simulieren. Wie im Screenshot zu sehen ist, gehen alle auf v1:

Und wo bleibt der Verkehr auf v2? Da in unserem Beispiel alle Anfragen nur aus unserer Kommandozeile kamen, gibt es ihn einfach nicht. Aber beachten Sie die unteren Zeilen im Screenshot oben: Das ist die Reaktion darauf, dass wir eine Anfrage aus dem Safari-Browser ausgeführt haben, die wiederum folgendes ausgegeben hat:

Uneingeschränkte Macht

Wir haben bereits erwähnt, dass reguläre Ausdrücke sehr mächtige Möglichkeiten für die Anfragenrouten bieten. Schauen Sie sich das folgende Beispiel an (wir denken, Sie werden selbst verstehen, was es tut):

Nun können Sie wahrscheinlich bereits erahnen, wozu reguläre Ausdrücke fähig sind.

Handeln Sie klug

Intelligentes Routing, insbesondere die Verarbeitung von Paket-Headern mittels regulärer Ausdrücke, ermöglicht es, den Verkehr nach Ihren Wünschen zu steuern. Und das vereinfacht die Inbetriebnahme neuen Codes erheblich – es ist einfach, erfordert keine Änderung des Codes selbst, und wenn nötig, kann alles schnell zurückgerollt werden.

Interessiert?

Haben Sie Lust, mit Istio, Kubernetes und OpenShift auf Ihrem Computer zu experimentieren? Das Team Red Hat Developer Team hat großartige Lehrbuch Ressourcen zu diesem Thema zusammengestellt und alle zugehörigen Dateien öffentlich zugänglich gemacht. Also nur zu und gönnen Sie sich nichts weniger.
 

Istio Egress: Der Ausgang über den Souvenirladen

Durch den Einsatz von Istio in Kombination mit Red Hat OpenShift und Kubernetes können Sie sich das Leben mit Microservices erheblich erleichtern. Das Service Mesh von Istio ist in die Pods von Kubernetes eingebettet, und Ihr Code wird (hauptsächlich) isoliert ausgeführt. Leistung, Änderungsfreundlichkeit, Nachverfolgbarkeit und mehr – all das lässt sich leicht durch die Verwendung von Sidecar-Containern erreichen. Aber was tun, wenn Ihr Microservice mit anderen Diensten kommunizieren muss, die außerhalb Ihres OpenShift-Kubernetes-Systems liegen?

Hier kommt Istio Egress ins Spiel. Kurz gesagt, es ermöglicht den Zugriff auf Ressourcen (sprich: „Dienste“), die nicht zu Ihren Kubernetes-Pods gehören. Ohne zusätzliche Konfiguration wird im Istio Egress-Umfeld der Datenverkehr nur innerhalb des Pod-Clusters und zwischen solchen Clustern basierend auf internen IP-Tabellen weitergeleitet. Diese Abschottung funktioniert hervorragend, bis Sie Zugang zu Diensten außerhalb benötigen.

Egress ermöglicht es, die oben genannten IP-Tabellen entweder auf Basis von Egress-Regeln oder für einen IP-Adressenbereich zu umgehen.

Angenommen, wir haben ein Java-Programm, das eine GET-Anfrage an httpbin.org/headers ausführt.

(httpbin.org ist einfach eine nützliche Ressource zum Testen von ausgehenden Dienstanfragen.)

Wenn Sie in die Befehlszeile eingeben curl http://httpbin.org/headers, sehen wir Folgendes:

Oder Sie können dieselbe Adresse im Browser öffnen:

Wie wir sehen, gibt der dort befindliche Dienst einfach die übergebenen Header zurück.

Wir ersetzen sozusagen direkt

Jetzt nehmen wir den Java-Code dieses externen Dienstes in Bezug auf unser System und führen ihn bei uns aus, wo, wie erwähnt, Istio läuft. (Sie können dies selbst tun, indem Sie sich an unseren Istio-Leitfadenwenden.) Nachdem wir das entsprechende Container-Image erstellt und auf der OpenShift-Plattform ausgeführt haben, rufen wir diesen Dienst mit dem Befehl auf curl egresshttpbin-istioegress.$(minishift ip).nip.io, woraufhin wir Folgendes auf dem Bildschirm sehen:

Hmm, was ist passiert? Es hat ja gerade noch funktioniert. Was bedeutet Not Found? Wir haben gerade doch eingerichtet. curl.

Wir erweitern die IP-Tabellen für das gesamte Internet.

Dafür müssen wir Istio verantwortlich machen (oder danken). Denn Istio besteht einfach aus Sidecar-Containern, die für die Entdeckung und Weiterleitung zuständig sind (und für viele andere Dinge, über die wir zuvor gesprochen haben). Aus diesem Grund wissen die IP-Tabellen nur, was sich innerhalb Ihres Cluster-Systems befindet. Httpbin.org befindet sich jedoch außerhalb und ist daher nicht erreichbar. An dieser Stelle hilft uns Istio Egress – ganz ohne Änderungen an Ihrem Quellcode.

Die folgende Egress-Regel zwingt Istio, den benötigten Dienst zu suchen (wenn nötig, auch im gesamten weltweiten Internet), in diesem Fall httpbin.org. Wie aus dieser Datei (egress_httpbin.yml) hervorgeht, ist die Funktionalität hier recht einfach:

Jetzt müssen wir nur noch diese Regel anwenden:

istioctl create -f egress_httpbin.yml -n istioegress

Die Egress-Regeln können Sie mit dem Befehl anzeigen istioctl get egressrules:

Und schließlich starten wir das Team erneut curl – und sehen, dass alles funktioniert:

Wir denken offen

Wie Sie sehen, ermöglicht Istio die Interaktion mit der Außenwelt. Mit anderen Worten, Sie können weiterhin OpenShift-Dienste erstellen und diese über Kubernetes verwalten, während alles in Pods läuft, die nach Bedarf hoch- oder herunterskalierbar sind. Gleichzeitig können Sie problemlos auf externe Dienste zugreifen, die Ihre Umgebung betreffen. Und ja, um es noch einmal zu betonen, all dies kann erfolgen, ohne Ihren Code zu berühren.

Das war der letzte Beitrag in der Serie über Istio. Bleiben Sie dran – es gibt noch viel Interessantes!

Quelle: habr.com