Service Mesh

Einfach erklärt

In einer Microservices-Architektur kommunizieren Dutzende oder Hunderte Services miteinander. Jede Verbindung braucht Retry-Logik, Timeouts, Verschlüsselung und Monitoring. Diese Logik in jeden Service einzeln einzubauen ist fehleranfällig und aufwändig. Ein Service Mesh löst das, indem es diese Querschnittsaufgaben aus dem Anwendungscode herausnimmt und in eine eigene Infrastrukturschicht verlagert.

Das Kernprinzip ist das Sidecar-Pattern: Neben jedem Service-Container läuft ein kleiner Proxy-Container (meist Envoy). Dieser Proxy fängt allen ein- und ausgehenden Traffic ab und kümmert sich um Verschlüsselung, Load Balancing, Retries und Telemetrie – ohne dass der Service-Code angepasst werden muss.

Data Plane vs. Control Plane:

Ebene	Aufgabe	Beispiel
Data Plane	Verarbeitet tatsächlichen Traffic	Envoy-Proxies
Control Plane	Konfiguriert und überwacht die Proxies	Istio Pilot

Technischer Deep Dive

Kernfunktionen

• mTLS: Gegenseitige TLS-Authentifizierung zwischen allen Services – kein Service kann sich als ein anderer ausgeben
• Circuit Breaking: Wenn ein Service überlastet ist, werden Anfragen automatisch abgewiesen statt zu warten
• Retries & Timeouts: Konfigurierbar pro Route, ohne Code-Änderungen
• Distributed Tracing: Jede Anfrage bekommt eine Trace-ID, die durch alle Services weitergegeben wird

Typische Istio-Konfiguration

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: llm-service
spec:
  http:
  - route:
    - destination:
        host: llm-service
        subset: v2
      weight: 10   # 10% Canary Traffic
    - destination:
        host: llm-service
        subset: v1
      weight: 90