Service-Mesh-Sidecar
Der Proxy (meist Envoy), der als Sidecar neben jedem Dienst in einem Service Mesh injiziert wird und dessen gesamten Netzwerkverkehr abfängt. Weil er zwischen den Diensten sitzt, liefert er mTLS, Traffic-Steuerung, Retries und Observability — ohne dass der Anwendungscode sich ändert.
Mechanik: Das Mesh (Istio, Linkerd) injiziert automatisch einen Proxy-Sidecar in jeden Pod; sämtlicher ein- und ausgehender Verkehr läuft durch ihn hindurch. Die Proxys (die Data-Plane) werden zentral von einer Control-Plane gesteuert. Was es „gratis" dazu gibt: mTLS (automatische gegenseitige Verschlüsselung zwischen Diensten), Traffic-Steuerung (Canary-Releases, gewichtetes Routing, Fault Injection), Resilienz (Retries, Timeouts, Circuit Breaking) und Observability (Metriken, Traces, Logs für sämtlichen Dienst-zu-Dienst-Verkehr). Der Haken: ein Proxy pro Pod bedeutet Ressourcen-Overhead, zusätzliche Latenz und operative Komplexität — deshalb gewinnen „sidecar-lose" Meshes (Istio Ambient, Cilium) an Boden, die die Funktion auf den Node beziehungsweise eBPF verlagern. Das vorherrschende Muster für Dienst-zu-Dienst-Kommunikation in großen Clustern. Verwandt mit Sidecar-Container und Network Policy.