Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Kubernetes Objekt-Backup: Velero & PVC-Restore

Dieses Modul (100 bis 110 Minuten) schließt eine Lücke, die zwei Vorgängermodule dieses Repos jeweils ausdrücklich offen gelassen haben: “Kubernetes Cluster-Recovery” hat Velero nur konzeptionell eingeordnet, ohne eigenes Hands-on, “Kubernetes Multi-Master Disaster Recovery” hat Velero und PVC-Restore bewusst ausgeklammert. Ihr startet mit der Einordnung, die den Unterschied zum etcd-Snapshot klar macht: Velero sichert Kubernetes-API-Objekte (Deployments, Services, ConfigMaps und mehr) selektiv, namespace- und label-genau, während ein etcd-Snapshot immer den gesamten Clusterzustand auf einen Zeitpunkt zurücksetzt. Danach folgt die Architektur: ein Velero-Server-Deployment im Cluster, die velero-CLI als Steuerzentrale und ein node-agent-DaemonSet für den Zugriff auf Volume-Inhalte, alle über eine BackupStorageLocation an ein S3-kompatibles Object-Storage-Backend angebunden. Für dieses Modul übernimmt MinIO, als Pod im selben Cluster betrieben, genau diese Rolle: ein S3-kompatibles Backend, komplett lokal, ohne Cloud-Account. Im ersten Hands-on legt ihr einen eigenen Namespace samt API-Objekten an, sichert ihn per velero backup create, löscht ihn gezielt und stellt ihn per velero restore create selektiv wieder her, ohne dass der Rest des Clusters davon betroffen ist. Im zweiten, größeren Hands-on geht es um den Fall, den der erste bewusst ausspart: den Inhalt einer PersistentVolumeClaim. Weil die hier verwendeten lokalen StorageClasses (Minikubes standard- Provisioner bzw. kinds local-path-Provisioner) auf hostPath aufsetzen und keine CSI-Snapshot-Schnittstelle bereitstellen, kann Velero hier keinen CSI-Volume-Snapshot ziehen. Stattdessen übernimmt der node-agent-Pfad (dateisystembasierte Integration, historisch über Restic, neuere Velero-Versionen standardmäßig über Kopia) ein dateisystembasiertes Backup der Volume-Daten direkt vom Node, unabhängig von der StorageClass. Ihr sichert eine PVC über diesen Pfad, löscht sie und stellt ihren Inhalt in einer neuen PVC wieder her. Voraussetzung sind beide Vorgängermodule gleichzeitig: Kubernetes Cluster-Recovery (etcd-Snapshot als Grundlage für die Abgrenzung) und Kubernetes Storage (PersistentVolume, PersistentVolumeClaim und StorageClass als Vorwissen für den zweiten Hands-on-Block). Die Session läuft vollständig lokal über Minikube oder kind samt In-Cluster-MinIO, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

100 bis 110 Minuten, live (remote oder vor Ort), Input & Hands-on

Teilnehmende

Ops/Admins, die Kubernetes-Objekte und PVC-Inhalte selektiv sichern und wiederherstellen können wollen, nicht nur den gesamten Clusterzustand per etcd-Snapshot

Voraussetzungen

Abgeschlossene Module “Kubernetes Cluster-Recovery” UND “Kubernetes Storage” (beide Pflicht), lauffähige lokale Docker-Umgebung für Minikube oder kind

Warum dieses Training für deine Organisation wirkt

Ein API-Objekt ist kein etcd-Snapshot

Wer im Ernstfall nur einen einzelnen Namespace zurückholen will, aber nur das Alles-oder-nichts-Werkzeug etcd-Snapshot kennt, riskiert einen unnötigen Komplett-Rollback des gesamten Clusters. Velero liefert die selektive Alternative dazu.

PVC-Inhalte brauchen einen eigenen Pfad

Ein API-Objekt-Backup sichert das Manifest einer PersistentVolumeClaim, nicht automatisch ihren Inhalt. Ohne den node-agent-Pfad bleibt der eigentliche Anwendungszustand ungesichert, gerade dort, wo keine CSI-Snapshots zur Verfügung stehen.

Ohne Object-Storage-Backend kein Backup

Velero schreibt grundsätzlich in ein S3-kompatibles Backend, nie direkt auf den Node. Wer dieses Zusammenspiel nicht einmal selbst aufgebaut hat, unterschätzt, wie viel Konfiguration vor dem ersten Backup steht.

Was Teilnehmende mitnehmen

  • Velero als selektives API-Objekt-Backup von einem etcd-Snapshot abgrenzen: namespace- und label-genaue Wiederherstellung statt Totalrücksetzung des gesamten Clusterzustands.
  • Die Velero-Architektur benennen (Server-Deployment, CLI, node-agent-DaemonSet) und MinIO als lokales, S3-kompatibles Object-Storage-Backend als BackupStorageLocation registrieren.
  • Einen eigens angelegten Namespace samt API-Objekten per velero backup create sichern, gezielt löschen und per velero restore create selektiv wiederherstellen.
  • Begründen, warum die hier verwendeten lokalen StorageClasses (hostPath-basiert) keine CSI-Snapshots liefern und ein dateisystembasiertes Backup über den node-agent-Pfad deshalb nötig ist.
  • Eine PersistentVolumeClaim mitsamt ihrem Inhalt über den node-agent-Pfad sichern und in einer neuen PVC wiederherstellen.
  • Abgrenzen, was dieses Modul bewusst nicht leistet: produktive Objekt-Storage-Anbindung, automatisierte Backup-Schedules und Cluster-Migration via Velero.

