Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 13 Min.

Istio: Ein Service Mesh für Mikroarchitektur-Komponenten: Vermittlungsstelle


Linux Magazin - epaper ⋅ Ausgabe 10/2019 vom 05.09.2019

Moderne Applikationen basieren meist auf einer Architektur aus vielen kleinen Mikrokomponenten, die irgendwie miteinander kommunizieren müssen. Istio erleichtert diese Kommunikation erheblich.


Artikelbild für den Artikel "Istio: Ein Service Mesh für Mikroarchitektur-Komponenten: Vermittlungsstelle" aus der Ausgabe 10/2019 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 10/2019

© Josef Krcil, 123RF

Eine der disruptivsten Neuerungen der vergangenen Jahre nach dem Cloud Computing dürfte zweifellos der Mikroarchitektur- Ansatz sein. Der rückt so richtig erst im Gefolge der Container ins Bild. Denn vorher, als zur Virtualisierung nur KVM & Co. zur Verfügung standen, wäre es unklug gewesen, Minikomponenten in einzelnen virtuellen Systemen zu betreiben. Der Ressourcen-Overhead, der durch viele ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 10/2019 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 10/2019 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 10/2019 von 25 Jahre Linux-Magazin mit Gewinnspiel: Geschenkt!. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
25 Jahre Linux-Magazin mit Gewinnspiel: Geschenkt!
Titelbild der Ausgabe 10/2019 von Großes Gewinnspiel:. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Großes Gewinnspiel:
Titelbild der Ausgabe 10/2019 von Ein kurzer Rückblick auf das Jahr des ersten Linux-Magazins: W3C und Eurofighter. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Ein kurzer Rückblick auf das Jahr des ersten Linux-Magazins: W3C und Eurofighter
Titelbild der Ausgabe 10/2019 von Das Linux-Magazin und seine Konkurrenten: Umkämpftes Treppchen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Das Linux-Magazin und seine Konkurrenten: Umkämpftes Treppchen
Vorheriger Artikel
Wie die Cloud Design-Entscheidungen bestimmt: Der große Spr…
aus dieser Ausgabe
Nächster Artikel Kaleidoskop der Wissenschaft: Eine Suchmaschine für Argument…
aus dieser Ausgabe

Eine der disruptivsten Neuerungen der vergangenen Jahre nach dem Cloud Computing dürfte zweifellos der Mikroarchitektur- Ansatz sein. Der rückt so richtig erst im Gefolge der Container ins Bild. Denn vorher, als zur Virtualisierung nur KVM & Co. zur Verfügung standen, wäre es unklug gewesen, Minikomponenten in einzelnen virtuellen Systemen zu betreiben. Der Ressourcen-Overhead, der durch viele fast leere VMs entstanden wäre, hätte zur Verschwendung von CPU und RAM im großen Stil geführt.

Bei Containern ist das naturgemäß anders: Container verbraten keine CPUZyklen alleine dafür, dass sie laufen. Am Ende ist ein Container ja nur eine Kombination mehrerer Separationstechniken auf der Ebene des Linux-Kernels, um eine Applikation in eine virtuellen Umgebung einzuhegen. Weil der Linux-Kernel ohnehin läuft, bedarf es dafür kaum zusätzlicher Ressourcen.
Dass man im Gegenzug in solchen Containern nur Linux-Programme betreiben kann, ist leicht hinnehmbar. Das Gros der Anwender möchte Applikationen unter Linux virtualisieren und genau dieses Problem lösen Container.

Der Autor
Martin Gerhard Loschwitz beschäftigt sich seit vielen Jahren intensiv mit Cloud Computing und Themen wie Open Stack oder Kubernetes und Ceph.

Endlich agil

