Istio ist eine konfigurierbare quelloffene Servicenetzschicht, die die Container in einem Kubernetes-Cluster verbindet, überwacht und sichert. Zum Zeitpunkt der Erstellung dieses Artikels arbeitete Istio nativ nur mit Kubernetes zusammen, aber dank seines Open-Source-Charakters kann jeder Erweiterungen schreiben, die eine Ausführung von Istio auf jeder beliebigen Cluster-Software ermöglichen. Heute soll das Augenmerk auf der Verwendung von Istio mit Kubernetes liegen, was dem gängigsten Anwendungsfall entspricht.

Kubernetes ist ein Tool für die Containerorchestrierung und ein zentraler Bestandteil von Kubernetes ist ein Knoten. Ein Knoten besteht aus einem oder mehreren Containern sowie Dateisystemen oder anderen Komponenten. Eine Microservice-Architektur kann aus einem Dutzend unterschiedlicher Knoten bestehen, die jeweils unterschiedliche Microservices darstellen. Kubernetes verwaltet die Verfügbarkeit und die Ressourcenauslastung der Knoten und fügt, wenn der Bedarf steigt, Pods mit dem Pod-Autoscaler hinzu. Istio fügt zusätzliche Container in den Pod ein, um Sicherheit, Verwaltung und Überwachung hinzuzufügen.

Aufgrund seiner Quelloffenheit kann Istio auf jedem Public-Cloud-Provider, der die Anwendung unterstützt, und in jeder privaten Cloud mit entsprechend gewillten Administratoren ausgeführt werden.

Das folgende Video erklärt mehr über die Grundlagen von Istio:

Wenn Unternehmen zu Microservices wechseln, müssen sie Dutzende oder Hunderte von bestimmten Anwendungen unterstützen. Die separate Verwaltung dieser Endpunkte bedeutet die Unterstützung einer großen Anzahl virtueller Maschinen oder VMs und erfordert außerdem die Berücksichtigung des jeweiligen Bedarfs. Cluster-Software wie Kubernetes ist zwar in der Lage, Pods zu erstellen und zu skalieren, Kubernetes stellt aber weder Routing noch Regeln für den Datenverkehr und auch keine leistungsfähigen Überwachungs- oder Debugging-Tools bereit.

Hier kommt das Servicenetz ins Spiel.

Mit der zunehmenden Anzahl von Services steigt auch die Anzahl der möglichen Kommunikationswege exponentiell an. Zwei Services verfügen lediglich über zwei Kommunikationspfade. Drei Services haben sechs, während zehn Services bereits neunzig solcher Pfade bieten. Ein Servicenetz bietet eine zentrale Möglichkeit zur Konfiguration dieser Kommunikationspfade, indem eine Richtlinie für die Kommunikation erstellt wird.

Ein Servicenetz instrumentiert die Services und lenkt den Kommunikationsverkehr entsprechend einer vordefinierten Konfiguration. Anstatt einen aktiven Container konfigurieren zu müssen (oder zu diesem Zweck Code zu schreiben), kann ein Administrator das Servicenetz mit entsprechender Konfiguration versorgen und ihm dann diese Arbeit überlassen. Bisher musste dies immer mit Webservern und Service-to-Service-Kommunikation erfolgen.

Die gängigste Vorgehensweise, dies in einem Cluster zu tun, ist die Anwendung des Sidecar-Musters. Ein Sidecar ist ein neuer Container innerhalb des Pods, der den Kommunikationsverkehr zwischen Services und Containern (weiter)leitet und überwacht.

Wie bereits erwähnt, setzt Istio auf Kubernetes auf und fügt Container hinzu, die für den Programmierer und Administrator im Grunde unsichtbar sind. Diese als „Sidecar“ bezeichneten Container fungieren quasi als zwischengeschalteter „Mittelsmann“, der den Datenverkehr lenkt und die Interaktionen zwischen den Komponenten überwacht. Istio und Kubernetes arbeiten in kombiniertem Einsatz in drei Bereichen zusammen: Konfiguration, Überwachung und Verwaltung.

