Does this really need Kubernetes?

Kubernetes is one of those technologies that makes perfect sense until somebody tells you they want to use it for a single internal application that gets deployed four times a year.

I get the attraction. You get a common way to run containers, schedule workloads, recover from failed nodes and roll out changes. CNCF reported that 82% of container users surveyed were running Kubernetes in production in 2025. This is established infrastructure, not an experiment. But that number tells you how widely it is used, not whether your particular application needs it.

There is a second project hiding inside the first one

Suppose a small company wants to move its app from a couple of servers to Kubernetes. That sounds like a deployment project. In practice it is also a question about networking, storage, secrets, logging, upgrades, security, and who owns the cluster after launch.

A cluster that only one engineer understands is not necessarily an improvement over two well-maintained virtual machines. On the other hand, if you have several services, frequent deployments, inconsistent environments and ongoing scaling headaches, I would absolutely consider building a shared platform.

My test is simple: name the current problem first. Are releases risky? Are machines being configured manually? Are services constantly competing for capacity? If Kubernetes directly fixes those, great. If the argument starts and ends with “everybody uses Kubernetes now,” I would push back.

The question I'd ask a small software team

How often are you shipping changes, and what's painful about the current process? If the answer is that releases happen once a month and someone manually logs into a VM, there may be a simpler fix: containerize the app, set up repeatable deployments and put decent monitoring around it. You can get a long way without operating a full cluster.

Where Kubernetes starts to earn its place is when several applications share an environment, teams need consistent deployment patterns, and the cost of doing everything separately becomes its own problem. It can also make sense when you need the same model of operation across data centers and cloud providers. But those benefits come with networking, storage, security and upgrade responsibilities.

I care a lot about who owns the platform after launch. A consultant can get a cluster running over a weekend. That tells you almost nothing about whether the client can patch it, recover from a storage failure or know why an application stopped reaching a dependency six months later.

I'm not anti Kubernetes. I think it's excellent when it solves a problem you actually have. I'd just rather see a boring, reliable deployment than a sophisticated cluster nobody wants to maintain.