Contents8
Kubernetes is everywhere: in job ads, in architecture proposals, in the platforms of the big cloud providers. It has become the standard for systems that run hundreds of services, and deservedly so. For a company of 20 to 500 people running a handful of tools, the question is not whether Kubernetes is a good tool (it is), but whether it solves a problem the company actually has.
This article from our Infrastructure and cloud section explains what Kubernetes brings, what it costs to maintain, and the signs that say you can do without it, for now or for good.
In short
Kubernetes spreads containers across several machines and keeps them in the described state: that is its strength when there are many services and several machines.
It provides no database, no monitoring and no backups: those jobs remain whole.
It needs upkeep: each minor version gets about a year of patches, and an outdated version can cost more at a provider.
A few services on one or two servers are managed more simply with containers described in a file, tested backups and a recovery plan.
What Kubernetes does, in one sentence
The Kubernetes documentation presents it as a portable, extensible, open source platform for managing containerised workloads. In practice, you describe the desired state to it (this service, in three copies, with this much memory) and it works continuously to reach that state across a set of machines: it restarts what fails, spreads the load, rolls out new versions progressively.
of container users run Kubernetes in production, up from 66% in 2023
of respondents name cultural changes within the team as the top challenge
name complexity
The first figure says Kubernetes has become the standard among those already using containers at scale. The other two are a reminder that it is not adopted like a piece of software you install: it changes the way a team works.
What Kubernetes does not do
This is the least known part, and the official documentation is very clear. In its section on what Kubernetes is not, it states that it:
- does not provide built-in application-level services such as a database, a cache or a cluster storage system;
- does not dictate or provide logging, monitoring or alerting solutions, beyond mechanisms to collect and export metrics;
- does not build your application or deploy your source code;
- does not provide a comprehensive machine configuration, maintenance or management system.
In other words, adopting Kubernetes does not settle backups, monitoring or the database: those jobs remain whole, and on top of that they have to be made to work inside Kubernetes. For a small team, this is the point that matters: you add a layer to run, you do not remove one.
What it costs to maintain
Kubernetes moves fast. The project’s releases page states that only the three most recent minor versions are maintained, and that each one gets about a year of patch support. A cluster therefore has to be upgraded at least once a year, checking each time that everything running on it keeps up.
At a provider, this rhythm has an explicit price. At AWS, for example, a managed cluster costs 0.10 dollars an hour under standard support, and 0.60 dollars under extended support, once its version has gone past the standard period. Other providers have their own price lists; the principle stays the same: overdue maintenance gets paid for. This cost comes on top of the machines themselves, and we have listed it among the five items that inflate a cloud bill.
The main cost, though, is human: you need someone who understands how the cluster works, its networking, permissions and upgrades, and who can be reached when it misbehaves. Kubernetes does not remove the work of system administrators: it shifts it towards more specialised skills.
The signs you do not need it
Containers on one or two servers are enough when
You run fewer than twenty or so services, often off-the-shelf tools
The workload is stable and fits on one machine
A few minutes of downtime, during an update or a restore, is acceptable
Nobody in the team or at your provider runs Kubernetes day to day
Kubernetes is justified when
Several teams each deploy their own services, several times a day
The workload varies a lot and has to adapt on its own, up and down
A service must not stop if a whole machine fails
A team already knows how to run it, or your provider does it for you
The threshold of twenty or so services is not a standard: it is an order of magnitude, to be checked against your own situation. The most reliable criterion remains the last one in each column: the skills available to run it.
What is enough instead
For most mid-sized companies, a simpler setup covers the need:
- containers described in a file, with Docker Compose, which its documentation presents as a tool for defining and running multi-container applications; the description of the services lives in a versioned repository and can be replayed on another machine;
- a router in front of the services, which handles addresses and certificates;
- off-server backups, actually restored, and a written list of services and their volumes;
- external monitoring, which warns you when a service stops responding;
- a written recovery plan, with the real restore time measured.
From the field
That is the setup for our own tools: a dozen services in Docker containers, behind a Traefik router, on a single VPS, for five client companies. No Kubernetes. On 5 July 2026, a badly targeted clean-up command destroyed the containers of ten of those services in one go. The data, kept in volumes, was saved, and we answered with written operating rules, not with an orchestrator: the problem was a command, not the lack of a cluster.
The limit of this setup is well known: a single server is a single point of failure. If your business cannot tolerate the downtime of a restore, the first step is not necessarily Kubernetes: a second server ready to take over, or managed services at a provider, often meet the need with less complexity. The trade-offs between server and cloud are detailed in dedicated server, VPS or cloud: choosing by use.
If you go ahead anyway
There are good reasons to go ahead: a team that already masters it, an application that has to scale, a vendor that only ships its software that way. In that case, three precautions:
- Prefer a managed service if nobody in-house runs a cluster: the provider takes on the trickiest part.
- Plan upgrades from the start, at least one a year, with a test environment.
- Keep out of the cluster what does not need to be in it, a managed database for example, rather than putting everything inside.
The cluster then joins the infrastructure foundation shared by your projects: same rules for access, backups and budgets.
Where to start
Count your services, and for each one note who runs it and what downtime is acceptable. If the list is short and a few minutes of downtime does not put the business at risk, start with well-described containers, backups that really restore, monitoring that warns you before customers do and a written disaster recovery plan. A concrete example of this setup is in self-hosted n8n in production.
The other articles in the section cover neighbouring steps: which tools to move out of SaaS first, the real three-year cost of leaving SaaS, cloud migration without breaking things, Europe’s dependence on the American cloud and what NIS2 will require of French companies.
If you want this setup for your business tools, our Leaving SaaS offer installs it on a server of your own, up to five services, with tested backups and documentation included. If a team is proposing Kubernetes and you want a second opinion, tell us about the project.
Frequently asked questions
Is Kubernetes suitable for a mid-sized company?
It is when the company runs many services, deployed often by several teams, or when it has to absorb large swings in load without interruption. For a few internal tools on one or two servers, containers described in a file, tested backups and external monitoring are usually enough, with far less operating work.
What is the difference between Docker Compose and Kubernetes?
Docker Compose describes and starts several containers on one machine, from a file. Kubernetes spreads containers across a set of machines and keeps them continuously in the described state: restarts, load balancing, progressive rollouts. Compose is simpler to run; Kubernetes becomes useful when a single machine is no longer enough or must not be a single point of failure.
How much does a managed Kubernetes cluster cost?
It depends on the provider. At AWS, the control plane of a managed cluster is billed at 0.10 dollars an hour under standard support and 0.60 dollars under extended support, on top of the machines that run the services. The main cost, however, remains operating hours: upgrades, monitoring, permissions and networking for the cluster.
Do you need Kubernetes for high availability?
No. Kubernetes is one way to get there, not the only one. A second server ready to take over, a managed database with replication, or a managed container service at a provider often cover the needs of a mid-sized company. Start by putting a figure on the acceptable downtime: that is what tells you which level of redundancy to pay for.
Sources
- Kubernetes, Overview (new tab)kubernetes.io
- Kubernetes, Releases (new tab)kubernetes.io
- AWS, Amazon EKS pricing (new tab)aws.amazon.com
- Docker, Docker Compose (new tab)docs.docker.com
Jim · founder of Brain Plus AI
Also in infrastructure and cloud
Choose and price8 min
Dedicated server, VPS or cloud: choosing by use
Dedicated server, VPS or cloud: none of them is the right choice for everything. What really sets them apart, the four questions that decide for each use, and why most companies end up combining all three.
Practical guide13 min The topic guide
Cloud infrastructure: the foundation for all your projects
Before the first project, a cloud infrastructure foundation settles accounts, access, backups and budget once and for all, and every later project inherits it. What it contains, where to put it, what it costs and why running it matters more than installing it.
Practical guide9 min
Self-hosted n8n with Docker: what production requires
Installing n8n with Docker takes a few commands; making it hold up in production takes a handful of decisions. Database, encryption key, updates, telemetry and GDPR: what the n8n documentation says, and what our own operation adds.