Die Kosten eines Kubernetes Persistent Volume sind die Kosten des Cloud-Datenträgers, den der CSI-Treiber dafür anlegt: Gigabyte je Monat nach Datenträgertyp, dazu bereitgestellte IOPS und Durchsatz, wo der Typ sie getrennt berechnet, und Snapshots nach gespeichertem Volumen. Kubernetes selbst hat keinen Speicherpreis; die Storage Class entscheidet, welcher Datenträgertyp entsteht, und die Reclaim Policy, ob er mit dem Claim verschwindet oder weiterläuft. Diese Seite beschreibt die Zuordnung von Persistent Volume zu Datenträger, von Storage Class zu Typ, warum verwaiste Volumes die häufigste Speicherverschwendung eines Clusters sind, was Volume Snapshots kosten und was ein CSI-Treiber daran ändert. Die Datenträgertypen der drei Anbieter im Vergleich stehen unter Block-, Objekt- und Dateispeicher.
So funktioniert es
Ein Pod bindet einen Persistent Volume Claim (PVC), der Claim bindet ein Persistent Volume (PV), und hinter dem PV steht bei dynamischer Bereitstellung ein Datenträger des Anbieters, den der CSI-Treiber mit den Parametern der Storage Class angelegt hat: Typ, Größe, Redundanz, bei manchen Typen IOPS und Durchsatz. Der Anbieter berechnet den Datenträger ab seiner Erstellung, nach bereitgestellter Größe, nicht nach belegtem Platz, und unabhängig davon, ob ein Pod ihn gerade eingehängt hat. Ein PVC über 100 GiB kostet 100 GiB, auch wenn 5 GiB geschrieben sind.
Die Reclaim Policy der Storage Class legt fest, was beim Löschen des Claims geschieht. Delete, der Standard der eingebauten Klassen bei allen drei Anbietern, löscht PV und Datenträger. Retain lässt beide stehen: Das PV geht in den Zustand Released, der Datenträger läuft weiter und kostet weiter, bis jemand ihn von Hand löscht. Retain schützt Daten vor einem versehentlichen Löschen und ist zugleich der Ursprung der meisten verwaisten Volumes. Ein zweiter Ursprung sind Cluster, die gelöscht wurden, während ihre Datenträger blieben (nicht-produktive Cluster), und StatefulSets, deren PVCs beim Herunterskalieren bestehen bleiben, weil Kubernetes sie nicht mitlöscht.
Ein Snapshot eines Volumes entsteht über die CSI-Objekte VolumeSnapshot und VolumeSnapshotClass als Snapshot des Anbieters und wird wie dieser berechnet: nach gespeichertem Volumen je Monat, bei AWS und Azure inkrementell gegenüber dem vorigen Snapshot, mit eigener Reclaim Policy der Snapshot-Klasse. Ein Backup-Werkzeug, das täglich Snapshots zieht und nie löscht, baut eine Position auf, die mit jedem Tag wächst und zu keinem laufenden Pod mehr gehört.
AWS
Der EBS-CSI-Treiber legt EBS-Volumes an; die Storage Class nennt den Typ (gp3, gp2, io2, st1, sc1) und bei gp3 und io2 wahlweise IOPS und Durchsatz, die über der Grundausstattung getrennt berechnet werden. Im Cost and Usage Report stehen die Volumes unter Amazon EC2 mit Usage Types wie EUC1-EBS:VolumeUsage.gp3 und Snapshots unter EUC1-EBS:SnapshotUsage; die Preise je Typ und die Dimensionen erklärt Amazon EBS.
Azure
Die eingebauten Klassen von AKS: managed-csi (Standard SSD, die Klasse default ist dieselbe), managed-csi-premium (Premium SSD) und ab Kubernetes 1.35 managed-csi-premium-v2, dazu azurefile-csi für Dateifreigaben; alle mit Reclaim Policy Delete. In Clustern über mehrere Verfügbarkeitszonen legen die eingebauten Klassen seit Kubernetes 1.29 zonenredundante Datenträger (ZRS) an, die mehr kosten als lokal redundante (LRS); wer LRS will, braucht eine eigene Klasse.
Google Cloud
GKE legt eine Standardklasse an, die Balanced Persistent Disks erzeugt (standard-rwo), mit Delete als Standard-Policy; Retain lässt PV und Datenträger beim Löschen des Claims stehen. Autopilot-Pods binden Datenträger ebenso, und der Datenträger wird neben den Pod-Requests berechnet.
Was es für Ihre Kosten bedeutet
Speicher ist die Position eines Clusters, die am seltensten mit ihm skaliert: Datenträger bleiben, wenn Pods gehen, und Snapshots bleiben, wenn Datenträger gehen. Drei Dinge sind deshalb zu entscheiden. Die Klassen: Welche Typen Teams anfordern dürfen und welcher der Standard ist, denn der Standard entscheidet, was jedes StatefulSet ohne Angabe bekommt; eine Standardklasse mit Premium-Datenträger macht jeden Testcluster teuer. Die Reclaim Policy: Delete für alles, was aus einem Backup wiederherstellbar ist, Retain nur dort, wo der Verlust eines Datenträgers der Verlust der Daten wäre, und dann mit einem Prozess, der Released-Volumes regelmäßig prüft. Die Snapshots: eine Aufbewahrungsfrist je Klasse, die das Werkzeug durchsetzt.
In den Abrechnungsdaten steht ein Datenträger unter dem Speicherdienst des Anbieters mit seiner Ressourcen-ID, nicht unter dem Cluster und nicht beim Pod, dessen Preis was ein Pod kostet aus dem Node ableitet; die Zuordnung zum Cluster und zum Namespace läuft über die Tags, die der CSI-Treiber setzt, und die PVC-Daten aus dem Cluster (Kubernetes-Kostendaten). Ein Datenträger ohne Pod ist in den Abrechnungsdaten nicht von einem mit Pod zu unterscheiden; erst der Abgleich mit den PVs des Clusters zeigt die Waisen (Leerlauf- und verwaiste Ressourcen). Die Wahl des Typs ist ein Hebel der Speicheroptimierung: Derselbe Claim auf gp3 statt gp2 kostet weniger, ohne dass ein Pod sich ändert.
Wo es schiefgeht
- Released-Volumes laufen weiter. Symptom: Die Speicherposition eines Clusters sinkt nicht, obwohl Workloads abgebaut wurden. Ursache: Die Storage Class hat
Retain; PV und Datenträger bleiben nach dem Löschen des Claims bestehen. - StatefulSet herunterskaliert, PVCs bleiben. Symptom: Ein StatefulSet mit drei Replikas hat zehn PVCs. Ursache: Kubernetes löscht die PVCs eines StatefulSet beim Herunterskalieren nicht; jeder bleibt ein bezahlter Datenträger.
- Cluster gelöscht, Datenträger nicht. Symptom: Ein Konto zeigt Datenträger ohne Instanz. Ursache: Die Volumes gehörten einem gelöschten Cluster; der Anbieter löscht sie nicht mit.
- Snapshots ohne Frist. Symptom: Die Snapshot-Position wächst linear mit der Zeit. Ursache: Tägliche Snapshots ohne Aufbewahrungsregel; auch Snapshots gelöschter Volumes bleiben.
- Standardklasse zu teuer. Symptom: Jeder Namespace bezahlt Premium-Speicher. Ursache: Die Standardklasse erzeugt den teuren Typ, und Claims nennen keine Klasse.
- Zonenredundanz unbemerkt. Symptom: Die Datenträger eines AKS-Clusters kosten mehr als der Preis der Klasse vermuten lässt. Ursache: In Clustern über mehrere Zonen legen die eingebauten Klassen ZRS-Datenträger an.
- Größe statt Nutzung. Symptom: Volumes sind zu 5 Prozent belegt und voll berechnet. Ursache: Datenträger kosten nach bereitgestellter Größe; ein großzügiger Claim bleibt großzügig.
Beispiel
Listenpreise, gelesen am 2026-10-21 aus der AWS-Preisliste für Frankfurt (eu-central-1): gp3 0,0952 USD und gp2 0,119 USD je GB und Monat, EBS-Snapshots 0,054 USD je GB und Monat.
Ein PVC über 100 GiB auf gp3 kostet 100 × 0,0952 = 9,52 USD im Monat; auf gp2 11,90 USD, 2,38 USD mehr für dieselbe Größe. Zwanzig verwaiste Volumes zu 50 GiB, mit Retain zurückgeblieben, kosten 20 × 50 × 0,0952 = 95,20 USD im Monat für Daten, die kein Pod liest. Ein tägliches Snapshot-Backup des 100-GiB-Volumes mit 5 GiB Änderung je Tag und 30 Tagen Aufbewahrung hält einen vollen und 29 inkrementelle Snapshots, 100 + 29 × 5 = 245 GiB, also 245 × 0,054 = 13,23 USD im Monat; ohne Aufbewahrungsfrist kommen jeden Monat 150 GiB und 8,10 USD hinzu.
Quellen
Gelesen am 2026-10-21. Kubernetes Persistent Volumes, Storage Classes und Volume Snapshots, AWS Price List Bulk API, Angebot AmazonEC2, eu-central-1, AWS EBS-CSI-Treiber, Microsoft Speicher in AKS, Google Cloud Persistent Volumes in GKE.