Service-Mesh-Architekturdiagramm: Data Plane, Control Plane und mTLS

Sobald ein System Dutzende Services hat, taucht in jedem davon derselbe Netzwerkcode auf: Retries, Timeouts, TLS zwischen Services, Metriken pro Aufruf, Traffic Splitting für Releases. Ein Service Mesh holt diesen Code aus den Services heraus und verlegt ihn in den Netzwerkpfad, wo ein Team ihn für alle konfigurieren kann.

Dieser Artikel erklärt, wie ein Mesh aufgebaut ist, was Control Plane und Data Plane jeweils tun, wie automatisches mTLS funktioniert und welche Kosten ein Mesh für viele Teams zur falschen Wahl machen. Das Diagramm zeigt das klassische Sidecar-Design.

Data Plane und Control Plane

Die Data Plane ist eine Gruppe von Proxys, die im Pfad jeder Anfrage zwischen Services sitzen. Im Sidecar-Modell bekommt jeder Pod seinen eigenen Proxy-Container. Die App spricht einfaches HTTP mit ihrem lokalen Proxy; der Proxy erledigt alles auf der Leitung: Verschlüsselung, Retries, Load Balancing, Metriken. Istio nutzt Envoy als Sidecar; Linkerd nutzt einen eigenen, eigens dafür gebauten Proxy, geschrieben in Rust.

Die Control Plane berührt nie den Anfrage-Traffic. Sie beobachtet Services und Endpunkte im Cluster, übersetzt deine Policies in Proxy-Konfiguration, verteilt diese Konfiguration an jeden Proxy und stellt die Zertifikate aus, mit denen sich die Proxys ausweisen. In Istio ist das istiod; siehe die Architekturseite von Istio. Die Architekturreferenz von Linkerd beschreibt die entsprechenden Teile.

Automatisches mTLS und Workload-Identität

Mutual TLS zwischen jedem Paar von Services ist die Funktion, die die meisten Teams überzeugt. Jeder Proxy bekommt von der Control Plane ein kurzlebiges Zertifikat, das den Workload benennt, typischerweise als SPIFFE-ID, abgeleitet aus Kubernetes-Namespace und Service Account, etwa spiffe://cluster.local/ns/shop/sa/orders. Wenn sich zwei Proxys verbinden, legen beide Zertifikate vor, beide prüfen sie, und die Verbindung ist verschlüsselt.

Zwei Folgen sind wichtig:

• Identität ersetzt Netzwerkposition. Eine Policy kann sagen „Payments akzeptiert nur Aufrufe vom Orders-Service-Account“, was stärker ist als „aus diesem Subnetz“.
• Rotation passiert automatisch. Zertifikate leben ein paar Stunden, und niemand muss für ihre Erneuerung ein Ticket aufmachen.

Schalte den Strict Mode ein, sobald alles im Mesh ist, damit Klartextverbindungen abgelehnt statt stillschweigend akzeptiert werden.

Eine Anfrage durch das Mesh

Folge einem Aufruf von Orders zu Payments:

1. Die Orders-App schickt eine einfache HTTP-Anfrage an den Service-Namen von Payments. Eine Traffic-Umleitung schickt sie an den lokalen Sidecar statt ins Netzwerk.
2. Der Orders-Sidecar sucht gesunde Payments-Endpunkte aus der Konfiguration, die die Control Plane verteilt hat, wählt per Load-Balancing-Algorithmus einen aus und wendet den Timeout für diese Route an.
3. Er öffnet eine mTLS-Verbindung zum Payments-Sidecar oder nutzt eine bestehende wieder und legt dabei das Orders-Zertifikat vor.
4. Der Payments-Sidecar prüft das Zertifikat, prüft die Authorization Policy (darf Orders Payments aufrufen?) und leitet die Anfrage über localhost an die Payments-App weiter.
5. Beide Sidecars zeichnen die Anfrage, ihren Status und ihre Latenz auf. Schlägt der Aufruf mit einem wiederholbaren Status fehl, kann der Orders-Sidecar innerhalb seines Budgets einen Retry machen.

Keine der beiden Apps weiß, dass all das passiert ist. Das ist der Sinn und zugleich das Risiko: Verhalten, das man im Code nicht sieht, muss an anderer Stelle sichtbar sein, etwa im Diagramm.

Ein Mesh einführen

Führe es schrittweise ein. Installiere die Control Plane, nimm die Services Namespace für Namespace im Permissive Mode auf, damit Klartext weiter funktioniert, beobachte die Metriken und stelle dann jeden Namespace auf strict mTLS um. Authorization Policies kommen zuletzt, beginnend mit den Services, die sensible Daten halten.

Traffic-Policies

Weil jeder Aufruf einen Proxy passiert, kann das Mesh überall dieselben Regeln durchsetzen:

• Timeouts und Retries, mit Budgets, damit sich Retries während eines Ausfalls nicht vervielfachen.
• Circuit Breaking und Outlier Detection: kein Traffic mehr an Instanzen, die immer wieder scheitern.
• Traffic Splitting nach Gewicht oder Header; so werden Canary-Releases in einem Mesh umgesetzt.
• Fault Injection zum Testen: Verzögerungen oder Fehler für einen Prozentsatz der Aufrufe.

