Istio fügt einer Menge von Microservices Traffic-Management, Sicherheit und Observability hinzu, ohne ihren Code anzufassen. Das ist nur möglich, weil sich seine beiden Hälften die Arbeit teilen: eine Data Plane, die den Traffic tatsächlich verarbeitet, und eine Control Plane, die der Data Plane sagt, was zu tun ist. Diese Anleitung behandelt beide und das Sidecar-Modell, das sie mit deinen Workloads verbindet.

Der Sidecar: ein Proxy, der neben deinem Container mitläuft

Im Standardmodus von Istio bekommt jeder Workload-Pod neben dem Anwendungs-Container einen zweiten eingeschleust: einen Envoy-Proxy, der so konfiguriert ist, dass er den gesamten ein- und ausgehenden Traffic dieses Pods abfängt. Deine Anwendung bindet weiterhin an ihren Port und stellt ausgehende Aufrufe genau so, als wäre nichts anders; der Sidecar sitzt transparent im Pfad, und genau das ist der Punkt. Die Anwendung muss nie wissen, dass der Proxy da ist.

Was das bringt: TLS, Retries, Timeouts, Load Balancing und Autorisierung wandern aus dem Anwendungscode in Konfiguration, die auf den Proxy angewendet wird. Ein Entwicklungsteam schreibt Geschäftslogik; das Mesh behandelt die Netzwerkbelange einheitlich über jeden Service hinweg, statt dass jedes Team seine eigene Version derselben Belange selbst implementiert (oder vergisst).

Die Data Plane: Envoy, der die eigentliche Arbeit erledigt

Die Data Plane ist die Gesamtheit all dieser Sidecar-Proxys, die tatsächlich jede Anfrage zwischen Services tragen. Hier wird Traffic verschlüsselt, hier wird eine Anfrage nach einem Timeout wiederholt, hier könnte eine Version eines Services für ein Canary-Release 10 % des Traffics erhalten. Die Data Plane entscheidet Policy nicht selbst; sie setzt durch, welche Konfiguration auch immer die Control Plane an sie geschoben hat.

Die Control Plane: istiod

istiod ist Istios Control Plane und läuft als eigene Menge von Pods im Namespace istio-system. Er erledigt drei verschiedene Aufgaben:

• Verteilung der Konfiguration. Du drückst deine Absicht in Istios eigenen Kubernetes-Ressourcen aus, etwa „teile den Traffic 90/10 zwischen diesen zwei Versionen auf“. istiod übersetzt das in Envoys natives Konfigurationsformat und schiebt es an jeden relevanten Sidecar, sodass du Envoy-Konfiguration nie direkt von Hand schreibst (die frühere „Learn“-Reihe zu Envoy in dieser Bibliothek behandelt, wie diese zugrunde liegende Konfiguration tatsächlich aussieht, für alle, die neugierig sind, was istiod erzeugt).
• Certificate Authority. istiod stellt die Zertifikate aus und rotiert sie, die jeder Sidecar für Mutual TLS nutzt, sodass Service-zu-Service-Traffic verschlüsselt ist und jede Seite die Identität der anderen verifizieren kann, ohne dass Anwendungscode selbst Zertifikate verwaltet.
• Service Discovery und Policy. istiod verfolgt, welche Services existieren und wo, und verteilt Authentifizierungs- und Autorisierungs-Policy an die Proxys, die sie durchsetzen müssen.

Sidecar-Injection: wie ein Pod tatsächlich einen Proxy bekommt

Die Installation von Istio allein ändert nichts an deinen laufenden Workloads. Sidecar-Injection ist ein separater, expliziter Schritt: Labele einen Namespace (istio-injection=enabled), und jeder danach in diesem Namespace erstellte Pod bekommt bei der Erstellung automatisch einen Envoy-Sidecar in seine Spec eingefügt. Bestehende Pods werden nicht rückwirkend verändert; sie müssen neu erstellt werden (gelöscht und erneut angewendet oder über ein Deployment ausgerollt), nachdem das Label gesetzt ist, bevor sie den Sidecar bekommen.

Dieses Opt-in-Design pro Namespace ist beabsichtigt. Jeden Namespace in einem Cluster automatisch zu meshen, einschließlich System-Namespaces, die nie einen Sidecar betreiben sollten, würde Ressourcen-Overhead und Komplexität hinzufügen, die niemand verlangt hat. Labeln gibt dir die Kontrolle darüber, welche Workloads genau gemesht werden.

Ein Pod mit seinem Sidecar zeigt zwei Container, wo ein ungemeshtes Gegenstück einen zeigt:

kubectl get pods
# NAME                READY   STATUS
# reviews-v1-abc123   2/2     Running   ← Sidecar vorhanden
# ratings-v1-def456   1/1     Running   ← kein Sidecar (ungelabelter Namespace)

Für einen Workload, der einen Sidecar braucht, ohne dass sein ganzer Namespace gelabelt wird, fügt manuelle Injection (istioctl kube-inject) den Sidecar zu einem einzelnen Manifest hinzu, bevor es angewendet wird, in der nächsten Anleitung zusammen mit dem Rest der Installation behandelt.

Ein Hinweis zum Ambient Mode

Alles oben beschreibt Istios ursprüngliche, Sidecar-basierte Architektur, die der Rest dieser Reihe behandelt. Istio bietet außerdem eine alternative, sidecar-lose Variante, den Ambient Mode, der die Data Plane in eine Komponente pro Knoten (ztunnel) und einen Waypoint-Proxy pro Namespace aufteilt, statt in jeden Pod einen Proxy einzuschleusen, mit dem Ziel, den Ressourcen-Overhead eines Envoy pro Workload zu senken. Er ist ein ausreichend großer architektonischer Unterschied, um außerhalb des Umfangs dieser Reihe zu liegen; was du hier über Traffic-Management- und Sicherheitskonzepte lernst, gilt konzeptionell auch im Ambient Mode, aber die Mechanik, wie Traffic abgefangen wird, unterscheidet sich. Konsultiere Istios eigene Dokumentation, wenn der Ambient Mode genau das ist, was du evaluierst.