Service Mesh

KAPITEL 10 · ENTERPRISE IT

Service Mesh

Die Infrastrukturschicht für Microservices-Kommunikation – automatische mTLS-Verschlüsselung, intelligentes Traffic-Management, Resilienz-Patterns und vollständige Observability ohne Code-Änderungen.

mTLS Security Traffic Management Observability Resilienz

Was ist ein Service Mesh?

Definition

Ein Service Mesh ist eine dedizierte Infrastrukturschicht, die die Kommunikation zwischen Microservices in einer verteilten Anwendung verwaltet. Es fungiert als transparenter Proxy, der Sicherheit, Traffic-Steuerung und Observability bereitstellt – ohne dass Anwendungscode geändert werden muss.

Im Enterprise-Umfeld löst ein Service Mesh kritische Herausforderungen: Automatische Verschlüsselung aller Service-zu-Service-Kommunikation (mTLS), Canary Deployments und Blue-Green-Deployments ohne Downtime, Circuit Breaker und Retry-Logik für Resilienz sowie verteiltes Tracing und Metriken für vollständige Transparenz.

Das Grundprinzip: Jeder Microservice erhält einen Sidecar-Proxy (z.B. Envoy), der alle ein- und ausgehenden Anfragen abfängt. Die Control Plane steuert zentral Policies, Zertifikate und Routing-Regeln. Die Anwendung bleibt unverändert.

Wann brauche ich ein Service Mesh?

  • Ja: Bei 10+ Microservices mit komplexer Abhängigkeitsstruktur
  • Ja: Wenn Zero Trust Security (mTLS überall) erforderlich ist
  • Ja: Für fortgeschrittene Deployment-Strategien (Canary, Blue-Green)
  • Ja: Wenn verteiltes Tracing und zentrale Observability fehlen
  • Nein: Bei Monolithen oder wenigen Services (< 5)
  • Nein: Wenn das Team keine Kubernetes-/Infrastruktur-Expertise hat

Architektur: Data Plane vs. Control Plane

Jedes Service Mesh besteht aus zwei fundamentalen Ebenen, die strikt getrennt sind.

Service Mesh Architektur

Data Plane

  • Sidecar-Proxies (Envoy, Linkerd-proxy)
  • Pro Service-Instanz ein Proxy
  • Fängt gesamten Traffic ab
  • Führt mTLS-Handshake durch
  • Sammelt Metriken & Traces
  • Wendet Routing-Regeln an

Control Plane

  • Zentraler Controller (Istiod, Linkerd-controller)
  • Verteilt Konfiguration an Proxies
  • Verwaltet CA & Zertifikate
  • Service Discovery
  • Policy Enforcement Point
  • Aggregiert Telemetrie-Daten

Warum diese Trennung?

Die Data Plane ist performance-kritisch und läuft nah am Service. Die Control Plane ist zentral und kann unabhängig skaliert/gewartet werden. Fällt die Control Plane aus, arbeitet die Data Plane mit der letzten bekannten Konfiguration weiter – kein Totalausfall.

Service Mesh Lösungen im Vergleich

Feature Istio Linkerd Consul Connect Cilium
Sidecar-Proxy Envoy linkerd-proxy (micro) Envoy eBPF (sidecarless)
Ressourcenverbrauch Mittel-Hoch Niedrig Mittel Sehr niedrig
Lernkurve Steil Flach Mittel Mittel
Multi-Cluster ✅ Native ✅ Native ✅ Native ✅ Native
mTLS ✅ Automatisch ✅ Automatisch ✅ Automatisch ✅ Transparent
Traffic-Splitting ✅ Erweitert ✅ Basis ✅ Basis ✅ Erweitert
Gateway-API Support ✅ Vollständig ✅ Teilweise ⚠️ In Arbeit ✅ Vollständig
Best For Große Enterprise-Plattformen Einstieg, Performance HashiCorp-Stack eBPF/CNI-Integration

Kernfunktionen eines Service Mesh

