Sidecars Einsatz in Kubernetes
Multicontainer Prinzip Sidecar
Der Nutzen von Sidecars in Kubernetes hat viele Facetten. Da die Anwendungsfälle sehr unterschiedlich sein können, sind einige besondere Varianten im Folgenden beschrieben. Generell beschreibt ein Sidecar lediglich das Starten eines weiteren Containers in einem bestehenden Pod, so dass dieser als Multicontainer Pod zum Einsatz kommt. Von einem Sidecar spricht man aber erst dann, wenn einer der Container der Hauptcontainer ist und der andere Container ebenfalls auf Teile des selben Speichers zugreifen kann.
Sidecar Containers können für andere Hauptcontainer wiederverwendet werden und bieten daher für viele Pods standardisierte Funktionserweiterungen an.
Weitere gerne genutzte Multicontainer Szenarien neben Sidecars wären:
- Ambassador
- Adapter
Ambassador
Der Hauptcontainer kommuniziert mit anderen Anwendungen über den Localhost und sieht dabei die eigentliche Verbindung zum Dienst nicht. Denkbar wäre eine Datenbankabfrage wie redis oder auch memcached. Der Ambassador Container sorgt für die externe Verbindung zu diesen Diensten und operiert als Proxy.
Adapter
Mit dem Adapter lassen sich die Ausgaben und Interfaces nach außen vereinheitlichen. Ein Einsatz ist beispielsweise für ein externes Monitoring denkbar, wo jeder Hauptcontainer trotz unterschiedlicher Applikationen mit den selben Aufrufen funktionieren und Daten nach einem Schema ausgeben soll. Anstelle die Applikationen selber zu verändern, gerade wenn es sich um 3rd Party handelt undenkbar, ist hier ein Weg der Anpassbarkeit geschaffen.
Sidecar in yaml definieren
Beispiel für ein Deployment mit Sidecar zur Weitergabe des Webroots:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.17
ports:
- containerPort: 80
volumeMounts:
- mountPath: /usr/share/nginx/html
name: webroot # Name ist gleich
- name: busybox
image: busybox:1
volumeMounts:
- mountPath: /tmp/html
name: webroot # Name ist gleich
volumes:
- name: webroot
persistentVolumeClaim:
claimName: webroot-pvc
Durch den identischen Namen des volumeMounts sind die Daten im Sidecar ebenfalls verfügbar. Dort auch unter einem anderen Pfad, der mit dem mountPath individuell konfigurierbar ist. Der persistentVolumeClaim teilen sich die beiden Container im Pod.
Spezifische Einsatzgebiete die häufiger zum Einsatz kommen sind:
Backups
Mittels Sidecar können automatisierte Backups der geteilten Daten erstellen und im Anschluss an einen dedizierten Server gesendet werden. Auf diese Weise ist es möglich komplexe Systeme wie Bacula zu verwenden und ohne auf einfache Skripte begrenzt zu sein.
Metriken und Healthchecks
Auch Metriken können durch ein Sidecar aufgebaut werden. So kann z.B. die Ausgabe von /health und /metrics generiert und von Prometheus oder anderen externen Servern abgerufen werden.
Logdateien Export mittels Sidecar
Ein gestarteter Logging Agent kann sich die Logs von jedem beliebigen Applikations Container beschaffen. Dieser kann beispielsweise fluentd sein.
Reparaturen
Da Volumes auch immer für Sidecars zugänglich gemacht werden können, ist ein Anpassung der Daten möglich. Für solche Zwecke eignen sich kleine Images wie Busybox sehr gut.
Secrets Injection
Ein neuerer Ansatz Secrets zu nutzen sieht vor diese nach Bedarf über das Sidecar zu beschaffen und dem Hauptcontainer auf explizite Anfrage zu übergeben. Ziel ist die Erhöhung der Sicherheit bei Passwortzugriffen. Ein Ansatz von Hashicorp ist hier zu finden.
Wenn ihr Fragen habt, meldet euch: info@mobilistics.de