Auch Entwickler begrüßen den Containeransatz, denn er erlaubt es, agiler zu arbeiten als bisher. Als es darum ging, möglichst viel Workload in eine VM zu packen, war es nicht sinnvoll, ihn auf viele kleine Komponenten zu verteilen. Die großen Monolithen, die es bis heute gibt – etwa MySQL – bezeugen das.
Im Kontext mit Containern liegen die Dinge aber anders. Wenn man einzelne Komponenten einer Applikation in unterschiedliche Container packen, dort betreiben und verwalten kann, ist das auch in der Entwicklung möglich. Wo Entwickler die Komponenten einer App unabhängig voneinander warten und entwerfen, lebt das Konzept der Mikroreleases. „Release early, release often“ – eine Forderung, die im Kontext der großen Monolithen oft in Vergessenheit geriet, ist nun umsetzbar. Jetzt lassen sich die Komponenten regelmäßig im laufenden Betrieb austauschen, ohne Probleme zu verursachen. Denn implizite Hochverfügbarkeit ist bei den modernen Containeranwendungen der Gegenwart Teil des Designs und nicht etwas, das man im Nachhinein per Clustermanager aufpfropft.
Ferner ist die Fehlersuche bei Mikroarchitektur- Anwendungen leichter: Entwickler haben es schließlich nur mit eben jenem Code zu tun, den sie selbst geschrieben haben und warten – und nicht mit einem Wust aus verschiedenen Teilen, die alle irgendwie integriert sein müssen. Durch die Minireleases fällt zudem schneller auf, wenn sich ein Fehler einschleicht – und nicht erst Monate später, wenn es die fertige Riesenapplikation dann im Rahmen eines Wartungsfensters auf die produktiven Systeme schafft.

Kommunikation tut Not

Freilich hat jede Medaille zwei Seiten, und die Mikroarchitektur auf Containerbasis ist keine Ausnahme von dieser Regel. Denn damit die einzelnen Teile einer Mikroservice-Applikation erfolgreich zusammenspielen können, ist es nötig, die Kommunikation zwischen diesen Komponenten irgendwie zu ermöglichen. Wie kann sich ein Entwickler das Leben erleichtern, wenn er beispielsweise an einer Shop-Applikation arbeitet, bei der ein Kundeneinkauf durch verschiedene Teile des Programms wandert und von einer Komponente zur nächsten weiterzuleiten ist?

Trivial ist das Thema Verbindung in Containern ja ohnehin schon nicht. Bei Kubernetes etwa ist ein Proxyserver ab Werk mit an Bord, ohne den die Verbindung von der Außenwelt hin zu einer Applikation gar nicht möglich wäre. Denn ein Container läuft üblicherweise in einem eigenen Namespace, was sein Netzwerk angeht – und dort ist er vom Hauptnetzwerk des Systems aus gar nicht so einfach zu erreichen.
Hier kommt Istio ins Spiel (Abbildung 1 ). Das Programm verspricht, ein Full Service Mesh zwischen den einzelnen Komponenten einer Microservices-Applikation zu bilden. Es nimmt dem Admin also die Planung der Netzwerkverbindungen unterhalb der einzelnen Komponenten ab. Taugt dieses Konzept oder ist es eher Schall und Rauch? Das Linux-Magazin stellt Istio vor und verrät, für wen die Lösung infrage kommt.

Abbildung 1: Istio erweitert ein bestehendes Setup auf Basis von Pods um APIs und zentrale Steuerbarkeit.


© AVI Networks

Was ist ein Service Mesh?

