Persistent volumes that just work. CSI installed automatically.
Every cluster is delivered with a CSI driver and default StorageClass. Create a PVC, and it binds. No day-2 storage debugging required.
The pain
In many Kubernetes environments, storage becomes a day-2 problem:
Manual CSI setup and configuration
Wrong defaults causing pending PVCs
Inconsistent StorageClass behavior across environments
Day-2 storage debugging instead of shipping features
K8S Engine approach
Storage should be a platform capability, not a project.
CSI driver installed automatically
Based on your chosen provider strategy, the appropriate CSI driver is configured during cluster creation.
Default StorageClass configured
A sensible default StorageClass is created and marked as default. PVCs work immediately.
Resize and snapshots
Volume expansion and snapshot capabilities are supported where the underlying provider allows.
Clear documentation
Storage behavior is documented per provider. No guessing about what's supported.
What "out of the box" means
# Create a PVC — it binds without extra steps
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10Gi
# No StorageClass specified — uses the default
# PVC binds. Volume provisions. Done.
Create PVC
PVC Binds
Use Storage
Honest constraints
Hybrid clusters can mix compute sources, but storage needs a defined strategy.
Primary storage provider (recommended)
For most clusters, define a primary storage provider. This gives you straightforward operations and predictable behavior.
Multi-StorageClass setups
Advanced setups with multiple StorageClasses across providers are supported as an enterprise feature. Requires explicit configuration.