Volume Driver (Docker/K8s)

Docker: docker volume create --driver local-persist --opt mountpoint=/home/user/data my-vol Kubernetes (CSI): Du installierst den Treiber meist als DaemonSet. Dann nutzt du ihn in der StorageClass: provisioner: ebs.csi.aws.com. Der User merkt nichts davon (Abstraction).

1. CSI (Container Storage Interface)

Früher war der AWS-Treiber fest in Kubernetes einkompiliert ("In-Tree"). Um einen Bug im AWS-Treiber zu fixen, musste man ganz Kubernetes updaten. CSI ist der neue Standard. Treiber sind eigene Pods (Sidecars), die über gRPC mit dem Kubelet reden. "Mount Volume X nach Pfad Y". Das macht K8s extrem modular. Jeder Storage-Hersteller (NetApp, Pure) liefert seinen eigenen CSI-Treiber.

2. Multi-Attach (ReadWriteMany)

Die meisten Block-Treiber (EBS, GPD) können nur RWO (ReadWriteOnce). Nur ein Node kann die Disk mounten. Wenn du replicas: 3 hast, starten 2 Pods nicht ("Volume Multi-Attach Error"). Für Shared Storage brauchst du File-Lvl Treiber (NFS, EFS, CephFS). CSI Treiber melden ihre "Capability" an K8s, sodass der Scheduler Fehler verhindert.

3. Volume Snapshots

Moderne Treiber unterstützen Snapshots via API. kubectl apply -f snapshot.yaml. Der CSI Treiber sagt dem Storage Array: "Mach einen Backup-Snapshot (jetzt!)". Das erlaubt konsistente Datenbank-Backups direkt aus Kubernetes heraus, ohne Skripte.

Der komplexe CSI Attach-Detach-Lifecycle

Wenn in Kubernetes ein Pod geplant wird (z. B. auf Node B), der ein EBS-Cloud-Volume (AWS) nutzt, beginnt im Hintergrund eine massive, asynchrone CSI (Container Storage Interface) Orchestrierung. Der Controller-Prozess in der Master-Control-Plane sendet per gRPC den AWS-Befehl ControllerPublishVolume an den Cloud API Endpoint (aws ec2 attach-volume). Wichtig: Das Kubelet auf Node B ist blind! Es pollt geduldig, bis das Block-Device auch "physisch" im /dev/-Ordner im Linux-Kernel von Node B auftaucht (oft 5–15 Sekunden in Public-Clouds). Sobald der SCSI-Bus es erkennt, schaltet das lokale Kubelet um auf NodeStageVolume (Mounten ins globale Node-Directory) und anschließend zu NodePublishVolume (Bind-Mount via Linux Cgroups direkt in das Target-Directory). Hängt attach, bluten Deployments langsam aus, da Pods unzündbar in Phase "ContainerCreating" verharren.

CSI Topology-Aware Scheduling Delay

Wie erzwingt K8s, dass ein Pod (Frontend-App), der Disk-1 (angeklemmt an Server in der Availability-Zone eu-central-1a) benutzen muss, nicht vom Scheduler blind in Zone 1b deployed wird, wo er die Disk technisch unfähig zu mounten ist? Der moderne Ansatz ist VolumeBindingMode: WaitForFirstConsumer. Statt Disks sofort provisorisch beim Erstellen in einer zufriedengestellten AZ zu booten, wartet der CSI Provisioner passiv ab. Der Scheduler evaluiert erst CPU/RAM auf allen Nodes. Fällt die Wahl auf einen Server in 1a, kommuniziert der Scheduler via "Topology Annotations" mit dem CSI-Agent: "Der Pod landet in 1a, errichte dein SAN-LUN-Storage präventiv genau in dieser Zone." Das entkoppelt Workload-Platzie-Erfordernisse vom "Hardware ist blind"-Syndrom.

CSI Ephemeral Inline-Volumes vs. Persistent

Normales CSI triggert PersistentVolumes (PV/PVC). Der Storage-Lebenszyklus überdauert den Tod des Pods (die ID in AWS bleibt, Reconnect). Für hypermoderne Zero-Trust und Vault Architekturen gibt es CSI Inline Ephemeral Volumes. Im YAML des Pods referenziert man keinen PVC, sondern bindet den CSI Treiber direkt in die .spec.volumes Inlines ein (csi.driver: secrets-store.csi.k8s.io). Kubelet triggert bei Erschaffung den CSI Treiber auf dem Node local, es wird im Fluge RAM (tmpfs artig) oder kurzlebiges Secrets/Config Data generiert und direkt injiziert. Stirbt dieser Pod, reißt der Kubelet-Garbage-Müll automatisch alle CSI-Artefakte für diese Volume Instanz sofort unwiederbringlich ab, was die Cloud API Aufrufe (Attachment Hölle) massiv senkt und Security maximiert.