Google Cloud Storage: Den CSI-Treiber für GKE installieren

Grundlagen und Architektur

Für Block-Storage in GKE ist der GCE Persistent Disk CSI-Treiber der zentrale Mechanismus. Er ersetzt den früheren in-tree PD-Treiber (Persistent Disk). Dieser Treiber war direkt in Kubernetes integriert und wurde bereits seit GKE-Versionen um 1.18 standardmäßig eingeführt. In neueren GKE-Clustern ist er oft schon aktiviert.

Der Vorteil des Treibers ist, dass er API-Aufrufe an Compute Engine integriert und dynamisches Provisionieren, Snapshots, Cloning (ab bestimmten Versionen) sowie bessere Trennung/Modularität gegenüber dem in-tree-Ansatz erlaubt.

Für Dateifreigaben wie zum Beispiel für NFS-ähnliche Zugriffe steht der Filestore-CSI-Treiber zur Verfügung, der eine Anbindung an Filestore-Instanzen ermöglicht. Der Arbeitsfluss ähnelt dem des PD-Treiber-Setups, allerdings mit zusätzlichen Überlegungen zur Instanzverwaltung und Mount-Level-Konfiguration.

Darüber hinaus gibt es den GCS-Fuse-CSI-Treiber für das Einbinden von GCS Buckets als Dateisystem via FUSE, der optional via Add-on aktiviert werden kann. Allerdings eignet sich GCS Fuse nicht für Anwendungen mit hohen IOPS-Anforderungen, sondern eher für leseintensive oder Archiv-Workloads.

Zu beachten ist, dass Google die Treiberkomponenten im Cluster bei Updates verwaltet und aktualisiert, und Admins sollten in der Regel nicht manuell in die Deployment-Details eingreifen.

Voraussetzungen

Bevor die Installation gestartet werden kann, müssen verschiedene Bedingungen erfüllt sein. Dazu gehören die folgenden:

• Es muss ein aktives GKE-Cluster in einer unterstützten Version (zum Beispiel ab v1.18 oder höher) installiert sein.
• gcloud und kubectl müssen korrekt konfiguriert mit entsprechenden Zugangsdaten und Zugriffsrechten versehen sein.
• notwendige GCP-APIs müssen freigeschaltet sein (Compute Engine API, Kubernetes Engine API, eventuell Filestore API)
• Es sollten möglichst keine Altkonfigurationen aktiv sein, die mit dem alten in-tree PD-Treiber arbeiten. In GKE-Versionen ab 1.22 wird die Migration zur CSI-basierten Variante empfohlen beziehungsweise notwendig
• Im Projekt müssen ausreichende IAM-Rechte eingerichtet sein, insbesondere zum Erstellen und Verwalten von Disks, Filestore-Instanzen.
• Für Filestore sollte eine geeignete Netzwerktopologie vorhanden sein, zum Beispiel VPC, Subnetz, eventuell Shared VPC, und ebenso eine Zugriffsstruktur, damit die Instanz von den Node-Pools erreichbar ist.

Darüber hinaus ist es empfehlenswert, zusätzliche Maßnahmen zu unternehmen:

• Eine Übersicht über die Zonen anlegen, in denen der Cluster läuft, um passende Zonenzuordnungen bei Volumes zu gewährleisten.
• Entscheiden, ob regionale PDs oder zonale PDs verwendet werden sollen beziehungsweise prüfen, ob das in GKE unterstützt wird.
• Im Voraus Snapshots und Daten-Backups planen, zum Beispiel die Integration des CSI Snapshot Controllers abwägen.

Schritt 1: Prüfen und Aktivieren des GCE PD CSI-Treibers

In GKE-Standard-Clustern ist der GCE PD CSI-Treiber nicht zwangsläufig automatisch aktiv. In Autopilot-Clustern hingegen ist er standardmäßig aktiviert und kann nicht deaktiviert werden.

Anwender können den Status mit folgendem Befehl prüfen:

gcloud container clusters describe <CLUSTER_NAME> --region <REGION>

