"Gefahr ist mein zweiter Vorname", sagte Austin Powers, ein mysteriöser Mann auf internationaler Ebene. Aber was von Superagenten und Spezialdiensten hoch geschätzt wird, ist überhaupt nicht für Computerdienste geeignet, bei denen langweilige Dinge viel besser sind als Gefahren.
Und Istio macht zusammen mit OpenShift und Kubernetes die Bereitstellung von Mikrodiensten wirklich langweilig und vorhersehbar - und das ist großartig. Wir werden darüber und vieles mehr im vierten und letzten Beitrag der Istio-Reihe sprechen.Wenn Langeweile stimmt
In unserem Fall tritt Langeweile nur in der letzten Phase auf, wenn es nur darum geht, den Prozess zu beobachten. Dafür müssen Sie jedoch alles vorkonfigurieren, und hier finden Sie viele interessante Dinge.Bei der Bereitstellung einer neuen Version Ihrer Software sollten Sie alle Optionen zur Risikominimierung berücksichtigen. Das Arbeiten im Parallelmodus ist eine sehr leistungsfähige und bewährte Testmethode. Mit Istio können Sie hierfür den „Geheimdienst“ (eine vor neugierigen Blicken verborgene Version Ihres Mikrodienstes) verwenden, ohne das Produktionssystem zu beeinträchtigen. Es gibt sogar einen speziellen Begriff dafür - "Secret Launch" (Dark Launch), der wiederum durch eine Funktion mit dem nicht weniger spyware-Namen "Traffic Mirroring" aktiviert wird.Beachten Sie, dass im ersten Satz des vorherigen Absatzes der Begriff "Bereitstellen" anstelle von "Freigeben" verwendet wird. Sie sollten wirklich in der Lage sein, Ihren Microservice so oft bereitzustellen und natürlich zu nutzen, wie Sie möchten. Dieser Dienst sollte in der Lage sein, Datenverkehr zu empfangen und zu verarbeiten, Ergebnisse zu erzielen sowie in Protokolle zu schreiben und zu überwachen. Gleichzeitig muss dieser Service selbst überhaupt nicht in Produktion gehen. Softwarebereitstellung und -freigabe sind nicht immer dasselbe. Sie können die Bereitstellung jederzeit durchführen, sie jedoch erst freigeben, wenn Sie vollständig bereit sind.Langeweile zu organisieren ist interessant
Sehen Sie sich die folgende Istio-Routing-Regel an, mit der alle HTTP-Anforderungen an den Empfehlungs-v1-Mikroservice weitergeleitet werden (alle Beispiele stammen aus dem Istio Tutorial GitHub-Repo ), während Sie sie an den Empfehlungs-v2-Mikroservice spiegeln:Achten Sie auf die Beschriftung mirror:am unteren Bildschirmrand - hier wird die Verkehrsspiegelung festgelegt. Ja, das ist so einfach!Das Ergebnis dieser Regel ist, dass Ihr Produktionssystem (v1) weiterhin eingehende Anforderungen verarbeitet, die Anforderungen selbst jedoch in v2 asynchron gespiegelt werden, dh, ihre vollständigen Duplikate werden dort abgelegt. Auf diese Weise können Sie die Arbeit von v2 unter realen Bedingungen - an realen Daten und Datenverkehr - testen, ohne die Arbeit des Produktionssystems zu beeinträchtigen. Ist die Testorganisation dadurch langweilig? Ja natürlich. Aber das wird interessanterweise gemacht.Drama hinzufügen
Bitte beachten Sie, dass im v2-Code Situationen vorgesehen werden müssen, in denen eingehende Anforderungen zu Datenänderungen führen können. Die Abfragen selbst werden einfach und transparent gespiegelt, aber die Wahl der Verarbeitungsmethode im Test liegt bei Ihnen - und das ist schon ein wenig aufregend.Wiederholen Sie den wichtigen Punkt
Ein geheimer Start mit Verkehrsspiegelung (Dark Launch / Request Mirroring) kann durchgeführt werden, ohne den Code zu beeinflussen.Denkanstöße
Aber was ist, wenn der Ort zum Spiegeln der Anforderungen darin besteht, einige von ihnen nicht an v1, sondern an v2 zu senden? Zum Beispiel ein Prozent aller Anfragen oder nur Anfragen von einer bestimmten Benutzergruppe. Wenn Sie sich bereits ansehen, wie v2 funktioniert, übertragen Sie nach und nach alle Anforderungen auf die neue Version. Oder kehren Sie umgekehrt zu v1 zurück, wenn mit v2 etwas schief geht. Es scheint Canary Deployment zu heißen („Canary Deployment“ - der Begriff geht auf den Bergbau zurück , und wenn er russischen Ursprungs wäre, würde er wahrscheinlich einen Hinweis auf Katzen enthalten ), und jetzt werden wir dies genauer untersuchen.Canary Deployment bei Istio: Vereinfachung der Inbetriebnahme
Vorsicht und nach und nach
Das Wesentliche des Bereitstellungsmodells von Canary Deployment ist äußerst einfach: Wenn Sie eine neue Version Ihrer Software (in unserem Fall Microservice) starten, geben Sie zunächst einer kleinen Gruppe von Benutzern Zugriff darauf. Wenn alles gut geht, erhöhen Sie diese Gruppe langsam, bis die neue Version zu verschrotten beginnt, oder - falls dies nicht der Fall ist - übertragen Sie schließlich alle Benutzer darauf. Durch die sorgfältige und schrittweise Einführung einer neuen Version und die kontrollierte Umstellung der Benutzer können Sie Risiken reduzieren und das Feedback maximieren.Natürlich vereinfacht Istio die kanarische Bereitstellung, indem es mehrere gute Optionen für intelligentes Abfrage-Routing bietet. Und ja, all dies kann ohne Berühren Ihres Quellcodes erfolgen.Filtern Sie den Browser
Eines der einfachsten Routing-Kriterien ist die browserbasierte Umleitung. Angenommen, Sie möchten, dass v2 nur Anforderungen von Safari-Browsern sendet. So geht's:Wir wenden diese Routing-Regel an und curlsimulieren dann mit dem Befehl echte Anforderungen an den Microservice in einer Schleife. Wie Sie im Screenshot sehen können, gehen alle zu Version 1:Und wo ist der Verkehr auf v2? Da in unserem Beispiel alle Anfragen nur von unserer eigenen Kommandozeile kamen, existiert sie einfach nicht. Beachten Sie jedoch die Grundlinien im obigen Screenshot: Dies ist eine Reaktion auf die Tatsache, dass wir die Anforderung über den Safari-Browser ausgeführt haben, der wiederum Folgendes ausgegeben hat:Unbegrenzte Macht
Wir haben bereits geschrieben, dass reguläre Ausdrücke sehr leistungsfähige Funktionen zum Weiterleiten von Abfragen bieten. Schauen Sie sich das folgende Beispiel an (wir glauben, Sie selbst werden verstehen, was es tut):Jetzt wissen Sie wahrscheinlich bereits, wozu reguläre Ausdrücke in der Lage sind.Handle schlau
Durch intelligentes Routing, insbesondere durch die Verarbeitung von Paket-Headern mit regulären Ausdrücken, können Sie den Datenverkehr nach Ihren Wünschen steuern. Dies vereinfacht die Inbetriebnahme von neuem Code erheblich - es ist einfach, es ist nicht erforderlich, den Code selbst zu ändern, und bei Bedarf kann alles schnell zurückgegeben werden, wie es war.Interessiert an?
Möchten Sie unbedingt mit Istio, Kubernetes und OpenShift auf Ihrem Computer experimentieren? Das Red Hat Developer Team hat ein hervorragendes Tutorial zu diesem Thema vorbereitet und alle zugehörigen Dateien freigegeben. Also mach weiter und leugne dir nichts. Istio Egress: Ausgang durch den Geschenkeladen
Die Verwendung von Istio mit Red Hat OpenShift und Kubernetes kann Ihr Leben mit Microservices erheblich vereinfachen. Das Istio-Dienstprogrammraster ist in Kubernetes-Pods versteckt, und Ihr Code wird (meistens) isoliert ausgeführt. Leistung, einfache Änderung, Rückverfolgung und mehr - all dies ist durch die Verwendung von Beiwagencontainern einfach und präzise 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, Sie können einfach auf Ressourcen (sprich: "Dienste") zugreifen, die nicht in Ihrem Kubernetes-System enthalten sind. Wenn Sie keine zusätzliche Konfiguration durchführen, wird der Datenverkehr in der Istio Egress-Umgebung nur innerhalb des Pod-Clusters und zwischen diesen Clustern basierend auf internen IP-Tabellen weitergeleitet. Und diese Art von Welpen funktioniert so lange, bis Sie Zugang zu Dienstleistungen von außen benötigen.Mit Egress können Sie die oben genannten IP-Tabellen umgehen, entweder basierend auf Egress-Regeln oder für einen Bereich von IP-Adressen.Angenommen, wir haben ein Java-Programm, das eine GET-Anforderung an httpbin.org/headers ausführt.(httpbin.org ist nur eine praktische Ressource zum Testen ausgehender Serviceanfragen.)Wenn Sie an der Eingabeaufforderung eingebencurl http://httpbin.org/headerswir werden folgendes sehen:Oder Sie können dieselbe Adresse in einem Browser öffnen:Wie Sie sehen können, gibt der dort befindliche Dienst einfach die an ihn übergebenen Header zurück.Importsubstitution in die Stirn
Nehmen wir nun den Java-Code dieses Dienstes außerhalb unseres Systems und führen ihn zu Hause aus, wo Istio steht. (Sie können dies selbst tun, indem Sie sich auf unser Istio-Tutorial beziehen .) Nachdem Sie das entsprechende Image erstellt und auf der OpenShift-Plattform ausgeführt haben, rufen wir diesen Dienst mit einem Befehl auf. Anschließend curl egresshttpbin-istioegress.$(minishift ip).nip.iowird auf dem Bildschirm Folgendes angezeigt:Ups, was ist passiert? Trotzdem hat es einfach funktioniert. Was bedeutet nicht gefunden? Wir haben es nur für ihn getan curl.Erweitern Sie IP-Tabellen auf das gesamte Internet
Schuld (oder danke) Istio dafür. Schließlich handelt es sich bei Istio nur um Beiwagencontainer, die für die Erkennung und Weiterleitung verantwortlich sind (nun, für viele andere Dinge, über die wir zuvor gesprochen haben). Aus diesem Grund wissen IP-Tabellen nur, was sich in Ihrem Clustersystem befindet. Und httpbin.org befindet sich außerhalb und ist daher nicht verfügbar. Und hier kommt Istio Egress zur Rettung - ohne die geringste Änderung in Ihrem Quellcode.Die folgende Egress-Regel zwingt Istio, (falls erforderlich, im gesamten Internet) nach dem gewünschten Dienst zu suchen, in diesem Fall httpbin.org. Wie Sie dieser Datei (egress_httpbin.yml) entnehmen können, ist die Funktionalität hier ziemlich einfach:Es bleibt nur diese Regel anzuwenden:istioctl create -f egress_httpbin.yml -n istioegress
Sie können die Ausgangsregeln mit dem folgenden Befehl anzeigen istioctl get egressrules:Führen Sie zum Schluss den Befehl curl erneut aus - und stellen Sie sicher, dass alles funktioniert:Wir denken offen
Wie Sie sehen können, 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 steuern, indem Sie alles in Pods speichern, die nach Bedarf vergrößert und verkleinert werden. 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 zu berühren.Dies war der letzte Beitrag in der Istio-Reihe. Bleiben Sie bei uns - viele interessante Dinge vor uns!