Was ist Istio?

Zum Zeitpunkt der Erstellung funktioniert Istio nativ nur mit Kubernetes, aber seine Open-Source-Natur ermöglicht es jedem, Erweiterungen zu schreiben, mit denen Istio auf jeder Cluster-Software laufen kann. Heute konzentrieren wir uns auf die Verwendung von Istio mit Kubernetes, dem beliebtesten Anwendungsfall.

Kubernetes ist ein Container-Orchestrierungstool, und eine Kerneinheit von Kubernetes ist ein Knoten. Ein Knoten besteht aus einem oder mehreren Containern sowie Dateisystemen oder anderen Komponenten. Eine Microservice-Architektur kann ein Dutzend verschiedener Knoten umfassen, die jeweils unterschiedliche Microservices darstellen. Kubernetes verwaltet die Verfügbarkeit und den Ressourcenverbrauch von Knoten und fügt Pods hinzu, wenn die Nachfrage steigt, mit dem Pod-Autoscaler. Istio fügt weitere Container in den Pod ein, um Sicherheit, Verwaltung und Überwachung hinzuzufügen.

Da Istio quelloffen ist, kann es auf jedem öffentlichen Cloud-Anbieter, der es unterstützt, und jeder privaten Cloud mit willigen Administratoren laufen.

Das folgende Video erläutert weitere Informationen zu den Grundlagen von Istio:

Wenn Unternehmen auf Microservices umsteigen, müssen sie Dutzende oder Hunderte von Anwendungen unterstützen. Die separate Verwaltung dieser Endpunkte bedeutet, dass viele virtuelle Maschinen oder VMs unterstützt werden, einschließlich der Nachfrage. Cluster-Software wie Kubernetes kann Pods erstellen und skalieren, bietet aber kein Routing, keine Verkehrsregeln, leistungsfähige Überwachungs- oder Debugging-Tools.

Geben Sie das Service Mesh ein.

Mit der zunehmenden Zahl von Diensten steigt auch die Zahl der möglichen Kommunikationswege exponentiell an. Zwei Services verfügen nur über zwei Kommunikationspfade. Drei Dienststellen haben sechs, während 10 Dienststellen 90 haben. Ein Service Mesh bietet eine einzige Möglichkeit, diese Kommunikationspfade zu konfigurieren, indem eine Richtlinie für die Kommunikation erstellt wird.

Ein Service Mesh instrumentiert die Dienste und leitet den Kommunikationsverkehr gemäß einer vordefinierten Konfiguration. Das bedeutet, dass ein Administrator statt einem laufenden Container zu konfigurieren (oder Code dafür zu schreiben) der Service Mesh die Konfiguration bereitstellen und es diese Arbeit erledigen lassen kann. Dies musste bisher immer mit Webservern und Service-to-Service-Kommunikation geschehen.

Die gebräuchlichste Methode, dies in einem Cluster zu tun, ist die Verwendung des Sidecar-Musters. Ein Sidecar ist ein neuer Container innerhalb des Pods, der den Kommunikationsverkehr zwischen Diensten und Containern leitet und beobachtet.

Wie bereits erwähnt, setzt Istio auf Kubernetes auf und fügt Container hinzu, die für den Programmierer und Administrator im Wesentlichen unsichtbar sind. Diese so genannten Sidecar-Container ähneln einer Person in der Mitte, die den Verkehr leitet und die Interaktionen zwischen den Komponenten überwacht. Die beiden arbeiten auf drei Arten zusammen: Konfiguration, Überwachung und Verwaltung.

Die primäre Methode zum Festlegen der Konfiguration mit Kubernetes ist der Befehl kubectl, üblicherweise „kubectl -f <filename>“ , wobei die Datei eine YAML-Datei ist. Istio-Nutzer können entweder neue und verschiedene Typen von YAML-Dateien mit kubectl ausführen oder den neuen, optionalen ioctl-Befehl verwenden.

Mit Istio können Sie den Zustand Ihrer Anwendungen, die mit Kubernetes laufen, ganz einfach überwachen. Die Istio-Instrumentierung kann den Zustand von Anwendungen verwalten und visualisieren und bietet damit mehr Einblick als die allgemeine Überwachung von Clustern und Knoten, die Kubernetes bereitstellt.

Da die Schnittstelle für Istio im Wesentlichen mit der von Kubernetes identisch ist, erfordert die Verwaltung nahezu keinen zusätzlichen Aufwand. Tatsächlich ermöglicht Istio dem Benutzer, Richtlinien zu erstellen, die sich auf den gesamten Kubernetes-Cluster auswirken und ihn verwalten, wodurch der Zeitaufwand für die Verwaltung jedes Clusters reduziert wird und gleichzeitig kein benutzerdefinierter Verwaltungscode erforderlich ist.

Zu den Hauptvorteilen eines Service Mesh gehören Funktionen für verbessertes Debuggen, Überwachen, Routing, Sicherheit und Nutzen. Das heißt, mit Istio ist es weniger aufwändig, eine größere Gruppe von Diensten zu verwalten.

