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

Kubernetes is the default answer to a question many teams never actually asked. A candid field guide to where orchestration earns its keep, where it just adds a control plane to your problems, and how to tell which situation you are in.

Kubernetes is genuinely excellent, and it is also the most over-applied piece of infrastructure of the last decade. Both things are true. It has become the de facto operating system of the cloud — the 2025 CNCF survey put Kubernetes in production at 82% of surveyed organisations² — and that very ubiquity is the problem: when a tool is everywhere, teams reach for it before they have asked whether their problem is the shape it solves. This guide is about asking that question honestly.

01What Kubernetes is actually for

Kubernetes is a container orchestrator: it takes a fleet of machines and a declarative description of the workloads you want running, and it works continuously to make reality match that description — scheduling containers, restarting the ones that die, scaling them, and rerouting traffic when a machine fails.¹ That is a real, hard problem, and Kubernetes solves it well. The mistake is assuming you have that problem.

You have it when you are running many services that need independent scaling, rolling updates, self-healing, and portability across environments — and when you have enough of them that doing this by hand is the actual bottleneck. You do not have it when you run one web app and a database, or a handful of cron jobs, and your real constraint is shipping features, not orchestrating a fleet.

02Day 1 is a demo; Day 2 is the job

The single most useful lens for this decision is the split between Day 1 and Day 2 operations. Day 1 is standing the thing up — a tutorial, a kubectl apply, a green dashboard. It is genuinely a good afternoon. Day 2 is everything after: upgrades, certificate rotation, node patching, capacity planning, monitoring, backups, incident response, and the security posture of the whole stack.⁶ Day 2 is where clusters are actually lived in, and it never ends.

Consider the most routine Day-2 task: upgrading the cluster. Kubernetes minor versions arrive roughly three times a year, each supported for about a year, so a cluster you never touch drifts out of support in around twelve months. Upgrading it is a deliberate, staged procedure — control plane first, then node pools, respecting the version-skew rules — not a single button.⁷ Multiply that by every cluster and every environment, forever. If nobody on the team owns that recurring work, the cluster does not become simpler over time; it becomes a liability.

The question is never "can we run Kubernetes?" — a good engineer can stand one up in an afternoon. The question is whether you want to be running it in eighteen months, at 3 a.m., during an incident, on a version two releases behind.

03What the cluster actually costs

Managed Kubernetes removes the hardest part — you no longer operate the control plane yourself — but it is not free, and the fixed cost is easy to under-count. Amazon EKS charges $0.10 per hour per cluster for the control plane during standard support (about $72 a month), and — a detail many teams miss — $0.60 per hour once a cluster falls into extended support on an older version, a six-fold jump that quietly punishes clusters nobody upgraded.³ Google's GKE and Azure's AKS have their own management-fee and free-tier structures, and every provider bills you separately for the actual worker nodes, storage, and traffic on top.⁴⁵

The fixed fee is the small number. The larger cost is the standing team competence Day 2 demands, and the multiplication when you run separate dev, staging, and production clusters — each paying its own control-plane fee and each needing the same upkeep.³ None of this is an argument against Kubernetes. It is an argument for counting the whole bill, not just the sticker on the control plane, before you commit.

04The lighter tools most apps could use instead

For a large share of real applications, something smaller is not a compromise — it is the correct engineering choice:

• Docker Compose — for a single host running a handful of related containers (an app, a worker, a database, a cache), Compose gives you declarative, reproducible multi-container setups without any orchestration layer at all.⁸ Most side projects, internal tools, and early-stage products never outgrow it.
• A managed container service — AWS App Runner, Google Cloud Run, Azure Container Apps and similar run a container image directly, scaling it (often to zero) and handling TLS, deployments, and networking for you, with no cluster to operate.⁹ You trade some flexibility for the disappearance of Day 2.
• A platform-as-a-service — for a straightforward web app, a PaaS that deploys from a Git push removes containers from your mental model entirely. That is frequently the right answer for a team whose scarce resource is engineering time, not infrastructure control.

The honest test: if a managed service or a PaaS runs your workload today and you cannot name a concrete capability it is denying you, you do not yet need a cluster.

05A short decision checklist

Before adopting Kubernetes, count how many of these are true for you 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 give them to you.
3. You need to run across multiple clouds or on-prem, and portability is a real requirement rather than a someday-maybe.
4. You have a person or team who will own Day-2 operations — upgrades, security, on-call — as an explicit responsibility.
5. The complexity Kubernetes adds is smaller than the complexity it removes for your specific workload.

If most of these are true, Kubernetes will pay you back. If you are checking boxes because they sound like where you want to be in two years, run the lighter tool now and migrate when the pain is real. Migrating into Kubernetes because you outgrew Compose is a good problem; running Kubernetes you never needed is a self-inflicted one — and be wary of the opposite extreme too, since very large clusters bring their own scaling limits and considerations.¹⁰

06Where OcxlyDev lands

We use Kubernetes where it fits and reach for less where it does not, and we treat that as a sign of judgement, not indecision. Orchestration is a powerful tool for a specific class of problem — many services, real scale, a team to run it. For everything else, the calm choice is usually the smaller one: ship on the lightest thing that works, keep your Day-2 burden proportional to your team, and adopt the cluster the day your workload — not the industry's fashion — actually asks for it.