Kubernetes: when it helps and when it adds complexity
A practical look at container orchestration - for which companies Kubernetes solves real problems and when it creates more issues than it resolves.
By 2018, Kubernetes had become the standard answer to the question "how do we manage containers in production". It is a mature platform with a large community and genuine successful deployments at large companies. At the same time, I regularly see situations where teams adopt Kubernetes not because they are solving a specific problem, but because "it is the right thing to do" or "everyone is doing it".
The result is infrastructure nobody fully understands, which has become harder, not easier, to operate.
What Kubernetes actually solves
Kubernetes was built for a specific class of problems. It works well when:
- The infrastructure runs many small services and you need to manage their lifecycle: deployment, restart on failure, scaling under load.
- Different teams deploy their services independently and need a platform that provides a consistent way to do so.
- Load is unstable and you need to automatically allocate and release resources.
- The company operates across multiple clouds or data centres and needs portability.
If none of these points describe the actual situation - Kubernetes is most likely a premature complication.
What Kubernetes adds beyond the benefits
Managing a Kubernetes cluster is a separate operational task. Here is what comes with it:
- A network model that is more complex than standard. Services, namespaces, ingress, policies - these are not configured in a day and require solid understanding.
- Storage. State in Kubernetes is a separate conversation. Databases in Kubernetes require careful handling.
- Monitoring and logging. The observability tooling for a cluster is a separate stack to learn and maintain.
- Cluster upgrades. Kubernetes develops actively. Keeping the version current is regular work that cannot be ignored.
- Team skill. You cannot install Kubernetes and walk away. You need people who understand how it works and can diagnose problems.
For a company with 5 to 10 services and a team of 3 to 5 developers, this may be excessive. For a company with 50+ services and several teams - it is already a reasonable choice.
Three questions before making the decision
First: how many independently deployable services do we have now - and how many are planned in a year? If fewer than ten - Kubernetes is probably premature.
Second: does the team include one or more people prepared to become cluster operators - not developers, but specifically infrastructure operators? Without this, Kubernetes becomes a black box that works until the first serious problem.
Third: what are we currently using for deployment, and what specific problem with that are we solving by moving to Kubernetes? If the answer is "well, we have Docker Compose and it mostly works, but we want to do it like the big companies" - that is not a problem, it is a preference. Better to first confirm the problem is real.
Alternatives worth knowing about
If Kubernetes is premature - there are intermediate solutions. Docker Compose is sufficient for many small teams in production. Managed container services from cloud providers reduce part of the operational burden. Simple platform services like managed PaaS allow deployment without going deep into orchestration.
The move to Kubernetes makes sense - but it should be driven by real requirements, not by the technology's readiness.