Nehmen wir zum Beispiel an, dass ein Dienst mehrere Abhängigkeiten hat. Der Dienst pay_claim einer Versicherungsgesellschaft ruft den Dienst deductible_amt auf, der wiederum den Dienst is_member_covered aufruft, und so weiter. Eine komplexe Abhängigkeitskette kann 10 oder 12 Serviceaufrufe enthalten. Wenn einer dieser 12 Server ausfällt, kommt es zu einer Kaskade von Fehlern, die zu einer Art 500-Fehler, 400-Fehler oder möglicherweise gar keiner Antwort führen.

Um diese Aufrufe zu debuggen, können Sie so etwas wie einen Stack verwenden. Am Frontend können die Entwickler auf der Client-Seite sehen, welche Elemente in welcher Reihenfolge von den Webservern abgerufen werden, und diese überprüfen. Frontend-Programmierer können ein Wasserfalldiagramm erhalten, das beim Debuggen hilft.

Was das Beispiel nicht zeigt, ist, was innerhalb des Rechenzentrums passiert – wie callback=parselLotamaAudiences vier andere Webdienste aufruft und welche langsamer reagieren. Später werden wir sehen, wie Istio Tools zum Verfolgen von Funktionsaufrufen in einem Diagramm wie diesem bereitstellt.

DevOps- Teams und die IT-Administration möchten möglicherweise den Datenverkehr beobachten, um Latenz, Betriebszeit, Fehler als Prozentsatz des Datenverkehrs usw. zu ermitteln. Oft möchten sie ein Dashboard sehen. Ein Dashboard bietet eine Visualisierung der Summe oder des Durchschnittswerts oder dieser Metriken im Zeitverlauf, möglicherweise mit der Möglichkeit, einen Drilldown zu einem bestimmten Knoten, Dienst oder Pod durchzuführen. Kubernetes bietet diese Funktionen nicht nativ.

Standardmäßig erlaubt Kubernetes jedem Pod, Datenverkehr an jeden anderen Pod zu senden. Mit Istio können Administratoren eine Richtlinie erstellen, um einzuschränken, welche Dienste miteinander arbeiten können. So können Dienste beispielsweise nur andere Dienste aufrufen, bei denen es sich um echte Abhängigkeiten handelt. Eine weitere Richtlinie zur Aufrechterhaltung der Dienste ist eine Ratenbegrenzung. Diese verhindert, dass übermäßiger Datenverkehr einen Dienst verstopft und Denial-of-Service-Angriffe verhindert.

Standardmäßig bietet Kubernetes einen Round-Robin-Load-Balancing. Wenn es sechs Pods gibt, die einen Microservice bereitstellen, bietet Kubernetes einen Lastenverteiler oder einen Service, der in aufsteigender Reihenfolge Anfragen an jeden Pod sendet, dann beginnt der Prozess von vorne. Manchmal setzt ein Unternehmen jedoch verschiedene Versionen desselben Dienstes in der Produktion ein.

Das einfachste Beispiel hierfür wäre vielleicht eine blaue oder grüne Bereitstellung. In diesem Fall könnte die Software eine völlig neue Version der Anwendung in der Produktion erstellen, ohne dass Produktionsbenutzer dazu geschickt werden. Nach der Einführung der neuen Version kann das Unternehmen die alten Server behalten, um die Umstellung im Falle eines Ausfalls schnell zu ermöglichen.

Mit Istio ist dies so einfach wie die Verwendung von Tagging in einer Konfigurationsdatei. Administratoren können auch Bezeichnungen verwenden, um anzugeben, mit welcher Art von Dienst eine Verbindung hergestellt werden soll, und Regeln basierend auf Headern erstellen. So können beispielsweise Beta-Benutzer zu einem Canary-Pod mit dem neuesten und besten Build weiterleiten, während reguläre Benutzer zum stabilen Produktions-Build wechseln.

Wenn ein Dienst überlastet oder ausgefallen ist, schlagen weitere Anfragen fehl, während das System weiterhin überlastet wird. Da Istio Fehler und Verzögerungen verfolgt, kann es nach einer bestimmten, durch die Richtlinie festgelegten Anzahl von Anfragen eine Pause erzwingen, sodass ein Dienst wiederhergestellt werden kann. Sie können diese Richtlinie im gesamten Cluster durchsetzen, indem Sie eine kleine Textdatei erstellen und Istio anweisen, sie als neue Richtlinie zu verwenden.

Istio bietet standardmäßig Identität, Richtlinien und Verschlüsselung sowie Authentifizierung, Autorisierung und Audit (AAA). Alle verwalteten Pods, die mit anderen kommunizieren, verwenden verschlüsselten Datenverkehr, wodurch jegliche Beobachtung verhindert wird. Der Identitätsdienst stellt in Kombination mit der Verschlüsselung sicher, dass kein unbefugter Benutzer einen Serviceanruf vortäuschen oder „spoofen“ kann. AAA stellt Sicherheits- und Betriebsexperten die Tools zur Verfügung, die sie zur Überwachung benötigen, und das bei geringerem Aufwand.

Traditionelle Anwendungen benötigen weiterhin die Identitäts-, Richtlinien- und Sicherheitsfunktionen, die Istio bietet. Das führt dazu, dass Programmierer und Administratoren auf der falschen Abstraktionsebene arbeiten und für jeden Dienst immer wieder dieselben Sicherheitsregeln neu implementieren. Mit Istio können sie auf der richtigen Ebene arbeiten und Richtlinien für den Cluster über ein einziges Bedienfeld festlegen.