CSI WON’T SAVE YOU - Why “CSI Support” is not a storage strategy and you are being setup to fail.
summary
CSI handles only create attach detach remove and ignores replication disaster recovery and data mobility, so relying on it leads to scale and operational gaps. Arrays hit limits when Kubernetes creates thousands of volumes — think 20,000 LUNs and >100 CRUD ops/min — and vendor CSI drivers vary wildly. Portworx builds a Kubernetes-native pooled layer that consumes one block device per node and provides replication, app‑consistent snapshots to S3, autopilot resizing, RBAC via JWT and KMS encryption. DR uses declarative cluster pairs and achieves RPO of minutes or zero sync, and it works across clouds.
AI-written summary · about
chapters (7)
- 0:00Introduction and premise
- 2:16Stateless applications myth
- 8:38CSI limitations and scale issues
- 10:26Inverting storage strategy
- 13:34Portworx vs alternatives
- 16:27Kubernetes-native storage features
- 25:56Q&A session
related talks
48mCSI in Kubernetes
27mCeph-CSI: The Engine Behind Persistent Storage in Kubernetes
32mUnderstanding Kubernetes Storage: Getting in Deep by Writing a CSI Driver
22mCSI Driver X FUSE Drivers: a Kubernetes Object Storage Solution for AI/ML Data Portability
41mHDFS CSI Plugin: Speed Up Kubernetes in On-Premises Big Data Cluster
01h 27mIntro + Deep Dive: Kubernetes Storage SIG
35mBeyond Storage Management
40mCeph CSI Driver: Bridging Containers and Ceph