Question 1

Why do most CSI drivers struggle as my Kubernetes environment scales?

Accepted Answer

Most CSI drivers for traditional storage arrays are thin shims over legacy provisioning workflows that were never designed for high‑churn, machine‑scale environments like Kubernetes. Every PersistentVolume operation requires extra API calls to an external array controller, which adds latency and amplifies bottlenecks as you go from dozens to hundreds or thousands of volumes.

Question 2

Our PoC with a CSI driver went fine—why do problems only show up later?

Accepted Answer

In small PoCs, you might only create a handful of volumes, so the extra provisioning calls and controller work are barely noticeable. At production scale, those same workflows multiply across hundreds or thousands of PVs, stressing controller CPU, array APIs, and even Kubernetes control plane resources—so pod startup, scale‑out, and recovery all slow down dramatically.

Question 3

What does “CRUD churn” mean in this context?

Accepted Answer

CRUD churn refers to the rapid create/read/update/delete lifecycle of volumes and pods that’s normal in modern Kubernetes environments—for CI pipelines, AI/ML workloads, multi‑tenant platforms, and elastic microservices. Traditional arrays and their CSI drivers tend to provision in seconds, while cloud native solutions like Portworx measure provisioning in milliseconds, so churn at scale exposes those architectural gaps quickly.

Question 4

Can’t I just turn on more features in my array to fix this?

Accepted Answer

Adding features like snapshots, replication, or extra monitoring on the array side usually increases the number and complexity of API calls required for every volume operation. At scale, that additional overhead makes the CSI driver and array controller an even bigger bottleneck for Kubernetes rather than a performance accelerator.

Question 5

What is “cloud native storage” (CNS), and how is it different from a CSI driver on an array?

Accepted Answer

Cloud native storage solutions like Portworx keep all provisioning and lifecycle operations inside Kubernetes itself, instead of depending on an external array control plane for every action. They still use CSI for integration, but the heavy lifting—provisioning, replication, snapshots, and health tracking—happens in the cluster, which reduces latency, improves observability, and keeps performance flat even as you add hundreds of volumes.

Question 6

Do I have to abandon my existing storage arrays to use Portworx?

Accepted Answer

No. Portworx can abstract existing arrays by consuming their block devices as backing storage and pooling them inside Kubernetes. That lets you keep your current investments while gaining cloud native behavior—consistent features, faster provisioning, and hybrid or multi‑cloud portability—regardless of the underlying array vendor or model.

Question 7

What kinds of limits can I hit when I attach PVs directly from arrays or cloud disks?

Accepted Answer

When you rely on external volumes, you’re constrained by LUN and attachment limits on hosts—exactly like in traditional hypervisor environments. Even hyperscale clouds cap the number of volumes per instance (for example, widely used EC2 types are limited to a few dozen EBS volumes), which can prevent you from fully utilizing your Kubernetes worker nodes as PV counts grow.

Question 8

How does Portworx keep up with provisioning demands at large scale?

Accepted Answer

Portworx provisions volumes natively inside Kubernetes and avoids chatty, imperative APIs to external storage controllers for each operation. In Portworx’s own testing, provisioning times stayed flat as they scaled from 200 to 600 PVs—and average volume creation time was on the order of 160 milliseconds, not seconds.

Question 9

What should I test in a PoC to know if my CSI driver will work at scale?

Accepted Answer

Go beyond “happy path” demos and simulate high‑churn scenarios: mass PVC creation, frequent scale‑out/scale‑in of stateful workloads, and node failure plus pod rescheduling under load. Measure provisioning time, pod startup and recovery times, control‑plane CPU/memory usage, and how the system behaves when the array is under stress or rate‑limiting API calls.

Question 10

Where does Portworx fit if I’m already standardizing on Pure Storage arrays?

Accepted Answer

Portworx acts as a cloud native data platform that runs on top of your existing Pure arrays or cloud storage, giving Kubernetes clusters fast, resilient, and portable storage semantics while still leveraging enterprise‑grade hardware underneath. You get the best of both worlds: proven array capabilities plus a storage layer designed specifically for Kubernetes‑scale CRUD patterns.

Data on Kubernetes at Scale: Why Your CSI Driver Can’t Keep Up

Part 4: The Solution – Comprehensive Data Storage Infrastructure with Portworx and Pure

Part 3: The Challenge – Bringing Proven Enterprise Data Storage to Kubernetes

Part 2: The Helmsman Arrives! – A History of Containers and Kubernetes

Part 1: How We Got Here – Virtualization Solves Enterprise Challenges

Author: Tim Darnell