Danach sollte der Admin im Abschnitt addonsConfig.gcePersistentDiskCsiDriverConfig.enabled den Wert true finden.

Wenn der Wert false oder nicht gesetzt ist, können Nutzer in einem bestehenden Cluster (Standard-Modus) das Add-on wie folgt aktivieren:

gcloud container clusters update <CLUSTER_NAME> \
  --update-addons=GcePersistentDiskCsiDriver=ENABLED

In einem Neuanlage-Szenario lässt sich dies direkt bei der Cluster-Erstellung mit --addons=GcePersistentDiskCsiDriver aktivieren.

Google rät davon ab, den PD-CSI-Treiber manuell aus dem GitHub-Repository in einem GKE-Cluster auszurollen. Der Anbieter empfiehlt ausdrücklich, sich auf die GKE-interne Verwaltung zu verlassen.

Schritt 2: StorageClass für GCE Persistent Disk definieren

Damit Kubernetes dynamisch Volumes mit dem PD-CSI-Treiber bereitstellen kann, benötigt der Admin eine StorageClass mit dem passenden provisioner und sinnvollen Parametern.

Ein Beispiel für eine StorageClass mit SSD:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-ssd-sc
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
  replication-type: none
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion:  true

Der Befehl volumeBindingMode: WaitForFirstConsumer wird empfohlen, weil die Bindung an die Zone, in welcher der Pod letztlich läuft, erst beim Scheduling erfolgt. So wird vermieden, dass die Disk in einer nicht passenden Zone erstellt wird.

Die Anweisung allowVolumeExpansion: true erlaubt darüber hinaus nachträgliches Vergrößern des Volumes, sofern dies unterstützt wird.

Der type-Parameter kann unter anderem pd-standard, pd-ssd oder pd-balanced sein, je nach gewünschter Performance des Speichermediums.

Weitere Parameter wie Verschlüsselung (zum Beispiel mit CMEK), Labels, Taints oder Replikationsoptionen können in der StorageClass spezifiziert werden.

GKE bringt bei vielen Standard-Installationen bereits StorageClasses mit Namen wie standard-rwo oder premium-rwo, die intern den PD-CSI-Treiber verwenden.

Danach ist der Admin in der Lage eine, StorageClass in seinem Kubernetes-Cluster zu erstellen oder aktualisieren. Dies geschieht mit folgendem Befehl.

kubectl apply -f storageclass.yaml

Der Inhalt einer StorageClass kann beispielsweise wie folgt aussehen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: pd.csi.storage.gke.io
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Nach dem Anlegen der StorageClass kann der Nutzer mit kubectl get sc überprüfen, ob die neue SC verfügbar ist.

Schritt 3: PersistentVolumeClaim anlegen

Sie können nun PersistentVolumeClaims (PVCs) erstellen, die auf die StorageClass zugreifen und automatisch Google Persitent Disks zur Verfügung stellen. Dies geschieht mit diesem Code:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gke-pd-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: pd-ssd-sc
  resources:
    requests:
      storage: 10Gi

Der Befehl zum Anwenden lautet:

kubectl apply -f pvc.yaml

Sobald ein Pod die PVC verwendet, erstellt GKE eine neue Persistent Disk im zugehörigen Projekt und bindet sie an die Node, auf die der Pod läuft. Der PVC sollte dann den Status Bound haben.

Die erzeugte Disk hat standardmäßig denselben Namen wie der PVC (plus interne Suffixe).

In der GCP-Console ist das Volume dann unter Compute Engine → Disks zu finden. Falls ein Pod in einer anderen Zone geplant ist, gewährleistet WaitForFirstConsumer dafür, dass Disk und Pod in derselben Zone liegen.

Es ist zudem möglich, statisch vorhandene Disks, zum Beispiel aus dem externen Management, als PVs über CSI zu referenzieren, aber das ist ein Spezialfall.

Schritt 4: Funktionen überprüfen

