A Kubernetes cluster runs for months without intervention. Then an upgrade is due, and it becomes clear how many parts depend on it.
Anyone who runs such an environment knows both states. Day to day, the cluster demands little attention. Pods restart, nodes are added or drop out, and the system compensates on its own.
It is precisely this calm that leads to the misjudgement that operations are the smaller task. They are just rarely visible.
A cluster is made up of many components
What is called the cluster is an assembly: a control plane with etcd, a CNI plugin for networking, an ingress controller, CSI drivers for storage and, depending on the environment, cert-manager, metrics-server and a monitoring stack.
Each of these components has its own release schedule and its own supported version range. None of these schedules takes the others into account.
At least two Kubernetes upgrades a year
Kubernetes releases a new minor version three times a year. Each version then receives patches for around fourteen months, twelve of which count as the standard support period.
Anyone who wants to stay within the supported range therefore carries out at least two upgrades a year.
What an upgrade drags along with it
An upgrade does not stop at the control plane. It drags the neighbouring components along with it, because their supported version ranges shift as well.
And it affects your own manifests, because API versions are first marked as deprecated and then removed a few versions later.
What you operate is therefore not a single piece of software but a matrix of versions in which every part has to fit every other. This matrix shifts by itself, even if nobody touches anything.
The effort comes in bursts
Between upgrades, the effort is small. At upgrade time it is large and also hard to estimate, because only the preparation reveals which part will not keep up.
An ingress controller that ran unchanged for two years can hold up an upgrade because its supported version does not make the jump.
What lies beneath the applications
Backing up etcd is quickly set up; the rehearsed restore is the real work.
The availability of the control plane depends on whether one controller or several run across separate zones. Certificates have a limited lifetime and do not announce themselves before they expire.
A quiet year proves nothing
A cluster that ran smoothly for a year does not prove that operations are under control. It proves that nothing fell due that year that would have set the matrix in motion.
The question is staffing, not skill
Technically, there is nothing unusual about these tasks. A team that introduced Kubernetes can also carry them out. The harder question is a different one. Can the necessary knowledge be kept available permanently for something that is needed twice a year?
Months pass between two upgrades. People change roles or companies, and the experience from the last round can only partly be recalled. Anyone who relies on a single person for this work does not have a knowledge problem but an availability problem.
The remedies are well known: documentation, a second person familiar with the topic, a test cluster for a dry run. All three carry an ongoing cost for a benefit that materialises twice a year.
When running it yourself makes sense
It makes sense when the platform itself is part of your own product or when requirements demand control over every layer. It makes less sense when the cluster is the foundation for applications and nothing else.
Where the platform layer can be handed over
The control plane, Kubernetes version and upgrades, the operating system and patching of the nodes, networking and storage can all be operated by someone else while the application layer stays in-house. Namespaces, deployments, images, resources and permissions do not change owner in the process.
The matrix does not disappear, but it becomes someone else’s job.
You can find out where Netstream draws this line and what a dedicated cluster on Swiss infrastructure costs on the Managed Kubernetes page.