Für wen dieses Modul ideal ist

  • • Ops/Admins mit abgeschlossenen Modulen “Kubernetes Cluster-Recovery” UND “Kubernetes Storage”
  • • Alle, die neben dem etcd-Snapshot einen selektiven, namespace-genauen Wiederherstellungsweg kennen wollen
  • • Teams, die PVC-Inhalte bisher für automatisch gesichert hielten, nur weil das zugehörige API-Objekt gesichert war

Rahmendaten

  • • Dauer: 100 bis 110 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei aufeinander aufbauende Hands-on-Übungen (API-Objekt-Restore, PVC-Restore), Abgrenzung als Abschlussblock
  • • Voraussetzungen: beide Module “Kubernetes Cluster-Recovery” und “Kubernetes Storage”, lauffähige lokale Docker-Umgebung für Minikube oder kind, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Recap & Einordnung: Velero vs. etcd-Snapshot (10 min): die entscheidende Unterscheidung, warum ein selektives API-Objekt-Backup ein anderes Werkzeug ist als ein vollständiger etcd-Snapshot, ohne Snapshot-Grundlagen aus dem Vorgängermodul erneut einzuführen.

  2. Architektur: Velero-Komponenten & MinIO als lokales S3-Backend (15 min): Server-Deployment, CLI und node-agent-DaemonSet im Zusammenspiel, MinIO als in-Cluster betriebenes, S3-kompatibles Object-Storage-Backend, Registrierung als BackupStorageLocation.

  3. Hands-on 1: Namespace- und API-Objekt-Backup & Restore (25 min, Hands-on): einen eigenen Namespace samt API-Objekten anlegen, per velero backup create sichern, gezielt löschen und per velero restore create selektiv wiederherstellen.

  4. Hands-on 2: PVC-Restore über den node-agent-Pfad (40 min, Hands-on): begründen, warum die hier verwendete lokale StorageClass keine CSI-Snapshots liefert, eine PVC samt Inhalt über den node-agent-Pfad sichern, löschen und in einer neuen PVC wiederherstellen.

  5. Abgrenzung: was dieses Modul bewusst nicht leistet (10 min): produktive Objekt-Storage-Anbindung, automatisierte Backup-Schedules per Velero-Schedule-CRD und Cluster-Migration via Velero im Überblick, ohne eigenes Hands-on.

  6. Puffer/Q&A (10 min): offene Fragen, individuelle Vertiefung je nach Backup-Anforderung der Teilnehmenden.

Dieses Modul setzt beide Vorgängermodule gleichzeitig voraus: Kubernetes Cluster-Recovery: etcd Backup & Restore (etcd-Snapshot als Grundlage für die Abgrenzung zu Velero) und Kubernetes Storage: Volumes, PersistentVolumes & Claims (PersistentVolume, PersistentVolumeClaim, AccessModes und StorageClass als Vorwissen für Hands-on 2). Wer eines der beiden Module noch nicht hat, sollte es zuerst buchen, keines der beiden reicht hier allein.

Was dieses Modul bewusst nicht behandelt: die produktive Anbindung an einen echten Objekt-Storage-Dienst (S3, Azure Blob Storage oder Google Cloud Storage statt des lokalen MinIO), automatisierte Backup-Schedules über die Velero-Schedule-CRD sowie die Migration eines Clusters in einen anderen über Velero. Dieses Modul zeigt den manuellen, nachvollziehbaren Backup- und Restore-Ablauf als Grundlage, keine produktive Automatisierung und keine Cluster-Migration.

Hands-on Inhalte (Auszug)

MinIO & BackupStorageLocation einrichten

  • MinIO als Pod im Cluster betreiben und einen Bucket für Velero-Backups anlegen
  • Velero mit den MinIO-Zugangsdaten installieren und die Verbindung als BackupStorageLocation verifizieren

Namespace-Backup & Restore

  • Einen eigens angelegten Namespace samt API-Objekten per velero backup create sichern und den Backup-Status prüfen
  • Den Namespace gezielt löschen und per velero restore create selektiv wiederherstellen, ohne den Rest des Clusters anzufassen

PVC-Backup über den node-agent-Pfad

  • Eine PersistentVolumeClaim mit Dateninhalt für den node-agent-Pfad per Annotation markieren und per velero backup create sichern
  • Die PVC löschen und ihren Inhalt in einer neuen PVC über velero restore create wiederherstellen

Verifikation

  • Mit kubectl get all -n und kubectl exec bestätigen, dass API-Objekte und Dateiinhalt nach dem Restore identisch zum Ausgangszustand sind
  • Backup- und Restore-Status fortlaufend mit velero backup describe und velero restore describe gegenprüfen, statt dem Ergebnis blind zu vertrauen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit vom Backup bis zum verifizierten Restore) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen