»Gefahr ist mein zweiter Vorname«, sagte Austin Powers, das internationale Rätsel. Doch was bei Superagenten und Geheimdiensten geschätzt wird, ist für die Computerwelt völlig ungeeignet, wo Langeweile weit besser ist als Gefahr.
Und Istio zusammen mit OpenShift und Kubernetes machen das Deployment von Mikrodiensten zu einer wahrhaft langweiligen und vorhersehbaren Angelegenheit – und das ist großartig. Darüber und vieles mehr werden wir im vierten und letzten Beitrag der Istio-Serie sprechen.
Wenn Langeweile das Richtige ist
In unserem Fall tritt Langeweile nur in der Endphase auf, wenn es nur noch darum geht, zu sitzen und den Prozess zu beobachten. Aber dafür muss alles vorher konfiguriert werden, und hier erwartet Sie viel Interessantes.
Beim Rollout einer neuen Version Ihrer Software sollten Sie alle Möglichkeiten zur Risikominderung in Betracht ziehen. Der parallele Betrieb ist eine leistungsstarke und bewährte Testmethode, und Istio ermöglicht es, dafür einen "geheimes Dienst" (eine versteckte Version Ihres Microservices, die für Außenstehende nicht sichtbar ist) zu nutzen, ohne in den Betrieb der Produktionssysteme einzugreifen. Dafür gibt es sogar einen speziellen Begriff – "Dark Launch", der durch eine Funktion mit dem nicht weniger geheimnisvollen Namen "Traffic Mirroring" aktiviert wird.
Bitte beachten Sie, dass im ersten Satz des vorherigen Absatzes der Begriff „Deployment“ (bereitstellen) und nicht „Release“ (veröffentlichen) verwendet wird. Sie sollten in der Lage sein, Ihren Mikrodienst so oft zu deployen – und natürlich zu nutzen – wie Sie möchten. Dieser Dienst sollte in der Lage sein, den Datenverkehr zu empfangen und zu verarbeiten, Ergebnisse auszugeben sowie Protokolle zu schreiben und überwacht zu werden. Dennoch muss dieser Dienst nicht in die Produktion überführt werden. Deployment und Softwareveröffentlichung sind nicht immer dasselbe. Deployment können Sie jederzeit durchführen, während eine Veröffentlichung nur dann erfolgt, wenn Sie endgültig bereit sind.
Die Organisation von Langeweile ist interessant
Werfen Sie einen Blick auf die folgende Istio-Routingregel, die alle HTTP-Anfragen an den Mikrodienst Recommendation v1 leitet (alle Beispiele stammen aus ), während sie gleichzeitig auf den Mikrodienst Recommendation v2 gespiegelt werden:
Achten Sie auf das Label mirror: unten im Screenshot – es bestimmt das Traffic-Mirroring. Ja, so einfach ist das!
Das Ergebnis dieser Regel wird sein, dass Ihr Produktionssystem (v1) weiterhin eingehende Anfragen bearbeitet, während die Anfragen asynchron an v2 gespiegelt werden, das heißt, vollständige Duplikate werden dorthin gesendet. So können Sie v2 unter realen Bedingungen testen – mit echten Daten und Traffic – ohne in das Produktionssystem einzugreifen. Macht dies das Testen langweilig? Ja, absolut. Aber es wird auf interessante Weise durchgeführt.
Fügen wir etwas Dramatik hinzu.
Bitte beachten Sie, dass der Code in v2 Situationen berücksichtigen muss, in denen eingehende Anfragen zu Datenänderungen führen können. Die Anfragen selbst werden leicht und transparent gespiegelt, aber die Wahl der Bearbeitungsmethode im Test bleibt Ihnen überlassen – und das ist durchaus aufregend.
Lassen Sie uns einen wichtigen Punkt wiederholen.
Ein geheimes Launch mit Traffic-Mirroring (Dark Launch/Request Mirroring) kann durchgeführt werden, ohne den Code zu berühren.
Nahrung zum Nachdenken.
Was, wenn man einen Teil der Anfragen nicht an v1, sondern an v2 sendet? Zum Beispiel ein Prozent aller Anfragen oder nur Anfragen von einer bestimmten Benutzergruppe. Und dann, wenn wir sehen, wie v2 funktioniert, allmählich alle Anfragen auf die neue Version umstellen. Oder umgekehrt alles auf v1 zurücksetzen, falls mit v2 etwas schiefgeht. Das scheint als Canary Deployment bezeichnet zu werden. , und hätte er russische Wurzeln, würde er wahrscheinlich auf ) verweisen, und jetzt werden wir das näher betrachten.
Canary Deployment in Istio: sanfter Einstieg
Vorsichtig und schrittweise
Das Konzept des Canary Deployment ist ganz einfach: Wenn Sie eine neue Version Ihrer Software (in unserem Fall eines Mikrodienstes) bereitstellen, gewähren Sie zunächst einer kleinen Gruppe von Benutzern Zugang. Wenn alles gut geht, erweitern Sie diese Gruppe langsam, bis die neue Version anfängt, Probleme zu machen – oder, wenn dies nicht der Fall ist, letztendlich alle Benutzer auf die neue Version umschalten. Durch die schrittweise Einführung der neuen Version und die kontrollierte Umstellung auf diese können Sie Risiken minimieren und das Nutzerfeedback maximieren.
Natürlich vereinfacht Istio das Canary Deployment und bietet mehrere gute Optionen für das intelligente Routing von Anfragen. Und ja, all dies kann erreicht werden, ohne Ihren Quellcode zu ändern.
Browser filtern
Eines der einfachsten Kriterien für das Routing ist die Umleitung basierend auf dem Browser. Angenommen, Sie möchten, dass nur Anfragen aus Safari-Browsern an v2 weitergeleitet werden. So geht's:
Wenden wir diese Routing-Regel an und simulieren dann mit dem Befehl curl in einer Schleife echte Anfragen an den Mikrodienst. Wie im Screenshot zu sehen ist, gehen alle an v1:
Wo bleibt der Traffic auf v2? Da alle Anfragen in unserem Beispiel lediglich über die Kommandozeile gekommen sind, gibt es ihn schlichtweg nicht. Beachten Sie jedoch die unteren Zeilen im obigen Screenshot: dies ist die Reaktion auf eine Anfrage, die wir aus dem Safari-Browser ausgeführt haben, die folgendes ausgab:
Unbegrenzte Macht
Wir haben bereits erwähnt, dass reguläre Ausdrücke sehr mächtige Möglichkeiten zur Anfragenvermittlung bieten. Sehen Sie sich das folgende Beispiel an (wir denken, Sie werden selbst verstehen, was es tut):
Nun können Sie sich wahrscheinlich vorstellen, wozu reguläre Ausdrücke fähig sind.
Handeln Sie klug
Intelligente Routing-Techniken, insbesondere das Verarbeiten der Paket-Header mithilfe regulärer Ausdrücke, ermöglichen es Ihnen, den Traffic nach Ihren Wünschen zu steuern. Zudem vereinfacht es die Integration neuer Codes – es ist einfach, benötigt keine Änderungen am Code selbst, und wenn nötig, kann alles schnell auf den ursprünglichen Zustand zurückgesetzt werden.
Interessiert?
Sie brennen darauf, mit Istio, Kubernetes und OpenShift auf Ihrem Computer zu experimentieren? Das Team hat großartige Arbeit geleistet Zu diesem Thema habe ich alle zugehörigen Dateien zur Verfügung gestellt. Also los, gönnen Sie sich alles!
Istio Egress: Ausgang über den Souvenirladen
Die Kombination von Istio mit Red Hat OpenShift und Kubernetes kann den Umgang mit Mikrodiensten erheblich erleichtern. Das Service-Mesh von Istio ist innerhalb der Kubernetes-Pods versteckt, während Ihr Code (größtenteils) isoliert ausgeführt wird. Leistung, einfache Anpassungen, Tracing und mehr – all das profitiert von der Verwendung von Sidecar-Containern. Aber was passiert, wenn Ihr Mikrodienst 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 (lesen Sie: "Dienste"), die nicht Teil Ihres Kubernetes-Pod-Systems sind. Ohne zusätzliche Konfiguration wird der Datenverkehr in der Istio Egress-Umgebung nur innerhalb des Pod-Clusters und zwischen solchen Clustern basierend auf internen IP-Tabellen geroutet. Diese Isolation funktioniert ausgezeichnet, solange Sie keinen Zugriff auf externe Dienste benötigen.
Egress ermöglicht es, die oben genannten IP-Tabellen entweder basierend auf Egress-Regeln oder für einen IP-Adressbereich zu umgehen.
Angenommen, wir haben ein Java-Programm, das eine GET-Anfrage an httpbin.org/headers sendet.
(httpbin.org ist einfach eine nützliche Ressource zum Testen ausgehender Service-Anfragen.)
Wenn wir in der Eingabeaufforderung eingeben curl http://httpbin.org/headers, sehen wir Folgendes:
Oder wir können dieselbe Adresse im Browser öffnen:
Wie wir sehen, gibt der dort ansässige Service einfach die übermittelten Header zurück.
Importersatz direkt
Jetzt nehmen wir den Java-Code dieses externen Services in Bezug auf unser System und führen ihn bei uns aus, wo, erinnern wir uns, Istio installiert ist. (Sie können dies selbst tun, indem Sie sich auf .) Nachdem wir das entsprechende Image gebaut und auf der OpenShift-Plattform gestartet haben, rufen wir diesen Service mit dem Befehl curl egresshttpbin-istioegress.$(minishift ip).nip.io, nach dem wir auf dem Bildschirm Folgendes sehen werden:
Oh, was ist passiert? Es hat doch gerade noch funktioniert. Was bedeutet Not Found? Wir haben doch gerade dafür curl.
IP-Tabellen für das gesamte Internet erweitert.
Die Verantwortung dafür liegt bei Istio. Denn Istio ist einfach eine Sidecar-Container-Lösung, die für die Erkennung und Weiterleitung verantwortlich ist (und für viele andere Dinge, die wir zuvor beschrieben haben). Aus diesem Grund kennen die IP-Tabellen nur die Inhalte innerhalb Ihres Cluster-Systems. Httpbin.org liegt jedoch extern und ist daher nicht zugänglich. Hier kommt Istio Egress ins Spiel – ganz ohne Änderungen am Quellcode.
Die folgende Egress-Regel zwingt Istio, den benötigten Dienst zu suchen (wenn nötig, im gesamten weltweiten Internet), in diesem Fall httpbin.org. Wie aus dieser Datei (egress_httpbin.yml) ersichtlich ist, ist die Funktionalität hier recht einfach:
Es bleibt nur noch, diese Regel anzuwenden:
istioctl create -f egress_httpbin.yml -n istioegress
Die Egress-Regeln können mit dem Befehl angesehen werden istioctl get egressrules:
Und schließlich führen wir den Befehl erneut aus curl – und sehen, dass alles funktioniert:
Denken wir offen
Wie Sie sehen, ermöglicht es Istio, die Interaktion mit der Außenwelt zu organisieren. Mit anderen Worten, Sie können weiterhin OpenShift-Dienste erstellen und diese über Kubernetes verwalten, indem Sie alles in Pods halten, die je nach Bedarf nach oben oder unten skaliert werden. Dabei können Sie ruhigen Gewissens auf externe Dienste zugreifen, die außerhalb Ihrer Umgebung liegen. Und ja, lassen Sie uns noch einmal betonen, dass Sie all dies tun können, ohne Ihren Code zu berühren.
Dies war der letzte Beitrag aus der Serie über Istio. Bleiben Sie bei uns – es gibt noch viele interessante Themen!
Quelle: habr.com
