Microservice Management mit Kubernetes und Istio

Eine kurze Geschichte über die Vor- und Nachteile von Microservices, das Service Mesh-Konzept und Google-Tools, mit denen Sie Microservice-Anwendungen ausführen können, ohne den Kopf mit endlosen Einstellungen von Richtlinien, Zugriffen und Zertifikaten zu verstopfen, und schnell Fehler finden, die sich nicht im Code, sondern in der Microservice-Logik verstecken.



Der Artikel basiert auf dem Bericht von Craig Box auf unserer letztjährigen DevOops 2017-Konferenz. Video und Übersetzung des Berichts sind unterboten.


Craig Box (Craig Box, Twitter ) - DevRel von Google, zuständig für Microservices sowie Kubernetes- und Istio-Tools. In seiner aktuellen Geschichte geht es um die Verwaltung von Microservices auf diesen Plattformen.

Beginnen wir mit einem relativ neuen Konzept namens Service Mesh. Dieser Begriff wird verwendet, um das Netzwerk interagierender Mikrodienste zu beschreiben, aus denen die Anwendung besteht.



Auf hoher Ebene sehen wir das Netzwerk als eine Pipe, die einfach Bits bewegt. Wir möchten uns nicht um sie oder beispielsweise um die MAC-Adressen in Anwendungen kümmern, aber wir bemühen uns, über die Dienste und Verbindungen nachzudenken, die sie benötigen. Wenn Sie aus der Sicht von OSI schauen, dann haben wir ein Netzwerk der dritten Ebene (mit Funktionen zum Bestimmen der Route und der logischen Adressierung), aber wir möchten in Bezug auf das siebte denken (mit der Funktion des Zugriffs auf Netzwerkdienste).

Wie sollte ein echtes Netzwerk der siebten Ebene aussehen? Vielleicht möchten wir so etwas wie eine Spur von Verkehr um problematische Dienste sehen. Damit Sie eine Verbindung zum Dienst herstellen können und gleichzeitig die Ebene des Modells von der dritten Ebene angehoben wurde. Wir möchten eine Vorstellung davon bekommen, was im Cluster passiert, unbeabsichtigte Abhängigkeiten finden und die Hauptursachen für Fehler herausfinden. Wir müssen auch unnötigen Overhead vermeiden, z. B. das Herstellen einer Verbindung mit hoher Latenz oder das Herstellen einer Verbindung zu Servern mit einem kalten oder nicht vollständig erwärmten Cache.

Wir müssen sicher sein, dass der Verkehr zwischen Diensten vor trivialen Angriffen geschützt ist. Eine gegenseitige TLS-Authentifizierung ist erforderlich, ohne jedoch die entsprechenden Module in jede von uns geschriebene Anwendung einzubetten. Es ist wichtig, nicht nur auf Verbindungsebene, sondern auch auf höherer Ebene steuern zu können, was unsere Anwendungen umgibt.

Service Mesh ist eine Schicht, mit der wir die oben genannten Probleme in einer Mikrodienstumgebung lösen können.

Monolith und Microservices: Vor- und Nachteile

Aber zuerst fragen wir uns, warum wir diese Probleme überhaupt lösen sollten. Wie haben wir vorher Software entwickelt? Wir hatten eine Anwendung, die ungefähr so ​​aussah - wie ein Monolith.



Es ist großartig: Der gesamte Code ist in voller Ansicht. Warum nicht diesen Ansatz weiter verfolgen?
Ja, weil der Monolith seine eigenen Probleme hat. Die Hauptschwierigkeit besteht darin, dass wir jedes Modul neu bereitstellen müssen, wenn wir diese Anwendung neu erstellen möchten, auch wenn sich nichts geändert hat. Wir sind gezwungen, eine Anwendung in derselben Sprache oder in kompatiblen Sprachen zu erstellen, auch wenn verschiedene Teams daran arbeiten. Tatsächlich können einzelne Teile nicht unabhängig voneinander getestet werden. Es ist Zeit, es zu ändern, es ist Zeit für Microservices.



