„Gefahr ist mein zweiter Vorname“, sagte Austin Powers, ein internationaler Mann voller Geheimnisse. Doch was bei Superagenten und Geheimdiensten hohes Ansehen genießt, eignet sich überhaupt nicht für Computerdienste, bei denen Langeweile weitaus besser ist als Gefahr.
Und Istio macht zusammen mit OpenShift und Kubernetes die Bereitstellung von Microservices wirklich langweilig und vorhersehbar – und das ist großartig. Darüber und noch viel mehr werden wir im vierten und letzten Beitrag der Istio-Reihe sprechen.
Wenn Langeweile richtig ist
In unserem Fall entsteht Langeweile erst in der Endphase, wenn nur noch das Zuschauen übrig bleibt. Dafür müssen Sie jedoch zunächst alles konfigurieren und hier erwarten Sie viele interessante Dinge.
Bei der Bereitstellung einer neuen Version Ihrer Software lohnt es sich, alle Möglichkeiten zur Risikominimierung in Betracht zu ziehen. Die parallele Ausführung ist eine sehr leistungsstarke und bewährte Methode zum Testen, und Istio ermöglicht Ihnen die Verwendung eines „geheimen Dienstes“ (einer versteckten Version Ihres Microservices), um dies zu tun, ohne das Produktionssystem zu beeinträchtigen. Dafür gibt es sogar einen speziellen Begriff – „Dark Launch“, der wiederum durch eine Funktion mit dem ebenso spöttischen Namen „Traffic Mirroring“ aktiviert wird.
Bitte beachten Sie, dass im ersten Satz des vorherigen Absatzes der Begriff „Bereitstellen“ und nicht „Freigeben“ verwendet wird. Sie sollten Ihren Microservice wirklich so oft bereitstellen und natürlich nutzen können, wie Sie möchten. Dieser Dienst muss in der Lage sein, Datenverkehr zu empfangen und zu verarbeiten, Ergebnisse zu liefern sowie in Protokolle zu schreiben und zu überwachen. Gleichzeitig muss dieser Dienst selbst jedoch nicht unbedingt in Produktion gehen. Die Bereitstellung und Veröffentlichung von Software ist nicht immer dasselbe. Sie können die Bereitstellung durchführen, wann immer Sie möchten, die Freigabe jedoch erst vornehmen, wenn Sie dazu bereit sind.
Langeweile zu organisieren ist interessant
Schauen Sie sich die folgende Istio-Routing-Regel an, die alle HTTP-Anfragen an die Microservice-Empfehlung v1 weiterleitet (alle Beispiele stammen aus ), während sie gleichzeitig auf den Empfehlungsv2-Mikroservice gespiegelt werden:
Achten Sie auf das Etikett mirror: am unteren Bildschirmrand – hiermit wird die Verkehrsspiegelung eingestellt. Ja, so einfach ist das!
Das Ergebnis dieser Regel ist, dass Ihr Produktionssystem (v1) weiterhin eingehende Anfragen verarbeitet, die Anfragen selbst jedoch asynchron auf v2 gespiegelt werden, d. h. ihre vollständigen Duplikate werden dorthin gelangen. Auf diese Weise können Sie v2 unter realen Bedingungen testen – mit echten Daten und echtem Datenverkehr – ohne den Betrieb des Produktionssystems in irgendeiner Weise zu beeinträchtigen. Wird die Organisation von Tests dadurch langweilig? Ja auf jeden Fall. Aber es ist auf interessante Weise gemacht.
Fügen wir Drama hinzu
Bitte beachten Sie, dass im v2-Code Situationen berücksichtigt werden müssen, in denen eingehende Anfragen zu Datenänderungen führen können. Die Anfragen selbst werden einfach und transparent abgebildet, die Wahl der Verarbeitungsmethode im Test liegt jedoch bei Ihnen – und das ist etwas besorgniserregend.
Wiederholen wir einen wichtigen Punkt
Der geheime Start mit Verkehrsspiegelung (Dark Launch/Request Mirroring) kann durchgeführt werden, ohne den Code in irgendeiner Weise zu beeinträchtigen.
Denkanstöße
Was passiert, wenn der Ort, an dem Anfragen gespiegelt werden, einige davon nicht an v1, sondern an v2 sendet? Beispielsweise ein Prozent aller Anfragen oder nur Anfragen einer bestimmten Benutzergruppe. Und dann, nachdem wir uns bereits mit der Funktionsweise von Version 2 befasst haben, werden alle Anforderungen nach und nach auf die neue Version übertragen. Oder umgekehrt, alles auf Version 1 zurücksetzen, wenn mit Version 2 etwas schief geht. Ich glaube, es heißt Canary Deployment. , und wenn es russischen Ursprungs wäre, würde es wahrscheinlich einen Verweis darauf enthalten ), und jetzt werden wir uns das genauer ansehen.
Canary-Bereitstellung in Istio: Vereinfachung der Inbetriebnahme
Vorsichtig und schrittweise
Die Essenz des Canary Deployment-Bereitstellungsmodells ist äußerst einfach: Wenn Sie eine neue Version Ihrer Software (in unserem Fall einen Microservice) starten, gewähren Sie zunächst einer kleinen Gruppe von Benutzern Zugriff darauf. Wenn alles gut geht, vergrößern Sie diese Gruppe langsam, bis die neue Version zu funktionieren beginnt, oder – wenn dies nicht der Fall ist – migrieren Sie schließlich alle Benutzer dorthin. Durch die durchdachte und schrittweise Einführung einer neuen Version und die kontrollierte Umstellung der Benutzer darauf können Sie Risiken reduzieren und das Feedback maximieren.
Natürlich vereinfacht Istio die Canary-Bereitstellung, indem es mehrere gute Optionen für die intelligente Weiterleitung von Anforderungen bietet. Und ja, das alles ist möglich, ohne Ihren Quellcode in irgendeiner Weise zu berühren.
Filtern des Browsers
Eines der einfachsten Routingkriterien ist die browserbasierte Umleitung. Nehmen wir an, Sie möchten, dass nur Anfragen von Safari-Browsern zu Version 2 wechseln. So wird es gemacht:
Wenden wir diese Routing-Regel an und verwenden dann den Befehl curl Wir werden echte Anfragen an den Microservice in einer Schleife simulieren. Wie Sie im Screenshot sehen können, gehen sie alle auf Version 1 über:
Wo ist der Verkehr auf v2? Da in unserem Beispiel alle Anfragen nur von unserer eigenen Kommandozeile kamen, existiert sie einfach nicht. Aber achten Sie auf die unteren Zeilen im obigen Bildschirm: Dies ist eine Reaktion auf die Tatsache, dass wir eine Anfrage vom Safari-Browser ausgeführt haben, die wiederum Folgendes hervorgebracht hat:
Unbegrenzte Macht
Wir haben bereits geschrieben, dass reguläre Ausdrücke sehr leistungsstarke Möglichkeiten zum Weiterleiten von Anforderungen bieten. Schauen Sie sich das folgende Beispiel an (wir glauben, dass Sie verstehen werden, was es bewirkt):
Mittlerweile haben Sie wahrscheinlich eine Vorstellung davon, was reguläre Ausdrücke bewirken können.
Handeln Sie klug
Intelligentes Routing, insbesondere die Verarbeitung von Paket-Headern mithilfe regulärer Ausdrücke, ermöglicht es Ihnen, den Datenverkehr nach Ihren Wünschen zu steuern. Und dies vereinfacht die Implementierung von neuem Code erheblich – es ist einfach, es ist keine Änderung des Codes selbst erforderlich und bei Bedarf kann alles schnell in den ursprünglichen Zustand zurückversetzt werden.
Interessiert?
Möchten Sie gerne mit Istio, Kubernetes und OpenShift auf Ihrem Computer experimentieren? Team hervorragend zubereitet zu diesem Thema erstellt und alle dazugehörigen Dateien öffentlich zugänglich gemacht. Also machen Sie weiter und verweigern Sie sich nichts.
Istio-Ausgang: Ausgang durch den Souvenirladen
Durch die Verwendung von Istio zusammen mit Red Hat OpenShift und Kubernetes können Sie Ihr Leben mit Microservices viel einfacher machen. Das Service Mesh von Istio ist in Kubernetes-Pods versteckt und Ihr Code wird (meistens) isoliert ausgeführt. Leistung, Wechselfreundlichkeit, Rückverfolgbarkeit etc. – all das ist durch den Einsatz von Sidecar-Containern einfach zu bedienen. Was aber, wenn Ihr Microservice mit anderen Diensten kommunizieren muss, die sich außerhalb Ihres OpenShift-Kubernetes-Systems befinden?
Hier kommt Istio Egress zur Rettung. Kurz gesagt, es ermöglicht Ihnen lediglich den Zugriff auf Ressourcen (sprich: „Dienste“), die nicht Teil Ihres Kubernetes-Pod-Systems sind. Wenn Sie keine zusätzliche Konfiguration durchführen, wird der Datenverkehr in der Istio Egress-Umgebung nur innerhalb eines Pod-Clusters und zwischen solchen Clustern basierend auf internen IP-Tabellen weitergeleitet. Und eine solche Verpuppung funktioniert hervorragend, solange man keinen Zugriff auf Dienste von außen benötigt.
Mit Egress können Sie die oben genannten IP-Tabellen umgehen, entweder basierend auf Egress-Regeln oder auf einem Bereich von IP-Adressen.
Nehmen wir an, wir haben ein Java-Programm, das eine GET-Anfrage an httpbin.org/headers stellt.
(httpbin.org ist lediglich eine praktische Ressource zum Testen ausgehender Serviceanfragen.)
Wenn Sie in der Befehlszeile eingeben curl http://httpbin.org/headers, wir werden Folgendes sehen:
Oder Sie öffnen die gleiche Adresse im Browser:
Wie Sie sehen, gibt der dort befindliche Dienst einfach die ihm übergebenen Header zurück.
Wir ersetzen Importe frontal
Nehmen wir nun den Java-Code dieses Dienstes außerhalb unseres Systems und führen ihn selbst aus, wo, wie Sie sich erinnern, Istio installiert ist. (Sie können dies selbst tun, indem Sie Kontakt aufnehmen .) Nachdem wir das entsprechende Image erstellt und auf der OpenShift-Plattform gestartet haben, rufen wir diesen Dienst mit dem Befehl auf curl egresshttpbin-istioegress.$(minishift ip).nip.io, woraufhin wir Folgendes auf dem Bildschirm sehen:
Ups, was ist passiert? Es hat einfach alles funktioniert. Was bedeutet „Nicht gefunden“? Wir haben es einfach für ihn getan curl.
Ausweitung der IP-Tabellen auf das gesamte Internet
Dafür sollte Istio verantwortlich gemacht (oder gedankt) werden. Schließlich handelt es sich bei Istio nur um Sidecar-Container, die für die Erkennung und Weiterleitung (und viele andere Dinge, über die wir zuvor gesprochen haben) verantwortlich sind. Aus diesem Grund wissen IP-Tabellen nur, was sich in Ihrem Clustersystem befindet. Und httpbin.org liegt außerhalb und ist daher nicht zugänglich. Und hier kommt Istio Egress zur Rettung – ohne die geringste Änderung an Ihrem Quellcode.
Die unten stehende Egress-Regel zwingt Istio dazu, (bei Bedarf im gesamten Internet) nach dem erforderlichen Dienst, in diesem Fall httpbin.org, zu suchen. Wie Sie dieser Datei (egress_httpbin.yml) entnehmen können, ist die Funktionalität hier recht einfach:
Es bleibt nur noch die Anwendung dieser Regel:
istioctl create -f egress_httpbin.yml -n istioegress
Mit dem Befehl können Sie Egress-Regeln anzeigen istioctl get egressrules:
Und schließlich führen wir den Befehl erneut aus curl – und wir sehen, dass alles funktioniert:
Wir denken offen
Wie Sie sehen, können Sie mit Istio die Interaktion mit der Außenwelt organisieren. Mit anderen Worten: Sie können weiterhin OpenShift-Dienste erstellen und diese über Kubernetes verwalten und dabei alles in Pods aufbewahren, die je nach Bedarf vergrößert und verkleinert werden können. Und gleichzeitig können Sie sicher auf Dienste außerhalb Ihrer Umgebung zugreifen. Und ja, wir wiederholen noch einmal, dass dies alles möglich ist, ohne Ihren Code in irgendeiner Weise zu berühren.
Dies war der letzte Beitrag der Serie auf Istio. Bleiben Sie dran – es liegen viele interessante Dinge vor Ihnen!
Source: habr.com