Wer sich auf der Istio-Website[1] umschaut, stößt oft auf den Begriff Service Mesh für Cloudapplikationen. Weil „Mesh“ aber mittlerweile fast so abgelutscht ist wie „Cloud Computing“, hilft es, den Begriff im Istio-Kontext genauer zu definieren. Unter „Service Mesh“ verstehen die Istio-Entwickler die Gesamtheit aller Komponenten, die Bestandteil einer Mikroservice-Applikation sind.
Im vorherigen Beispiel vom Webshop könnten das alle Komponenten sein, die am Bestellprozess irgendwie beteiligt sind: Die Applikation, die die Website darstellt, jene, die die Queue eingehender Bestellungen überwacht, jene, die E-Mails für Bestellungen generiert, und jene, die diese E-Mails verschickt – der Fantasie sind hier im Grunde keine Grenzen gesetzt. Gemeinsam ist all diesen Komponenten, dass sie über ein Netz miteinander kommunizieren. Das ist einfacher gesagt als getan – und im schlechtesten Fall mit viel Aufwand in der Entwicklung verbunden, der eigentlich gar nicht nötig wäre.
Dass es der Entwickler hier mit vielen Aspekten des Themas Verbindung zu tun bekommt, wird schnell klar: Das geht schon bei der simplen Frage los, woher denn etwa die Applikation, die E-Mails versendet, weiß, wie sie die Applikation erreicht, die E-Mails generiert. In klassischen Umgebungen wären beide Funktionen Teil desselben Programms – oder man hätte die Versand-Applikation einfach mittels statischer IP-Adresse mit dem Mailgenerator verbunden.
Das geht in Container-basierten Applikationen auf Basis einer Microservice- Architektur aber gar nicht. Schließlich sollen die einzelnen Teile der Applikation ja mit der anliegenden Last nahtlos skalieren können. Ist im Webshop gerade die Hölle los, müssen mehr E-Mail-Versender und E-Mail-Generatoren laufen, doch die haben alle dynamische IP-Adressen. Wie erfahren sie also voneinander?

Discovery, Load Balancing, Routing und mehr

Es gibt bereits Lösungen für dieses Problem, etwa Consul oder Etcd. Beide haben Services-Verzeichnisse, bei denen Dienste sich registrieren, um anderen Diensten des Verbunds „Ich bin hier!“ zuzurufen. Baut der Admin Consul oder Etcd in seine Applikation ein, hat er aber nur das Auto- Discovery-Problem gelöst. Das ist jedoch nicht das einzige.
Hinzu kommt die Frage, wie Load Balancing über alle Instanzen eines bestimmten Microservice hinweg möglich ist. Falls Routing sein muss – wer implementiert die entsprechenden Regeln? Und gibt es Traffic, den man unterbinden möchte? Falls ja – womit tut man das? Auf all diese Fragen gibt es separate Antworten: Load Balancing ginge per HA-Proxy, Filtering mit NFtables, Routing-Regeln lassen sich manuell setzen. Doch dass die Entwickler von Microarchitektur-Applikationen all diese Komponenten betreiben und als Teil ihrer Applikation warten wollen, ist zweifelhaft.
An eben dieser Stelle setzen die Istio- Entwickler an: Sie versprechen den Entwicklern von Container-Applikationen, dass sie eine zentrale Netzwerkschnittstelle anbieten, mit denen die Teile einer Applikation sprechen. Die erforderlichen Dienstleistungen, also Load Balancing, Filtering, Discovery von vorhandenen Diensten und so weiter kommen dann von Istio. Um all diese Features nutzen zu können, muss der Admin Istio lediglich in seine Applikation integrieren.

Nicht nur Kubernetes

Was deutlich weniger komplex ist, als es im ersten Moment klingt. Vorab: Istio unterstützt aktuell ab Werk den Betrieb Flottenin Kubernetes, ist darauf aber nicht für immer festgelegt (Abbildung 2 ). Support etwa für Mesosphere ist in der Planung – denn Istio nutzt keine Features, die es nur und ausschließlich bei Kubernetes gibt. Weil praktisch niemand pures Kubernetes verwendet, sondern jeder auf eine der existierenden Kubernetes- Distributionen setzt, ist es wichtig, dass Istio sich auch an diese anpasst.
Und das ist der Fall: Aktuell lässt Istio sich mit Minikube ebenso wie mit Googles Kubernetes Engine oder Open Shift ausrollen. Auch Kubernetes-Cluster in AWS unterstützt Istio nativ. In einen bestehenden Kubernetes-Cluster lädt der Admin das Istio-Regelwerk und fügt die Istio-Pod-Definitionen hinzu – fertig, die Istio-Funktionalität lässt sich in Kubernetes nun nutzen. Doch wie genau funktioniert das in der Praxis?

Abbildung 2: Istio richtet sich aktuell noch bevorzugt an Kubernetes-Nutzer und spielt mit vielen Kubernetes-Varianten zusammen, wie hier beispielsweise in AWS.


