A team I worked with spent four months standing up a production Kubernetes cluster for what turned out to be three services and a database. It was beautifully done — Helm charts, network policies, an ingress controller, the works. It also went down one Friday evening because a certificate the cluster managed expired, and nobody on the team knew where to look. They'd bought a platform they couldn't operate, to solve a problem they didn't have. The three services would have run happily on a managed container platform that needed roughly none of that expertise.
That story isn't a knock on Kubernetes. Kubernetes is genuinely excellent at what it does. It's a knock on adopting it by default — because “everyone uses it” has quietly become the reason a lot of teams take on an enormous operational commitment they never actually needed. This post is the honest version of the decision I wish more teams made deliberately.
First, be clear about what Kubernetes actually is
Kubernetes is not a deployment target. That framing is where a lot of the trouble starts. People treat it like “a fancier place to put my container,” when it's really a distributed system you now co-own and operate. It has a control plane, a scheduler, its own networking model, its own storage abstractions, its own identity and access system, and a release cadence that expects you to keep up.
When you adopt Kubernetes, you're not adopting a feature. You're adopting a platform, and platforms need owners. The question is never “can Kubernetes run my app?” — it can run almost anything. The question is “can my team run Kubernetes?” Those are completely different questions, and confusing them is how you end up with the certificate-expiry Friday.
Good reasons to adopt it
There's a real shape to problems Kubernetes solves well, and if yours matches, the complexity earns its keep.
The strongest signal is many services that scale independently. If you're running dozens of components with different scaling profiles — one that spikes at lunchtime, one that grinds through batch jobs overnight, one that must stay warm — Kubernetes' scheduler and autoscaling give you control that's genuinely hard to replicate with simpler tools. That's the workload it was built for.
Portability is the next one. If you run across multiple clouds, or cloud plus on-premises, and you want one consistent way to deploy and operate everything, Kubernetes is the closest thing the industry has to a common substrate. Write your manifests once, run them broadly. For a business with real multi-cloud or regulatory-driven on-prem requirements, that consistency is worth a lot.
Then there's fine-grained control. Custom rollout strategies, precise traffic shaping, network policies between services, sidecars, operators that encode operational knowledge as code — if you need this level of control and you'll actually use it, Kubernetes hands it to you. The keyword is use. Having the control and never touching it is just paying for weight you carry but never lift.
And underneath all three: operational maturity. Kubernetes rewards teams that have — or are genuinely committed to building — platform engineering capacity. If you have people who will own the cluster, keep it patched, understand its failure modes, and be on call for it, the payoff is real. If you're hoping it'll just run itself, read the next section carefully.
Signs it's overkill
The mirror image is just as clear, and it describes a lot more teams than the marketing implies.
If you have a handful of services and modest, predictable traffic, Kubernetes is solving a scaling problem you don't have. A steady web app and an API doing thousands of requests a minute do not need a scheduler orchestrating a fleet. They need somewhere reliable to run, which is a much smaller ask.
If your team is small and has no platform engineering capacity, that's the loudest signal of all. Kubernetes doesn't reduce operational work; it relocates and concentrates it into a specialised skill set. A five-person product team running a cluster is spending a meaningful slice of its capacity on the platform instead of the product. That trade is sometimes worth it. Usually, at that size, it isn't.
And if a managed container service or a serverless platform would meet your needs, adopting Kubernetes instead means paying the complexity tax for benefits you'll never draw on. This is the most common mistake I see: teams reach for the most powerful tool available rather than the simplest one that fits, and then wear the operational cost forever.
Here's the decision as a rough flow — not gospel, but it catches most cases:
Do you have many services that
must scale independently, OR real
multi-cloud / on-prem portability needs?
|
+-------------+-------------+
| NO | YES
v v
Do you have a dedicated Do you have (or will you
platform / ops team to fund) a team to operate,
run and patch a cluster? patch and be on-call for it?
| |
+-----+-----+ +-------+-------+
| NO | maybe | NO | YES
v v v v
Managed Managed Managed Kubernetes
containers / Kubernetes Kubernetes (managed
serverless (AKS/EKS/ first, grow control plane
(Fargate, GKE) as a into self- still advised)
Cloud Run, stepping managed only
Container stone if forced
Apps)
Notice where the arrows mostly point. For a large share of teams, the honest answer sits on the left — and that's not a lesser outcome, it's the right-sized one.
The hidden costs nobody budgets for
The infrastructure bill is the part everyone sees. The part that surprises people is that Kubernetes is a thing you must secure, upgrade, monitor, and troubleshoot — continuously, forever.
Clusters need patching, and Kubernetes moves fast; a version falls out of support roughly yearly, so “set it and forget it” isn't on the menu. RBAC needs designing and maintaining, because the default is either too open or a source of confusing permission errors, and getting it wrong is a security incident waiting to happen. Monitoring has to span layers that didn't exist before — the app, the pod, the node, the control plane — and an outage can originate in any of them.
That last point is the one that quietly drains teams: debugging spans several layers. When something's slow, is it your code, the container, the pod's resource limits, a node under memory pressure, the network overlay, a misbehaving ingress, or the control plane? A simpler platform collapses most of those layers and hands the rest to your cloud provider. Kubernetes hands them all to you.
So budget for the people and the time, not just the compute. A cluster's real cost is measured in engineer-hours and on-call rotations. If that line item doesn't appear in your plan, your plan is wrong.
The sensible middle paths
The choice was never “raw Kubernetes or nothing.” There's a spectrum, and most teams should start further down it than they think.
Managed Kubernetes — AKS, EKS, GKE — takes the control plane off your plate. Your provider runs and patches the brain of the cluster; you still own the workloads, the nodes, the networking choices, and the upgrades of what runs on top. It removes a genuinely hard slice of the burden, and if you've decided Kubernetes is right, this is almost always where you should begin rather than self-managing.
A step simpler, container platforms like Azure Container Apps, AWS Fargate, and Google Cloud Run give you containers without any cluster to manage. You hand over an image, set some scaling rules, and the platform deals with the rest. For the “handful of services, modest traffic” team, this hits the sweet spot: you get containerisation, autoscaling, and rolling deploys without ever learning what a kubelet is.
And the path that gets dismissed too quickly: start simpler, move to Kubernetes later. Because your app is already containerised on Cloud Run or Fargate, that later migration is far less dramatic than teams fear — the container is the portable unit, and you carry it with you. Starting simple doesn't paint you into a corner. It buys you time to see whether you ever actually need the corner.
A few takeaways
Adopt Kubernetes when scale, portability, and control genuinely demand it and you can support it operationally — all of those, not two of three. If you can't staff the operations, the other reasons don't save you; you'll just have a powerful platform quietly rotting. Choose the simplest platform that meets your needs today, because you can grow into Kubernetes when the need is real, and the container you're already running makes that growth cheap.
Most of all, make it a decision rather than a default. “Everyone uses it” is not a requirements analysis. The teams who thrive on Kubernetes chose it with open eyes and staffed it properly. The teams who regret it backed into it because it seemed like the obvious answer — and obvious answers to unasked questions are how good engineers end up debugging a certificate they didn't know existed on a Friday night.
Want an honest assessment of the right platform for your workloads? See our Kubernetes & Container Orchestration services.
