Service Mesh: Kommunikation zwischen Diensten steuern

Kurz: Eine Infrastrukturschicht, die den Netzwerkverkehr zwischen Microservices übernimmt, absichert und beobachtbar macht, ohne dass jeder Dienst das selbst programmieren muss.

Genauer: In einem System mit vielen Diensten brauchen alle dieselben Dinge: verschlüsselte Verbindungen, Wiederholungsversuche, Zeitlimits, Lastverteilung, Metriken. Ein Service Mesh (zum Beispiel Istio oder Linkerd) verlagert das aus dem Anwendungscode in kleine Hilfs-Proxys, die neben jedem Dienst laufen („Sidecar“).

Im Detail

Aufbau

• Data Plane: die Proxys (häufig Envoy) neben jedem Dienst. Aller Verkehr läuft durch sie.
• Control Plane: zentrale Steuerung, die Regeln und Zertifikate an die Proxys verteilt. Der Dienst spricht scheinbar normal mit http://bestellung, der Sidecar fängt die Verbindung ab und erledigt den Rest.

Was das Mesh übernimmt

• mTLS: gegenseitig authentifizierte, verschlüsselte Verbindungen zwischen Diensten, mit automatisch erneuerten Zertifikaten.
• Traffic-Steuerung: 5 % des Verkehrs an eine neue Version (Canary), Spiegelung von Verkehr zum Testen.
• Resilienz: Wiederholungen, Zeitlimits, Circuit Breaker.
• Beobachtbarkeit: Metriken, Traces und Zugriffslogs ohne Code-Änderung.
• Richtlinien: Welcher Dienst darf mit welchem sprechen.

Kosten

Ein Mesh erhöht die Komplexität: zusätzliche Proxys brauchen Speicher und Rechenzeit, fügen Latenz hinzu und müssen betrieben und aktualisiert werden. Neuere Ansätze wie Istio Ambient oder eBPF-basierte Lösungen (Cilium) kommen ohne Sidecar je Pod aus.

Wann es sich lohnt

Bei wenigen Diensten genügen Bibliotheken und ein Ingress. Ein Service Mesh lohnt sich bei vielen Diensten, mehreren Teams, hohen Sicherheitsanforderungen (Zero Trust) und dem Wunsch nach einheitlicher Beobachtbarkeit.

Siehe auch: Microservices, Circuit Breaker und Backpressure, Observability, Container-Sicherheit