Kubernetes Storage Is Cloud-Native’s Hardest Scaling Problem

Kubernetes has made scaling compute look almost embarrassingly easy. Want more resources? Just spin up some more Pods. A node goes offline? Kubernetes will reschedule your workloads elsewhere. Traffic goes down? Scale everything back.

Then storage enters the chat, and it’s a different story altogether.

A Pod can be ephemeral. A database cannot. Containers can hop between nodes in seconds, but the data they depend on must live somewhere, with all its own limitations around capacity, latency, throughput, and reliability. Kubernetes can abstract away the storage interface, but it cannot eliminate the physical limitations of the storage itself.

This leads to an awkward mismatch at the very heart of cloud-native computing. Compute is designed with elastic scaling in mind, while persistent storage must know the exact location of the bits. With Kubernetes now running more and more stateful workloads, including databases and AI infrastructure, the cracks are starting to show.

Compute moves more easily than data

Kubernetes’ PersistentVolume system deliberately separates storage from the lifecycle of the Pod consuming it. A PersistentVolume can survive a Pod disappearing and later be attached to another workload. That’s essential for stateful applications, and it introduces a level of complexity that doesn’t exist to the same degree with CPU and memory.

For stateless applications, if you need more capacity, Kubernetes can just schedule a new Pod on an available node. For stateful apps, it needs to ask other questions. Where’s the data? Can the Pod see it? Is the access mode supported? What’s the remaining capacity in the zone? What if the node hosting the data fails?

CSI (the Container Storage Interface) gives Kubernetes a standard way to communicate with storage backends. It solved an important architectural challenge by letting storage drivers evolve independently of the Kubernetes core. That being said, it’s an interface, not an elastic resource manager.

The storage backend still has to provide the capacity and performance the app demands.

Shared storage does not equal a free pass

That brings us back to shared storage. If a Pod can access data stored on a shared backend accessible from many nodes, it becomes more mobile. You don’t lose your data if a node goes down, and you don’t need to replicate all your data on every server.

The trade-off, however, is that the storage path now includes the network.

Latency is critical. Bandwidth is critical. Network congestion is critical. A storage system that works great with a few apps can break down under hundreds of Pods.

Workloads also demand very different things from storage. A database might require low-latency random writes. A data pipeline might need sustained write throughput. An AI cluster might need to rapidly copy huge models while several inference containers start up at once.

One shared storage system can technically serve all three. That doesn’t mean it should.

And this is why Kubernetes storage is a capacity planning problem. Platform teams must consider IOPS, throughput, latency, replication, and topology in addition to storage size.

Sometimes local storage is the answer

Node-local storage offers a different trade-off. Kubernetes can use storage devices attached directly to individual nodes, avoiding the network overhead of shared storage. That can make local storage attractive for latency-sensitive workloads where performance matters more than portability. 

The problem is that the data is tied to that node. If the node fails, Kubernetes can move the application to another node, but the application can’t simply take its local disk with it. The performance advantage comes at the cost of resilience and flexibility.

While Kubernetes does take into consideration the node affinity required by local PersistentVolumes, the storage still resides on the original node. The Kubernetes docs note that local volumes depend on the availability of the node and therefore are not a good fit for every workload.

This is a standard cloud-native trade-off: you sacrifice some mobility for better performance. There are scenarios, specifically with databases, caches, and other latency-sensitive applications, where this makes perfect sense. It would be a mistake, however, to assume that cloud-native means all workloads should use the same type of storage. The workload usually decides.

Stateful workloads expose the problem

Databases make these trade-offs all the more visible. Kubernetes StatefulSets allow workloads to have stable identities and persistent storage. So if a StatefulSet Pod is rescheduled, Kubernetes can reconnect it to its persistent volume rather than treating it like a completely new workload.

This does not, however, mean that the database is elastic.

Scaling out a database includes replication, consistency, and data distribution. Adding storage capacity depends on support from the storage driver. While Kubernetes can expand CSI volumes without taking them offline, the underlying CSI driver must support volume expansion for it to work.

And then there’s performance.

A database does not care if Kubernetes was able to attach a 2TB volume; it cares whether that volume provides the IOPS, latency, and throughput the workload needs. This is the reality of cloud-native storage: storage capacity is only one part of the picture.

AI is making it harder

AI workloads have changed storage from a back-end infrastructure problem to a performance issue. Inference systems might need to load large models, hold KV-cache data, and pull information from a vector index. These requirements put different pressures on the storage system, which means simply throwing faster hardware at the problem isn’t always enough.

Portworx’s overview of running AI inference on Kubernetes says the challenge is as much about moving data as it is about computing. Model-weight loading, KV-cache operations, and vector queries can put pressure on different components of the data pipeline. This presents an unfortunate scenario for companies investing in GPU clusters: the cluster may have a lot of compute power, but the accelerators may be waiting on data.

The same holds beyond AI: a Kubernetes cluster might have abundant CPU and memory available, but the application has stalled due to storage saturation. The cluster is not short of compute. It is short of data.