Kubernetes is powerful. It can orchestrate complex deployments across thousands of machines and handle failures automatically. It is also complex and requires expertise to operate well.
The result is that some teams adopt Kubernetes to solve a problem they don’t actually have, then spend a year fighting with it.
The problems Kubernetes solves
Orchestration of large distributed systems. If you have 100+ servers and 50+ services, Kubernetes provides a unified way to manage deployment, scaling, and healing.
Resource efficiency. Kubernetes packs services densely and moves them to idle capacity. You use fewer total servers.
High availability. Automatic failover, rolling updates without downtime, recovery from failures.
Portability. A service defined in Kubernetes runs the same whether you deploy to AWS, GCP, Azure, or on-premises.
These are genuinely valuable for large operations.
What Kubernetes requires
To run Kubernetes well, you need:
Dedicated ops staff. At least one person, ideally two or three, spending significant time on Kubernetes infrastructure and tooling.
Deep infrastructure knowledge. Kubernetes assumes you understand networking, storage, security, and distributed systems.
Monitoring and observability. Without good monitoring, you are operating blind.
Build pipeline sophistication. Container images, registries, deployments — all of this has to be automated.
Org overhead. Teams need coordination across who owns infrastructure, networking, storage, and applications.
When you actually need it
Your team is 30+ engineers. Communication and coordination overhead makes it hard to run services on shared infrastructure without orchestration.
You have 50+ services or 10+ teams. Resource sharing and deployment coordination become expensive without orchestration.
You need high availability SLAs. 99.9% uptime or higher usually requires the kind of automated recovery Kubernetes provides.
You deploy multiple times per day. Blue-green deployments, canary deployments, instant rollbacks — Kubernetes makes these easy.
Your infrastructure costs are a major expense. If you are spending £10,000+ per month on infrastructure, Kubernetes resource efficiency is worth optimizing.
When you probably don’t
Your team is under 10 people. The operational overhead outweighs the benefits.
You have fewer than five services. Docker Compose or simpler orchestration is fine.
You deploy once a week or less. The automation Kubernetes provides is not earning its overhead.
You can afford to have 5-10 minutes of downtime during deployments. Kubernetes handles downtime-free deployments. If you don’t need that, you don’t need Kubernetes.
Your infrastructure costs are under £2,000 per month. The efficiency gains from Kubernetes are not worth the operational cost.
The alternatives
Docker Compose. Simple orchestration for a single machine or small cluster. Sufficient for 1-5 services.
AWS ECS. AWS-specific orchestration. Simpler than Kubernetes, less portable, but less overhead.
Nomad. HashiCorp’s orchestration tool. Simpler than Kubernetes, less popular, fewer third-party tools.
Managed Kubernetes. AWS EKS, Google GKE, Azure AKS handle the infrastructure layer. You still need ops expertise for applications, but not for the cluster itself.
No orchestration. Servers, Docker containers, manual or scripted deployments. Works fine for small operations.
The hidden costs
Learning curve. Kubernetes has a 6-12 month learning curve for competency. This cost is often underestimated.
Migration cost. Moving existing services into Kubernetes is not free. Expect 20-40% overhead for the migration.
Ongoing operations. Kubernetes clusters break in ways that require deep knowledge to fix. A cluster that is not actively maintained will eventually become a disaster.
Third-party tool ecosystem. You will need an ingress controller, service mesh, logging, monitoring, package manager. Each of these is another tool to learn and maintain.
Alert fatigue. A Kubernetes cluster produces many alerts. Most are false positives or can be ignored. Learning to tune them is months of work.
Decision tree
1. Do you have 50+ services or 30+ engineers? If no, skip Kubernetes. 2. Do you need high availability? If no, skip Kubernetes. 3. Can you afford dedicated ops staff? If no, skip Kubernetes. 4. Do you already have Kubernetes expertise? If no, do not run it yourself — use managed Kubernetes. 5. Do you deploy multiple times per day? If no, reconsider.
If you have said yes to all of these and have the ops budget, Kubernetes is probably right.
If you choose Kubernetes
Use managed Kubernetes (AWS EKS, Google GKE, Azure AKS). It removes the cluster infrastructure burden and lets you focus on applications.
Start small. One or two teams on one cluster. Learn before scaling.
Invest heavily in monitoring and observability from day one. A broken Kubernetes cluster is opaque without good tooling.
Hire someone with Kubernetes experience, or allocate a team member to deep learning.
The honest assessment
Kubernetes is not bad. It is just not always appropriate. The teams struggling most with Kubernetes are the ones that adopted it before they needed it. They are spending months dealing with infrastructure complexity when they should be shipping features.
Kubernetes is a tool for organisations with mature deployment practices, significant scale, and teams that specialise in infrastructure. If that is not you, start smaller.