Upgrades without the outage

Sound familiar?

“The upgrade has been on the backlog for three months.” Every planning cycle it gets deferred, because nobody can say with confidence what will break. The gap grows, and so does the risk of the eventual jump.

“Only one person can deploy to production.” They know which script to run and in what order. They are also the single point of failure for every release, and they would quite like a holiday.

“We are not sure what is actually running in production.” There is a repository, and there is a cluster, and at some point they stopped being the same thing. Nobody knows exactly when.

Why teams get stuck

By the time a team reaches out, Kubernetes is rarely the actual problem. The cluster is up and the pods are running. What has accumulated is a platform nobody wants to change.

Each of those symptoms is defensible in isolation. Together they are why a routine version bump turns into a planned outage with six people on a call.

We have run this work in production: Kubernetes on RKE2 and vSphere in a hybrid enterprise estate in regulated financial services, and a lift-and-shift from semi-automated shell scripts to a highly available multi-tenant Kubernetes platform. The pattern repeats, and so do the fixes.

What it costs

Fixed scope, so you know the price before the work starts.

All prices exclude VAT. Larger multi-cluster platform work is quoted after a short scoping call.

Cluster Upgrade Runway

One week, fixed price. The deliverable is not only an upgraded cluster, it is the ability to do the next one yourselves.

1. Find what breaks. Where every cluster sits, how far from supported, and what the vendor support window looks like. We detect deprecated and removed API usage across your workloads, including the manifests nobody has opened since they were written.
2. Validate the path. The upgrade runs first against an environment that resembles production. If you do not have one, building it is part of the work. This is where the surprises are supposed to happen.
3. Production upgrade. Executed with your team watching, with a rollback path defined before we start.
4. Runbook. A written procedure specific to your estate, including the failure modes we hit and how they were handled. Your team runs the next upgrade from this document.

Clusters need upgrading permanently, so the point of this engagement is to make every following one cheap.

GitOps Foundation

Two weeks, fixed price. Argo CD, structured to survive more than one team using it.

The failure mode is familiar: someone installs Argo CD, points it at a repository, and eighteen months later there are four repositories, three ways of promoting a change and no reliable answer to what is running in production. The tool was never the difficult part. The repository structure and the promotion contract are.

You get a repository layout that scales past the first team, environment promotion that happens as a reviewable pull request, secrets handled properly rather than committed, drift detection that reports when the cluster stops matching Git, and a rollback that is a revert. Deployments become diffs with an audit trail attached, which is a security and compliance benefit as much as a delivery one.

Who this is for

A good fit if you have Kubernetes in production, a small platform team carrying more than it should, and a change process that has become the bottleneck. Most of our clients run somewhere between two and twenty clusters.

Not the right fit if you are still deciding whether to adopt Kubernetes at all. That question deserves an honest answer before anyone sells you a platform, and it is usually a shorter conversation than a fixed-scope engagement.

Handover is the point

We write comprehensive technical documentation as part of delivery, because an engagement that leaves your team dependent on us has failed at the thing you were buying. Every engagement ends with a walkthrough session with the engineers who own the platform afterwards.

What clients say

“Victor helped us out quickly by setting up observability in our k8s clusters. The setup is highly available and Victor was very responsive during the whole process, and also available for quick finetuning and setting up extra alerts after the installation. Highly recommended.”

• Jouke, Comper