Kubernetes for SMEs only works if you treat it as an operating model, not a one-off project. A cluster nobody maintains after the rollout loses its value within a few months: policies go stale, access piles up, and the knowledge lives in one person's head instead of the team's. Kubernetes operations means thinking about governance, security and handover from day one, not after the first outage.
I advise mid-sized companies on Kubernetes adoption and run production clusters of my own in a German cloud, with several control plane nodes spread across separate data centers for high availability. You can find all my Kubernetes articles collected on the Kubernetes page.
What is standard practice at large corporations, dedicated operations teams, clear ownership, a four-eyes principle for changes, gets skipped in many smaller companies. That foundation is exactly what decides whether Kubernetes turns into an investment or a liability.
Why companies adopt Kubernetes in the first place
Kubernetes is not an end in itself. If you build a cluster because it is currently the standard, you burn budget without a return. In my projects, the real motive almost always comes down to one of three things: faster time to market for new software, lower operating costs through better use of existing hardware, or the ability to serve several products on one shared platform instead of building separate infrastructure for every project.
Kubernetes itself promises automated rollouts, self-healing and horizontal scaling for that. All of that is technically true, but it does not automatically solve the business problem. A cluster with perfect automation is worth little if nobody in the company understands why a Pod just restarted or who is allowed to change a permission. That is exactly where the difference between a Kubernetes project and real Kubernetes operations begins.
From pilot project to real Kubernetes operations
A pilot project has an end date: a proof of concept runs for a few months, then someone decides whether it continues. An operating model has no end date. As soon as a cluster carries production traffic, you need answers to questions nobody asked during the pilot. Who patches the nodes? Who responds when a control plane node fails? Who checks whether a new deployment violates a policy before it goes live?
In practice, I see the same transition again and again at mid-sized clients: one developer builds the first cluster, usually on their own initiative because the team wanted to ship faster. That works as long as this one person is available. The moment they are on vacation, sick or no longer with the company, it becomes clear whether the project actually turned into an operating model.
Knowledge that does not depend on one person
The biggest risk factor I see with Kubernetes at SMEs is not the technology, it is how knowledge is distributed. If a cluster runs on GitOps, the desired state of the system lives in the Git repository, every change has a commit, an author and, ideally, a reason. If a cluster runs on manual kubectl commands from individual people, that memory exists nowhere except in their heads.
Three things matter for handover in my view. First, declarative configuration as the single source of truth, so a new Kubernetes expert on the team can reconstruct the cluster's state from the repository without asking their predecessor. Second, clearly assigned roles and permissions, so it is visible who is responsible for what, instead of one admin account for everyone. Third, documentation of the decisions, not just the configuration: why three nodes and not five, why this storage provider and not another.
That also includes making sure a restore has not just been tested once, but that several people on the team can actually perform one. How to back up etcd and volumes properly and rehearse a restore is covered in Kubernetes Backup: etcd and Volumes.
Governance and security belong together from the start
Governance and security get treated as separate topics in many projects. In practice, they belong together. Security protects the cluster and the applications inside it from unauthorized access. Governance makes sure the operation itself follows rules anyone can retrace.
For an SME, that means in concrete terms: roles and permissions through RBAC instead of shared admin accounts, policies that get enforced automatically instead of gathering dust in a wiki, and a log that shows who changed what and when. None of that is exotic, all of it is either built into Kubernetes or achievable with well-established tools. The official Kubernetes RBAC documentation describes the underlying model in detail.
Here is a short example of a role that gives a development team read access to Pods in their own namespace, without write access to anything else:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-shop
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
You bind this role to a group or a person through a RoleBinding, never to the whole team as cluster admin. Starting small and expanding permissions deliberately guards against the most common mistake I find during assessments: one cluster admin account for everyone, because that was easier at the start.
What running your own operations really means
Before you commit to an operating model, it is worth an honest look at three cost blocks: the infrastructure itself, ongoing operations, and the people who carry it. Infrastructure is usually the smallest block and the easiest to compare. Ongoing operations, monitoring, patching, backups, incident response, is regularly underestimated because it never shows up on an invoice, only in working hours. And people are the block SMEs are most likely to be missing: who in the company can actually restore a cluster in an emergency if the one person who set it up is not reachable?
That is exactly why comparing self-managed and managed Kubernetes only makes sense across all three blocks together, not just the server price. A detailed breakdown of the individual cost blocks is in Kubernetes Costs: What a Cluster Costs, and I answer the underlying question of self-managed or cloud in Kubernetes On-Premises or Cloud?.
Who Kubernetes pays off for, and who it does not
Kubernetes pays off if you run several services or microservices, if traffic spikes or growth require automatic scaling, and if several teams or products can share the same platform. The more standalone applications a company runs, the more a shared platform pays off, taking over standard tasks like rollout, restart and load distribution.
Company size alone decides nothing here. Two questions weigh more: are there at least two people who understand a cluster and are allowed to touch it, and is there an agreed way to reach someone outside office hours, for the nights when the application must not go down. A twenty person company with two experienced developers and an on-call arrangement runs Kubernetes more easily than a two hundred person company where a single person carries all of it alone.
Kubernetes rarely pays off for a single, manageable application with little operational overhead. A single server running containers, or a simple cloud service, is often enough, and the added complexity of a cluster costs more than it saves. Legacy applications with very specific infrastructure requirements, say a fixed IP address for a firewall rule, sometimes simply do not fit Kubernetes either, without the adaptation being worth it. Answering these questions honestly before adoption saves you from a cluster that only produces costs and never delivers the expected benefit.
Frequently asked questions
What is the difference between a Kubernetes project and Kubernetes operations?
A project has an end date and a defined goal, and once reached, it is done. Operations run indefinitely: patching, monitoring, governance and handing knowledge to new team members never stop. Companies that plan Kubernetes only as a project almost always underestimate the ongoing effort afterward.
How much expertise does a company need for Kubernetes operations?
Enough to handle roles, permissions, updates and incidents without depending on one irreplaceable person. That does not mean every developer needs to be a Kubernetes expert, but at least two people should be able to run the cluster independently in an emergency.
Is Kubernetes even suitable for small and mid-sized companies?
Yes, if several services or products run on the same platform and scaling or high availability are genuinely needed. For a single, simple application, the operational overhead usually outweighs the benefit.
What does high availability mean in Kubernetes in practice?
At least several control plane nodes, ideally spread across separate data centers, so the failure of one node does not take down the cluster. The available topologies are described in detail in the Kubernetes documentation on high availability options.
How to take the next step
The most important step before adopting Kubernetes is an honest one: clarify whether your company is ready to run it as an ongoing operation, not just roll it out once. That covers roles, permissions, backups and the question of who steps in during an emergency.
If you are not sure whether Kubernetes is the right step for your company, or how to make an existing cluster ready for handover, an honest assessment is usually the fastest way to clarity. My Kubernetes page shows how I approach that.
You will find all the examples in chapters 2 and 7 of my Kubernetes Practical Guide (Rheinwerk Computing).