Konfiguration

Die primäre Methode zum Definieren der Konfiguration mit Kubernetes stützt sich auf den Befehl „kubectl“, in der Regel „kubectl -f“, wobei es sich bei der Datei um eine YAML-Datei handelt. Istio-Benutzer können mit „kubectl“ entweder neue und andere Arten von YAML-Dateien ausführen oder aber den neuen, optionalen Befehl „ioctl“ verwenden.

Überwachung

Mit Istio können Sie den Allgemeinzustand Ihrer mit Kubernetes ausgeführten Anwendungen ohne großen Aufwand überwachen. Die Instrumentierung von Istio kann den Zustand von Anwendungen verwalten sowie darstellen und liefert damit mehr Einblick als die allgemeine Überwachung von Clustern und Knoten, die Kubernetes bietet.

Verwaltung

Da die Schnittstelle für Istio im Wesentlichen dieselbe wie für Kubernetes ist, erfordert die Verwaltung fast keinen zusätzlichen Aufwand. Istio ermöglicht dem Benutzer vielmehr die Erstellung von Richtlinien, die sich auf den gesamten Kubernetes-Cluster auswirken und diesen verwalten, was den Zeitaufwand für die Verwaltung der einzelnen Cluster reduziert und zugleich den Bedarf für benutzerdefinierten Verwaltungscode eliminiert.

Zu den Hauptvorteilen eines Servicenetzes gehören Funktionen für eine Verbesserung von Debugging, Überwachung, Routing, Sicherheit und Nutzung. Das bedeutet, dass es mit Istio weniger aufwändig ist, eine größere Gruppe von Services zu verwalten.

Verbessertes Debugging

Angenommen, dass ein Service mehrere Abhängigkeiten aufweist. Der Service „pay_claim“ bei einer Versicherungsgesellschaft ruft den Service „deductible_amt“ auf, der seinerseits den Service „is_member_covered“ aufruft, und so weiter. Eine komplexe Abhängigkeitskette enthält möglicherweise 10 oder 12 Serviceaufrufe. Wenn einer dieser 12 Aufrufe fehlschlägt, kommt es zu einer kaskadierenden Reihe von Ausfällen, die zu einer Art Fehler vom Typ 500 oder Typ 400 führen oder auf die möglicherweise überhaupt keine Reaktion erfolgt.

Zum Debuggen dieser Reihe von Aufrufen können Sie so etwas wie einen Stack-Trace verwenden. Am Front-End können clientseitige Entwickler sehen, welche Elemente in welcher Reihenfolge von Web-Servern zurückgezogen werden, und können diese anschließend untersuchen. Front-End-Programmierer können ein Wasserfalldiagramm erhalten, das bei der Fehlerbehebung hilft.

Was das Beispiel nicht zeigt, ist, sind die Abläufe innerhalb des Rechenzentrums, wie also durch „callback=parselLotamaAudiences“ vier weitere Web-services aufgerufen werden und welche davon langsamer reagieren. Später erfahren Sie, wie Istio Tools zur Verfolgung von Funktionsaufrufen in einem Diagramm ähnlich diesem bereitstellt.

Überwachung und Beobachtbarkeit

DevOps-Teams und die IT-Administration möchten gegebenenfalls den Datenverkehr beobachten, um sich über Latenz, Betriebszeit (Time-in-Service), Fehler als Prozentsatz des Datenverkehrs und so weiter zu informieren. Oft ist dazu die Anzeige eines Dashboards gewünscht. Ein Dashboard liefert eine Darstellung der Summe oder des Durchschnitts dieser Metriken im Zeitverlauf – eventuell mit der Möglichkeit, eine Drilldown-Operation bis zu einem bestimmten Knoten, Service oder Pod durchzuführen. Kubernetes stellt diese Funktionalität nicht nativ bereit.

Richtlinie

