Wer ein selbstgehostetes Kubernetes für seine IT-Infrastruktur nutzt, muss sich natürlich 😉 auch um die Sicherung seiner Daten kümmern, insbesondere – aber nicht nur – wenn Datenbanken und ähnliche Systeme mit persistenten Daten im Kubernetes-Cluster betrieben werden.
Idealerweise sollten die Kubernetes-eigenen Verwaltungsdaten wie auch die von den Anwendungen gespeicherten Daten gesichert werden. Ich gehe im folgenden davon aus, dass letztere sich in Persistent Volumes befinden, also innerhalb des Kubernetes-Clusters.
Ein System, das die genannten Wünsche erfüllt, ist Velero. Für die Installation im Kubernetes-Cluster kann man entweder ein CLI Tool oder ein Helm Chart verwenden. Die Details würden hier den Rahmen sprengen. In https://velero.io/docs/v1.18/basic-install/ und https://velero.io/docs/v1.18/basic-install/#install-and-configure-the-server-components finden sich Anleitungen dazu.
Durch die Installation werden im Kubernetes Custom Resources bekannt gemacht. Dazu zählen die Backup Storage Locations, mit denen man konfiguriert, wo Backups gespeichert werden sollen. Velero nutzt S3 Buckets und ein BackupStorageLocation-Objekt enthält die Zugangsdaten dazu:
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
name: location-name
namespace: namespace-for-velero
spec:
credential:
name: velero-s3-credentials
key: aws
provider: aws
objectStorage:
bucket: "velero-bucket"
config:
s3Url: "https://url.of.s3.service"
(Ausschnitt; Namen sind frei gewählt)
Nach unserer Erfahrung nutzt man am besten einen S3-Service außerhalb des Kubernetes-Clusters, bspw. einen Server mit MinIO (die Free Edition reicht aus, um bspw. einen Single Node auf Basis von Linux aufzusetzen).
In Velero kann man nun Backups zeitgesteuert anstoßen lassen. Dazu muss pro zu sichernder Anwendung ein Schedule-Objekt angelegt werden:
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: backup-of-my-app
namespace: namespace-for-velero
spec:
schedule: 15 2 * * *
template:
includedNamespaces:
- namespace-to-be-saved
storageLocation: location-name
schedule ist darin eine Cron Expression (minute hour dayOfMonth month dayOfWeek). Das Beispiel geht davon aus, dass die zu sichernde Anwendung in einem eigenen Namespace läuft, was nach unserer Auffassung ohnehin ein Best Practice ist. Mit weiteren Attributen können Timeouts, Verfallszeiten, Kopierverfahren etc. eingestellt werden. Details finden sich in der Velero-Backup-Referenz.
Die erfolgten Backups lassen sich mit kubectl get Backup -n namespace-for-velero auflisten:
backup-of-my-app-20260824181257 Completed ...
backup-of-my-app-20260825021557 Completed ...
Man erkennt an der Liste, dass Velero den Namen des Schedule-Objektes um einen Timestamp ergänzt, um die Backups zu benennen.
Um eine Anwendung aus einem Backup heraus wieder zu restaurieren, legt man ein Restore-Objekt an:
apiVersion: velero.io/v1
kind: Restore
metadata:
name: restore-my-app
namespace: namespace-for-velero
spec:
backupName: backup-of-my-app-20260825021557
includedNamespaces:
- namespace-to-be-restored
Velero erzeugt dann bei Bedarf den gesamten Namespace neu und restauriert darin die Kubernetes-Objekte sowie die Inhalte der referenzierten Volumes.
Ich konnte in diesem Post die Möglichkeiten von Velero nur anreißen. Über das gezeigte hinaus kann man bspw. Snapshots von Volumes benutzen, Datenbanken vor dem Backup einfrieren, in andere Namespaces restaurieren, Objekte ausfiltern oder sogar Cluster-übergreifende Backups/Restores nutzen. Nehmen Sie gerne Kontakt auf, wenn Sie mehr wissen wollen!