Zum Inhalt springen
Kubernetes · Cloud-Kosten · Datenbetrieb

Kubernetes-PVC sicher aufräumen:
Das neue Unused-Signal

Veröffentlicht: 1. Oktober 2026·Zaid Aljbour, Geschäftsführer·10 Min. Lesezeit

Kubernetes-PVC sicher aufräumen wird mit Version 1.37 messbarer, aber nicht automatisch. Der neue Beta-Zustand Unused zeigt, ob ein PersistentVolumeClaim (PVC) aktuell von keinem nicht-terminalen Pod referenziert wird. Sein lastTransitionTime liefert einen belastbaren Startpunkt für die Prüfung.

Das Signal beweist jedoch weder, dass die Daten geschäftlich entbehrlich sind, noch dass ein Snapshot wiederherstellbar ist. Teams sollten es deshalb als Kandidatenfilter in einen kontrollierten Prozess einbauen—nicht direkt an einen Löschbefehl koppeln.

Kurzantwort: Inventarisieren Sie Unused=True, warten Sie eine zum Datenzweck passende Frist ab, klären Sie Eigentümer und Wiederanlaufbedarf, prüfen Sie Reclaim Policy und Sicherung, testen Sie den Restore und löschen Sie erst nach dokumentierter Freigabe. Das Kubernetes-Signal startet die Entscheidung; es trifft sie nicht.

Was das Unused-Signal tatsächlich misst

Kubernetes 1.37 hebt das Feature Gate PersistentVolumeClaimUnusedSinceTime auf Beta und aktiviert es standardmäßig. Der bestehende PVC-Protection-Controller setzt Unused=True mit dem Grund NoPodsUsingPVC, wenn kein nicht-terminaler Pod den Claim referenziert. Sobald ein laufender oder noch wartender Pod den PVC nennt, steht der Zustand auf False.

BeobachtungWas sie belegtWas offen bleibt
Unused=TrueKein nicht-terminaler Pod referenziert den PVCEigentümer, Datenwert, künftige Nutzung
lastTransitionTimeZeitpunkt, an dem der Controller den Zustandswechsel sahExakter Infrastruktur-Unmount
Kein Unused-ZustandKeine verwertbare AussageFeature, Upgrade und erster Zustandswechsel prüfen
Unused=FalseMindestens ein nicht-terminaler Pod nennt den PVCOb der Pod tatsächlich Daten liest oder schreibt

Terminiert ein Batch-Pod mit Succeeded oder Failed, zählt er nicht länger als Nutzer. Ein nicht planbarer Pending-Pod zählt dagegen als Nutzung, weil bereits die Absicht im Pod-Spec geschützt wird. Laut Kubernetes Enhancement Proposal (KEP) kann der Controllerzeitpunkt Sekunden oder Minuten nach dem tatsächlichen Unmount liegen. Die ausgewiesene Leerlaufzeit kann dadurch zu kurz, aber nicht zu lang sein.

Warum Unused=True keine Löschfreigabe ist

Ein PVC kann absichtlich ohne aktiven Pod bestehen. Beispiele sind pausierte Testumgebungen, seltene Monatsläufe, manuell gestartete Analyse-Jobs, ein StatefulSet während einer Migration oder Daten für einen vorgesehenen Wiederanlauf. Auch ein gelöschtes Deployment kann außerhalb des Clusters noch als gewünschter Zustand in Git, Terraform oder einem Release-System existieren.

Die KEP nennt automatische Löschung ausdrücklich als Nicht-Ziel. Das ist die richtige Grenze: Kubernetes kennt Pod-Referenzen, aber nicht Aufbewahrungsfristen, Vertragsanforderungen, Datenklassifizierung oder den geschäftlichen Eigentümer. Ein sauberer Prozess verbindet deshalb technische Evidenz mit organisatorischer Verantwortung.

Wichtige Grenze: Deaktiviert ein Betreiber das Feature Gate, bleiben vorhandene Bedingungen in etcd erhalten, werden aber nicht mehr aktualisiert. Prüfen Sie vor jeder Automatisierung, ob kube-controller-manager das Signal aktiv pflegt und ob Update-Fehler sichtbar sind.

Die Risikomatrix für ungenutzte PersistentVolumeClaims

Eine einheitliche Frist für alle Claims ist bequem und gefährlich. Der Datenzweck bestimmt Wartezeit, Sicherung und Freigabe. Die folgende Matrix ist ein Entscheidungsmodell von ATMAN, keine Kubernetes-Vorgabe.

KlasseBeispieleMindestsicherung vor Löschung
TemporärPreview-Umgebung, reproduzierbare TestdatenEigentümerregel, kurze Frist, Manifest reproduzierbar
BetrieblichCI-Cache, Import-Zwischenstand, interner DienstAbhängigkeitscheck, definierte Frist, dokumentierter Rückweg
GeschäftskritischAnwendungsdatenbank, ProduktionsdateienSnapshot oder Backup, erfolgreicher Restore-Test, Vier-Augen-Freigabe
ReguliertAudit-, Vertrags- oder personenbezogene DatenAufbewahrungs- und Löschregel, Datenverantwortlicher, protokollierte Freigabe

Labels wie owner, data-class, retention und restore-tier machen Entscheidungen prüfbar. Fehlende Labels sind kein Grund für schnelles Löschen, sondern ein Signal für manuelle Klärung. Wer Kosten zuordnet, sollte zusätzlich StorageClass, angeforderte Kapazität, Zone und Provider-Volume-ID erfassen.

