TL;DR

PersistentVolumes (PV) und PersistentVolumeClaims (PVC) entkoppeln Storage-Bereitstellung von der Nutzung in Pods
StorageClasses ermöglichen dynamisches Provisioning - kein manuelles Anlegen von PVs mehr nötig
CSI-Treiber (Container Storage Interface) sind der Standard für Storage-Anbindung in Kubernetes
Access Modes wie ReadWriteOnce und ReadWriteMany bestimmen, wie viele Nodes gleichzeitig zugreifen
Volume Expansion erlaubt das Vergrößern bestehender Volumes ohne Datenverlust

Kubernetes Persistent Storage mit CSI-Treibern

Stateful Workloads wie Datenbanken, Message Queues oder Monitoring-Stacks brauchen persistenten Speicher. Kubernetes löst das über ein dreistufiges Modell: StorageClass, PersistentVolume und PersistentVolumeClaim. In diesem Guide konfigurieren wir Storage von Grund auf.

Das Storage-Modell im Überblick

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  StorageClass   │────▶│ PersistentVolume │◀────│      PVC        │
│  (Was & Wie)    │     │   (Der Speicher) │     │  (Die Anfrage)  │
│                 │     │                  │     │                 │
│ - Provisioner   │     │ - Capacity       │     │ - Size          │
│ - Parameters    │     │ - Access Modes   │     │ - Access Mode   │
│ - ReclaimPolicy │     │ - Mount Options  │     │ - StorageClass  │
└─────────────────┘     └─────────────────┘     └─────────────────┘
                              ▲
                              │ mount
                         ┌────┴────┐
                         │   Pod   │
                         └─────────┘

StorageClass definiert den Provisioner und Parameter. PV ist der tatsächliche Speicherplatz. PVC ist die Anforderung durch den Workload.

StorageClass konfigurieren

Eine StorageClass legt fest, welcher CSI-Treiber genutzt wird und wie Volumes erstellt werden.

AWS EBS StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
  encrypted: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Azure Disk StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-premium
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
  cachingmode: ReadOnly
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Wichtige Felder:

Feld	Bedeutung
`reclaimPolicy`	`Delete` löscht das Volume bei PVC-Löschung, `Retain` behält es
`volumeBindingMode`	`WaitForFirstConsumer` bindet erst bei Pod-Scheduling (empfohlen für Zonen-Awareness)
`allowVolumeExpansion`	Erlaubt nachträgliches Vergrößern des Volumes

PersistentVolumeClaim erstellen

Ein PVC fordert Speicher an. Bei dynamischem Provisioning erstellt Kubernetes automatisch ein passendes PV.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
  namespace: database
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-gp3
  resources:
    requests:
      storage: 50Gi

PVC im Pod einbinden

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: database
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:16
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
          subPath: pgdata
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: password
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: postgres-data

Den PVC-Status prüfen:

# PVC-Status anzeigen
kubectl get pvc -n database

# Details mit Events
kubectl describe pvc postgres-data -n database

# Zugehöriges PV finden
kubectl get pv | grep postgres-data

Access Modes verstehen

Access Mode	Abkürzung	Beschreibung	Typischer Einsatz
ReadWriteOnce	RWO	Ein Node liest/schreibt	Datenbanken, Single-Pod Workloads
ReadOnlyMany	ROX	Viele Nodes lesen	Shared Config, statische Assets
ReadWriteMany	RWX	Viele Nodes lesen/schreiben	Shared Uploads, CMS

RWO ist der häufigste Modus und wird von allen Cloud-Providern unterstützt. RWX erfordert spezielle Storage-Backends wie NFS, CephFS oder Azure Files.

CSI-Treiber installieren

Das Container Storage Interface (CSI) ist der Standard für Storage-Plugins seit Kubernetes 1.13. Jeder Cloud-Provider bietet eigene CSI-Treiber an.

AWS EBS CSI Driver

# Via Helm installieren
helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
helm repo update

helm install aws-ebs-csi-driver aws-ebs-csi-driver/aws-ebs-csi-driver \
  --namespace kube-system \
  --set controller.serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=arn:aws:iam::123456789:role/ebs-csi-role

Longhorn für On-Premise

Longhorn ist eine beliebte Open-Source-Lösung für verteilten Block Storage auf Bare-Metal-Clustern.

# Longhorn installieren
helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultDataPath="/var/lib/longhorn"

Longhorn erstellt automatisch eine StorageClass namens longhorn. Diese unterstützt Replikation, Snapshots und Backups.

Volume Expansion

Volumes vergrößern, ohne den Pod neu zu erstellen:

# PVC patchen - Storage von 50Gi auf 100Gi erhöhen
kubectl patch pvc postgres-data -n database \
  -p '{"spec":{"resources":{"requests":{"storage":"100Gi"}}}}'

# Status prüfen - Condition zeigt den Fortschritt
kubectl get pvc postgres-data -n database -o jsonpath='{.status.conditions}'

Voraussetzungen: Die StorageClass muss allowVolumeExpansion: true haben. Manche CSI-Treiber erfordern einen Pod-Neustart für die Dateisystem-Erweiterung.

Volumes können nur vergrößert, nie verkleinert werden.

StatefulSet mit Storage

Für Workloads mit mehreren Replicas und je eigenem Volume eignet sich ein StatefulSet mit volumeClaimTemplates:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-cluster
spec:
  serviceName: redis
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: ebs-gp3
      resources:
        requests:
          storage: 10Gi

Jedes Replica bekommt automatisch ein eigenes PVC: data-redis-cluster-0, data-redis-cluster-1, data-redis-cluster-2.

Troubleshooting

PVC bleibt im Status Pending:

# Events prüfen
kubectl describe pvc <name> -n <namespace>

# Häufige Ursachen:
# - StorageClass existiert nicht
# - CSI-Treiber nicht installiert
# - Keine Kapazität in der Zone
# - volumeBindingMode: WaitForFirstConsumer (wartet auf Pod)

Volume lässt sich nicht mounten:

# Pod-Events prüfen
kubectl describe pod <name> -n <namespace>

# CSI-Treiber Logs
kubectl logs -n kube-system -l app=ebs-csi-controller

FAQ

Was passiert mit meinen Daten, wenn ich ein PVC lösche?

Das hängt von der reclaimPolicy der StorageClass ab. Bei Delete wird das zugehörige Volume gelöscht. Bei Retain bleibt das PV erhalten und muss manuell bereinigt oder neu gebunden werden.

Wann brauche ich ReadWriteMany (RWX)?

Nur wenn mehrere Pods auf verschiedenen Nodes gleichzeitig in dasselbe Volume schreiben müssen. Für Datenbanken reicht ReadWriteOnce (RWO). RWX erfordert spezielle Backends wie NFS, CephFS oder Azure Files.

Kann ich den Storage-Typ eines bestehenden PVC ändern?

Nein. Sie müssen ein neues PVC mit der gewünschten StorageClass erstellen und die Daten migrieren. Kubernetes unterstützt kein In-Place-Ändern der StorageClass.

Wie funktioniert dynamisches Provisioning?

Wenn ein PVC eine StorageClass referenziert, kontaktiert der zugehörige CSI-Treiber automatisch die Storage-API (z.B. AWS EC2 API für EBS) und erstellt ein Volume. Danach wird automatisch ein PV-Objekt in Kubernetes angelegt.

Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kontakt aufnehmen Kontakt aufnehmen

Kubernetes Storage: CSI-Treiber und PV richtig nutzen