Zu Vcluster und Crossplane gab es in diesem Blog schon Experimente. Wir können eine Resource vcluster erstellen und Crossplane wird ein Helm-Chart mit einem Vcluster-Deployment ausrollen und diesen Cluster in Rancher registrieren. Dazu haben wir als Unterbau K3S mit der eingebetteten SQLite-DB genommen, da auch nur eine Single-Instanz verfügbar ist. Gut genug für Tests und Entwicklung.
Der Haken bei der Sache ist: auch bei hochverfügbarem Storage für die Datenbank kann schon mal was kaputtgehen. In der SQLite ist das ganze Leben des Vclusters drin. Gute Idee, das zu backupen.
Hier ist das Gist:
Es wird also im Kubernetes-Cluster ein Cronjob installiert, der periodisch einen Job startet, der den PVC der K3S-Instanz mountet und dort mit sqlite ein Backup initiert. Im Beispiel ist dann auch noch ein Job für einen Restore aufgeführt.
Zwei Probleme treten hier auf: Der PVC-Name muss manuell gesetzt werden (kriegt man in der Automatisierung, wenn man kustomize oder Helm verwendet, auch noch irgendwie hin. Und, je nach StorageClass (hier Longhorn), muss der Cronjob auf demselben Workernode laufen wie der K3S-Pod. Sonst gibts “multi-attach error”. Auch das könnte man irgendwie lösen, mit noch mehr Fummelei.
Ein kleines Go-Programm, welches permanent eine Datei (state.db) verschlüsselt in einen S3-Speicher ablegt.
$ ./vcluster-backup -h
Usage of ./vcluster-backup:
-accessKey string
S3 accesskey.
-backupFile string
Sqlite database of K3S instance. (default "/data/server/db/state.db")
-backupInterval int
Interval in minutes for backup. (default 2)
-bucketName string
S3 bucket name. (default "k3s-backup")
-decrypt
Decrypt the file
-encKey string
S3 encryption key.
-endpoint string
S3 endpoint.
-list
List S3 objects
-region string
S3 region. (default "default")
-secretKey string
S3 secretkey.
-trace string
Trace S3 API calls
-insecure string
Insecure S3 backend
Das Programm läuft im Vordergrund und je nach backupInterval Zeit wird alle paar Minuten die Datei state.db gesichert-
Wozu ist das jetzt gut? Nun, was oben als Job lief, läuft hier quasi nebenan. Um diesen Sidecar-Container ins Helm-Chart von Vcluster zu integrieren, bedarf es dieses PR. Fortan wird also auf denselben Speicher vom K3s zugegriffen und die Backups erstellt. Ein Beispiel für ein Deployment ist hier (sidecar wurde in sidecarContainer umbenannt). Die Arbeit lässt sich am stdout log beobachten.
Unsere Vcluster werden mit Crossplane und dem Helm-Provider deployt. Um das Backup und deren Einrichtung zu automatisieren, bedarf es einiger Erweiterungen.
Gegeben sei ein S3-Backend. Wir verwenden eine Minio-Instanz und ich verweise auch immer wieder auf die Version mit den Security-Fixes. Leicht mit Helm zu installieren. Wenn es im selben Cluster läuft, bräuchten wir nicht mal einen Ingress und können den internen Service-Endpunkt benutzen.
Um einen separaten User und Bucket für jeden erstellten Vcluster zu erstellen, bedarf es eines weiteren Helm-Charts: s3-register. Dieses benötigt die Admin-Credentials und den Endpunktnamen. Bucketname und Username werden aus dem Vcluster-Namen hergeleitet, das Passwort wird generiert und in ein Secret gespeichert. Von dort kann es dann vcluster-backup abrufen.
Schauen wir uns die gesamte Composition dazu an: