Upgrade production Kubernetes without downtime
Fixed scope. Your maintenance window. A rollback plan signed off before work begins. Your team never has to touch production, and does not lose a sprint to it.
An upgrade is not a project. It is a calendar.
Three facts this whole service rests on. Every one of them is yours to verify: the sources are under each tile.
Kubernetes ages on a calendar you do not control
A new minor release appears roughly three times a year, and each version gets about a year of patches. On Amazon EKS, standard support runs 14 months from release. A production cluster therefore needs upgrading at least twice a year, indefinitely.
Sources: kubernetes.io: release cadence, kubernetes.io: patch support, AWS EKS pricing. Verified 30 Aug 2026.
You are already paying for the delay
A cluster past standard support costs USD 0.60 per hour on Amazon EKS instead of USD 0.10. On Azure AKS, the Premium tier with Long-Term Support likewise costs USD 0.60 per hour against USD 0.10 on Standard. Both platforms charge USD 365 per month per cluster for a postponed upgrade, roughly EUR 3,760 a year per cluster.
Sources: AWS EKS pricing, AKS pricing (verified through the Azure Retail Prices API), Microsoft Learn: AKS LTS. Verified 30 Aug 2026.
Anyone can press the “Upgrade” button
Downtime is not caused by the cluster. It is caused by your applications: a single replica, a missing PodDisruptionBudget, no graceful shutdown, long-lived connections without draining. We answer for what happens twenty minutes after that button is pressed.
This one is not a statistic but experience from production clusters. What passes and what does not in your case comes out of the assessment, written down service by service.
Five phases, the weight sits on the third
Assessment, remediation, rehearsal, execution, handover. Everything else rests on the rehearsal, which is why it is a phase of its own, with its own time budget.
Read-only access, nothing touched in production. We go through manifests and Helm charts for deprecated and removed APIs, build an add-on compatibility matrix (CNI, CSI, ingress, cert-manager, service mesh, GitOps, autoscaler) and score every service on whether it survives a node drain. You get a risk map, a Workload Readiness Scorecard and an upgrade plan with a fixed price.
Whatever fails the Readiness Bar gets fixed before the upgrade, on the current cluster version. Missing PodDisruptionBudgets, a single replica on a service that should not have one, probes that lie, applications without graceful shutdown. Application fixes and the cluster upgrade never share one window.
We start outside production, of course: on your staging, or on a clone of the cluster that we build when staging does not resemble production in the ways that matter. The difference is not that we rehearse, it is what we take away from it: we run the whole upgrade including the rollback and record the timing of every step. Those timings then become the content of the maintenance window instead of being estimated. If something breaks, it breaks here, and we fix it before it ever reaches you.
This is the only way to talk about zero downtime and mean it. Without a measured rehearsal, “no downtime” is a hope.
In your maintenance window, nights and weekends included, following the runbook proven in the rehearsal. The rollback plan is agreed in writing beforehand. We track progress against your SLOs rather than against a feeling. If the indicators move, we know before you do.
Updated infrastructure code, a final report, and a runbook your own team can follow for the next upgrade. We do not need you dependent on us. If you hire us again, let it be because it pays off.
What you can find out for free, and what you can't
Before you talk to us, run these. We mean it: if they are enough, you just saved yourself CZK 70,000.
This part is solved, and free
- AWS EKS Upgrade Insights: since March 2025 it blocks the upgrade itself when it finds unresolved deprecated-API usage. Free, in the console. Source: AWS: announcement of 27 Mar 2025
- Azure AKS: pre-upgrade validation, including a check for API breaking changes and misconfigured PodDisruptionBudgets. Microsoft's own documentation also recommends open-source tools. Source: Microsoft Learn: AKS upgrade options
- kubent, Pluto, KubePug: open-source deprecated-API scanners. Free, and you can run them against the cluster or against the manifests in Git. kube-no-trouble · Pluto · KubePug
They all answer one question: “is there an API in my manifests that disappears in the target version?” It is an important question, it is solved, and nobody should be charging you for it. Links verified 7 Sep 2026.
None of them answers these
- What order to upgrade ingress-nginx, cert-manager, the CSI driver and Istio in, so they don't break each other
- Which admission webhook will quietly start blocking your deploys after the upgrade
- Whether a given service survives a node drain, and which one won't
- What is sitting in Git and ships tomorrow. EKS Insights reads a 30-day rolling audit log, so it keeps reporting a problem for a month after you fixed it Source: aws/containers-roadmap #2569
- How long the window takes, and the point at which the rollback call gets made
And above all: none of them sits down with your cluster at two in the morning on a Saturday and takes responsibility for what happens twenty minutes after that button gets pressed.
What “without downtime” means here
Zero downtime is a measured quantity, not a claim in a proposal. We measure the impact on availability first during the rehearsal on a clone of your cluster, and again during the upgrade itself, against your own SLOs. The measured figures go into the final report.
The yardstick is the Readiness Bar: ten specific conditions verified during the assessment. Anything that fails gets a separate remediation phase: we fix it before the upgrade, on the current cluster version. Application fixes and the cluster upgrade never share one window, because if something failed, the cause could not be traced.
Nobody can honestly promise zero downtime for an application they have never seen. That is why we start by looking at it.
How we arrive at a price
We do not publish a price list, because every cluster is neglected differently. What we do publish is a fixed price for the first step, and an honest account of what drives the second.
A fixed price for 1 cluster. Each additional cluster +CZK 25,000, up to 3 clusters.
You get a risk map, the full list of deprecated APIs, an add-on compatibility matrix, a Workload Readiness Scorecard and an upgrade plan, with a fixed price for execution.
What the price depends on:
- number of clusters
- how many versions the cluster is behind
- how many services fail the Readiness Bar
- whether a non-production environment exists to rehearse on
Each additional cluster +CZK 75,000. Services the assessment finds below the Readiness Bar are a separate line at CZK 19,000 per day.
The exact upgrade price is set after the assessment, because without one it would be a guess, and a guess on a production cluster is not a price but a promise somebody ends up paying for. Prices exclude VAT and apply to clusters on Azure AKS and Amazon EKS. For clients on continuous care (lifecycle) we also issue a quarterly patch-management report in a form an auditor accepts.
When this isn't worth it
One cluster, three nodes, no SLO, and nobody minds a night-time outage? Extended support on Amazon EKS costs USD 0.60 per cluster per hour, roughly USD 438 a month. That is cheaper than we are and it is a legitimate answer: pay AWS and upgrade when you have time.
This starts making sense from two production clusters up, or when an hour of downtime costs more than the whole window, or when nobody owns the cluster.
Source: AWS: EKS extended support pricing. The monthly figure is USD 0.60 × 730 hours; USD 365 of that is the surcharge over standard support. Verified 7 Sep 2026.
Before we talk about our price: work out what it costs you not to upgrade the cluster.
Calculate the cost of waiting →What people ask first
How much does a Kubernetes cluster upgrade cost?
The assessment is a fixed CZK 70,000 for 1 cluster, with each additional cluster at +CZK 25,000 (up to 3 clusters). It takes five working days and needs only read-only access. The upgrade starts at CZK 145,000 for 1 cluster and 1 version, with each additional cluster at +CZK 75,000. The final price depends on how many versions the cluster is behind, how many services fail the Readiness Bar, and whether a non-production environment exists.
We deduct the assessment fee from the upgrade price if you order the upgrade within 90 days. The exact upgrade price is set after the assessment, because without one it would be a guess.
Isn't EKS Upgrade Insights or kubent enough, and free?
For deprecated APIs, yes, and we recommend running them before you contact us. Since March 2025 AWS EKS Upgrade Insights blocks the upgrade itself when it finds unresolved use of an API that disappears in the target version. Azure AKS runs its own pre-upgrade validation, and kubent, Pluto and KubePug are free. That question is not worth paying for any more.
What they do not answer is the order add-ons have to be upgraded in, which admission webhook will quietly start blocking deploys afterwards, whether a given service survives a node drain, or what is sitting in Git and ships tomorrow: EKS Insights reads a 30-day rolling audit log. And none of them takes responsibility for the maintenance window. That is exactly where our work starts.
What access to our infrastructure do you need?
The assessment needs read-only access: a reader role in Azure or AWS and a ServiceAccount in the cluster with permission to read objects. We do not read secrets and do not need access to them.
Execution requires temporarily elevated rights, limited to the maintenance window and revocable in one step. On Azure we use Azure Lighthouse, on AWS a cross-account role with an ExternalId. We never enter the management account. Every action appears in your own logs under the name of a specific engineer.
What happens if the upgrade fails?
The rollback plan is agreed in writing before work starts, including the specific conditions that trigger it. We do not invent those criteria during the window, when there is no calm to do it in.
The rollback is part of the rehearsal: we run it on a clone of your cluster and time it. So we know in advance that it works and how many minutes it takes, and that figure goes into the maintenance window plan rather than being argued about on the night.
This is also why we never mix application fixes and the cluster upgrade into one window: if something failed, the cause could not be traced. Commercial terms for such an event are agreed in the contract, according to the scope of the engagement.
How long does it take and when does it run?
The assessment takes five working days. From assessment to execution is usually two to three weeks, depending on the scope of remediation. Execution itself runs in the maintenance window you choose, nights and weekends included. You set the window, not us.
Do you also work with self-hosted clusters?
Our priority is Azure AKS and Amazon EKS. That is where our process is most established and the pricing most predictable. Self-hosted clusters (kubeadm, RKE2, k3s) are assessed case by case: we will always do the assessment, and decide on execution based on how the cluster is built. We say so on the first call, not after you have paid.
We start by finding out what breaks
Tell us which version you are on and how many production clusters you run. We reply within one working day with a date and a scope. The first call needs no access at all.