Every eighteen months or so, the same argument does a lap of the internet. Someone writes “we moved off Kubernetes and cut our infra bill by 60%.” A few months later, someone else writes “we moved back to Kubernetes and here’s why.” Both posts get the same engagement, both are right about their own environment, and both get quoted afterwards as if they’d settled something universal. Neither side did.
I’m writing this because I sit on both ends of that argument at the same time, every day, and I don’t think either tribe is being honest with the other.
At my day job I’m a Cloud Architect at Ebucks, part of FirstRand Group — a South African bank. I design and run cloud-native platforms on AWS and Azure, and containerisation strategy there means EKS and AKS, under POPIA and PCI-DSS, with audit and governance requirements that don’t forgive a shortcut. At home, I run a four-node k3s cluster on Proxmox — Cilium CNI with eBGP, Gateway API, ArgoCD, Argo Rollouts, the works — for a personal setup with precisely zero regulatory requirement to run any of it. Nobody makes me run Kubernetes at home. I do it because I choose to, and this blog you’re reading is served off it.
That combination gives me a slightly unusual vantage point. I’m not a Kubernetes evangelist who’s never felt the pain of running it, and I’m not a “just use a VPS” contrarian who’s never had to prove change control to an auditor. So here’s the honest version: when Kubernetes is the right call, when it’s the wrong one, and how I actually tell the difference — for other people’s platforms, not just my own.
The Argument Is Usually About the Wrong Layer#
Most “Kubernetes is overkill” posts are actually complaints about something else wearing a Kubernetes costume:
- A team running a managed control plane (EKS, AKS, GKE) but still hand-rolling Helm charts, Ingress objects, and cert management that a PaaS would have given them for free
- A single service, single team, low-traffic app that got a full multi-node cluster because that’s what the last job used
- An operations team that never invested in the platform layer, so every deploy still means someone hand-editing YAML at 2am
None of that is an indictment of the orchestrator. It’s an indictment of adopting the orchestrator without building — or buying — the platform around it. Kubernetes is an API for scheduling and reconciling state. It was never meant to be consumed directly by application teams, any more than a hypervisor was meant to be consumed directly by end users. The teams who are miserable running it are usually the ones who skipped the platform engineering step and handed raw kubectl access to people who just wanted to ship a feature.
The complaint “Kubernetes is too complex” is almost always true at the point it’s made, and almost always fixable by someone building the missing abstraction layer, not by ripping the orchestrator out.
Where It Earns Its Complexity: The Bank#
At Ebucks, Kubernetes isn’t a technology choice I get to relitigate every quarter — it’s the substrate that makes several other non-negotiable things possible at once:
- Multiple teams, one platform. When containerisation strategy spans several engineering squads building different services, a shared, self-service platform with consistent RBAC, network policy, and deployment patterns is worth more than any single team’s preference for something lighter.
- Compliance as code, not compliance as a document. POPIA and PCI-DSS requirements — data residency, audit trails, network segmentation, encryption in transit and at rest — translate into Kubernetes primitives (NetworkPolicy, admission controllers, IAM-integrated service accounts, sealed secrets) that get enforced by the platform rather than by a wiki page nobody reads before a release.
- Progressive delivery as a control, not a nice-to-have. In a regulated environment, “deploy and watch the dashboards” isn’t an acceptable rollout strategy. Blue-green and canary patterns with automated pre-promotion checks are how you prove — to yourself and to an auditor — that a bad release never touched live traffic. Kubernetes plus a rollout controller gives you that as a repeatable, declarative pattern instead of a runbook someone might skip under pressure.
- Hybrid boundaries. Most banks aren’t greenfield. There’s an on-premise VMware estate, legacy workloads, and data-sovereignty constraints sitting right next to the cloud-native platform. Kubernetes gives you a consistent workload abstraction on both sides of that boundary, which matters more than it sounds when you’re the one who has to explain the data flow to a risk committee.
None of that is about scale in the “millions of requests a second” sense. Ebucks’ platforms aren’t hyperscale traffic problems. They’re governance problems wearing infrastructure clothes, and Kubernetes is one of the few substrates mature enough to encode governance as enforceable policy rather than as process. That’s the actual reason it earns its complexity in banking — not throughput, not elasticity, but the fact that “prove it” is a daily requirement and the platform needs to make proving it structurally easy.
Where It Doesn’t Need To: The Homelab (And I Still Run It There)#
Here’s the part that keeps me honest. This blog is a static Hugo site. It could run on a five-rand-a-month shared host, a single Caddy container on a Raspberry Pi, or a free tier on any static hosting provider, and nobody would ever notice the difference in latency, uptime, or cost. By every criterion I just laid out for the bank — multi-team governance, compliance-as-code, regulatory audit trail — a static blog needs precisely none of it.
I run it on k3s anyway, with Cilium eBGP, Gateway API, ArgoCD, Argo Rollouts doing blue-green promotions with automated e2e checks via Kargo, the full stack. That’s not because the workload demands it. It’s because operating that stack — writing the Playwright tests, debugging why a CiliumBGPPeeringPolicy sat in active instead of established, tracing eBPF flows in Hubble at an hour I’d rather not admit to — is the only way I actually learn a platform well enough to trust my own advice about it at work the next day. The homelab is a deliberate over-investment, made in full knowledge that it’s overkill for the workload, because the workload was never the point. The competence was.
That distinction matters more than people give it credit for: running Kubernetes because the problem demands it, and running Kubernetes because you’re deliberately building the skill to operate it, are both legitimate reasons — but only one of them is a legitimate reason to put it in front of production traffic at someone else’s expense.
The failure mode I actually distrust is a third category: running Kubernetes on someone else’s budget for the same reason I run it at home — because it’s interesting, because it looks good on a CV, because “that’s what the last job used” — while calling it a business requirement. That’s not a technology problem. It’s an honesty problem, and no orchestrator fixes it.
A Decision Framework, Not a Verdict#
Rather than a blanket answer, here’s roughly how I actually reason about it — for my own platforms and when I’m advising someone else on theirs.
or deployable unit?"} B -- No --> C{"Compliance/audit
requirement for
segmentation or
rollout control?"} B -- Yes --> D{"Do you already have
platform engineering
capacity to run it?"} C -- No --> E["Don't use Kubernetes.
PaaS, VM, or a single
container host is correct."] C -- Yes --> F["Kubernetes is defensible
even at small scale —
the requirement is governance,
not throughput."] D -- No --> G["Use a managed platform
(PaaS/serverless) until
you can staff the platform
layer properly."] D -- Yes --> H["Kubernetes earns its
complexity — build the
self-service layer on top."]
In table form, the questions I actually ask:
| Signal | Points towards Kubernetes | Points away from it |
|---|---|---|
| Number of teams/services sharing the platform | Several, needing consistent RBAC and network policy | One team, one deployable |
| Compliance/audit requirement | Data residency, segmentation, or rollout evidence required | None — “it works” is a sufficient answer |
| Deployment cadence and risk | Frequent releases needing progressive delivery controls | Infrequent, low-blast-radius changes |
| Existing platform engineering capacity | A team (or a very committed individual) to own the platform layer | Nobody dedicated to running the orchestrator itself |
| Workload shape | Heterogeneous services, varied scaling needs, hybrid on-prem/cloud | Homogeneous, static, or single-runtime workload |
| The actual reason on the table | Governance, portability, or genuine skill investment | “That’s what the last job used” |
Kubernetes earns its complexity when the organisation around it has outgrown a single deployable, not before. If you’re a single team shipping one service with no regulatory pressure and no hybrid boundary to manage, the orchestrator is buying you optionality you don’t currently need — and optionality has an ongoing operating cost, paid whether you use it or not.
The inverse rule matters just as much: don’t mistake “I want to learn this” for “the business needs this.” Both are valid motivations. Only one of them should be argued in a change-approval meeting.
The Pendulum Will Keep Swinging#
Both halves of the recurring internet argument are describing real experiences. The team that saved 60% moving off Kubernetes almost certainly had one service, one team, and no governance requirement heavy enough to justify the platform tax they were paying. The team that moved back almost certainly rediscovered — the hard way — that once you have more than a couple of services, someone else’s bespoke deployment scripts are just Kubernetes without the API, the ecosystem, or the operator community, badly reimplemented under deadline pressure.
Running it in both a bank and a homelab hasn’t made me a Kubernetes maximalist. It’s made me more specific about what problem it’s actually solving in each place — governance and multi-team consistency at work, deliberate skill-building at home — and considerably less patient with anyone who deploys it for neither reason and calls it inevitable.
Summary: Kubernetes is the right call when governance, multi-team consistency, or a genuine hybrid/compliance boundary makes its complexity a substitute for work you’d otherwise have to do manually and repeatedly; it’s the wrong call when none of that is present and the real reason is habit, résumé-building, or “that’s what we used last time.” Both are legitimate reasons to run it — but only the first one belongs in a production budget conversation.