Nach den obigen Schritten sollten Administrator unbedingt den Status und die Funktion der CSI-Komponenten kontrollieren. Dabei können CSI-Treiber-Pods mittels kubectl get pods -n kube-system | grep csi angezeigt werden. Die CSI-Pods sollten im Namespace kube-system im Status Running sein.

Die Anweisung kubectl get storageclass listet die StorageClass auf und zeigt, ob diese aktiv sind. Um den Status Bound zu überprüfen, gibt der Admin kubectl get pvc ein. Damit stellt er sicher, dass die PVCs korrekt an die Node angebunden ist.

Mit einem Test-Pod können Sie die Disk als Mount nutzen. Ein Beispiel hierfür dies:

apiVersion: v1
kind: Pod
metadata:
  name: pd-test-pod
spec:
  containers:
  - name: test-container
    image: ubuntu
    command: ["sleep", "3600"]
    volumeMounts:
    - name: test-volume
      mountPath: /data
  volumes:
  - name: test-volume
    persistentVolumeClaim:
      claimName: gke-pd-pvc

Um festzustellen, ob der Mount erfolgreich war, lässt sich ein simpler Test mit dem Befehl kubectl exec -it pd-test-pod -- /bin/bash

> echo "hello world" > /data/foo.txt durchführen.

Diese scheinbar triviale Operation validiert mehrere Aspekte gleichzeitig:

• Der Mount-Point /data ist erreichbar
• Der Pod hat Schreibrechte auf das Volume
• Das Dateisystem reagiert korrekt auf I/O-Operationen

Die reale Effizienz eines persistenten Speichers zeigt sich erst nach einem Pod-Neustart. Führen Sie daher einen gezielten Persistenz-Test durch:

• Als erstes muss eine persistente Testdatei vor dem Neustart angelegt werden:

kubectl exec -it pd-test-pod -- sh -c 'echo "Diese Datei sollte den Pod-Neustart überleben" > /data/persistence-validation.txt'

• Danach entfernen Sie den Pod kontrolliert:

kubectl delete pod pd-test-pod

• Für das Erstellen eines neuen, identischen Pods genügt Folgendes:

kubectl apply -f pod.yaml

• Zuletzt wird die Datenpersistenz nach dem Neustart wie folgt validiert:

kubectl exec -it pd-test-pod -- cat /data/persistence-validation.txt

Ein erfolgreicher Test beweist, dass das Storage-System die Daten tatsächlich persistent speichert, also unabhängig vom Pod-Lebenszyklus.

Zusätzlich können Admins eine erweiterte Validierung der Snapshot-Funktionalitäten durchführen. Dies ist vor allem für die geplanten Backup- und Disaster-Recovery-Szenarien wichtig, die im Notfall zuverlässig operieren müssen. Die Befehle für das Anlegen eines VolumeSnapshot für Backup-Zwecke und den Test einer Wiederherstellung aus diesem Snapshot sehen so aus:

kubectl apply -f snapshot.yaml

kubectl apply -f pod-from-snapshot.yaml

Nicht zuletzt stehen den Anwendern bei Problemen mehrere Diagnoseoptionen zur Verfügung:

• Die StorageClass-Konfiguration überprüfen:

kubectl get storageclass

kubectl describe storageclass fast-ssd

• Die PersitentVolumeClaims anzeigen und prüfen:

kubectl get pvc

• Vorhandene PVC lassen sich so anzeigen:

kubectl get pv

Detaillierte Pod-Informationen inklusive Volume-Mounts lassen sich hiermit abrufen:

kubectl describe pod pd-test-pod

Die methodische Validierung der Kubernetes-Storage-Konfiguration durch praktische Schreib-/Lese-Tests, Persistenz-Checks und Snapshot-Überprüfung stellt sicher, dass die Anwendungen zuverlässig auf persistente Daten zugreifen können. Dieser Ansatz identifiziert Probleme frühzeitig und gewährleistet, dass die Storage-Lösung funktional und betriebsbereit ist. Dies lohnt sich, da Storage-Probleme in einer produktiven Umgebung schwieriger zu beheben sind, als im Vorfeld der Entwicklungsphase präventive Tests durchzuführen.