Sechs Schritte für sicheres Kubernetes-PVC-Cleanup

  1. Kandidaten nur lesen. Listen Sie PVC mit Unused=True und lastTransitionTime clusterweit auf. Erzeugen Sie zunächst einen Bericht; ein Leselauf darf nichts patchen oder löschen.
  2. Signalgesundheit prüfen. Bestätigen Sie Kubernetes 1.37, das aktive Feature Gate und aktuelle Zustandswechsel. Beobachten Sie pvc_protection_controller_unused_condition_syncs_total sowie Controller-Fehler, bevor eine Frist berechnet wird.
  3. Geplante Nutzung ausschließen. Suchen Sie nach CronJobs, pausierten Workloads, StatefulSets, GitOps-Manifests, Helm-Releases und Wiederanlaufplänen. Ein heute fehlender Pod kann morgen absichtlich zurückkehren.
  4. Eigentümer und Schutzklasse bestätigen. Ordnen Sie Namespace und Claim einem verantwortlichen Team zu. Unklare Claims gehen in Quarantäne oder Ticketbearbeitung, nicht in automatische Löschung.
  5. Rückweg beweisen. Prüfen Sie StorageClass und Reclaim Policy. Erstellen Sie für schützenswerte Daten eine geeignete Sicherung. Kubernetes-VolumeSnapshots setzen einen unterstützenden CSI-Treiber voraus; testen Sie außerdem einen Restore in der benötigten Topologie.
  6. Freigeben, löschen und nachprüfen. Dokumentieren Sie Kandidat, Leerlaufzeit, Eigentümer, Sicherungsnachweis und Genehmigung. Löschen Sie zuerst kontrolliert den PVC und prüfen Sie anschließend PV, Provider-Volume, Snapshot-Aufbewahrung, Anwendung und Kosteninventar.

Der Ablauf passt in Cloud-&-DevOps-Betrieb mit nachvollziehbaren Freigaben. Für Anwendungen mit sensiblen Daten gehören Aufbewahrung und Löschberechtigung zusätzlich in das Cybersicherheits- und Datenmodell. Wer den Cluster erst auf 1.37 hebt, sollte die separate Prüfung von Node-Änderungen und Rollback nicht mit der Speicherbereinigung vermischen.

Reclaim Policy und Snapshot sind getrennte Entscheidungen

Die Reclaim Policy bestimmt, was mit dem PersistentVolume nach dem Löschen seines Claims geschieht. Dynamisch bereitgestellte Volumes erben sie in der Regel aus der StorageClass. Delete kann das externe Speicherobjekt mit entfernen; Retain lässt es zur manuellen Wiedergewinnung zurück. Keiner der beiden Werte ersetzt eine Aufbewahrungsentscheidung.

Ein VolumeSnapshot ist ebenfalls kein universelles Backup. Kubernetes stellt Snapshot-Objekte nur für CSI-Treiber bereit, und der Treiber muss die Funktion unterstützen. Zusätzlich beeinflussen DeletionPolicy, Provider-Aufbewahrung und Topologie, ob Daten nach dem Löschen noch existieren und wo sie wiederhergestellt werden können. Der sinnvolle Gate lautet daher nicht „Snapshot vorhanden“, sondern „Restore unter den benötigten Bedingungen erfolgreich“.

Häufige Fragen zum Kubernetes-PVC-Aufräumen

Löscht Kubernetes 1.37 ungenutzte PVC automatisch?

Nein. Kubernetes ergänzt nur den informativen Unused-Zustand und einen Übergangszeitpunkt. Eine Löschentscheidung, Frist, Freigabe oder Sicherung bleibt Aufgabe des Betreibers.

Bedeutet Unused=True, dass die Daten nicht mehr gebraucht werden?

Nein. Der Zustand bedeutet nur, dass kein nicht-terminaler Pod den Claim aktuell referenziert. Zeitgesteuerte Jobs, pausierte Anwendungen, Wiederanlaufpläne und externe Abhängigkeiten müssen separat geprüft werden.

Reicht ein VolumeSnapshot als Backup vor der Löschung?

Nur wenn CSI-Treiber, Aufbewahrung, Topologie und Wiederherstellung geprüft sind. Ein vorhandener Snapshot ohne erfolgreichen Restore-Test ist noch kein belastbarer Rückweg.

Welche Wartefrist ist für ungenutzte PVC sinnvoll?

Es gibt keine universelle Frist. Entwicklungsdaten können eine kurze Frist erlauben; Produktions-, Audit- oder Wiederanlaufdaten benötigen meist längere, verantwortungsbezogene Regeln. Die Frist folgt dem Datenzweck und dem getesteten Restore-Ziel.

Mit einem Nur-Lese-Bericht beginnen

Der nächste Schritt ist keine Löschautomatik. Starten Sie mit einem Nur-Lese-Bericht für einen begrenzten Cluster, prüfen Sie falsche Kandidaten und ergänzen Sie fehlende Eigentümerdaten. Erst wenn Wiederherstellung und Freigabe praktisch funktionieren, darf aus Beobachtung eine kontrollierte Aktion werden.

Quellen und Methodik

Dieser Beitrag trennt Kubernetes-Verhalten von der ATMAN-Empfehlung für einen risikobasierten Freigabeprozess. Matrix und Sechs-Schritte-Ablauf sind technische Analyse, keine Funktion oder Vorgabe des Kubernetes-Projekts. Alle Quellen wurden am 1. Oktober 2026 abgerufen.