Kubernetes has a reputation problem, and it's about perception more than technology.
Ask most people outside platform engineering what Kubernetes is and you get one of two answers. Either they've never heard of it, or they think only big companies with dedicated platform teams can use it. Both answers miss in the same direction. They assume operating Kubernetes and using it are equally hard.
They aren't, and that difference is the whole point of this post.
What Kubernetes actually is, briefly
Kubernetes is a container orchestration system. It decides where workloads run, how they get resources, how they restart when something fails, and how they scale when demand changes. Think of it as the operating system for distributed compute.
It's also hard to operate. Setting up a cluster, configuring networking, managing storage, handling upgrades and debugging scheduling failures are real engineering disciplines. Companies have whole platform teams whose job is to do this well.
As an end user you don't feel any of that, the same way you don't feel the TCP/IP stack when you send an email.
The two layers nobody talks about separately
People have two different relationships with Kubernetes, and they almost never get discussed separately.
The first is operating it. That means cluster management, node provisioning, network policies, storage classes, RBAC configuration and version upgrades. This is platform engineering. It takes Kubernetes expertise, and the people who do it well have earned their reputation.
The second is using it. That means launching a workload, getting a GPU, running a simulation, rendering a frame or starting a Jupyter notebook. This is the work of researchers, artists and scientists. It takes expertise in the work itself. It shouldn't take knowing what a pod spec looks like.
Most organizations treat these two layers as one. The difficulty of operating Kubernetes becomes the assumed barrier to using it. So researchers wait on tickets. Artists file requests. Scientists sit idle while IT provisions environments. The bottleneck is the gap between the people who understand the infrastructure and the people who need to use it.
What closing that gap looks like
When the two layers are properly separated, using compute feels closer to opening an app than managing infrastructure.
A researcher picks a workload template from a catalog. An IT administrator defined that template once, with the resource limits, storage mounts, GPU access and network policies already set. The researcher sees three fields: name, environment type, project. They click create. Sixty seconds later their environment is running with their storage mounted, their permissions correct and their tools ready.
They didn't write YAML, file a ticket, wait for IT to provision a VM, or configure anything. They got a working environment.
All the Kubernetes work still happened underneath. The scheduler placed resources across nodes, the storage plugin mounted the right volumes with the right POSIX permissions, the GPU operator assigned the right hardware, and the network policy kept the workload isolated from other tenants. The researcher never saw any of it because they never needed to.
Why this matters for organizations right now
For most organizations, the GPU capacity problem comes down to access.
Enterprise on-premises GPU utilization typically sits at 10 to 15% across the fleet. The hardware is there. The compute is provisioned. But the path from “researcher needs a GPU environment” to “researcher is using a GPU environment” has enough friction that workloads either queue behind a ticket system or run inefficiently because the researcher can't get exactly what they need.
When end users can provision their own environments from pre-approved templates, utilization changes. The hardware stays the same and the access model changes.
That's the argument for self-service compute, and it gets lost in debates about Kubernetes adoption. Some teams should learn Kubernetes and some shouldn't. What matters is whether the people who need compute should be blocked by the people who operate it. Almost always, they shouldn't.
The IT team argument
IT teams sometimes push back on self-service, and their reasons are fair. If anyone can launch any workload, you lose control over resource use, storage and security posture.
The fix is to make the template system the control point. IT defines which workloads are available, what resources they can use, what storage they can reach, and who can deploy them. Researchers deploy inside those limits without needing to know where the limits are or why they exist.
IT's work shifts. Instead of provisioning environments one request at a time, they maintain the template catalog that defines what self-service looks like. One template definition replaces hundreds of provisioning tickets. IT keeps the control and gets rid of the bottleneck.
The actual barrier
Your researchers don't need to understand Kubernetes for any of this. Your IT team needs to understand it well enough to configure templates correctly. And your organization needs a clear line between who operates the infrastructure and who uses it, so neither group blocks the other.
Drawing that line is harder inside an organization than it sounds. The tooling for it already exists.
The organizations getting the most out of modern compute figured out that you need Kubernetes expertise to run the platform and you don't need it to benefit from one. Their researchers, artists and scientists don't think about Kubernetes at all. They think about their work.
See how Orion delivers workloads to non-technical users. Book a demo
WRITTEN BY
Tony Como
Tony runs go-to-market at Juno, from first outreach to production deployment. He works across sales, partnerships, and operations to help technical teams move faster without adding infrastructure overhead.