Sidecar-Container sind zusätzliche Container in einem Kubernetes-Pod, die den Hauptcontainer unterstützen und parallel zu ihm laufen. Typische Sidecars sind Log-Agenten, Service-Mesh-Proxys oder Reverse-Proxys für TLS-Terminierung — sie ergänzen die App, ohne deren Code zu verändern.
So arbeiten Sidecar-Container
Sidecars teilen sich mit dem Hauptcontainer das Pod-Netzwerk und können über gemeinsame emptyDir-Volumes Daten austauschen. Ein Log-Agent liest zum Beispiel die Logdatei aus einem geteilten Volume und leitet sie an eine zentrale Sammelstelle weiter, während die App selbst unverändert bleibt.
Kubernetes unterstützt Sidecars nativ: Ein Container im Feld initContainers mit restartPolicy: Always startet vor dem Hauptcontainer und bleibt für die gesamte Pod-Lebenszeit aktiv. Ohne diese Einstellung wäre derselbe Container nur ein gewöhnlicher Init-Container, der einmalig läuft und beendet. Neben dem nativen Weg können Sidecars auch einfach als zweiter Eintrag in containers definiert werden.
Typische Anwendungsfälle
- Logging: Ein Log-Agent (etwa Fluentd oder Filebeat) sammelt und transportiert die Logs des Hauptcontainers.
- Service Mesh: Ein Proxy wie Envoy übernimmt Verkehrssteuerung, gegenseitige TLS-Authentifizierung und Observability — bei Istio wird der Proxy automatisch als Sidecar in jeden Pod injiziert. Grundlage ist das Service-Mesh-Muster.
- Proxy & TLS: Ein Reverse-Proxy terminiert TLS oder leitet lokale Verbindungen weiter.
- Konfiguration: Ein Reloader beobachtet Änderungen und stößt Neustarts oder Neuauswertung an.
Konfigurationen für Sidecars lassen sich komfortabel über projected volumes bereitstellen. Wie die Hauptcontainer können auch Sidecars Readiness- und Liveness-Probes besitzen; die Startup-Probe schützt langsam startende Anwendungen, auf die der Sidecar wartet.
Grundlagen: Pod, Pod-Spezifikation, StatefulSet, RuntimeClass, Kubernetes.