Sidecar-Container
Ein Hilfscontainer, der im selben Pod wie die Hauptanwendung läuft und sie um Funktionalität erweitert — Logging, Proxy, Sicherheit —, ohne dass die Anwendung selbst geändert werden muss. Das zentrale Muster hinter Service Mesh.
Mechanik: Container im selben Pod teilen sich das Netzwerk (dieselbe IP, localhost) und können Volumes gemeinsam nutzen, wodurch ein Sidecar den Verkehr der Hauptanwendung abfangen oder deren Logs transparent mitlesen kann. Klassische Anwendungsfälle: ein Envoy-Proxy, der den gesamten ein- und ausgehenden Verkehr übernimmt (Service Mesh wie Istio oder Linkerd), ein Log-Shipper, der Logs weiterleitet, oder ein Container, der Geheimnisse besorgt. Nutzen: Trennung der Zuständigkeiten — die Anwendung konzentriert sich auf ihre Logik, der Sidecar übernimmt Querschnittsaufgaben, beide lassen sich unabhängig aktualisieren. Abwägung: mehr Container bedeuten mehr Ressourcen-Overhead pro Pod, was "sidecar-lose" Meshes (eBPF) und Kubernetes' eingebaute Sidecar-Unterstützung (als Init-Container mit restartPolicy) hervorgebracht hat. Ein Grundmuster cloud-nativer Architektur. Hängt zusammen mit Service-Mesh-Sidecar und Init-Container.