Also haben wir den Monolithen in Teile geteilt. Möglicherweise stellen Sie fest, dass wir in diesem Beispiel einige der unnötigen Abhängigkeiten entfernt und die Verwendung der internen Methoden, die von anderen Modulen aufgerufen wurden, eingestellt haben. Wir haben Services aus den zuvor verwendeten Modellen erstellt und Abstraktionen in Fällen erstellt, in denen der Status beibehalten werden muss. Beispielsweise sollte jeder Dienst einen unabhängigen Status haben, damit Sie sich beim Zugriff darauf keine Gedanken darüber machen müssen, was in der übrigen Umgebung geschieht.

Was ist das Ergebnis?



Wir haben die Welt der gigantischen Apps verlassen, um das zu bekommen, was wirklich gut aussieht. Wir haben die Entwicklung beschleunigt, keine internen Methoden mehr verwendet, Services erstellt und können diese nun unabhängig skalieren, um den Service zu erweitern, ohne alles andere konsolidieren zu müssen. Aber was ist der Preis für Veränderung, den wir verloren haben?



Wir hatten zuverlässige Aufrufe in Anwendungen, weil Sie einfach eine Funktion oder ein Modul aufgerufen haben. Wir haben den vertrauenswürdigen Aufruf im Modul durch einen unzuverlässigen Remoteprozeduraufruf ersetzt. Der Service auf der anderen Seite ist jedoch nicht immer verfügbar.

Wir waren sicher und verwendeten denselben Prozess in derselben Maschine. Jetzt stellen wir eine Verbindung zu Diensten her, die sich möglicherweise auf verschiedenen Computern und in einem nicht vertrauenswürdigen Netzwerk befinden.

Bei dem neuen Ansatz im Netzwerk ist die Anwesenheit anderer Benutzer möglich, die versuchen, eine Verbindung zu den Diensten herzustellen. Die Verzögerungen nahmen zu und gleichzeitig nahmen ihre Messfähigkeiten ab. Jetzt haben wir schrittweise Verbindungen in allen Diensten, die einen Modulaufruf erstellen, und wir können nicht mehr nur die Anwendung im Debugger betrachten und herausfinden, was genau den Fehler verursacht hat. Und dieses Problem muss irgendwie gelöst werden. Natürlich brauchen wir neue Werkzeuge.

Was kann getan werden?

Es gibt mehrere Möglichkeiten. Wir können unsere Bewerbung annehmen und sagen, wenn RPC beim ersten Mal nicht funktioniert, sollten Sie es erneut versuchen und dann immer wieder. Warten Sie etwas und versuchen Sie es erneut oder fügen Sie Jitter hinzu. Wir können auch Entry-Exit-Traces hinzufügen, um zu sagen, dass der Anruf gestartet und beendet wurde, was für mich dem Debuggen entspricht. Sie können eine Infrastruktur hinzufügen, um die Authentifizierung von Verbindungen bereitzustellen und allen unseren Anwendungen das Arbeiten mit TLS-Verschlüsselung beizubringen. Wir müssen die Last des Inhalts einzelner Teams tragen und ständig die verschiedenen Probleme berücksichtigen, die in SSL-Bibliotheken auftreten können.

Die Konsistenz über mehrere Plattformen hinweg aufrechtzuerhalten, ist eine undankbare Aufgabe. Ich möchte, dass der Abstand zwischen den Anwendungen angemessen wird, damit die Möglichkeit der Nachverfolgung besteht. Wir benötigen auch die Möglichkeit, Konfigurationen zur Laufzeit zu ändern, um Anwendungen für die Migration nicht neu zu kompilieren oder neu zu starten. Diese Wunschliste und implementiert Service Mesh.

Isstio

Sprechen Sie über Istio .



Istio ist ein vollständiges Framework zum Verbinden, Verwalten und Überwachen der Microservice-Architektur. Istio wurde entwickelt, um auf Kubernetes zu arbeiten. Er selbst stellt die Software nicht bereit und möchte sie nicht auf den Computern verfügbar machen, die wir für diesen Zweck mit Containern in Kubernetes verwenden.



