Kubernetes Persistent Volumes

6 Kernkonzepte

Die wichtigsten Konzepte für persistenten Speicher in Kubernetes: PV · PVC · StorageClass · Access Modes · Reclaim Policy · Volume Snapshots Persistent Volumes (PV) und Persistent Volume Claims (PVC) sind die Grundlage für stateful Anwendungen in Kubernetes. Sie ermöglichen persistente Daten unabhängig vom Pod-Lebenszyklus.

Persistent Volume – Speicher bereitstellen

PV · cluster-wide · provisioned by admin

apiVersion: v1 kind: PersistentVolume metadata: name: pv-demo spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: /mnt/data

Persistent Volume (PV) ist eine Ressource im Cluster, die Speicher bereitstellt – unabhängig von einem Pod. PVs werden vom Administrator erstellt und können verschiedene Backends nutzen.

PV-Status

Status	Beschreibung
Available	PV ist verfügbar und noch nicht gebunden
Bound	PV ist an einen PVC gebunden
Released	PVC wurde gelöscht, PV wartet auf Reclaim
Failed	PV ist fehlgeschlagen (z.B. Storage-Problem)

Beispiele

# PV mit HostPath (nur für Entwicklung!)

apiVersion: v1

kind: PersistentVolume

metadata:

labels:

type: local

spec:

capacity:

storage: 5Gi

accessModes:

- ReadWriteOnce

persistentVolumeReclaimPolicy: Retain

hostPath:

path: /tmp/k8s-data

# PV mit NFS-Backend

nfs:

server: 192.168.1.100

path: /exports/k8s

Tipp: hostPath ist nur für lokale Entwicklung geeignet. In der Produktion verwenden Sie Cloud-Volumes (AWS EBS, GCE PD, Azure Disk) oder Netzwerkspeicher (NFS, Ceph).

Persistent Volume Claim – Speicher anfordern

PVC · namespace-scoped · requested by user

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi

Persistent Volume Claim (PVC) ist eine Anforderung von Speicher durch einen Benutzer oder Pod. Kubernetes bindet den PVC automatisch an einen passenden PV.

PVC-Status

Status	Beschreibung
Pending	PVC wartet auf einen passenden PV
Bound	PVC ist an einen PV gebunden
Lost	Der PV wurde gelöscht – PVC ist ohne Backend

Beispiele

# PVC mit StorageClass (dynamisch)

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

spec:

accessModes:

- ReadWriteOnce

storageClassName: standard

resources:

requests:

storage: 10Gi

# PVC mit Selektor (bindet an bestimmten PV)

selector:

matchLabels:

environment: production

Tipp: PVCs sind namespace-scoped. Ein Pod kann nur auf PVCs in seinem eigenen Namespace zugreifen. Verwenden Sie storageClassName für dynamische Provisionierung.

StorageClass – Dynamische Provisionierung

StorageClass · provisioner · parameters

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-storage provisioner: kubernetes.io/aws-ebs parameters: type: gp2 zone: eu-central-1a

StorageClass ermöglicht die dynamische Provisionierung von PVs. Sie definiert, welcher Provisioner verwendet wird und welche Parameter gesetzt werden.

Häufige Provisioner

Provisioner	Beschreibung
kubernetes.io/aws-ebs	AWS EBS Volumes
kubernetes.io/gce-pd	Google Compute Engine Persistent Disk
kubernetes.io/azure-disk	Azure Disk
kubernetes.io/azure-file	Azure File Share
kubernetes.io/vsphere-volume	vSphere Volumes
kubernetes.io/csi	Container Storage Interface (CSI) Treiber
kubernetes.io/no-provisioner	Keine dynamische Provisionierung (lokales Storage)

Beispiele

# StorageClass für AWS EBS

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

annotations:

storageclass.kubernetes.io/is-default-class: "true"

provisioner: kubernetes.io/aws-ebs

parameters:

type: gp3

iopsPerGB: "10"

encrypted: "true"

# StorageClass für NFS (CSI)

provisioner: nfs.csi.k8s.io

Tipp: Setzen Sie die Annotation storageclass.kubernetes.io/is-default-class: "true", um eine Standard-StorageClass zu definieren. PVCs ohne storageClassName verwenden dann diese Klasse.

Access Modes – Zugriffsarten definieren

RWO · ROX · RWX · ReadWriteOncePod

accessModes: - ReadWriteOnce - ReadOnlyMany - ReadWriteMany