Vorsicht mit Retries an zwei Stellen. Wenn die App einen Retry macht und der Sidecar auch, wird aus einem fehlschlagenden Aufruf eine ganze Reihe. Leg einen einzigen Verantwortlichen für Retries fest und schreib ihn auf.

Observability (fast) gratis

Proxys melden Anfragezahlen, Fehlerraten und Latenz pro Quelle und Ziel, ohne dass sich die Apps ändern. Sie können auch Trace-Spans starten und weitergeben, aber die App muss die Trace-Header weiterhin von eingehenden an ausgehende Anfragen durchreichen, sonst reißen die Traces an jedem Service ab.

Sidecars vs. Ambient Mode

Sidecars haben echte Kosten: Ein Proxy in jedem Pod braucht CPU und Speicher, fügt jedem Hop Latenz hinzu und macht Pod-Start und Upgrades aufwendiger. Der Ambient Mode von Istio entfernt den Sidecar pro Pod. Ein Proxy pro Node namens ztunnel übernimmt mTLS und Layer-4-Policies, und optionale Waypoint-Proxys übernehmen Layer-7-Funktionen nur für die Services, die sie brauchen. Der Preis ist ein anderes Betriebsmodell und weniger Jahre Produktionserfahrung als bei Sidecars.

Das Architekturdiagramm

So liest du es:

• Links: Das Ingress-Gateway nimmt Traffic von außen an und öffnet eine mTLS-Verbindung zum Sidecar im Orders-Pod.
• Mitte: In jedem Pod leitet der Sidecar über localhost an die App weiter. Der Orders-Sidecar ruft die Sidecars von Payments und Inventory per mTLS auf; die Apps fassen nie Zertifikate an.
• Unten: Die Control Plane verteilt Konfiguration und Zertifikate an die Proxys (gestrichelte Kanten). Sie liegt nicht im Anfragepfad.
• Rechts: Die Sidecars melden Metriken und Traces (gepunktet). Der Markdown-Block zeigt eine Policy für Payments: wer es aufrufen darf, Timeouts und Retries, Outlier Ejection und strict mTLS.

Wann man kein Mesh braucht

• Eine Handvoll Services oder ein Monolith mit ein paar Satelliten. Eine Bibliothek oder ein API-Gateway deckt den Bedarf zu einem Bruchteil der Kosten.
• Kein Team, das es verantwortet. Ein Mesh ist Infrastruktur, die Upgrades, Debugging-Know-how und On-Call-Wissen braucht.
• Wenn das Hauptziel nur Verschlüsselung ist. Viele Clouds und CNI-Plugins können Pod-Traffic ohne komplettes Mesh verschlüsseln.

Was in ein Mesh-Diagramm gehört

• Beide Planes, klar getrennt, die Control Plane außerhalb des Anfragepfads.
• Wo TLS beginnt und endet: von Proxy zu Proxy, und einfaches HTTP auf localhost.
• Identitäten, zumindest für Services mit Zugriffs-Policies.
• Policies, die das Verhalten ändern: Timeouts, Retries, Circuit Breaking.

Das Kubernetes-Architekturdiagramm zeigt den Cluster, in dem das Mesh läuft, das Zero-Trust-Architekturdiagramm erklärt, warum identitätsbasierte Policies wichtig sind, und das Microservices-Architekturdiagramm behandelt die Services selbst.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem C4-Modell-Pack einen Container für das Ingress-Gateway hinzu.
3. Füge für jeden Pod einen Rahmen aus dem Basis-Pack hinzu, darin eine Komponente für den Sidecar und einen Container für die App.
4. Füge einen Container für die Control Plane und Metriken aus dem DevOps-Pack hinzu.
5. Zeichne mTLS-Kanten zwischen den Sidecars, gestrichelte Kanten von der Control Plane und gepunktete Telemetrie-Kanten, und füge einen Markdown-Block aus dem Basis-Pack mit der Policy eines Services hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen einem Service Mesh und einem API-Gateway? Ein API-Gateway steuert den Traffic, der von außen ins System kommt. Ein Service Mesh steuert den Traffic zwischen den Services innerhalb des Systems. Viele Systeme nutzen beides.

Fügt ein Service Mesh Latenz hinzu? Ja, jeder Proxy-Hop fügt ein wenig hinzu, meist deutlich unter ein paar Millisekunden pro Hop, dazu CPU und Speicher für die Proxys. Miss es für deinen Traffic.

Muss ich für ein Mesh meinen Anwendungscode ändern? Meistens nicht. Die Ausnahme ist Tracing: Apps müssen Trace-Header weiterreichen, damit sich Traces über Services hinweg verbinden.

Was ist der Ambient Mode? Eine Istio-Data-Plane ohne Sidecars: Ein Proxy pro Node übernimmt mTLS und Layer 4, und optionale Waypoint-Proxys übernehmen Layer-7-Funktionen, wo sie gebraucht werden.

Wer sollte das Mesh verantworten? Ein Platform-Team. Service-Teams nutzen seine Funktionen über Policies, aber jemand muss es upgraden, überwachen und debuggen.

Kostenlos starten — ein Seat, keine Kreditkarte.