In der Abbildung sehen wir drei verschiedene Abschnitte der Maschinen und Blöcke, aus denen unsere Mikrodienste bestehen. Wir haben eine Möglichkeit, sie mithilfe der von Kubernetes bereitgestellten Mechanismen zu gruppieren. Wir können darauf abzielen und sagen, dass eine bestimmte Gruppe, die möglicherweise über eine automatische Skalierung verfügt, an einen Webdienst angehängt ist oder über andere Bereitstellungsmethoden verfügt, unseren Webdienst enthält. In diesem Fall müssen wir nicht an Maschinen denken, sondern arbeiten hinsichtlich des Zugriffs auf Netzwerkdienste.



Diese Situation kann in Form eines Diagramms dargestellt werden. Betrachten Sie ein Beispiel, wenn wir einen Mechanismus haben, der eine Bildverarbeitung ausführt. Der Benutzer auf der linken Seite ist der Verkehr, von dem wir im Microservice zu uns kommen.

Um Zahlungen vom Benutzer zu akzeptieren, verfügen wir über einen separaten Zahlungsmikroservice, der eine externe API aufruft, die sich außerhalb des Clusters befindet.

Um die Benutzeranmeldung zu verarbeiten, stellen wir einen Authentifizierungsmikroservice bereit, dessen Status außerhalb unseres Clusters erneut in der Cloud SQL-Datenbank gespeichert sind .

Was macht Istio? Istio verbessert Kubernetes. Sie installieren es mit einer Alpha-Funktion in Kubernetes namens Initializer. Wenn Sie die Software bereitstellen, werden Kubernetes dies bemerken und fragen, ob wir in jedem Kubernetes einen weiteren Container ändern und hinzufügen möchten. Dieser Container verarbeitet Pfade und Routing. Beachten Sie alle Anwendungsänderungen.

So sieht die Strecke mit Istio aus.



Wir haben externe Maschinen, die eingehende und ausgehende Proxys für den Datenverkehr in einem bestimmten Dienst bereitstellen. Wir können die Funktionen, über die wir bereits gesprochen haben, entladen. Wir müssen der Anwendung nicht beibringen, wie Telemetrie oder Tracing mit TLS durchgeführt werden. Aber wir können noch andere Dinge hinzufügen: automatische Unterbrechung, Geschwindigkeitsbegrenzung, kanarische Freigabe .

Der gesamte Datenverkehr wird jetzt über Proxyserver auf externen Computern und nicht direkt zu Diensten geleitet. Kubernetes erledigt alles unter derselben IP-Adresse. Wir werden in der Lage sein, Verkehr abzufangen, der zu Front- oder Enddiensten gehen würde.

Der externe Proxy, den Istio verwendet, heißt Envoy .



Envoy ist eigentlich älter als Istio, es wurde bei Lyft entwickelt. Ist seit mehr als einem Jahr in der Produktion tätig und hat die gesamte Infrastruktur von Microservices in Betrieb genommen. Wir haben Envoy für das Istio-Projekt in Zusammenarbeit mit der Community ausgewählt. Google, IBM und LYFT sind also die drei Unternehmen, die noch daran arbeiten.

Envoy ist in C ++ 11 geschrieben. Es ist seit über 18 Monaten in Produktion, bevor es zu einem Open Source-Projekt wurde. Wenn Sie es mit Ihren Diensten verbinden, werden nicht viele Ressourcen benötigt.

Hier sind einige Dinge, die Envoy tun kann. Dies ist die Erstellung eines Proxyservers für HTTP, einschließlich HTTP / 2 und darauf basierender Protokolle, wie z. B. gRPC. Es kann auch an andere Protokolle auf Binärebene weitergeleitet werden. Envoy kontrolliert Ihre Infrastrukturzone, damit Sie Ihren Teil autonom machen können. Es kann eine große Anzahl von Netzwerkverbindungen mit Wiederholungsversuchen verarbeiten und warten. Sie können eine bestimmte Anzahl von Versuchen festlegen, eine Verbindung zum Server herzustellen, bevor Sie den Anruf beenden und Informationen an Ihre Server senden, die der Dienst nicht beantwortet.