Access Modes definieren, wie ein Persistent Volume von Pods verwendet werden kann. Die Wahl des richtigen Access Mode ist entscheidend für die Anwendung.

Access Modes im Detail

Access Mode	Beschreibung	Verwendung
ReadWriteOnce (RWO)	Schreibzugriff von einem einzigen Node	Datenbanken, stateful Apps
ReadOnlyMany (ROX)	Lesezugriff von mehreren Nodes	Statische Assets, Config-Daten
ReadWriteMany (RWX)	Schreibzugriff von mehreren Nodes	Shared Storage, NFS, Cloud Storage
ReadWriteOncePod (RWOP)	Schreibzugriff von einem einzigen Pod	StatefulSets mit exklusivem Zugriff

Beispiele

# RWO – Datenbank (ein Pod schreibt)

accessModes:

- ReadWriteOnce

# RWX – Shared Storage (mehrere Pods lesen/schreiben)

accessModes:

- ReadWriteMany

# Kombination: RWO + ROX

accessModes:

- ReadWriteOnce

- ReadOnlyMany

Tipp: Nicht alle Storage-Backends unterstützen alle Access Modes. ReadWriteMany wird z.B. von AWS EBS nicht unterstützt – hier verwenden Sie EFS oder NFS.

Reclaim Policy – Was passiert nach PVC-Löschung?

Retain · Recycle · Delete

persistentVolumeReclaimPolicy: Retain

Reclaim Policy legt fest, was mit einem PV passiert, wenn der zugehörige PVC gelöscht wird. Die Wahl der Policy bestimmt, ob Daten erhalten bleiben.

Reclaim Policies im Detail

Policy	Beschreibung	Einsatz
Retain	PV bleibt mit Daten erhalten – muss manuell gelöscht werden	Produktion, Datenmigration
Delete	PV und zugehöriges Storage-Volume werden gelöscht	Dynamische Provisionierung
Recycle	Inhalt wird gelöscht (rm -rf), PV wird wieder verfügbar	Entwicklung (veraltet)

Beispiele

# Retain Policy – Daten bleiben erhalten

spec:

capacity:

storage: 10Gi

persistentVolumeReclaimPolicy: Retain

# Delete Policy – PV wird automatisch gelöscht

persistentVolumeReclaimPolicy: Delete

⚠️ Wichtig: Bei Retain bleibt das PV auch nach PVC-Löschung bestehen – der Administrator muss es manuell löschen. Bei Delete gehen die Daten verloren! Wählen Sie die Policy bewusst.

Volume Snapshots & Resize – Backup und Erweiterung

VolumeSnapshot · VolumeSnapshotClass · Resize

apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: mysql-snapshot-2024 spec: source: persistentVolumeClaimName: mysql-pvc

Volume Snapshots ermöglichen die Erstellung von Backups von PVCs. Die PVC-Resize Funktion erlaubt die Erweiterung von bestehenden Volumes.

Beispiele

# VolumeSnapshot erstellen

apiVersion: snapshot.storage.k8s.io/v1

kind: VolumeSnapshot

metadata:

spec:

volumeSnapshotClassName: csi-snapshot

source:

persistentVolumeClaimName: postgres-pvc

# PVC erweitern (nach Änderung der storage request)

# kubectl edit pvc postgres-pvc

# spec.resources.requests.storage: 20Gi

# Aus Snapshot wiederherstellen (neuer PVC)

dataSource:

apiGroup: snapshot.storage.k8s.io

kind: VolumeSnapshot

Tipp: Volume Snapshots sind ein mächtiges Werkzeug für Backups und Disaster Recovery. Die Unterstützung hängt vom CSI-Treiber und StorageClass ab. Die PVC-Erweiterung muss vom Storage-Backend unterstützt werden (allowVolumeExpansion: true).

Kubernetes Persistent Storage im Überblick

PV Cluster-weite Speicherressource
Administrator erstellt

PVC Speicheranforderung durch User/Pod
Namespace-scoped

StorageClass Dynamische Provisionierung
Provisioner + Parameter

Access Modes Zugriffsarten
RWO, ROX, RWX, RWOP

Reclaim Policy nach PVC-Löschung
Retain, Delete, Recycle

Snapshot Backup von Volumes
VolumeSnapshot

Quick Summary

PV

Persistent Volume

PVC

Persistent Volume Claim

StorageClass

Dynamische Provisionierung

RWO

Access Modes

Retain

Reclaim Policy

Snapshot

Backup & Resize

kubectl get pv · kubectl get pvc · kubectl get storageclass · kubectl get volumesnapshot