Do you need Kubernetes? A complexity-budget answer

Kubernetes solves real problems: scheduling many workloads across many machines, self-healing, rolling deployments, portable runtime across clouds, a rich ecosystem. If you have those problems, it is usually the right tool. The trouble is that it is also adopted by teams that have none of those problems and one problem it creates: the need for someone who understands it.

The questions that decide it

• How many distinct workloads do you run? A handful of services on one team rarely needs a scheduler.
• Who will operate the cluster at 2am? If the answer is “the cloud provider”, you are describing a managed service, and there may be a simpler one.
• What is the actual requirement: portability, density, autoscaling, isolation? Name it. Then check whether a managed container runtime satisfies it.
• What does the team already know? Skills are a constraint, not a nice-to-have. Operating Kubernetes badly is worse than not operating it.

What “earning its place” looks like

In the complexity budget, every element has to point at a requirement. “We might need to scale” is an assumption, not a requirement. “We run 40 services owned by six teams with different release cadences” is a requirement. “Our compliance regime demands workload isolation we can audit” is a requirement. Write the requirement down next to the technology, and if you can't, that's the finding.

Reversibility

Moving onto Kubernetes from a simpler runtime is usually medium effort. Moving off it once your deployment, networking, secrets and observability have been shaped around it is harder, not because the containers care but because the organisation's muscle memory does. This is a medium-to-high reversibility-cost decision dressed up as a technical one, and it deserves a written reason.

Do not use complexity to make an architecture look sophisticated.