The Kubernetes reality check: when to use it — and when not to

Kubernetes has become the default answer to a question many teams never asked. This is a practical look at where it earns its keep, where it mostly adds overhead, and how to tell which case you are in.

Kubernetes is very good at what it does, and it is also frequently used where it is not needed. Both of those are true. It has become a de facto standard — the 2025 CNCF survey put it in production at 82% of surveyed organisations² — and that popularity is part of the problem: when a tool is everywhere, teams often adopt it before asking whether their problem is the kind it solves. This guide is about asking that question first.

01What Kubernetes is for

Kubernetes is a container orchestrator. You give it a set of machines and a declarative description of the workloads you want running, and it works continuously to make the running state match that description: scheduling containers, restarting ones that fail, scaling them, and rerouting traffic when a machine goes down.¹ That is a genuine, hard problem, and Kubernetes handles it well. The question is whether you actually have that problem.

You do when you run many services that need independent scaling, rolling updates, self-healing, and portability across environments, and there are enough of them that managing this by hand is the real bottleneck. You do not when you run one web app and a database, or a few scheduled jobs, and your real constraint is shipping features rather than managing a fleet.

02Day 1 versus Day 2 operations

A useful way to frame the decision is the split between Day 1 and Day 2 operations. Day 1 is standing the cluster up: a tutorial, a kubectl apply, a working dashboard. That part is genuinely quick. Day 2 is everything afterwards: upgrades, certificate rotation, node patching, capacity planning, monitoring, backups, incident response, and the security of the whole stack.⁶ Day 2 is where a cluster actually lives, and it does not end.

Take the most routine Day-2 task, upgrading the cluster. Kubernetes releases a minor version roughly three times a year, each supported for about a year, so a cluster left alone drifts out of support in around twelve months. Upgrading is a staged procedure, control plane first and then node pools, following the version-skew rules, rather than a single button.⁷ Multiply that across every cluster and environment, indefinitely. If no one owns that recurring work, the cluster becomes a liability rather than getting simpler over time.

A good engineer can stand up a cluster in an afternoon. The harder question is whether you want to be running it in eighteen months, on a version two releases behind, during an incident.

03What a cluster costs

Managed Kubernetes takes away the hardest part, since you no longer run the control plane yourself, but it is not free, and the fixed cost is easy to undercount. Amazon EKS charges $0.10 per hour per cluster for the control plane during standard support, about $72 a month, and $0.60 per hour once a cluster falls into extended support on an older version, a six-fold increase that mainly hits clusters no one upgraded.³ Google's GKE and Azure's AKS have their own management-fee and free-tier structures, and every provider bills separately for the worker nodes, storage, and traffic on top.⁴⁵

The fixed fee is the small part. The larger cost is the ongoing team skill that Day 2 requires, multiplied when you run separate dev, staging, and production clusters, each paying its own control-plane fee and needing the same upkeep.³ None of this is an argument against Kubernetes. It is an argument for counting the whole bill before committing, not just the control-plane sticker price.

04Lighter tools that fit many apps

For many applications, something smaller is the better engineering choice rather than a compromise:

• Docker Compose — for a single host running a few related containers (an app, a worker, a database, a cache), Compose gives you declarative, reproducible multi-container setups with no orchestration layer.⁸ Many side projects, internal tools, and early products never outgrow it.
• A managed container service — AWS App Runner, Google Cloud Run, Azure Container Apps and similar run a container image directly, scale it (often to zero), and handle TLS, deployments, and networking, with no cluster to run.⁹ You give up some flexibility and lose the Day-2 burden.
• A platform-as-a-service — for a straightforward web app, a PaaS that deploys from a Git push takes containers out of the picture entirely. That is often the right answer when the scarce resource is engineering time rather than infrastructure control.

A simple test: if a managed service or PaaS runs your workload today and you cannot name a specific capability it is missing, you probably do not need a cluster yet.

05A short decision checklist

Before adopting Kubernetes, count how many of these are true right now, not aspirationally:

1. You run many independent services (roughly more than a handful) that scale and deploy on different schedules.
2. You genuinely need self-healing, automated rollouts and rollbacks, and horizontal autoscaling, and a lighter tool cannot provide them.
3. You need to run across multiple clouds or on-premises, and portability is a real requirement rather than a possibility.
4. You have a person or team who will own Day-2 operations, including upgrades, security, and on-call, as an explicit responsibility.
5. The complexity Kubernetes adds is smaller than the complexity it removes for your workload.

If most of these hold, Kubernetes will repay the effort. If you are ticking boxes because they describe where you hope to be in two years, use the lighter tool now and migrate when the need is real. Moving into Kubernetes because you outgrew Compose is a good problem to have; running Kubernetes you never needed is a self-inflicted one. The far extreme has its own limits too, since very large clusters bring their own scaling considerations.¹⁰

06Where OcxlyDev lands

We use Kubernetes where it fits and use something lighter where it does not, and we treat that as good judgement rather than indecision. Orchestration is a strong tool for a specific kind of problem: many services, real scale, and a team to run it. For everything else, the smaller choice is usually the right one. Run the lightest thing that works, keep the Day-2 burden in proportion to your team, and adopt a cluster when the workload actually calls for it.