Do you need Kubernetes for a small team ?

I’ve written elsewhere about when not to run Kubernetes and I won’t rehash it here (see kubernetes-ou-pas ). This post takes a different angle : a small outfit, a single DevOps, a handful of devs with no infra experience and the question that keeps coming back of whether to adopt K8s at all.

The answer isn’t technical, it’s human. I’ll frame it as three options, A, B and C, each with its own limits.

Option A : full Kubernetes

K8s standardises everything we end up rebuilding by hand anyway : service discovery, rollout, drain, health checks, scheduling. That’s the knockout argument and it’s a real one.

But with a single DevOps and four devs who have never touched infra, the risk is just as real. If that one person is the only one who understands the platform, every absence blocks everyone and the bus factor drops to one. K8s manifests, for devs who have never touched infra, are a wall.

So K8s is only justified if the DevOps has the background to stand it up quickly and, above all, the time to bring the team up to speed. Without that mentoring time, you don’t have a platform, you have a debt with a single creditor. And if you do go the K8s route, standing it up properly (see bare-metal Kubernetes in HA ) and hardening it (see Kubernetes hardening ) is part of the background, not an option.

Option B : orchestration delegated to the provider

This is the default choice if the DevOps you hired has a cloud-native or junior-infra profile. They lean on the provider for orchestration, scaling and high availability and focus on what delivers visible value : CI/CD, observability and DX.

Production is a matter of a few weeks and the team can interact with the stack without deep infra expertise. The limit is well known : vendor lock-in and costs that balloon with traffic.

I’ll be honest, this is the option I’d pick least willingly. You buy short-term time and lose control over your own bill.

Option C : the intermediate option

Between the two, there’s a space where you recover part of the orchestration benefits without imposing the full complexity of K8s on people who aren’t ready for it. It’s the compromise option, the one that keeps some reversibility while staying accessible to the team that has to live with it day to day.

What actually decides it

In the end the choice rests on two axes and neither is an architecture question : the DevOps’s real skills and the whole team’s ability to interact with the stack day to day.

In many contexts, all three options can work on paper. What makes the difference is the fit between the technical choice and the people who carry it. Personally I’d take A or C depending on the DevOps’s background and the mentoring time available ; as for B, I’d struggle to defend it wholeheartedly, even if I understand coming to it under schedule pressure.

YAGNI, plain and simple

• The question isn’t whether K8s is good, it’s whether your team can live with it.
• A single DevOps who understands the platform is a bus factor of one, so a blocking risk at every absence.
• K8s manifests remain a wall for devs who have never touched infra.
• B buys short-term time against lock-in and a growing bill.
• The real criterion is the DevOps’s skills and the whole team’s ability to live with the stack, not fashion.

[edit: 2026] The Ansible implementation of all this: the k0s role .