Besonderheiten und technische Details

Neben der grundlegenden Funktionsweise bieten die GKE-Persistent-Disks (PD) und ihre CSI-Treiber einige Besonderheiten, die Administratoren bei der Planung und im Betrieb kennen sollten.

Snapshots und Wiederherstellung

Der PD-CSI-Treiber unterstützt Volume-Snapshots über die Kubernetes-CSI-Snapshot-API. Voraussetzung dafür ist ein installierter CSI Snapshot Controller, der in GKE häufig als Add-on bereitgestellt wird. Ob ein Volume tatsächlich als CSI-Volume eingebunden ist, lässt sich in der PersistentVolume-Definition leicht prüfen: Der Eintrag csi.driver: pd.csi.storage.gke.io

weist eindeutig auf den PD-CSI-Treiber hin. Snapshots ermöglichen eine schnelle Wiederherstellung von Datenständen, etwa nach fehlerhaften Bereitstellungen oder Konfigurationsänderungen.

Volume Cloning

Seit etwa GKE-Version 1.22 unterstützt der Treiber zudem Volume Cloning. Damit können Administratoren bestehende Volumes als Vorlage für neue Datenträger verwenden, ein nützliches Feature etwa für Testumgebungen oder parallele Entwicklungs-Workloads. Wichtig ist, dass der verwendete PD-Treiber diese Funktion ebenfalls unterstützt.

Topologie und Zonenausrichtung

Bei zonalen GKE-Clustern ist es entscheidend, dass Persistent Disks in derselben Zone wie die jeweiligen Nodes erstellt werden. Nur so lassen sich Latenzprobleme und Fehler beim Mounten vermeiden. Der Parameter volumeBindingMode: WaitForFirstConsumer hilft hier, da das Volume erst dann bereitgestellt wird, wenn der Pod-Scheduler die Zielzone des Workloads kennt.

Multi-Attach und Zugriffstypen

Standardmäßig erlauben Persistent Disks nur den Modus ReadWriteOnce: sie können also jeweils nur von einem Node gleichzeitig gemountet werden. Wer Mehrfachzugriffe benötigt, sollte auf Filestore ausweichen. Dieser NFS-basierte Dienst erlaubt den Modus ReadWriteMany und ist damit für gemeinsam genutzte Dateisysteme oder Anwendungen mit parallelem Schreibzugriff besser geeignet.

Filestore CSI und Konfiguration

Für den Einsatz von Filestore muss der entsprechende CSI-Treiber aktiviert sein. Bei Standard-GKE-Clustern geschieht das per --update-addons=GcpFilestoreCsiDriver=ENABLED.

Der Provisioner lautet in diesem Fall filestore.csi.storage.gke.io. Mit ihm lassen sich sowohl dynamische als auch statische Freigaben einrichten – meist über klassische NFS-Mounts.

Automatisierung und Deployment-Hinweise

Google weist ausdrücklich darauf hin, den PD-CSI-Treiber nicht manuell in GKE-Clustern zu installieren. Stattdessen sollte stets die integrierte Bereitstellung über GKE-Mechanismen genutzt werden, um Kompatibilitätsprobleme zu vermeiden.

Ressourcenverbrauch und Overhead

Die CSI-Komponenten verursachen nur geringe Systemlast: Sie benötigen auf den Nodes meist nur wenige Dutzend Megabyte RAM und minimale CPU-Ressourcen. Lediglich die Logdateien können auf Dauer spürbar Speicherplatz auf den Boot Disks beanspruchen, insbesondere in Clustern mit hohem Storage-Traffic.

Upgrade-Fallen und Migration

Beim Upgrade von GKE auf neuere Versionen – etwa ab 1.25 – kann es vorkommen, dass ältere PersistentVolumes nicht mehr korrekt starten, wenn noch in-tree-Treiber im Einsatz sind. Daher empfiehlt es sich dringend, vor größeren Versionssprüngen sicherzustellen, dass alle PVs erfolgreich auf die CSI-Treiber migriert wurden.