Helm-Charts und ihre Festplatten: Was nach helm uninstall übrig bleibt
Ein Helm-Chart bringt oft eigene Festplatten mit, etwa für die Datenbank im Chart. Manche verschwinden beim Deinstallieren samt Daten, andere bleiben für immer liegen. Beides will man vorher wissen.
Ein WordPress-Chart, ein Chart für Matomo, eines für einen Suchindex: Viele Helm-Charts bringen ihre eigenen Festplatten mit. In den Values steht persistence.enabled: true und eine Größe, und nach der Installation liegen im Namespace ein oder mehrere PersistentVolumeClaims, kurz PVCs. Was mit ihnen passiert, wenn das Chart aktualisiert, deinstalliert oder neu installiert wird, ist erstaunlich uneinheitlich. Und es entscheidet darüber, ob Daten verloren gehen oder für immer als vergessene Festplatte Geld kosten.
Zwei Arten, wie ein Chart Festplatten anlegt
Als eigenes Objekt im Chart. Das Chart enthält ein Template pvc.yaml. Helm legt den Claim an, und er gehört zum Release wie ein Deployment oder ein Service. Helm markiert ihn mit den Annotationen meta.helm.sh/release-name und meta.helm.sh/release-namespace.
Über ein StatefulSet. Das Chart enthält ein StatefulSet mit volumeClaimTemplates, typisch für Datenbanken wie MariaDB oder PostgreSQL im Chart. Hier legt nicht Helm den Claim an, sondern der StatefulSet-Controller von Kubernetes, einen pro Replika: data-wordpress-mariadb-0, data-wordpress-mariadb-1. Helm kennt diese Claims nicht als eigene Objekte.
Der Unterschied klingt akademisch. Er ist es nicht.
Was helm uninstall löscht
Festplatte | Bei helm uninstall | Folge |
|---|---|---|
PVC aus einem Chart-Template | wird gelöscht | Bei Reclaim-Policy Delete ist die Festplatte samt Daten weg |
PVC mit | bleibt | Daten bleiben, niemand räumt sie auf |
PVC aus | bleibt | Daten bleiben, Helm weiß nichts mehr davon |
Die erste Zeile ist die gefährliche. Die üblichen Storage-Klassen haben die Reclaim-Policy Delete: Verschwindet der Claim, löscht der Cloud-Anbieter die Festplatte dahinter. Ein helm uninstall zum Aufräumen einer Testumgebung, die versehentlich auf die Produktionsdaten zeigte, ist genau so passiert. Manche Charts setzen deshalb resource-policy: keep auf ihren Claim, manche nicht. Ein Blick ins Template vor der ersten Installation lohnt sich.
Die dritte Zeile ist die teure. StatefulSet-Claims überleben jede Deinstallation. Neuere Kubernetes-Versionen kennen zwar persistentVolumeClaimRetentionPolicy am StatefulSet, das Claims beim Löschen mitnehmen kann, aber die meisten Charts setzen es nicht. Nach einem Jahr mit Test-Installationen liegen im Cluster Festplatten, die niemand mehr zuordnen kann.
Ein Beispiel: WordPress mit eingebauter Datenbank
Ein verbreitetes WordPress-Chart mit aktivierter MariaDB legt nach der Installation zwei Claims an: einen für die Uploads und Plugins, als eigenes Template im Chart, und einen für die Datenbank, aus dem StatefulSet der MariaDB. Wer das Release mit helm uninstall entfernt, erlebt beides auf einmal: Der Upload-Claim verschwindet, sofern das Chart ihn nicht mit keep markiert, und mit ihm alle Bilder. Der Datenbank-Claim bleibt liegen, samt aller Beiträge. Installiert man danach neu, stehen die alten Beiträge wieder da, aber ohne Bilder, und das neu erzeugte Datenbank-Passwort passt nicht mehr zur alten Datenbank. Die Seite zeigt einen Verbindungsfehler, und es dauert eine Weile, bis klar ist, warum. Wie eine WordPress-Seite ohne diese Falle entsteht, zeigt WordPress aus dem App-Katalog; weitere Fallen beschreibt WordPress auf Kubernetes: Sieben Fallen zwischen Chart und erster Seite.
Die Stolperfallen im Alltag
Größe ändern. In einem StatefulSet sind die volumeClaimTemplates unveränderlich. Wer in den Values die Größe der Datenbank-Festplatte erhöht, bekommt beim nächsten helm upgrade einen Fehler. Der Weg führt über den Claim selbst: Größe am PVC erhöhen, sofern die Storage-Klasse Erweiterung erlaubt, und das StatefulSet mit --cascade=orphan neu anlegen lassen, damit die Pods nicht mitgelöscht werden.
Neu installieren. Wird ein Release mit demselben Namen neu installiert, findet das StatefulSet seine alten Claims wieder und hängt sie ein. Das ist praktisch, wenn man es will, und überraschend, wenn man eine leere Installation erwartet hat. Ein Passwort, das im neuen Release zufällig neu erzeugt wird, passt dann nicht mehr zu den Daten der alten Datenbank.
Wiederherstellen. Wer einen Claim aus einem Snapshot zurückholt, legt ihn neu an. Fehlen dabei die Labels und Annotationen, mit denen Helm ihn markiert hatte, scheitert das nächste helm upgrade mit dem Hinweis, das Objekt gehöre nicht zum Release. Ein wiederhergestellter Claim muss also mit genau diesen Metadaten entstehen.
Snapshots von Chart-Festplatten
Block-Storage-Snapshots funktionieren für Chart-Festplatten genauso wie für jede andere. Zwei Dinge gilt es zu wissen:
- Ein Snapshot einer laufenden Festplatte ist absturzkonsistent. Er entspricht dem Zustand nach einem Stromausfall. Die meisten Datenbanken kommen damit zurecht, garantiert ist es nicht. Für wichtige Daten gehört ein Snapshot bei gestoppter Anwendung oder ein logischer Dump dazu.
- Vor dem Zurückspielen muss alles stehen, was die Festplatte nutzt. Eine Festplatte hängt an genau einem Node. Solange ein Pod des StatefulSets sie eingehängt hat, lässt sie sich nicht ersetzen.
Die bessere Frage: gehört die Datenbank ins Chart?
Für eine kleine Anwendung ist die mitgelieferte Datenbank bequem. Für alles, was Kunden nutzen, spricht vieles für eine Managed Database außerhalb des Clusters: automatische Backups, Wiederherstellung auf einen Zeitpunkt, Updates ohne Eingriff, und kein StatefulSet, das beim Upgrade eines Node-Pools umziehen muss. Die meisten Charts erlauben, die eingebaute Datenbank abzuschalten und eine externe anzugeben. Wie das mit einer Datenbank pro Service aussieht, steht unter Managed Datenbanken.
Eine Checkliste für Charts mit Daten
- Im Chart nachsehen, welche Claims es anlegt und ob sie
resource-policy: keeptragen. - Die Reclaim-Policy der verwendeten Storage-Klasse kennen.
- Snapshots nach Zeitplan einrichten, bevor echte Daten entstehen, nicht danach.
- Eine Wiederherstellung einmal üben, am besten in einer Testumgebung.
- Nach jedem Deinstallieren prüfen, welche Claims übrig sind, und sie bewusst löschen oder behalten.
- Für Datenbanken mit Kundendaten eine Managed Database erwägen.
Wie Clusterward mit Chart-Festplatten umgeht
Clusterward findet die Festplatten eines Helm-Services live im Cluster: Claims, die Helm dem Release zugeordnet hat, und Claims, die ein Pod des Releases eingehängt hat, also auch die aus StatefulSets. Die Volumes-Karte zeigt sie mit Mount-Pfad und Größe, markiert als „from the chart“. Snapshots laufen sofort oder nach Zeitplan pro Festplatte und stehen etwa eine Minute nach Fertigstellung als bereit da. Beim Wiederherstellen stoppt Clusterward jedes Deployment und StatefulSet, das die Festplatte nutzt, sichert den aktuellen Stand, legt den Claim mit den Metadaten von Helm neu an und startet wieder, sodass das Release ihn weiter als eigenen kennt. Bleibt nach einem Undeploy eine Festplatte zurück, lässt sie sich im Cockpit löschen, mit einem letzten Snapshot vorher. Die Größe bestimmt weiterhin das Chart. Mehr unter Volumes & Snapshots und Backups & Wiederherstellung; wie Helm-Services ausgerollt werden, unter Deployments.
Fazit
Ein Helm-Chart mit Daten ist zwei Dinge: die Anwendung, die Helm verwaltet, und die Festplatten, die ein Deinstallieren entweder löscht oder für immer liegen lässt. Schauen Sie vor der ersten Installation, welche Art Ihr Chart anlegt, sichern Sie die Festplatten von Anfang an und üben Sie das Zurückspielen einmal. Und überlegen Sie bei Kundendaten, ob die Datenbank überhaupt ins Chart gehört.
Helm-Charts mit Daten im Betrieb? Nennen Sie uns Ihre Charts. Wir sagen Ihnen, welche Festplatten sie anlegen und wie Sie diese sichern. Frage stellen →
Quellen und weiterführende Links
Häufige Fragen
- Das hängt davon ab, wie das Chart sie anlegt. Ein PVC aus einem Chart-Template wird gelöscht, bei Reclaim-Policy Delete samt Festplatte und Daten. Ein PVC mit helm.sh/resource-policy: keep bleibt, ebenso PVCs aus den volumeClaimTemplates eines StatefulSets. Diese muss später jemand bewusst aufräumen.