Why CSI Plug-ins Hit a Wall in Modern Application Platforms

Any application modernization strategy on Kubernetes encounters a storage problem sooner or later. The Container Storage Interface standardized how clusters access existing arrays and cloud disks, but it defines a storage interface, not the policies, replication, and recovery that an application platform needs. This article shows where self-service provisioning, GitOps integration, and automated Day-2 operations need more than the interface alone, and where higher-level storage automation fits.

Kubernetes turned ten in 2024, and the workload mix has inverted since launch. The platform built for stateless, ephemeral containers now hosts the most stateful systems enterprises run. The CNCF 2024 annual survey of 689 IT professionals found 74 percent of organizations using containers for stateful applications.

The Portworx-commissioned Voice of Kubernetes Experts 2024, a Dimensional Research survey of 527 Kubernetes practitioners, reported that 98 percent run data-intensive workloads on cloud-native platforms, with databases, analytics, and AI/ML leading the way. Stateful workloads have moved from the exception to the center of most modernization plans.

The storage layer underneath those workloads runs on the Container Storage Interface. CSI does its job well, and the job is a narrow one by design. It standardizes the interface between Kubernetes and storage, and it leaves backup, replication, disaster recovery, and application-consistent operations to other layers.

CSI in Plain English

CSI reached general availability in Kubernetes v1.13 in January 2019, after arriving as alpha in v1.9. It provided storage vendors with a standard way to expose block and file storage to containers without changing the core Kubernetes code. The architecture is worth a walk-through first, because the interface itself sets the limit of what CSI covers, not any single vendor’s driver. The operational work beyond it – backup, replication, disaster recovery, and policy – drives the sections below. 

A CSI driver is a shim with a few moving parts.

1. Controller plugin: one per cluster; it handles volume lifecycle calls such as create, delete, attach, and snapshot, and it reaches the external storage system through its API.
2. Node plugin: runs on every worker node and mounts or unmounts the volume so the pod uses it.
3. Sidecars: helper containers such as the provisioner, attacher, snapshotter, and resizer, each watching the Kubernetes API and firing the matching CSI call.

Every volume operation becomes an API call to the array or cloud service, followed by a wait for the reply. For a handful of volumes the cost stays invisible, but it surfaces at scale and on Day-2.

Storage Does Not Behave Like Compute

Compute in Kubernetes is disposable, so when a pod dies it respawns on another node and the scheduler treats the move as routine. Storage refuses to behave the same way. A block volume binds to one node, and the data inside it has to outlive the pod, the node, and sometimes the cluster. The shim moves the volume, while the replication, snapshot consistency, and recovery logic stay in the external system it calls.

The split produces two problems at scale. First, provisioning, snapshot, and monitoring actions route through API calls to the external system, and storage operations become a bottleneck as PV counts and churn rise, especially when a CSI controller or backend API serializes or rate-limits attach, provision, resize, and snapshot calls. The effect depends on the driver and the backend rather than on Kubernetes itself. Second, the live data sits outside the cluster’s declarative model, so the platform has no native handle on it the way it has on a Deployment.

A storage platform built for Kubernetes answers this differently. It runs the policy and reconciliation for provisioning, replication, snapshots, and quality-of-service as Kubernetes resources, while still presenting volumes through CSI. Portworx is one example, and OpenEBS and Rook with Ceph take similar in-cluster approaches. Cloud-vendor CSI drivers such as AWS EBS, Azure Disk, and Google Persistent Disk are infrastructure integrations with varying support for snapshots, expansion, and topology, not full data platforms. The distinction is where policy and reconciliation live, not whether every operation runs inside Kubernetes.

The above figure shows a reference architecture for storage automation on a Kubernetes application platform. Developer and GitOps requests enter the control plane. The storage automation layer sits between the control plane and the storage hardware, providing provisioning, replication, snapshots, and policy management layered above the CSI interface.

Self-Service Provisioning Breaks At The Storage Line

Platform engineering is now how most large teams ship. The Voice of Kubernetes Experts 2024 found 96 percent of surveyed organizations running a platform engineering function. The model runs on a simple division of labor. A platform team builds an internal developer platform with golden paths, developers request what they need through self-service, and the platform provisions it. For stateless services, the path stays clean.