© Amazon

Zwei Ebenen: Control und Data Plane

Wer ein übliches Istio-Deployment betrachtet, fühlt sich unwillkürlich an klassische Netzwerk-Switches erinnert. Ein Mesh, also die gesamte virtuelle Netzwerktopologie zwischen den Komponenten einer Microservice-Architektur-App, unterteilt Istio wie jene in zwei Ebenen: Einerseits enthält die Control Plane die gesamte Logik zur Steuerung aller Datenströme, andererseits implementiert die Data Plane eben jene Datenströme und sorgt dafür, dass sie die in der Policy festgelegten Regeln befolgen. Leider konnten die Istio-Entwickler der Versuchung nicht widerstehen, hier eine Vielzahl von Istio-spezifischen Begriffen zu erfinden. Ist der Admin die Arbeit mit Istio noch nicht gewohnt, verwirren die Bezeichnungen sehr – obgleich die meisten Komponenten in Istio Aufgaben wahrnehmen, für die es in der IT eindeutig benannte Vorbilder gibt.
Ein Beispiel dafür sind die Envoy Proxys, die Istio einem Container als so genannte Sidecars zur Seite stellt. Das ist allerdings kein Begriff aus dem Autohaus: Sidecars sind bei Istio einfach alle technischen Vorrichtungen, die an existierende Container geheftet werden, um für sie eine Dienstleistung zu erbringen.
Die Envoy Proxys sind dabei nur eine bestimmte Sidecar-Spielart: Durch sie leitet das Istio-Regelwerk den gesamten eingehenden wie auch den ausgehenden Traffic. Aufgrund von Anweisungen in Istiorollt Kubernetes die Proxys immer als Bestandteil eines Pod zusammen mit dem Workload-Container aus und konfiguriert das Gebilde so, dass der Proxy im Grunde so etwas wie einen Man-inthe- Middle für seinen Container darstellt.

Envoys im Fokus

Envoy Proxys, der Einfachheit halber im Istio-Sprech meist nur Envoys genannt, sind echte Multitalente. Als einzige Komponente des Setups ist der Envoy Proxy in C++ geschrieben, die Istio-Entwickler versprechen sich davon Performancevorteile gegenüber einer Lösung etwa in Go, wie es der Zeitgeist ja eher erwarten ließe. Sie manipulieren daher das Netfilter-Regelwerk des Hosts so, dass sie Zugriff auf den gesamten Traffic des Containers erhalten, in dessen Pod sie ausgerollt sind.
Die Hauptaufgabe der Envoy Proxys besteht aber gar nicht so sehr darin, diesen Traffic zu verändern. Zunächst sollen sie ihn einfach nur messen: Das Erheben von Telemetriedaten ist für die Funktionalität von Istio unbedingt notwendig, denn ohne ein entsprechendes Zahlenwerk wäre es etwa unmöglich, auf Basis tatsächlicher Zugriffe Load Balancing durchzuführen oder die Instanzen vorhandener Load Balancer bei Bedarf zu erweitern oder auch zu verkleinern.
Um eben diese Aufgaben kümmern die Envoys sich allerdings nicht direkt. Hier kommt die Control Plane ins Spiel, und dort insbesondere ein Dienst, der in gewisser Weise das Hirn einer Istio-Installation ist: der Mixer.

Der Mixer

Im Mixer ist eine Menge Intelligenz verbaut. Auf Basis der eingehenden Metrikdaten der verschiedenen Envoy-Instanzen im Cluster errechnet der Mixer etwa, welche Last auf dem System gerade anliegt und welche Regeln sich für das gesamte Service Mesh daraus ergeben. Das so entstandene Regelwerk gibt der Mixer anschließend an alle laufenden Envoy- Instanzen weiter, die es sodann auf den Hosts wieder in konkrete Systemkonfiguration umwandeln.
Das bedeutet freilich auch, dass der Mixer die Plattformunabhängigkeit von Istio möglich macht: Als generisches API lässt sich Istio mit jedem denkbaren Flottenin manager für Container verbinden. Und gleichzeitig stellt Istio eine Vielzahl von Funktionen für Containeranwendungen zur Verfügung, die der Entwickler andernfalls in seine Applikation integrieren müsste. Wer zum Beispiel die durch die laufenden Container erbrachten Dienstleistungen verrechnen möchte, kann den Mixer per Service Backend an das eigene Verrechnungssystem anschließen und erhält im Handumdrehen ein stabiles, definiertes Billing-API.

