Psst….Your Infrastructure Doesn’t Understand Kubernetes
There was a time–honestly, not that long ago–when provisioning storage was an act of patience.
You filed a ticket. Someone approved the ticket. Someone else (maybe even the same person) logged into something arcane and provisioned a volume. You waited. It showed up eventually. If it worked, you were grateful. And if it didn’t, you filed another ticket.
Then Kubernetes happened. It was clearly not just as a scheduler or a container orchestrator: It normalized automation and delegated infrastructure to the user. It taught people to expect that compute, network, and storage would behave like code. And storage—the old-world heavyweight of centralized control–hadon’t entirely caught up.
“We’re no longer talking about an admin spinning up a few volumes for the team,” says Alon Horev, cofounder and VP of Technology at VAST. “Now it’s a system where users are creating volumes themselves—sometimes through automation, sometimes dozens of times a day.”
This shift is not cosmetic. It’s not an edge case. It’s a full inversion of responsibility.
In the Kubernetes world, infrastructure doesn’t just belong to users—it’s created by them. And the implications for how storage is designed, governed, and secured are massive.
“Back in My Day Admins Were the API”
In the traditional model, storage was something static. Fixed capacity. Manually provisioned. Controlled by humans and, more importantly, by process.
You didn’t build applications around dynamic volume creation. You asked for what you needed, and if it wasn’t enough, you learned to work within your quota and escalated if you had to.
This made sense when environments were static, when clusters were monolithic. And when workloads didn’t scale up and down ten times a day.
But Kubernetes taught developers a different rhythm. Jobs aren’t scheduled once—they’re orchestrated, retried, autoscaled. Infrastructure isn’t provisioned by sysadmins—it’s declared by YAML and delivered via controller. And that includes storage.
The Day Your Job Became a User
“Imagine a job that runs ten times a day,” Horev says. “It doesn’t just run compute—it spins up volumes. The storage platform has to handle that dynamically.”
This is the new baseline: ephemeral workloads that expect infrastructure to respond in real time. Not just compute nodes and pods, but filesystems, object stores, and persistent volumes.
Ah but see, legacy storage systems weren’t built to handle a world where jobs, not people, are the users. They weren’t built to dynamically generate credentials, enforce per-user quotas, or guarantee quality of service on a per-application basis. They were built for admin-defined access patterns and long-lived resources.
Which means, when dropped into a Kubernetes-native environment, they…break. Or maybe they just become bottlenecks. Or, as Horev points out, they force the entire stack to bend to their shape.
Delegation...Without Giving Away the Castle
Relax though. Fixing this doesn’t mean giving up control.
What it does mean though is that it makes delegation safe, enforceable, and invisible in the best possible way. The user shouldn’t have to think about credentials, and the admin shouldn’t have to babysit provisioning. Somewhere in between, the system has to be smart enough to know who’s asking, what they’re allowed to do, and how to enforce that without becoming a choke point.
“You’re not giving them the keys to the castle,” Horev explains. “But you are giving them enough power that you’d better have safeguards in place.
That means infrastructure that understands nuance. Not just the old abstractions—users, volumes, permissions—but the new realities of workloads that spin up and disappear in seconds.
In the real world it means being able to create credentials that expire, throttle throughput for one namespace while leaving another untouched, and trace every action back to the job that triggered it. It means moving from static quota systems to dynamic boundaries that adapt as fast as the infrastructure they serve.
In short, the storage system has to be as programmatic as the job scheduler itself. Not just responsive, but intent-aware. Not just multi-tenant, but context-sensitive.
Because when you delegate storage to users you don’t know, workloads you can’t predict, and pipelines you didn’t write, the only way to stay sane is to bake trust into the architecture itself.
Storage as a Cloud-Native Primitive
The problem, of course, isn’t just technical. It’s, fancy word time, temporal.
Storage systems weren’t built for a world that moves this fast. They were built in a time when infrastructure was something you made decisions about.
Kubernetes changed the tempo. It redefined not just infrastructure, but the relationship people have with it. Nobody asks anymore. They declare. And what they declare isn’t “I need a file system,” it’s “this job runs at midnight and expects a persistent volume to be there when it wakes up.” And then again at 2 a.m. And again at 4. The storage system doesn’t just need to work. It needs to understand context.
You don’t SSH into a server to schedule a process anymore—you push a manifest. You don’t configure a subnet by hand—you let a CNI plugin assign it. Compute and networking became programmable. They became native to the environment.
Storage, by contrast, is still lagging behind. It’s still permissioned like a privileged artifact. Still manually provisioned in too many cases. Still clinging to the idea that someone should be in the loop.
But in this new world, there is no loop. There’s only the moment. The job. The workload that spins up and makes a request and expects infrastructure to exist. And if it doesn’t? The pipeline fails. The SLA is missed.
Oh and the sad ending to that? Nobody files a ticket–they move to a platform that gets it.
“The expectation now,” Horev says, “is that storage behaves like a cloud-native service. That you can create it, destroy it, secure it, and monitor it–all through an API.” Easy peasy until you realize that very few systems actually do this. They emulate it. They bolt it on. They create operators or sidecars or wrappers. But at heir core, they still assume a human is involved. Someone still owns the mount point.
The future doesn’t have time for that. Not when workloads are ephemeral, datasets are dynamic, and the job is its own user.
If this all feels vaguely dangerous—delegating provisioning to users you don’t know, trusting ephemeral jobs to create and destroy volumes without oversight—that’s because it is. Or at least, it feels that way, if you were trained in a world where control meant safety.
The old infrastructure model was rooted in the comfort of centralization. Control was hierarchical, top-down. Resources were scarce, so they were budgeted, rationed, managed and babysat. You had sysadmins, operators, platform teams and thhey carried the keys. They understood the systems and they served as the interface between infrastructure and everyone else.
And now?
Now a machine learning engineer pushes a YAML file into a CI/CD pipeline and storage appears. Now a batch job runs every hour and expects an object bucket to exist just because it asked.
Now, control isn’t enforced by people—it’s enforced by software, policies, automation. And the humans are mostly just trying to keep up.
“This is how modern applications are built. You don’t wait for an IT person to create a volume. You provision it in your pipeline. If you can’t do that, you’re too slow,” Horev says.
That sentence, you’re too slow, is really the knife, isn’t it?.
Speed isn’t just a competitive advantage anymore. It’s a gating factor for functionality. The moment your infrastructure can’t keep up with the developer’s expectations, it’s not just an annoyance, it’s a constraint. And constraints don’t live long in modern infrastructure. They get abstracted. Replaced.
Now here’s the forward-looking statement: the person provisioning volumes in 2025 might not be a person at all. It might be an agent. A workflow. A pipeline. If your system needs a human in the loop, you’re already behind.
What Survival Looks Like in a Programmable Infrastructure World
The machines, of course, don’t care about philosophy. They care about concurrency, latency, throughput, consistency guarantees.
The question, then, isn’t just whether storage systems understand Kubernetes in the abstract, it’s can they survive it in the concrete?
Because the truth is, the old systems can’t. Not really.
They weren’t built to handle thousands of concurrent requests from different users, jobs, and services.
They weren’t designed to track access control across ephemeral identities or enforce quotas in a system that tears itself down and stands back up again every five minutes. They don’t know what a namespace is. They don’t speak the language of pods. They weren’t built for a world where an application can create infrastructure in the same breath it consumes it.
To make it work, you need more than a fast backend. You need an architecture that understands intent. One that can take a credential, trace it back to a workload, enforce a limit, emit a log, and move on without human intervention.
You need multi-tenancy that isn’t a checkbox, but a foundational property—one that touches scheduling, provisioning, data paths, and the control plane. You need to be API-native, not just API-adjacent. You need to treat security as something the user defines, not something the system defends against.
And above all, you need to make this complexity disappear. Because if the user sees any of it—if they hit a wall, or a delay, or a permissions error they don’t understand—they won’t file a ticket. They’ll go somewhere else.
This is the difference between storage that works and storage that’s alive. Between infrastructure that performs and infrastructure that responds. Not because it’s smarter, but because it’s architected for a world where infrastructure isn’t centralized—it’s personal.
The job is the user. The pipeline is the operator. And the system, if it’s going to last, needs to meet them where they are—not where you wish they were.