Service Mesh

Was ist ein Service Mesh?

Ein Service Mesh verlagert übergreifende Netzwerkaufgaben aus dem Anwendungscode in die Plattform. Statt dass jedes Team Retries, Timeouts, Verschlüsselung und Metriken in der eigenen Sprache und im eigenen Framework umsetzt, leitet ein Mesh den gesamten Traffic zwischen Services über Proxies, die diese Regeln einheitlich anwenden. Bekannte Implementierungen sind Istio, Linkerd, Consul und Kuma, die meisten davon laufen auf Kubernetes.

Jedes Mesh besteht aus zwei Teilen. Die Data Plane bilden die Proxies, die den Traffic tatsächlich transportieren; Istio setzt auf Envoy, Linkerd auf einen eigenen schlanken Proxy in Rust. Die Control Plane verteilt Konfiguration, Zertifikate und Routing-Regeln an diese Proxies.

Sidecar- und Sidecarless-Architekturen

Modell	Funktionsweise	Abwägungen
Sidecar	In jeden Pod wird ein Proxy-Container injiziert, der ein- und ausgehenden Traffic abfängt	Feingranulare Layer-7-Kontrolle pro Workload; zusätzlicher CPU- und Speicherbedarf pro Pod; Neustarts bei Proxy-Upgrades
Ambient / Node-Proxy	Eine Komponente pro Node übernimmt Layer 4 und mTLS; optionale Layer-7-Proxies laufen nur bei Bedarf	Weniger Ressourcenbedarf und einfachere Upgrades; Layer-7-Funktionen brauchen zusätzliche Konfiguration
eBPF-gestützt	Kernel-Programme übernehmen Teile von Networking und Sichtbarkeit, teils kombiniert mit Proxies	Geringer Overhead; Layer-7-Sichtbarkeit hängt weiter von Proxy oder Protokoll-Parsing ab

Der Ambient-Modus von Istio, allgemein verfügbar seit Istio 1.24, teilt das Mesh in einen Zero-Trust-Tunnel pro Node und optionale Waypoint-Proxies. Cilium nutzt eBPF für seine Mesh-Funktionen. Die Wahl beeinflusst nicht nur die Kosten, sondern auch, welche Telemetrie Sie standardmäßig erhalten.

Was ein Mesh leistet

• Sicherheit: gegenseitiges TLS zwischen Services mit automatischer Zertifikatsrotation sowie identitätsbasierte Autorisierungsregeln.
• Traffic-Management: Retries, Timeouts, Circuit Breaking, Fault Injection und gewichtetes Routing, die Grundlage für Canary Deployments und Blue-Green-Umschaltungen.
• Einheitliche Telemetrie: Request-Zahlen, Fehlercodes und Latenz-Histogramme für jeden Hop, unabhängig von der Programmiersprache eines Service.

Service-Mesh-Observability: was Sie bekommen und was nicht

Weil jeder Request einen Proxy passiert, liefert ein Mesh konsistente Golden Signals für jedes Service-Paar. Istio stellt zum Beispiel Metriken wie istio_requests_total und istio_request_duration_milliseconds mit Labels für Quelle, Ziel und Antwortcode bereit. Damit ist ein Mesh eine hervorragende Quelle für Abhängigkeitskarten und für Alarme auf Fehlerquoten zwischen bestimmten Services.

Vollständige verteilte Traces liefert ein Mesh allein dagegen nicht. Die Proxies können pro Hop Spans erzeugen, wissen aber nicht, dass ein ausgehender Aufruf innerhalb der Anwendung zu einem eingehenden Request gehört. Die Anwendung muss Trace-Header wie W3C traceparent weiterreichen, die sogenannte Context Propagation. Ohne sie entstehen unverbundene Einzel-Spans. Zudem sieht ein Mesh nichts innerhalb des Prozesses: Langsames SQL, Lock-Konflikte oder heiße Schleifen bleiben ohne Instrumentierung oder Profiling unsichtbar.

Client- und Server-Sicht

Mesh-Proxies melden jeden Request von beiden Enden: Der Proxy der Quelle misst, was der Aufrufer erlebt hat, der Proxy des Ziels, was der aufgerufene Service geliefert hat. Der Vergleich lohnt sich. Zeigt die Client-Seite hohe Latenz, die Server-Seite aber nicht, geht die Zeit im Netzwerk, beim Verbindungsaufbau oder in Warteschlangen verloren, bevor der Request die Workload erreicht. Steigen beide Werte gemeinsam, liegt die Ursache im Ziel-Service selbst. Dort übernehmen Traces und Profile der Anwendung die weitere Analyse, etwa um langsame Datenbankaufrufe oder blockierte Threads zu finden.

Beispiel: eine gewichtete Canary-Route

Diese beispielhafte Istio-Konfiguration leitet 10 Prozent des Traffics auf Version 2 eines Service:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: checkout
spec:
  hosts: [checkout]
  http:
    - route:
        - destination: {host: checkout, subset: v1}
          weight: 90
        - destination: {host: checkout, subset: v2}
          weight: 10

Zusammen mit Mesh-Metriken nach Zielversion vergleichen Sie Fehlerquote und p99-Latenz von v1 und v2 direkt nebeneinander und entscheiden datenbasiert über Freigabe oder Rollback statt aus dem Bauch heraus. Die Subsets selbst definiert eine passende DestinationRule.

Best Practices und typische Stolperfallen

• Ein Mesh für einen konkreten Bedarf einführen, etwa durchgängiges mTLS oder Traffic Splitting, nicht nur für Metriken, denn der Betriebsaufwand ist real.
• Mesh-Telemetrie mit Anwendungsinstrumentierung kombinieren, etwa über OpenTelemetry, damit Traces durchgängig sind und Arbeit im Prozess einschließen.
• Retries mit Bedacht konfigurieren. Retries auf mehreren Ebenen vervielfachen die Last während eines Ausfalls und können einen Teilausfall zum Totalausfall machen.
• Proxy-Overhead beobachten. Messen Sie CPU, Speicher und zusätzliche Latenz der Proxies selbst, besonders bei Sidecars und hohen Request-Raten.
• Metrik-Kardinalität kontrollieren. Labels pro Pod und pro Pfad auf Mesh-Metriken können Millionen Zeitreihen erzeugen; aggregieren Sie, wo es geht.
• Sampling konsistent halten zwischen Proxies und Anwendungen, damit Mesh-Spans und Anwendungs-Spans desselben Traces gemeinsam erhalten bleiben.

Wie Obseria hilft

Obseria übernimmt Mesh-Metriken per Prometheus-Scraping oder OTLP und korreliert sie mit Traces und Logs aus OpenTelemetry und dem Obseria Agent. Obseria TopoGraph verbindet Mesh-Traffic mit der Infrastruktur-Topologie, sodass Sie sehen, welche Pods, Nodes und Services an einem fehlerhaften Aufrufpfad beteiligt sind. Details zu Kubernetes finden Sie unter Kubernetes Monitoring, durchgängige Request-Ansichten unter Distributed Tracing.