Sicherheit (Zero Trust)

  • mTLS: Automatische gegenseitige TLS-Verschlüsselung zwischen allen Services
  • Zertifikats-Rotation: Automatische Erneuerung kurzlebiger Zertifikate
  • Authorization Policies: Feingranulare Zugriffskontrolle (wer darf was aufrufen)
  • Identity: SPIFFE/SPIRE-basierte Service-Identität statt IP-Adressen

Traffic Management

  • Canary Deployments: Graduelles Traffic-Shifting (5% → 25% → 100%)
  • Blue-Green: Sofortiges Umschalten zwischen Versionen
  • A/B Testing: Header-basiertes Routing zu verschiedenen Versionen
  • Mirroring: Traffic duplizieren zu Test-Umgebungen

Observability

  • Distributed Tracing: Automatische Trace-Propagation (OpenTelemetry)
  • Goldene Metriken: Latenz, Traffic, Fehlerrate, Sättigung pro Service
  • Access Logs: Strukturierte Logs aller Requests
  • Service Topology: Automatische Abhängigkeitskarte

Resilienz

  • Retries: Automatische Wiederholung fehlgeschlagener Requests
  • Timeouts: Verhindern von hängenden Anfragen
  • Circuit Breaker: Isolieren fehlerhafter Services
  • Rate Limiting: Schutz vor Überlastung

Enterprise Use Cases

Microservices bei Scale

Ab 10-20 Services wird manuelle Kommunikation unmanagebar. Das Mesh übernimmt Service Discovery, Load Balancing und Fehlerbehandlung zentral.

Vorteil: Entwickler fokussieren auf Business-Logik, nicht auf Netzwerk-Code

Zero Trust Security

Compliance-Anforderungen (PCI-DSS, HIPAA, ISO 27001) verlangen Verschlüsselung aller internen Kommunikation. mTLS per Default.

Vorteil: Audit-fähige Verschlüsselung ohne App-Refactoring

Progressive Delivery

Risikominimierung bei Releases: Neue Version erhält zunächst 5% Traffic. Metriken werden automatisch ausgewertet, Rollback bei Anomalien.

Vorteil: Blast Radius minimieren, MTTR reduzieren

Multi-Cluster / Multi-Cloud

Einheitliche Policies über Cluster-, Region- und Cloud-Grenzen hinweg. Zentrale Governance bei dezentraler Ausführung.

Vorteil: Konsistente Security & Observability überall

FAQ – Häufige Fragen & Antworten

Häufige Fragen zu Service Mesh

Was ist der Unterschied zwischen einem API Gateway und einem Service Mesh?

Beide ergänzen sich, haben aber unterschiedliche Aufgaben:

  • API Gateway: Nord-Süd-Traffic (extern → intern). Authentifizierung externer Clients, Rate Limiting, Request Transformation.
  • Service Mesh: Ost-West-Traffic (intern ↔ intern). mTLS zwischen Services, interne Resilienz, Service-to-Service-Observability.

In modernen Architekturen werden beide kombiniert. Viele Mesh-Lösungen (Istio, Cilium) bieten mittlerweile auch Gateway-Funktionalität via Gateway API.

Verursacht ein Service Mesh signifikanten Performance-Overhead?

Der Overhead hängt stark von der Implementierung ab:

  • Istio (Envoy): ~2-5 ms zusätzliche Latenz pro Hop, ~50-100 MB RAM pro Sidecar
  • Linkerd: ~1-2 ms Latenz, ~10-20 MB RAM (optimierter Rust-Proxy)
  • Cilium (eBPF): Near-zero Overhead, kein Sidecar nötig

Für die meisten Enterprise-Anwendungen ist der Overhead vernachlässigbar gegenüber dem Nutzen. Bei extrem latenzsensiblen Systemen eBPF-basierte Lösungen evaluieren.

Brauche ich wirklich ein Service Mesh oder reicht Kubernetes allein?