Auch der Pilot ist wichtig

Allerdings ist der Mixer nicht der einzige Dienst in Istio, der Envoys mit Regeln versorgt – eine ebenso große Rolle spielt hier der Pilot, der ebenfalls zu Istios Control Plane gehört. Er ist ein generisches API und kümmert sich zunächst um das Thema Service Discovery. Wie der Mixer ist der Pilot ebenfalls eine Abstraktionsebene: Er verbindet sich auf der einen Seite mit den APIs verschiedener Container- Orchestrierer, zum Beispiel von Kubernetes, Mesos oder Cloud Foundry, und leitet die so gewonnen Informationen auf der anderen Seite an die einzelnen Envoys weiter.
Dafür gibt es einzelne Adapter, nämlich die Platform Adapter, die sich um eben diese Übersetzung kümmern. Alle Envoy-Instanzen haben auf diese Weise immer die Übersicht über alle Containerinstanzen und erhalten damit auch die Möglichkeit, die Last innerhalb des Mesh ideal zu verteilen.
Noch eine Aufgabe nimmt das Pilot-API wahr: Es ist für Admins die in Istio vorgesehene Schnittstelle, um eigene, explizite Regeln unmittelbar zu definieren. Wer sich durch die Istio-Dokumentation gräbt, gelangt schnell zu der Überzeugung, Istio kümmere sich gewissermaßen um alle Belange ohnehin selbst und mache aus einem Verbindungschaos automatisch ein tolles Orchester. Ganz so leicht ist es aber eben doch nicht – der Admin muss Istio schon sagen, wie er es denn gern hätte. Und eben dafür ist das Regel-API in Istio nötig.

Wie steht es um die Sicherheit?

Die Control Plane in Istio enthält noch eine dritte Komponente: Istio Auth ist eine vollständige Authentifizierungslösung, um zwischen den Instanzen eines Mesh einerseits und diesen und der Außenwelt andererseits fein granulierte Zugriffs- und Sicherheitsregeln zu etablieren. Ab Werk sorgt Istio Auth jedenfalls dafür, dass die gesamte Kommunikation des Mesh innen wie außen TLS-verschlüsselt ist – die Sicherheitsverantwortlichen, in deren Netzen Istio-Installationen stehen, werden sich entsprechend freuen.
Auch diese Funktion ist über die Envoys realisiert, die von Istio Auth die passenden Informationen mitgeteilt bekommen und dann die Konfiguration entsprechend umsetzen. Mittlerweile erlaubt Istio Auth fein granulierte Zugriffsmodelle, die kaum einen Wunsch offen lassen dürften.

Abbildung 3: Neben Kubernetes wie hier in Form von Red Hats Open Shift soll Istio in Zukunft …


© Red Hat

Lohnt die Komplexität?

