Sidecar: Hilfscontainer im Pod

Ein Sidecar ist ein Container, der im selben Pod wie der eigentliche Anwendungscontainer läuft und ihm eine Querschnittsaufgabe abnimmt: Protokollierung, Verschlüsselung, Proxy, Metriksammlung oder Konfigurationsaktualisierung. Der Begriff stammt vom Beiwagen eines Motorrads – er fährt mit, ist aber nicht der Hauptdarsteller.

Warum überhaupt ein zweiter Container?

Ein Pod ist die kleinste Einheit in Kubernetes und teilt sich Netzwerk-Namespace und Speicher-Volumes. Container in einem Pod sehen sich gegenseitig über localhost und können dieselben Dateien lesen. Genau das macht den Sidecar nützlich: Er kann den Verkehr der Hauptanwendung abfangen, ohne dass die Anwendung selbst davon weiß.

Typische Aufgaben

  • Proxy und Verschlüsselung: In einem Service Mesh übernimmt ein Sidecar-Proxy den gesamten Netzwerkverkehr des Pods – gegenseitige TLS-Authentifizierung, Wiederholungen, Zeitlimits, Verkehrslenkung. Das ist die bekannteste Verwendung.
  • Protokolle sammeln: Ein Log-Weiterleiter liest die Logdateien aus einem gemeinsam genutzten Volume und schickt sie an die Zentrale. Die Anwendung schreibt weiter einfach in eine Datei.
  • Metriken bereitstellen: Ein kleiner HTTP-Dienst stellt Kennzahlen unter /metrics bereit, die das Monitoring abholt – häufig genutzt für Anwendungen, die selbst keine Kennzahlen liefern.
  • Konfiguration nachziehen: Ein Sidecar beobachtet Änderungen und lädt die Anwendung neu oder schreibt aktualisierte Dateien, statt einen Neustart zu erzwingen.
  • Secrets bereitstellen: Ein Sidecar holt Geheimnisse aus einem Tresor und legt sie als Dateien ab, die rotiert werden können.
apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
    - name: app                       # Hauptcontainer
      image: registry.example.org/webapp:1.4.2
      ports:
        - containerPort: 8080
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
    - name: log-forwarder             # Sidecar
      image: registry.example.org/fluent-bit:3.1
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
          readOnly: true
  volumes:
    - name: logs
      emptyDir: {}

Lebenszyklus: der praktische Knackpunkt

Ein Sidecar, der die Protokolle weiterleitet, muss nach der Anwendung starten und nach ihr beendet werden – sonst gehen die letzten Zeilen verloren. In Kubernetes löst man das auf zwei Wegen:

  • Init-Container mit restartPolicy: Always und der Angabe restartPolicy: Always in initContainers: Der Container startet vor der Anwendung und wird nach deren Ende noch betrieben. Das ist die offiziell empfohlene Variante (natives Sidecar).
  • Austrittshaken: Ein preStop-Haken in der Anwendung wartet, bis der Sidecar die Puffer geleert hat. Funktioniert, ist aber fehleranfällig und vom Verhalten der Anwendung abhängig.
spec:
  initContainers:
    - name: log-forwarder
      image: registry.example.org/fluent-bit:3.1
      restartPolicy: Always          # macht den Init-Container zum nativen Sidecar
  containers:
    - name: app
      image: registry.example.org/webapp:1.4.2

Nebenwirkungen und Grenzen

  • Ressourcen: Jeder Sidecar verbraucht Speicher und CPU. Bei hundert Pods mit je einem Proxy sind das spürbare Reserven – und jede Anfrage läuft über einen zusätzlichen Netzwerkschritt.
  • Betriebsaufwand: Ein Sidecar pro Pod muss mit aktualisiert werden. Wird es über einen Mutations-Webhook eingefügt, steuert der Cluster das zentral – aber ein Fehler im Webhook legt die Pod-Erstellung lahm.
  • Debugging: Fehler treten oft im Proxy auf, nicht in der Anwendung. Ohne Einsicht in dessen Protokolle wird die Ursache leicht falsch verortet.
  • Alternative: Ein Sidecar pro Knoten (DaemonSet) oder Ambient Mode – dort übernimmt eine knotennahe Komponente die Aufgabe, ohne dass jeder Pod den Proxy mitführt. Das senkt den Aufwand deutlich.

Abgrenzung

Nicht jede Hilfsaufgabe gehört in einen Sidecar. Ein Cronjob, ein eigener Dienst oder eine Bibliothek in der Anwendung sind oft einfacher. Der Sidecar ist die richtige Antwort, wenn die Aufgabe pro Pod anfällt, vom Anwendungscode getrennt bleiben soll und die Netzwerk- oder Dateisicht des Pods benötigt.

Verwandte Grundlagen: Kubernetes, Pod, Service Mesh, Container.