Pexon Consulting | 8 Min. Lesezeit | 25.03.2026
TL;DR
Ein Service Mesh teilt sich in zwei Schichten: Die Control Plane konfiguriert Regeln für Routing, Security und Observability. Die Data Plane setzt diese Regeln auf jedem einzelnen Request um — über Sidecar-Proxies wie Envoy. Seit Istio 1.24 gibt es mit Ambient Mesh eine dritte Option, die Sidecars überflüssig macht und bis zu 90 % Ressourcen spart. Dieser Artikel zeigt, wie beide Schichten zusammenspielen und wann sich welcher Ansatz lohnt.
Warum Service Mesh — und warum jetzt?
Wer 20 Microservices auf Kubernetes betreibt, hat kein Routing-Problem. Wer 200 betreibt, hat ein Governance-Problem. Genau hier setzt ein Service Mesh an.
Die CNCF Annual Survey 2024 zeigt: 42 % der befragten Unternehmen nutzen ein Service Mesh in Produktion. Das ist ein Rückgang von 50 % im Vorjahr — nicht weil die Technologie schlecht ist, sondern weil der Betrieb mit Sidecar-Proxies operativ aufwendig war. Ambient Mesh ändert das gerade grundlegend.
Für Unternehmen mit 300 bis 3.000 Mitarbeitern und wachsender Microservice-Landschaft stellt sich nicht mehr die Frage ob Service Mesh, sondern wie. Die Antwort beginnt beim Verständnis der zwei Schichten.
Control Plane: Das Gehirn des Mesh
Die Control Plane berührt keinen einzigen Request. Sie konfiguriert ausschließlich, wie Requests verarbeitet werden sollen. Bei Istio heißt diese Komponente istiod — ein einzelnes Binary, das als Deployment im Namespace istio-system läuft.
Was istiod konkret tut:
- Pilot überwacht den Kubernetes API Server auf Änderungen an VirtualServices, DestinationRules und Kubernetes-Ressourcen (Services, Endpoints, Pods). Bei Änderungen übersetzt Pilot die Konfiguration in Envoy-spezifische Regeln und pusht sie per xDS-Protokoll an alle betroffenen Proxies.
- Citadel (integriert in istiod) generiert und rotiert TLS-Zertifikate für mTLS zwischen allen Services — automatisch, ohne manuelles Zertifikatsmanagement.
- Galley validiert Konfigurationen, bevor sie an die Proxies gehen.
Das Entscheidende: Die Control Plane ist deklarativ. Sie definieren den Soll-Zustand, istiod sorgt dafür, dass die Data Plane ihn umsetzt.
So sieht eine typische Traffic-Regel aus:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: checkout-routing
spec:
hosts:
- checkout-service
http:
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: checkout-service
subset: v2
- route:
- destination:
host: checkout-service
subset: v1Diese Regel leitet Requests mit dem Header x-canary: true an Version 2 des Checkout-Service — alle anderen an Version 1. Die Control Plane pusht diese Konfiguration an jeden Envoy-Proxy im Mesh. Der Entwickler des Checkout-Service muss davon nichts wissen.
Unsere Empfehlung: Halten Sie die Control Plane so schlank wie möglich. Ein istiod-Pod mit 1 vCPU und 2 GB RAM reicht für Cluster mit bis zu 500 Services. Erst darüber hinaus lohnt sich ein horizontales Scale-out.
Data Plane: Wo die Arbeit passiert
Die Data Plane berührt jeden einzelnen Request. Sie besteht aus Envoy-Proxies, die als Sidecar neben jedem Pod laufen. Diese Proxies übernehmen:
- Load Balancing — Round Robin, Least Connections oder Consistent Hashing
- Retry-Logik und Timeouts — ohne eine Zeile Code in Ihrem Service
- mTLS-Verschlüsselung — jeder Request ist verschlüsselt, jede Identität verifiziert
- Telemetrie — Latenz, Error Rates und Request Volume pro Service-Paar
Was das in Zahlen bedeutet: Bei 1.000 Requests pro Sekunde über 16 Verbindungen fügt Istio im p50 etwa 3 ms und im p99 etwa 10 ms Latenz hinzu. Ein einzelner Sidecar verbraucht dabei rund 0,2 vCPU und 60 MB RAM. Für die meisten Business-Applikationen ist das vernachlässigbar — für Echtzeit-Trading-Systeme nicht.
Die Proxy-Konfiguration lässt sich jederzeit prüfen:
# Aktive Envoy-Konfiguration eines Pods anzeigen
istioctl proxy-config routes deploy/checkout-service -n production
# Synchronisierungsstatus aller Proxies prüfen
istioctl proxy-status
# Detaillierte Cluster-Konfiguration eines Sidecar
kubectl exec deploy/checkout-service -c istio-proxy
-- curl -s localhost:15000/clusters | head -20Wenn istioctl proxy-status bei einem Pod STALE anzeigt, hat die Control Plane die Konfiguration nicht erfolgreich ausgeliefert. Das ist der häufigste Grund für unerklärliche 503-Fehler in der Praxis.
Ambient Mesh: Die Sidecar-lose Zukunft
Seit Istio 1.24 ist Ambient Mesh stabil und produktionsreif. Die Idee: Statt in jedem Pod einen Sidecar-Proxy zu betreiben, übernimmt ein ztunnel (Zero Trust Tunnel) als DaemonSet auf jedem Node die Layer-4-Aufgaben — mTLS, TCP-Routing und Basis-Telemetrie. Für Layer-7-Funktionen wie HTTP-Routing oder Retries kommen optionale Waypoint Proxies pro Namespace hinzu.
Der Vorteil ist drastisch: In manchen Szenarien spart Ambient Mesh über 90 % der Ressourcen gegenüber dem Sidecar-Modell, weil Layer-7-Processing nur dort stattfindet, wo es tatsächlich gebraucht wird.
Unsere klare Position dazu: Für neue Projekte auf Kubernetes empfehlen wir Ambient Mesh als Standard. Die Sidecar-Architektur hat ihren Dienst getan, aber der operative Overhead — Sidecar Injection, Resource Requests pro Pod, Rolling Restarts bei Proxy-Updates — rechtfertigt sich für die meisten Workloads nicht mehr.
Wer bestehende Sidecar-Deployments migrieren will: Istio unterstützt den gemischten Betrieb. Sie können Namespace für Namespace umstellen. Das Istio-Roadmap-Dokument 2025-2026 bestätigt, dass Sidecar-Support langfristig erhalten bleibt — Ambient ist eine Option, kein Zwang.
Service Mesh in der Praxis: Worauf es wirklich ankommt
Nach über 30 Kubernetes-Projekten bei Kunden zwischen 300 und 5.000 Mitarbeitern sehen wir immer wieder dieselben Muster. Hier unsere verdichteten Empfehlungen:
Starten Sie mit mTLS und Observability, nicht mit Traffic Management. Die meisten Teams installieren Istio für Canary Deployments — und nutzen dann 6 Monate lang nur mTLS und Prometheus-Metriken. Das ist genau richtig. Die Sicherheitsgewinne allein rechtfertigen ein Service Mesh.
Wählen Sie Ihr Mesh nach Teamgröße, nicht nach Feature-Liste. Istio dominiert mit rund 47 % Marktanteil den Enterprise-Bereich. Linkerd ist schneller und einfacher, aber weniger flexibel. Cilium arbeitet auf Kernel-Ebene und eignet sich für Hochperformanz-Szenarien. Für die meisten Mittelständler auf Azure AKS empfehlen wir Istio — Microsoft bietet es als managed Add-on für AKS an.
Investieren Sie in Platform Engineering statt in Mesh-Konfiguration. Ein Service Mesh ist Infrastruktur, kein Entwickler-Tool. Wenn Ihre Entwickler VirtualServices schreiben, läuft etwas falsch. Bauen Sie Abstractions — Golden Paths, Helm Charts, Crossplane Compositions — damit Teams die Mesh-Funktionen nutzen, ohne die Mesh-Konfiguration zu kennen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Control Plane und Data Plane im Service Mesh?
Die Control Plane ist das Steuerungszentrum: Sie definiert Routing-Regeln, Security-Policies und Observability-Konfigurationen. Die Data Plane führt diese Regeln aus — sie besteht aus Proxies (typischerweise Envoy), die jeden einzelnen Netzwerk-Request zwischen Microservices verarbeiten. Kurz: Die Control Plane sagt was passieren soll, die Data Plane tut es.
Brauche ich ein Service Mesh für mein Kubernetes-Cluster?
Ab etwa 15-20 Microservices wird ein Service Mesh sinnvoll, weil manuelles mTLS-Management, Retry-Logik und Observability in jedem Service einzeln zu implementieren nicht skaliert. Unter 10 Services reichen Kubernetes-native Mechanismen wie Network Policies und Ingress Controller in der Regel aus.
Wie viel Latenz fügt ein Service Mesh hinzu?
Istio fügt im Normalfall 3 ms (p50) bis 10 ms (p99) pro Request bei 1.000 RPS hinzu. Mit Ambient Mesh und reinem L4-Processing (mTLS ohne HTTP-Routing) sinkt der Overhead deutlich unter 1 ms. Für die meisten Web-Applikationen und APIs ist das irrelevant.
Was ist Ambient Mesh und ersetzt es Sidecars?
Ambient Mesh ist Istios neuer Architekturansatz seit Version 1.24. Statt einem Sidecar-Proxy pro Pod läuft ein leichtgewichtiger ztunnel-Proxy pro Node. Layer-7-Funktionen werden nur bei Bedarf über Waypoint Proxies bereitgestellt. Ambient ersetzt Sidecars optional — beide Modi können parallel im selben Cluster betrieben werden.
Welches Service Mesh eignet sich für Azure AKS?
Für Azure AKS empfehlen wir Istio, da Microsoft es als managed Add-on direkt in AKS integriert hat. Das vereinfacht Betrieb und Updates erheblich. Alternativ bietet Cilium auf AKS starke eBPF-basierte Networking-Features. Linkerd eignet sich gut für kleinere Cluster mit Fokus auf Einfachheit.
Nächste Schritte
Ein Service Mesh richtig aufsetzen heißt: Control Plane schlank halten, Data Plane verstehen, Ambient Mesh evaluieren. Das klingt überschaubar — in der Praxis scheitert es an fehlender Kubernetes-Erfahrung, nicht an der Technologie.
Wenn Sie Ihre Microservice-Architektur absichern und skalierbar machen wollen, sprechen Sie mit unserem Kubernetes-Team. Wir beraten von der Architektur-Entscheidung bis zum Produktivbetrieb — herstellerunabhängig und hands-on.
Mehr zu unserer Arbeit mit Cloud-nativen Architekturen finden Sie in unseren Case Studies und im Überblick zu unserem Azure Consulting. Für einen strukturierten Einstieg bieten wir auch Workshops an, die Ihr Team in zwei Tagen auf Produktionsniveau bringen.