Beschäftigt ein Entwickler sich im Detail mit Istio, bekommt er es im ersten Moment also mit einiger Komplexität zu tun. Da liegt die Frage auf der Hand, ob die Funktionen von Istio diese Komplexität wirklich rechtfertigen. Ließen sich vergleichbare Ergebnisse nicht auch mit Bordmitteln erreichen? Welche Funktionen liefert Istio im Detail? Ein einfaches Beispiel verdeutlicht, warum Istio im Kontext von Containerflotten besonders wertvoll ist.
Man stelle sich etwa eine simple Webapplikation wie die eingangs schon beschriebene vor. Das Geschäft brummt und generiert einigen Umsatz, doch Firefox-Anwender beklagen sich ständig über Probleme in der Darstellung des Webshops. Das Devops-Team hat zwi- schenzeitlich herausgefunden, was des Übels Wurzel ist, möchte aber eine spezielle Variante der Applikation erst im Realbetrieb mit Firefox-Nutzern testen, bevor man sie für alle ausrollt. Im Fachjargon nennt sich diese Vorgehensweise Canary Releasing.
Wie soll das im konkreten Beispiel aber funktionieren? Klar ist, dass der zur Applikation gehörende Load Balancer sich um die entsprechende Verteilung kümmern muss, wenn die Canary-Version der Applikation für Firefox-Nutzer ausgerollt ist. Ohne Istio wäre das aus Entwicklersicht aber sehr komplex: Erst einmal ist es in Kubernetes ab Werk gar nicht so leicht, überhaupt einen Load Balancer zu bekommen – den betreibt man im schlechtesten Falle als Teil der Containerflotte selbst.
Zudem wäre der Load Balancer entsprechend neu zu konfigurieren, damit er ein Regelwerk für den HTTP-Header nutzt, auf den der Load Balancer ja abstellen muss. Denn sonst kann er die diversen Browserarten gar nicht voneinander unterscheiden. Wer sich all das baut, hat am Ende ein komplexes Konstrukt aus Regeln und Diensten, das absolut spezifisch für diese eine Softwarelösung ist.

Abbildung 4: … auch andere Umgebungen wie Mesos unterstützt – die APIs in Istio geben das jedenfalls her.


© dc21q

Traffic-Management

Sieht man sich dasselbe Beispiel auf Basis von Istio an, ergeben sich die aus seiner Nutzung resultierenden Vorteile schnell von selbst. Das zentrale Motiv, Istio zu verwenden, besteht für den Admin meist darin, dass Istio mehr oder minder autonom den gesamten Traffic innerhalb des Service Mesh einer Applikation auf Mikroarchitektur-Basis handhabt. Hierzu trennt es strikt zwischen der Skalierbarkeit der virtuellen Containerumgebung einerseits und der Skalierung des Traffics darin andererseits.
Das bedeutet im Beispiel des Load Balancers für bestimmte Browser-Varianten: Der Admin legt nicht im Detail fest, welche Instanzen eines bestimmten Pod welche Aufrufe abbekommen sollen. Er gibt nur das gewünschte Aufrufverhalten des Load Balancers insgesamt an, etwa: „Alle Anfragen mit dem Useragent Google Chrome landen auf den Pods der Version 1.0 der Applikation X, während alle Anfragen mit Firefox auf dem Pod mit derVersion 1.1 der Applikation X landen.“ Dass die Version 1.0 auf den Pods 1 bis 5 der Applikation läuft und die Version 1.1 auf den Pods 6 und 7, ist aus Istio-Sicht dabei völlig egal.
Würde der Admin zusätzliche Pods von 1.0 oder 1.1 starten, würden die Envoy Proxys diese automatisch in die schon bestehenden Balancing-Regeln integrieren. Istio verlässt sich hier einfach auf die Versionsnummer, die der Admin im entsprechenden Label beim Starten des Pod festgelegt hat. Für den Admin fiele so kein Mehraufwand an.
Um das oben beschriebene Beispiel umzusetzen, ist übrigens gar nicht viel nötig: Eine Yaml-Datei, die das entsprechende Regelwerk enthält und sich per »istio«-Befehl in Istio einspielen lässt, genügt völlig. Entsprechende Beispiele finden sich in der Istio-Dokumentation.

Abbildung 5: Kiali von Red Hat visualisiert das Service Mesh in Istio und macht es so leichter verständlich.


© Red Hat

Noch mehr Möglichkeiten

