Kubernetes is the industry standard for running containerised applications at scale, and it is also one of the most over-adopted tools in modern IT. Plenty of UK businesses have ended up with a cluster because a developer wanted the experience or a cloud provider recommended it, then discovered they had taken on a platform that needs genuine ongoing engineering attention. The technology is excellent. The question is whether your workload is the kind that benefits from it.
This guide explains what container orchestration actually does, the honest signals that you need it, the simpler options that serve most businesses perfectly well, and what running a cluster properly involves. As a UK provider that both builds custom software and manages cloud infrastructure, our view is that Kubernetes is a very good answer to a specific problem rather than a default choice.
What container orchestration actually does
A container packages an application with everything it needs to run, so it behaves the same on a developer's laptop as it does in production. That solves the packaging problem. It does not solve the operating problem: something still has to decide which server each container runs on, notice when one dies, start a replacement, route traffic only to healthy copies, and add or remove copies as demand changes.
Container orchestration is the automation of those decisions. With Kubernetes you describe the state you want in configuration, such as "run five copies of this service, each with this much memory, reachable at this address", and the cluster works continuously to make reality match that description. If a server fails at three in the morning, workloads are rescheduled elsewhere without anyone being paged.
A cluster has two halves. The control plane runs the API server, the scheduler that places workloads, the controllers that reconcile desired and actual state, and etcd, which stores the cluster's configuration. Worker nodes run an agent called the kubelet plus a container runtime, and group containers into pods. Around that core, most production clusters add Helm for packaging releases, an ingress controller for routing traffic in, persistent volumes for anything that stores data, and a monitoring stack such as Prometheus and Grafana.
Docker and Kubernetes are not competitors
This confuses a lot of decision makers, so it is worth being explicit. Docker builds and runs individual containers, typically on one machine. Kubernetes runs many containers across many machines and manages the scheduling, networking, scaling and rollouts between them. Images built with Docker are the units that Kubernetes schedules.
Docker Compose sits between the two. It runs several containers together on a single host, which is genuinely enough for a great many applications. If Compose on a well-managed server meets your needs, that is not a compromise; it is the appropriate tool.
The honest signs you need Kubernetes
Kubernetes earns its complexity when several of the following are true at once, not when only one is:
You run several services that scale independently. If your API, background workers and scheduled jobs all have different load profiles and you want each to scale on its own, orchestration saves real effort. A single application that scales as one unit does not need it.
You deploy frequently and cannot accept downtime. Rolling updates, health-checked rollouts and instant rollback are built into Kubernetes. If you deploy once a month during a maintenance window, you are paying for capability you will not use.
You need identical environments. Where regulatory or quality requirements mean development, staging and production must genuinely match, describing the whole environment as configuration is a strong advantage.
You are deliberately avoiding lock-in, or running across environments. Kubernetes is vendor-neutral, so the same workload definitions run on Azure Kubernetes Service, Amazon EKS, Google Kubernetes Engine or your own hardware. If you have a real requirement to move between providers, or to run some workloads on-premises and some in the cloud, that portability is worth something.
You already have the engineering capacity. This is the one most often skipped. A cluster is a platform, and platforms need owners. If nobody is going to patch it, watch it and understand it, it will quietly become the least reliable part of your estate.
The signs you do not
Be honest about the opposite case. A single web application with steady traffic, a small team with no platform engineer, a product still searching for its market, or a workload that comfortably fits on two virtual machines are all situations where Kubernetes will cost you more in attention than it returns in capability.
The failure mode is rarely dramatic. It is a cluster that works, running on a version nobody wants to upgrade, understood by one person who has since left, with configuration that no longer matches what is actually deployed. That is a worse position than the simple setup it replaced.
The simpler alternatives worth considering first
Most businesses that think they need Kubernetes are well served by something further down this list:
- A managed container platform. Azure Container Apps, AWS App Runner, Google Cloud Run and similar services run your containers, scale them and handle the underlying infrastructure. You get most of the operational benefit with a fraction of the surface area to manage.
- Platform as a service. For standard web applications, a PaaS removes infrastructure concerns entirely and is usually the fastest route from code to production.
- Docker Compose on managed virtual machines. Unfashionable and frequently correct. A couple of well-patched, monitored servers running Compose behind a load balancer is a legitimate production setup for many applications.
- Managed Kubernetes rather than self-hosted. If you do need Kubernetes, take the managed control plane. Running your own control plane and etcd is specialist work with very little commercial upside for most organisations.
What it really costs to run
The cluster fee is the smallest part of the bill. Budget realistically for the compute behind the nodes, which usually needs headroom so workloads can be rescheduled when a node is lost; storage and network egress; the monitoring and logging stack; and the engineering time to patch, upgrade and support the platform.
That last item is the one that gets underestimated. Kubernetes releases move quickly and clusters need regular version upgrades, which are routine but not automatic. If you cannot identify who will do that work, the honest answer is that the platform is not yet affordable for you, regardless of the infrastructure quote.
Getting it right if you do proceed
If the case holds up, a few decisions early on prevent most of the pain later. Use a managed service so you are not maintaining a control plane. Keep configuration in version control and deploy from it, so the cluster's state is always described somewhere readable rather than living in someone's terminal history. Set resource requests and limits from the start, because a single unbounded workload can destabilise a whole node. Configure role-based access control and network policies before you have workloads to retrofit them around. Get monitoring and alerting in place at the same time as the first deployment, not after the first incident. And plan the upgrade cadence as a standing commitment rather than a project.
Frequently asked questions
What is Kubernetes in simple terms?
Kubernetes is software that runs and manages containerised applications across a group of servers. You tell it what you want running and it handles the rest: choosing which server each container runs on, restarting anything that fails, routing traffic to healthy copies only, and scaling the number of copies up or down as demand changes.
Do small businesses need Kubernetes?
Usually not. Kubernetes is designed for estates with several independently scaling services, frequent deployments and dedicated engineering capacity. A small business running one or two applications is normally better served by a managed container platform, a platform as a service, or Docker Compose on well-managed servers, all of which need far less ongoing attention.
What is the difference between Docker and Kubernetes?
Docker builds and runs individual containers, typically on a single machine. Kubernetes runs many containers across many machines and handles scheduling, networking, scaling, health checks and rollouts between them. They work together rather than competing: images built with Docker are the units that Kubernetes schedules and manages.
What are the alternatives to Kubernetes?
The main alternatives are managed container platforms such as Azure Container Apps, AWS App Runner and Google Cloud Run, traditional platform as a service offerings, and Docker Compose running on managed virtual machines. Each gives you containerised deployment with significantly less operational complexity, which suits the majority of business applications.
How much does Kubernetes cost to run?
The cluster fee itself is minor compared with the total cost. You need to budget for the compute behind the worker nodes with enough headroom for failover, storage and network egress, a monitoring and logging stack, and the engineering time for patching, upgrades and support. That engineering time is the most frequently underestimated element.
Is Kubernetes secure by default?
No platform is secure purely by default. A Kubernetes cluster needs role-based access control so users and services have only the permissions they require, network policies to control which pods can communicate, proper secrets management, image scanning before deployment, and regular patching of both the cluster version and base images. Cluster access should also be tied to your existing identity provider rather than shared credentials.
Deciding with a clear head
Kubernetes is a genuinely excellent piece of engineering that solves a real problem: running many containerised services reliably across many machines. The mistake is treating it as a maturity milestone rather than a tool with prerequisites. If you have multiple services scaling independently, frequent deployments and the capacity to own a platform, it will repay the investment. If you do not, a managed container platform will get you the same outcomes with far less to maintain.
Synergi Tech builds software and manages cloud infrastructure for organisations across the UK, including containerised workloads on Kubernetes and on simpler platforms where that is the better fit. If you are weighing up container orchestration and want a straight answer about which side of the line you sit on, get in touch and we will talk it through. You can also read more about container orchestration with Kubernetes or our DevOps services.