Do you really need Kubernetes?

Kubernetes has become one of the defining technologies of modern cloud infrastructure.

It manages containers, handles scaling, supports automated rollouts and rollbacks, provides service discovery and creates a common platform for running distributed workloads. The Kubernetes project describes it as a portable and extensible platform for managing containerized workloads and services.

There is a good reason it became so popular.

There is also a question that is becoming increasingly useful to ask:

Do you actually need it?

The answer depends on what you are running, how you operate it and what your team needs from its infrastructure.

Kubernetes solves real problems. But adopting it also introduces its own operational model, vocabulary, tooling and expertise requirements.

For some teams, that trade-off makes sense.

For others, it can be more infrastructure than the application needs.

Kubernetes solves a specific class of problems

Kubernetes becomes particularly valuable when workloads are distributed, containerized and expected to operate reliably at scale. In those environments, teams may need automated scheduling, service discovery, rolling deployments, self-healing, horizontal scaling and more sophisticated workload management, all of which are core capabilities Kubernetes was designed to provide. Its control plane continuously works toward a desired state rather than simply executing a fixed sequence of commands, while the platform can provide a consistent operational model across different environments.

For a team running dozens of services across multiple environments, having a common platform through which workloads can be deployed, scaled and managed can be a significant advantage. But that does not mean every application needs Kubernetes. A small application with one or two services may have little to gain from operating a Kubernetes cluster, while a managed container platform may already provide the scaling and deployment capabilities it needs. In other cases, a serverless architecture can remove entire categories of infrastructure management, or a simpler container platform may be enough.

Kubernetes is undeniably powerful. The more useful question is whether the problems it is designed to solve actually exist in your environment, and whether they justify the operational complexity that comes with the platform.

This distinction becomes especially important when Kubernetes adoption starts from the infrastructure side rather than the application side.

“We should use Kubernetes” is rarely a complete architectural decision.

A better conversation starts with:

• What are we running?
• How frequently does it change?
• How much does it need to scale?
• How many services do we expect?
• Who will operate the platform?
• What level of control do we actually need?
• What happens if the platform itself becomes a source of operational work?

Those questions usually produce a much more useful answer.

The operational cost is part of the architecture

Kubernetes is open source, but operating Kubernetes is not free.

The cost is not limited to the cluster itself.

There is the control plane, networking, ingress or gateway configuration, storage, security, upgrades, observability, CI/CD integration, secrets management, access control and incident response.

There is also the human side.

Engineers need to understand the platform well enough to troubleshoot it.

That expertise can be an advantage when Kubernetes is central to the company's architecture. It can become unnecessary overhead when the platform exists mainly because “everyone uses Kubernetes.”

The Kubernetes project itself makes an important distinction: Kubernetes provides the building blocks for developer platforms, but it does not include every application-level service, CI/CD workflow, monitoring solution or infrastructure management capability. Those choices remain with the organization.

That flexibility is one of Kubernetes' strengths, but is also part of the complexity.

A Kubernetes environment is rarely just Kubernetes.

It becomes Kubernetes plus networking plus storage plus security plus observability plus deployment tooling plus cloud integrations.

This is where managed Kubernetes can change the equation.

Teams can outsource parts of cluster management while keeping the Kubernetes API and ecosystem they need.

But even managed Kubernetes does not remove the responsibility of understanding workloads, permissions, networking, resource allocation and application behavior.

The abstraction moves the boundary.

It does not make the system disappear.

Choose the platform around the workload

Kubernetes should earn its place in the architecture. When an application genuinely needs its capabilities or a team needs a consistent platform across many workloads, the investment can make sense. But if the same application could run reliably on something simpler, that simplicity has value too. Kubernetes is widely adopted, but popularity alone is not a reason to use it. The right choice depends on the workload, the operating model and the team responsible for keeping it running.

Kubernetes can be the right platform for one environment and more than another one needs. Knowing the difference is part of good engineering.

For a broader introduction to modern cloud infrastructure, see Cloud Computing: What It Is and Why It Matters.