Sie müssen sich keine Gedanken über das erneute Laden der Anwendung machen, um die Konfiguration hinzuzufügen. Sie stellen einfach eine Verbindung mit einer API her, die Kubernetes sehr ähnlich ist, und ändern die Konfiguration zur Laufzeit.

Das Istio-Team hat einen großen Beitrag zur UpStream Envoy-Plattform geleistet. Zum Beispiel eine Einspritzfehlerwarnung. Wir haben es möglich gemacht zu sehen, wie sich die Anwendung verhält, wenn die Anzahl der Anforderungen für das fehlgeschlagene Objekt überschritten wird. Außerdem wurden die Funktionen der grafischen Anzeige und der Verkehrstrennung implementiert, um Fälle zu behandeln, in denen die kanarische Bereitstellung verwendet wird.



Die Abbildung zeigt, wie die Architektur des Istio-Systems aussieht. Wir werden nur zwei Microservices nehmen, die zuvor erwähnt wurden. Letztendlich ist im Diagramm alles einem softwaredefinierten Netzwerk sehr ähnlich. Vom Envoy-Proxyserver, den wir mit den Anwendungen bereitgestellt haben, wird der Datenverkehr mithilfe von IP-Tabellen im Namespace übertragen. Das Control Panel ist für die Verwaltung der Konsole verantwortlich, verarbeitet jedoch nicht den Datenverkehr selbst.
Wir haben drei Komponenten. Pilot, der die Konfiguration erstellt, überprüft die Regeln, die mithilfe der API für das Istio-Kontrollfeld geändert werden können, und aktualisiert Envoy anschließend so, dass es sich wie ein Clustererkennungsdienst verhält. Istio-Auth dient als Zertifizierungsstelle und überträgt TLS-Zertifikate an Proxies. Die Anwendung benötigt kein SSL, sie kann eine Verbindung über HTTP herstellen, und Proxys erledigen dies alles für Sie.

Mixer verarbeitet Anforderungen, um sicherzustellen, dass Sie die Sicherheitsrichtlinien einhalten, und überträgt dann Telemetrieinformationen. Ohne Änderungen an der Anwendung vorzunehmen, können wir alles sehen, was in unserem Cluster passiert.

Istio Vorteile

Lassen Sie uns also detaillierter über die fünf Dinge sprechen, die wir von Istio erhalten werden. Betrachten Sie zunächst das Verkehrsmanagement . Wir können die Verkehrssteuerung von der Skalierung der Infrastruktur trennen, sodass wir früher etwa 20 Instanzen der Anwendung ausführen konnten und 19 davon in der alten Version und eine in der neuen Version, dh 5% des Datenverkehrs in der neuen Version. Mit Istio können wir eine beliebige Anzahl von Instanzen bereitstellen, die wir benötigen, und gleichzeitig angeben, wie viel Prozent des Datenverkehrs an neue Versionen gesendet werden sollen. Eine einfache Regel der Trennung.

Alles kann im laufenden Betrieb nach Regeln programmiert werden. Envoy wird regelmäßig aktualisiert, wenn sich die Konfiguration ändert, und dies führt nicht zu Serviceausfällen. Da wir auf der Ebene des Zugriffs auf Netzwerkdienste arbeiten, können wir die Pakete anzeigen. In diesem Fall besteht die Möglichkeit, auf den Benutzeragenten zuzugreifen, der sich auf der dritten Ebene des Netzwerks befindet.



Zum Beispiel können wir sagen, dass jeder Datenverkehr vom iPhone einer anderen Regel folgt, und wir werden einen bestimmten Teil des Datenverkehrs auf die neue Version leiten, die wir für ein bestimmtes Gerät testen möchten. Der interne aufrufende Microservice kann bestimmen, zu welcher bestimmten Version eine Verbindung hergestellt werden muss, und Sie können ihn auf eine andere Version übertragen, z. B. 2.0.