Standardmäßig erlaubt Kubernetes jedem Pod, Datenverkehr an jeden beliebigen anderen Pod zu senden. Mit Istio können Administratoren eine Richtlinie erstellen, um einzuschränken, welche Services miteinander arbeiten dürfen. So könnte beispielsweise konfiguriert werden, dass Services nur dann andere Services aufrufen dürfen, wenn es sich bei diesen um echte Abhängigkeiten handelt. Eine weitere Richtlinie zur Aufrechterhaltung der Funktion von Services ist eine Durchsatzbegrenzung (Ratenlimit), mit der das Verstopfen (Blockieren) eines Service durch übermäßigen Datenverkehr vermieden wird und die Denial-of-Service-Angriffe verhindert.

Routing und Lastausgleich

Standardmäßig bietet Kubernetes einen Lastausgleich im Umlaufverfahren. Wenn es sechs Pods gibt, die jeweils einen Microservice bereitstellen, stellt Kubernetes eine Einrichtung für den Lastausgleich oder einen „Service“ bereit, der in aufsteigender Reihenfolge Anforderungen an jeden Pod sendet und dann von vorne beginnt. Es kommt jedoch vor, dass ein Unternehmen unterschiedliche Versionen desselben Service im Produktionsbetrieb bereitstellt.

Das einfachste Beispiel hierfür ist eine Blau/Grün-Bereitstellung. In diesem Fall könnte die Software eine völlig neue Version der Anwendung im Produktionsbetrieb erstellen, ohne jedoch Produktionsbenutzer an sie zu senden. Nach der Hochstufung der neuen Version kann das Unternehmen die alten Server weiter nutzen, um im Falle einer Störung oder eines Ausfalls schnell wieder auf sie zurückgreifen zu können (Switchback).

Mit Istio ist dies so einfach wie die Kennzeichnung einer Konfigurationsdatei mit Tags. Administratoren können auch Kennzeichnungen verwenden, um anzugeben, zu welchem Typ von Service eine Verbindung hergestellt werden soll, und um Regeln auf der Grundlage von Kopfzeilen zu erstellen. So zum Beispiel können sich Beta-Benutzer zu einem „Canary“-Pod mit dem aktuellsten und umfangreichsten Build weiterleiten lassen, während reguläre Benutzer mit dem stabilen Produktionsbuild arbeiten.

Unterbrechung des Kreislaufs

Wenn ein Service überlastet oder inaktiv ist, schlagen zusätzliche Anforderungen fehl und überlasten das System so noch weiter. Da Istio Fehler und Verzögerungen überwacht und verfolgt, kann es nach einer bestimmten, per Richtlinie festgelegten Anzahl von Anforderungen eine Pause erzwingen, damit ein Service wiederhergestellt werden kann. Sie können diese Richtlinie im gesamten Cluster durchsetzen lassen, indem Sie Istio mithilfe einer kleinen Textdatei anweisen, sie als neue Richtlinie zu nutzen.

Sicherheit

Istio bietet standardmäßig Identitäts-, Richtlinien- und Verschlüsselungsfunktionen sowie Services für die Authentifizierung, die Autorisierung und für Audits (kurz AAA). Für alle verwalteten Pods, die mit anderen Pods kommunizieren, erfolgt der Datenverkehr verschlüsselt, wodurch jegliche Beobachtung verhindert wird. Der kombinierte Einsatz von Identitätsservice und Verschlüsselung stellt sicher, dass nicht berechtigte Benutzer keine Serviceaufrufe vortäuschen oder fälschen können (Spoofing). AAA bietet Sicherheits- und Betriebsexperten die Tools, die sie für die Überwachung benötigen, und das bei geringerem Systemaufwand.

Vereinfachte Administration

Traditionelle Anwendungen erfordern immer noch die Identifizierungs-, Richtlinien- und Sicherheitsfunktionen, die Istio bietet. Das hat zur Folge, dass Programmierer und Administratoren auf der falschen Abstraktionsebene arbeiten und dieselben Sicherheitsregeln für jeden Service wieder und wieder implementieren müssen. Istio ermöglicht ihnen, auf der richtigen Ebene zu arbeiten und die Richtlinie(n) für den Cluster über eine Steuerkonsole festzulegen.