What Kubernetes requires in operation

kubernetes

Share this post with your network.

A Kubernetescluster runs for months without intervention. Then an upgrade is due, and it becomes clear how many components depend on it.

Anyone who operates such an environment is familiar with both states. In everydayag , the cluster requires little attention. Pods restart, nodes are added or removed, and the system compensates for this automatically.

It is precisely this tranquility that leads to the misconception that running the business is the easier task. It is rarely visible.

A cluster consists of many components

What is referred to as the cluster is a combination of: a control plane with etcd, a CNI plugin for the network, an ingress controller, CSI drivers forag, and, depending on the environment, a certificateag, metrics server, and a monitoring stack.

Each of these components has its own release plan and supported version range. None of these plans are dependent on the others.

At least two Kubernetes upgrades per year

Kubernetes is released three times a year in a new minor version. Each version is then supported with patches for approximately fourteen months, with twelve months being the standard support period.

Those who wish to remain within the supported area must therefore perform at least two upgrades per year.

What an upgrade brings with it

An upgrade doesn't stop at the control plane. It also affects adjacent components because their supported version ranges change along with it.

And it affects the company's own manifests, because API versions are first marked as obsolete and are dropped a few versions later.

Therefore, what is being operated is not a single piece of software, but a matrix of versions in which every part must fit every other part. This matrix shifts on its own, even if no one touches anything.

The effort comes in waves

Between upgrades, the effort required is minimal. On upgrade dates, it is significant and difficult to estimate, because only the preparation reveals which parts will be missing.

An Ingress controller that has run unchanged for two years can block an upgrade because its supported version cannot make the jump.

What lies beneath the applications

Setting up a backup of etcd is quick; the actual work lies in the rehearsed restore process.

The availability of the control plane depends on whether one controller or multiple controllers are running across separate zones. Certificates have an expiration date and will not notify you before they expire.

A quiet year proves nothing

A cluster that ran smoothly for a year doesn't prove that the operation is sound. It proves that nothing came up during that year that would have disrupted the matrix.

Theagis the cast, not the skill

Technically, there's nothing unusual about these tasks. A team that has implemented Kubernetes can also perform them. The more difficultagis another one: Can the necessary knowledge be maintained permanently for something that's only needed twice a year?

Months pass between upgrades. People change roles or companies, and the experience from the last iteration is only partially available. Anyone who relies on a single person for this work doesn't have a knowledge problem, but an availability problem.

The remedies are known: documentation, a second person involved in the topic, a test cluster for the trial run. All three incur ongoing costs for a benefit that materializes twice a year.

When self-operation is suitable

It's suitable if the platform itself is part of your own product or if the requirements demand control over every layer. It's less suitable if the cluster is theagfor applications and nothing else.

Where the platform level can be delegated

Control plane, Kubernetes version and upgrades, operating system and node patching, network andagcan all be managed externally, while the application layer remains in-house. Namespaces, deployments,ag, resources, and permissions do not change ownership.

The matrix does not disappear, but it becomes the responsibility of another entity.

Where this boundary lies at Netstream and what a dedicated cluster on Swiss infrastructure costs can be found on the Managed Kubernetes.

More from our blog

Newsletter

Subscribe to our newsletter.

Do you haveagabout our services or need more information? Please contact us via the form or directly at hello(at)netstream

Alternatively, you can use our LiveChat in the bottom right corner or call us on 058 058 40 00.

Netstream Logo White

Learn more.

Learn more about your options with the Netstream Cloud. Leave your contact details and we'll get in touch.

Or call us at:
058 058 40 00