Storage is where the golden path tends to stop. A developer requests a database from a self-service catalog, but the backup policy, replication factor, performance tier, and disaster-recovery target are routed to a ticket and a storage admin. CSI provisions the volume, but backup, replication, disaster recovery, compliance, and application-consistency policies usually need extra controllers, storage-platform features, or external automation. The work meant to be self-service becomes a manual exception, and modernization slows at the layer carrying the business data.

GitOps Stops At The Volume Boundary

GitOps made the cluster’s desired state a file in Git, reconciled by an agent such as Argo CD or Flux. It works because a Deployment, a Service, and a ConfigMap are fully described by their manifests, whereas persistent data is not. A volume’s contents, its point-in-time snapshots, and its replication state never live in a YAML file, so the most valuable part of a stateful application sits outside the GitOps loop.

Teams feel this as the GitOps gap, the space between the declarative state in the repository and the live data in the cluster. Tools such as Velero, a widely used open source Kubernetes backup and migration project, close part of the gap by backing up Kubernetes resources and persistent volume data together. Portworx Backup goes further, adding application-consistent snapshots, centralized multi-cluster management, and namespace- or pod-level granular restore across any cloud or on-prem cluster. For a platform team, data protection and mobility have to become declarative resources, the same way a Deployment is, or GitOps will govern only half the application.

Day-2 Is Where Modernization Lives Or Dies

Day-1 is provisioning, and Day-2 is everything after, where the shim model shows its age across three recurring failure modes.

• Stuck volumes after a node failure: when a node goes down, its volumes stay attached from the storage system’s view, and pods will not reschedule until something force-detaches them. Some drivers and managed cloud controllers force-detach on their own, while others wait on a manual action, so recovery time depends on the driver.
• Volume expansion: online resize has matured and is stable in Kubernetes since v1.24, though it still requires the StorageClass, filesystem, and underlying disk to align, and the driver to support expansion.
• Snapshot restore: a CSI snapshot is a data-plane primitive, but restoring a stateful app still needs PVC recreation from the snapshot, application resource coordination, and namespace and storage-class mapping, validated under pressure.

These failure modes are not edge cases. The Spectro Cloud State of Production Kubernetes 2025 survey of 455 engineers, architects, and executives found that more than half described their clusters as manual snowflakes despite claiming a mature platform function, and that storage is often where the manual work hides. The 2025 Voice of Kubernetes Experts follow-up, again commissioned by Portworx, found that persistent storage was named by 31 percent of respondents as a top operational challenge, alongside security and resilience.

A storage platform layered on Kubernetes turns these into platform behavior rather than runbook steps. Portworx, installed as an operator, exposes disaster recovery schedules, application-consistent snapshots, and cross-cluster migration as declarative custom resources. Those resources let a standard GitOps tool drive recovery and keep the volumes and their manifests aligned to the point of protection. Velero and OpenEBS address parts of the same Day-2 surface, so the choice is one of scope rather than category.

CSI Interface Versus A Storage Platform On Kubernetes

The split of responsibilities looks like this. Capabilities vary by driver, backend, and platform, and most storage platforms still present volumes through CSI.

Where the operational work lands on Day-2 sharpens the same point.

Why Care About The Storage Layer

For enterprise buyers, the implication is a sharper procurement checklist with three axes. The first axis is ownership, since a storage layer running its lifecycle inside Kubernetes behaves differently from one routing every operation through an external box and its API limits. The second axis is Day-2 automation, where a platform that expresses backup, replication, and disaster recovery as declarative resources removes the late-night runbook that a person executes by hand. The third axis is portability, because protected data moving between clusters and clouds with its manifests turns a migration from a manual dump into a declarative step.

For storage vendors, the pressure is to ship a platform service rather than a driver. A CSI driver alone provisions volumes and leaves the operational surface to the customer, and platform teams now treat the operational surface as part of the product they buy.

Key Takeaways

CSI solved the integration problem of its era and gave Kubernetes a clean, vendor-neutral path to existing storage. The platform it now serves needs more than an interface; it requires backup, replication, disaster recovery, and application-consistent operations expressed as policy that the control plane reconciles. CSI stays the standard way to attach storage, and the higher-level automation sits above it. For platform teams, enterprises, and the developers who depend on them, storage that behaves like a managed platform service is what drives modernization through Day-2 rather than stalling at the data line.