Dieser Artikel muss sich mit einer Kurzübersicht über die Istio-Funktionen begnügen. Unübersehbar im Vordergrund steht bei Istio das Prinzip der Stabilität, das alle Funktionen durchzieht. Funktionales Load Balancing ist nur die offensichtlichste davon, aber bei Weitem nicht die einzige.
So verfügt Istio etwa über eingebaute Health Checks für alle Pods, die der Pilot erfolgreich identifiziert hat. Istio überwacht diese Backends regelmäßig. Fällt ein Backend aus, reagieren die Envoy Proxys meist augenblicklich und nehmen das nun defekte Backend aus der Distribution. Läuft mal etwas unerwartet schief und doch mal eine Verbindung ins Leere, erkennt Istio das ebenfalls von allein und der zuständige Envoy Proxy polt die Verbindung augenblicklich um. Das gilt natürlich nur, falls der Admin als Standardtaktik nicht »Retry« in der Istio- Konfiguration festgelegt hat und so ein anderes Verhalten erzwingt.
Wer testen möchte, ob die eigene Container- Applikation wie gewünscht auf Fehler reagiert, findet in Istio einen Fault- Injection-Modus. Die Lösung spielt dann gewissermaßen Chaos Monkey und versorgt die anliegenden Pods mit unsinnigen Eingabedaten. Aus Entwickler-Sicht ist das enorm hilfreich, weil sich eine Applikation in einer Staging-Umgebung so schon testen lässt, ohne im realen Betrieb Probleme zu riskieren.
Wenn alles drunter und drüber geht, bietet Istio auch eine Circuit-Breaker-Funktion: Dabei handelt es sich um eine Art Throttling, das greift, wenn spezifische Parameter – etwa die Anzahl der eingehenden Verbindungen – vom Admin festgelegte Werte überschreiten.
Eben weil jeder Pod als Teil des Mesh- Netzwerks am dynamischen Routing von Traffic beteiligt ist, lassen sich Meshes auf Istio-Basis durch die Circuit-Breaker- Funktion gut gegen Bösewichte sichern. Die ganz große Traffic-Bombe wird freilich auch ein solches Setup nicht schadlos überstehen, Skript-Kiddies macht der Ansatz das Leben aber schwieriger.
Nicht zu vergessen sind schließlich auch die Policy-basierten Optionen in Istio: Per zentralem API lässt sich bestimmter Traffic herausfiltern oder in geordnete Bahnen lenken.

Fazit

Für Container-Applikationen bietet das automatische Traffic-Re-Routing in vielerlei Hinsicht massive Vorteile. Zunächst gilt: Istio bietet offene und gut dokumentierte APIs. Dadurch wird Istio völlig unabhängig von einer bestimmten Plattform (Abbildungen 3 und4 ). Nutzt ein Entwickler also Istio, kann er – ob als Entwickler oder als Devops-Mensch – dieselbe Schnittstelle nutzen, egal ob das Setup auf Mesos, auf Kubernetes, auf AWS oder sonstwo läuft.
In der Gegenrichtung gilt dasselbe: Woher eine Istio-Instanz ihre Informationen bekommt, ist zunächst mal egal. Innerhalb der Umgebung lassen sich sämtliche Daten stets über dieselben APIs aufrufen. Verbindet der Admin also einen Istio-Cluster mit Prometheus, um eine bessere Zahlenbasis für den Zustand des Netzwerks zu bekommen, erfolgt der Zugriff auf diese Daten wie auf alle anderen Daten auch.
Zugleich bietet Istio für das Routing von Traffic innerhalb des Mesh Funktionen, die ohne Istio nur mühsam nachimplementierbar wäre – und vor allem nicht als generische Lösung, sondern stets Setup-spezifisch. Wer eine Applikation auf Basis des Mikroarchitektur-Ansatzes plant und umsetzt, sollte sich Istio deshalb unbedingt genauer ansehen und das Produkt in die eigene Planung einbeziehen. Mehr Flexibilität in Sachen Netzwerk geht kaum.
Dass Istio keine Eintagsfliege ist, beweist übrigens mal wieder Red Hat: Dort hat man ein feines Gespür für Trends und bietet für Istio mittlerweile Kiali an. Das stellt die Mesh-Regeln von Istio grafisch dar und ermöglicht eine ansprechende Virtualisierung (Abbildung 5 ).(jcb ) n

Infos

[1] Istio-Website:[https://istio.io]