Storage in Kubernetes Stopped Being An Afterthought, and That Changes Everything

I remember the exact moment I realized Kubernetes storage was becoming a real problem at work. We had a containerized PostgreSQL instance running in production, and a developer asked the most innocent question: "Can we take a snapshot of just this database without shutting it down?"

I stood there blankly. The answer was no—not cleanly, anyway. We'd have to orchestrate it manually, coordinate with our storage vendor, potentially cause downtime. That was 2023. In that moment, I realized that Kubernetes had solved the easy problem (running stateless containers) and now the entire industry was scrambling to solve the hard one: keeping data safe and accessible in a distributed system.

Reading through the Kubernetes SIG Storage spotlight recently, I felt something shift in how I think about this problem. Storage in Kubernetes has matured from an awkward afterthought into a genuinely sophisticated domain, and the implications for how we build stateful systems are significant.

The Evolution From In-Tree Chaos to Real Abstractions

When Kubernetes first launched, storage was practically an accident. The assumption was that containers were ephemeral—you spin them up, they do work, they disappear. The idea that you'd run databases or stateful systems in Kubernetes seemed almost crazy.

That forced the Kubernetes project to do something interesting: they realized stateful workloads weren't going away, so they had to build proper abstractions. PersistentVolumes and PersistentVolumeClaims emerged as the core mental model, but initially, everything was baked into the core Kubernetes code as "in-tree plugins." This was messy. Every storage vendor had to submit code to the Kubernetes project itself.

Then CSI—Container Storage Interface—changed the game entirely. It moved storage drivers outside the core, allowing vendors to maintain their own implementations without touching Kubernetes internals. I've seen how much cleaner this makes operations. Instead of waiting for Kubernetes releases to get storage features, vendors can ship updates independently. That's real engineering.

What's Actually Happening Now

The current work coming out of SIG Storage tells me the group has moved past "basic integration" into genuinely difficult territory.

VolumeGroupSnapshot, which just hit GA, solves a problem I've encountered multiple times: how do you snapshot a multi-volume application atomically? A database using separate volumes for data and logs needs both captured at exactly the same moment, or you're in an inconsistent state. Before this, you either did complex orchestration manually or accepted the risk. Now it's a first-class Kubernetes primitive.

Changed Block Tracking is even more interesting to me. Incremental backups are fundamental to managing large datasets efficiently. Instead of copying terabytes of unchanged data repeatedly, you only copy what changed since the last backup. The fact that this is now built into the CSI abstraction means we're not reinventing this at every organization anymore.

And COSI—Container Object Storage Interface—signals that the SIG recognizes object storage as equally important as block storage. S3-compatible storage is everywhere now, and having a standardized way to provision and consume buckets through Kubernetes API is overdue.

What This Actually Means for People Building Things

Here's my honest take: this matters most to teams managing databases, data pipelines, or any stateful workload in Kubernetes.

The release of VolumeAttributesClass to GA is the win that caught my attention most. You can now dynamically adjust storage properties—IOPS, throughput—through the Kubernetes API without recreating volumes or going out-of-band. This feels trivial until you're in production and your peak load suddenly needs 5x the IOPS you provisioned. Before, that was pain. Now it's an API call.

What I find myself wondering, though: are organizations actually using these features? CSI adoption is solid, but the more advanced features like VolumeGroupSnapshot require both Kubernetes support and storage vendor support. I've seen plenty of environments still struggling with basic storage operations because they haven't updated their storage drivers or haven't invested in learning these capabilities.

I also think there's still a gap around operational visibility. We have better primitives now, but when a backup fails or a snapshot stalls, debugging that across the storage layer and Kubernetes layer is still painful.

The Real Shift

What strikes me most about this spotlight is that SIG Storage is no longer solving for "how do we make storage work in Kubernetes at all?" They're solving for "how do we make stateful workloads first-class citizens, complete with enterprise features like crash-consistent snapshots and incremental backups?"

That's a fundamentally different problem, and it means Kubernetes is genuinely mature for stateful workloads now—if you're willing to learn the abstractions.

The question I'm left with: if you're running databases or stateful systems in Kubernetes today, are you actually leveraging these newer features, or are you still operating them like legacy on-premise systems?

Source: This post was inspired by "Spotlight on SIG Storage" by Kubernetes Blog. Read the original article