Kubernetes bietet bereits Service Discovery, Load Balancing und grundlegende Netzwerkpolicies. Ein Service Mesh ergänzt:

  • mTLS: K8s NetworkPolicies filtern nur, verschlüsseln nicht
  • Advanced Traffic: Canary, Mirroring, Fault Injection
  • Application-Level Observability: HTTP-Metriken, nicht nur TCP/UDP
  • Retry/Circuit Breaker: Ohne Code-Änderung

Faustregel: Unter 10 Services → K8s reicht. 10-50 Services → Linkerd. 50+ Services oder strenge Compliance → Istio/Cilium.

Wie funktioniert mTLS im Service Mesh genau?

Der Prozess ist vollständig automatisiert:

  1. Die Control Plane fungiert als interne CA und stellt kurzlebige Zertifikate aus (typisch 24h Gültigkeit)
  2. Jeder Sidecar erhält beim Start ein Zertifikat + Private Key
  3. Bei jeder Verbindung führen beide Sidecars einen gegenseitigen TLS-Handshake durch
  4. Beide Seiten validieren das Zertifikat des Gegenübers gegen die Mesh-CA
  5. Zertifikate werden automatisch rotiert vor Ablauf

Die Anwendung selbst sieht nur Klartext-Traffic zum lokalen Sidecar. Die Verschlüsselung ist transparent.

Was ist die Gateway API und warum ist sie wichtig?

Die Gateway API ist der offizielle Kubernetes-Standard für Ingress/Gateway-Konfiguration (Nachfolger von Ingress Resources).

  • Vendor-neutral: Gleiche YAML-Manifeste für Istio, Cilium, NGINX, Traefik, etc.
  • Erweiterbar: Role-based Configuration (Platform Admin vs. App Developer)
  • Zukunftssicher: Wird von allen großen Mesh- und Gateway-Projekten unterstützt

Empfehlung: Neue Projekte direkt mit Gateway API starten, nicht mit proprietären CRDs.

Sidecar vs. Sidecarless (eBPF) – was soll ich wählen?

Sidecar (Envoy/Linkerd):

  • ✅ Bewährt, volle Feature-Parität
  • ✅ Funktioniert auf jedem CNI
  • ❌ Ressourcen-Overhead (RAM/CPU pro Pod)
  • ❌ Zusätzliche Latenz-Hops

Sidecarless (Cilium/eBPF):

  • ✅ Near-zero Overhead
  • ✅ Kernel-Level Performance
  • ❌ Benötigt modernen Linux-Kernel (≥ 5.x)
  • ❌ Manche Advanced-Features noch in Entwicklung

Empfehlung: Greenfield mit modernem Kernel → Cilium. Bestands-Cluster oder maximale Kompatibilität → Istio/Linkerd.

Zusammenfassung

Die wichtigsten Punkte

  • Service Mesh: Infrastrukturschicht für sichere, beobachtbare und resiliente Microservices-Kommunikation
  • Zwei Ebenen: Data Plane (Sidecar-Proxies) + Control Plane (zentrale Steuerung)
  • Kernfunktionen: mTLS, Traffic Management, Observability, Resilienz
  • Lösungen: Istio (Enterprise-Standard), Linkerd (leichtgewichtig), Cilium (eBPF), Consul Connect
  • Wann einsetzen: 10+ Services, Zero Trust Compliance, Progressive Delivery
  • Gateway API: Zukunftsstandard für vendor-neutrale Konfiguration
  • Trend: Sidecarless/eBPF-Architekturen gewinnen an Bedeutung

Weiterführende Themen

Kubernetes Enterprise

Cluster-Management, RBAC, Network Policies und Production Readiness.

Zu Kubernetes Enterprise
Zero Trust

Zero Trust Architektur, mTLS, Identity-Aware Proxies und Mikrosegmentierung.

Zu Zero Trust
Observability

Metrics, Logs, Traces, OpenTelemetry und SLO-basiertes Monitoring.

Zu Observability
API Gateway Management

API Gateways, Gateway API, Rate Limiting und externe Traffic-Steuerung.

Zu API Gateway