Der zweite Vorteil ist die Transparenz . Wenn Sie eine Ansicht innerhalb des Clusters haben, können Sie verstehen, wie es erstellt wird. Wir müssen im Entwicklungsprozess keine Tools für Metriken erstellen. Metriken sind bereits in jeder Komponente enthalten.

Einige glauben, dass es völlig ausreicht, ein Protokoll für die Überwachung zu führen. Tatsächlich brauchen wir jedoch nur einen solchen universellen Satz von Indikatoren, die jedem Überwachungsdienst zugeführt werden können.



So sieht die mit dem Prometheus-Dienst erstellte Istio-Symbolleiste aus. Denken Sie daran, es im Cluster bereitzustellen.

Im Beispiel zeigt der Screenshot eine Reihe von überwachten Parametern, die für den gesamten Cluster spezifisch sind. Interessantere Dinge lassen sich beispielsweise daraus ableiten, wie viel Prozent der Anwendungen mehr als 500 Fehler verursachen, was einen Fehler impliziert. Die Antwortzeit wird in allen aufrufenden und antwortenden Dienstinstanzen innerhalb des Clusters zusammengefasst. Für diese Funktionalität sind keine Einstellungen erforderlich. Istio weiß, was Prometheus unterstützt, und er weiß, welche Dienste in Ihrem Cluster verfügbar sind, sodass Istio-Mixer ohne zusätzliche Einstellungen Metriken an Prometheus senden kann.
Mal sehen, wie es funktioniert. Wenn Sie einen bestimmten Dienst aufrufen, sendet der Proxy-Dienst Informationen zu diesem Aufruf an Mixer, der Parameter wie Wartezeit auf Antwort, Codestatus und IP erfasst. Es normalisiert sie und sendet sie an alle von Ihnen konfigurierten Server. Speziell für die Anzeige der Hauptindikatoren gibt es den Prometheus-Dienst und die FLUX DB-Adapter, aber Sie können auch Ihren eigenen Adapter schreiben und Daten in jedem Format für jede andere Anwendung anzeigen. Und Sie müssen nichts an der Infrastruktur ändern, wenn Sie eine neue Metrik hinzufügen möchten.



Wenn Sie eingehender recherchieren möchten, verwenden Sie das verteilte Zipkin- Rückverfolgungssystem. Informationen zu allen über den Istio-Mixer weitergeleiteten Anrufen können an Zipkin gesendet werden. Dort sehen Sie die gesamte Kette von Microservice-Aufrufen, wenn Sie auf den Benutzer antworten, und finden leicht einen Service, der die Verarbeitungszeit verzögert.



Auf Anwendungsebene besteht kein Grund zur Sorge, einen Trace zu erstellen. Envoy selbst übergibt alle erforderlichen Informationen an den Mixer, der sie an den Trace sendet, z. B. an Zipkin, den Stackdriver-Trace von Google oder eine andere Benutzeranwendung.

Lassen Sie uns über Fehlertoleranz und Effizienz sprechen.


Zeitüberschreitungen zwischen Serviceaufrufen sind erforderlich, um den Zustand von Load Balancern zu testen. Wir führen Fehler in diese Verbindung ein und sehen, was passiert. Betrachten Sie ein Beispiel. Angenommen, es besteht eine Verbindung zwischen Dienst A und Dienst B. Wir warten 100 Millisekunden auf eine Antwort des Videodienstes und geben nur 3 Versuche aus, wenn das Ergebnis nicht empfangen wird. Im Wesentlichen werden wir 300 Millisekunden brauchen, bevor ein erfolgloser Verbindungsversuch gemeldet wird.



Außerdem sollte unser Filmdienst beispielsweise die Bewertung des Films über einen anderen Mikroservice prüfen. Die Bewertung hat eine Zeitüberschreitung von 200 Millisekunden und es werden zwei Anrufversuche angegeben. Wenn Sie einen Videodienst aufrufen, können Sie 400 Millisekunden warten, wenn die Sternebewertung nicht in Reichweite ist. Wir erinnern uns jedoch, dass der Filmdienst nach 300 ms meldet, dass er inaktiv ist, und dass wir die wahre Ursache des Fehlers nie erfahren werden. Die Verwendung von Zeitüberschreitungen und das Testen der Ereignisse in diesen Fällen ist eine hervorragende Möglichkeit, alle möglichen cleveren Fehler in Ihrer Microservice-Architektur zu finden.

Mal sehen, was mit Effizienz zu tun hat. Der Kubernetes-Balancer selbst wirkt nur auf der Ebene der vierten Schicht. Wir haben einen Eingabekonstruktor für den Lastausgleich von der zweiten bis zur siebten Schicht erfunden. Istio ist als Balancer für die Netzwerkschicht mit Zugriff auf Netzwerkdienste implementiert.

Wir führen TLS-Offloading durch, daher verwenden wir in Envoy modernes, gut dotiertes SSL, sodass Sie sich keine Sorgen über Sicherheitslücken machen müssen.

Ein weiterer Vorteil von Istio ist die Sicherheit .



Was sind die grundlegenden Sicherheitsfunktionen in Istio? Der Istio-Auth-Dienst funktioniert in verschiedene Richtungen. Es verwendet ein öffentliches Framework und eine Reihe von Authentifizierungsstandards für SPIFFE- Dienste. Wenn es sich um einen Verkehrsfluss handelt, verfügen wir über eine Istio-Zertifizierungsstelle, die Zertifikate für die Dienstkonten ausstellt, die wir im Cluster ausführen. Diese Zertifikate entsprechen dem SPIFFE-Standard und werden von Envoy mithilfe des Sicherheitsmechanismus von kubernetes verteilt. Envoy verwendet Schlüssel für die bidirektionale TLS-Authentifizierung. So erhalten Backend-Anwendungen Kennungen, auf deren Grundlage bereits eine Richtlinie organisiert werden kann.

Istio verwaltet Root-Zertifikate selbstständig, sodass Sie sich keine Gedanken über Widerrufs- und Ablaufdaten machen müssen. Das System reagiert auf die automatische Skalierung. Wenn Sie also eine neue Entität einführen, erhalten Sie ein neues Zertifikat. Keine manuellen Einstellungen. Sie müssen keine Firewall konfigurieren. Benutzer verwenden Netzwerkrichtlinien und Kubernetes, um Firewalls zwischen Containern zu implementieren.

Schließlich die Anwendung von Richtlinien . Mixer ist ein Integrationspunkt für Infrastruktur-Backends, die Sie mit Service Mesh erweitern können. Dienste können problemlos innerhalb eines Clusters verschoben, in mehreren Umgebungen, in der Cloud oder lokal bereitgestellt werden. Alles ist für die Betriebssteuerung von Anrufen ausgelegt, die über Envoy erfolgen. , , . , - 20 . 20 , .

, , , , ICL . , , , , . , Mixer , . .



Erinnerst du dich an die erste Folie mit einer Foto-App, mit der wir angefangen haben, Istio zu lernen? All dies ist unter einer so einfachen Form verborgen. Auf der obersten Ebene wird alles, was Sie brauchen, automatisch erledigt. Sie stellen die Anwendung bereit und müssen sich keine Gedanken darüber machen, wie Sie eine Sicherheitsrichtlinie definieren oder einige Routing-Regeln konfigurieren. Die Anwendung funktioniert genau so, wie Sie es erwarten.

Wie fange ich mit Istio an?

Istio unterstützt frühere Versionen von Kubernetes, aber die neue Initialisierungsfunktion, über die ich gesprochen habe, ist in Version 1.7 und höher. Dies ist eine Alpha-Funktion in Kubernetes. Ich empfehle die Verwendung der Alpha-Cluster von Google Container Engine. Wir haben Cluster, die Sie für eine bestimmte Anzahl von Tagen aktivieren und gleichzeitig alle darin enthaltenen Produktionsfunktionen nutzen können.

Istio — github. 0.2. 0.1 kubernetes. 0.2 kubernetes. , . Envoy , . Istio , Cloud Foundry .

. Google Container Engine 1.8 -, Istio — .

, 14 DevOops 2018 (): , .