What upgrades and support involve on Kubernetes
Kubernetes upgrades are a recurring obligation, not a one-off project. The Kubernetes project maintains the three most recent minor releases, and releases arrive about three times a year on a cycle of roughly 14 weeks. Patch support for each minor runs about one year, roughly 14 months including the pre-release period. As of September 2026, the supported minors were 1.37 (end of life October 28, 2027), 1.36 (end of life June 28, 2027) and 1.35 (end of life February 28, 2027). A cluster that stays on 1.35 past its end-of-life date stops receiving security fixes, so the upgrade calendar has to be set by those dates, not by when someone has time.
Upgrades get triggered in four common ways: an end-of-life date approaches, a security fix ships in a patch release that your cluster needs, a new add-on or operator requires a newer API server, or your distribution vendor changes its supported version set or support terms. Before each one, confirm which component versions your distribution pins, which add-ons (ingress, CNI, CSI drivers, metrics, GitOps controllers) support the target minor, and whether any workload uses APIs removed in that release. Version skew rules require the API server to move one minor at a time and let kubelets trail by up to three minors, so a long gap usually means several sequential upgrades rather than one jump.
Teams that already run Kubernetes often keep routine patch releases in-house, since these are usually low-risk when the cluster is well documented and rehearsed. Multi-version catch-up, where a cluster is several minors behind, is a different job. It calls for a sequenced plan, deprecated API remediation, add-on matrix checks and rehearsals in staging that mirror production. Many organizations also bring in a partner under a retainer for coverage outside working hours or for when the internal team is stretched. Ask any partner which of these they will perform, what is in a rehearsal, and how they will record the results.
What to decide now: name an owner for the upgrade calendar, document which distribution and add-on versions are in use, and confirm where the next end-of-life date falls for each cluster. Then decide which tasks your own staff will run and which will need outside help. A written scope with those lines drawn clearly makes both the internal plan and any quote easier to compare.
What the upgrade and support work includes
Each upgrade follows the same sequence: assess, plan the version skew, rehearse, change production, then hand over. The support retainer keeps the cluster on a supported minor release after go-live.
Assessment, inventory and API checks
We record the cluster version, distribution, node pools, installed add-ons and workloads, then compare them with the three supported minor releases and their end-of-life dates. The inventory also scans manifests, Helm charts and GitOps repositories for deprecated and removed APIs, so each affected object is fixed before the upgrade window opens.
Version skew and upgrade order
The plan moves kube-apiserver first, one minor version at a time, then kube-controller-manager, kube-scheduler and kubelets within the allowed skew. Kubelets may run up to three minor versions behind the API server, so node pools can lag, but each hop is written down with its order, pause points and the checks that gate the next step.
Add-on and CNI, CSI, ingress and certificate compatibility
Each networking, storage, ingress and certificate component is matched against the target Kubernetes version and its upgrade notes. A mismatched CNI or CSI driver can block node drains or stall volume attachment, so the review names an owner, the chart or driver version and any manual step that must run in a fixed order.
Staging rehearsal with etcd snapshot and rollback
The full sequence runs first in a staging cluster built to resemble production, starting with an etcd snapshot taken with etcdctl snapshot save. The rollback steps are rehearsed too, including restoring from that snapshot with etcdutl, so the team knows how a failed control plane step will look before production.
Production execution, verification and handover
The production change runs from the rehearsed runbook, with a fresh snapshot taken beforehand and go or no-go checks between the control plane, node pool and add-on steps. Post-upgrade verification covers API health, node readiness, workload rollouts, ingress and certificate status and monitoring. Runbooks and handover notes go to your operators.
Support retainer scope
The retainer can cover patch releases on an agreed cadence, monitoring of Kubernetes release and end-of-life notices, incident response within windows set in the contract, and ad hoc changes such as adding a node pool. Scope, deliverables and timelines are agreed in writing before work starts, so confirm which of these items are included.
What drives upgrade cost and duration
This table lists the factors that change how much work each Kubernetes minor version hop takes, why each one matters and how to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Minor versions to cross | Upgrades move one minor version at a time, so each hop is a separate change with its own testing, rollback point and skew check. Crossing several versions multiplies the work. | Stay close to the current supported minor release and schedule upgrades on the release cadence rather than letting clusters fall behind. Confirm current support dates on the Kubernetes releases page before planning. |
| Cluster count and node pools | Every cluster and node pool needs its own control plane, node and add-on sequence, and its own verification. Mixed kubelet versions across pools add skew to track. | Standardize cluster builds and node pool definitions, and use the same runbook for each. Retire clusters that no longer have a purpose before the next upgrade window. |
| Control plane topology | A stacked control plane (etcd on the control plane nodes) and an external etcd cluster need different sequencing, backup checks and quorum safeguards. Losing quorum during a control plane change is hard to recover from. | Take and verify an etcd snapshot before each control plane change. Keep three or more control plane nodes and an odd etcd member count, and upgrade one control plane node at a time while watching quorum. |
| Add-ons, custom resources and operators | Ingress controllers, CNI and CSI plugins, metrics and logging stacks, and operators each have their own version support matrix. Old CRD versions can block API removals. | Inventory every add-on, its installed version and its supported Kubernetes range. Remove unused operators and CRDs, and confirm the target version of each add-on before starting the hop. |
| Custom admission policies and webhooks | Validating and mutating webhooks sit in the request path. A webhook that is unavailable or incompatible with a new API version can block workloads or the upgrade itself. | List every webhook with its failure policy, namespace selector and owner. Confirm each one supports the target API versions, and test it in staging with the new control plane before production. |
| Stateful workloads and persistent volumes | Databases, queues and stateful sets need drain, disruption budget and storage driver compatibility checks. Data-bearing nodes take longer to cycle safely. | Confirm backups and restore tests for persistent volumes before the upgrade. Check pod disruption budgets, CSI driver compatibility and the node drain order for each stateful service. |
| Air-gapped image and chart mirroring | Without internet access, every control plane image, add-on image and Helm chart for the target version must be mirrored to the private registry and repositories before the upgrade starts. | Build a mirror manifest for each target version and verify the images are present before the change window. Keep the mirror process repeatable so each hop reuses it. |
| Distribution vendor upgrade tooling | Certified distributions and managed services ship their own upgrade procedures, support windows and supported-version rules. Their tooling can speed up the work or add prerequisites. | Ask the vendor which versions and paths it supports, what its upgrade tooling changes, and whether support covers your target release. Document any vendor-specific steps in the upgrade runbook. |
| Compliance evidence requirements | Change records, test results, benchmark scans and approvals may be needed for an assessment. Collecting them after the fact takes time and can leave gaps. | Define the evidence list before the first upgrade, such as change approvals, pre-upgrade snapshots, test results and post-upgrade scan output. Store it with each change so each hop produces the same records. |
| Environments to rehearse | Each hop should be rehearsed in a staging environment that matches production closely enough to expose skew, add-on and webhook problems. More environments mean more rehearsal cycles. | Keep a staging cluster that mirrors production topology and add-ons. Rehearse each hop there first, and record the findings so later hops and environments reuse them. |
Upgrade and support phases
A sequence that moves each cluster one minor version at a time, proves the change in staging, and leaves a record an auditor or operator can follow.
Inventory and baseline the clusters
Record the version of every control plane node, etcd member, worker pool and add-on, plus the kube-apiserver version that sets the skew limit for kubelets. Confirm API usage, cluster-wide add-ons and that etcd snapshots and workload backups have been taken and restored successfully in a test. The output is a baseline document the client signs off, so every later step compares against the same facts.
Review compatibility and deprecations
Scan manifests, Helm charts, operators and custom resources for APIs removed or deprecated between the current and target minor version, and check each add-on's published support matrix for the target release. Each affected item gets an owner, a fix or a documented exception, and written sign-off from that owner. The output is a compatibility register with every item resolved or accepted.
Rehearse the full sequence in staging
Run the complete upgrade in a staging cluster built to match production topology, in the same order planned for production: control plane first, then the remaining control plane components and kubelets. Record how long each stage took, which health checks failed, and what manual steps were needed. The rehearsal also includes a rollback path and an etcd restore drill. The output is a runbook revised from what the rehearsal showed.
Execute the production change window
Upgrade one control plane node at a time behind the API server load balancer, then the other control plane components and worker pools in the agreed order, draining nodes as the runbook specifies. Check etcd quorum, API availability, node readiness and critical workloads after each node. A stop condition in the runbook defines when work halts and rollback begins. The output is a completed change log with timestamps and check results for each node.
Verify conformance and workloads
Run the agreed conformance and workload checks, including add-on health, ingress and DNS resolution, admission policies, autoscaling and a sample of application smoke tests owned by the client's teams. Confirm the audit logging and monitoring still receive data. The output is a verification report signed by the platform owner, and a change record that links the baseline, compatibility register, rehearsal results and production log as evidence.
Run steady-state support
Track the three supported minor releases, the patch cadence published on the Kubernetes release pages, and end-of-life dates for each version in use and each add-on. Schedule the next upgrade before the current minor version reaches end of life. Under a retainer, reviews cover new patch releases, deprecation notices and the backlog of compatibility items, and each review produces an updated baseline. Confirm with the vendor or distribution which support window applies to your build.
What teams keep in-house and what they outsource
The table shows which upgrade and support tasks platform teams usually keep, which they often outsource or retain, and the skills each task needs, and a partner does not replace the workload owners who approve changes and test their applications.
| Activity | Usually in-house | Often outsourced or retained | Skills required |
|---|---|---|---|
| Routine patch application | Platform team schedules and applies patches to approved minor releases within the supported set | Partner runs patch cycles under a retainer or as a fixed-scope task | Kubernetes cluster administration, Linux node maintenance |
| Change approval and business owner testing | Change board and workload owners approve changes and test their own applications | Usually kept in-house; partner prepares change records and test evidence | Release management, security review |
| Catch-up upgrades across several minors | Platform team sets the target and the order of stepwise upgrades | Partner plans the path and executes one minor version at a time alongside the team | Kubernetes cluster administration, networking, storage, release management |
| Deprecated API remediation across many charts | Chart owners update their manifests and values | Partner scans charts, prioritizes findings and fixes shared templates | Kubernetes cluster administration, release management |
| Add-on compatibility work | Platform team owns CNI, ingress, storage and monitoring add-ons | Partner tests add-on versions against the target minor and proposes version pins | Networking, storage, Kubernetes cluster administration |
| Staging rehearsal design | Platform team defines the rehearsal scope and pass criteria | Partner designs the rehearsal and runs it with the team before production | Kubernetes cluster administration, release management, networking, storage |
| etcd backup verification before change | Platform team takes snapshots and confirms they can be read before each change | Partner can run restore tests within a written scope; the team keeps custody of backups | etcd operations, security review |
| Out-of-hours incident cover | Platform on-call covers weekday changes and escalations | Retained partner cover for out-of-hours incidents, with response terms set in writing | etcd operations, networking, Linux node maintenance, Kubernetes cluster administration |
What usually goes wrong and how to prevent it
Each card pairs a failure pattern with the check that prevents it. Most of these problems surface during a change window, which is when they cost the most to fix.
Jumping several minors or out of order
Clusters that fall behind the three supported minors often try to close the gap in one move. The version skew policy requires kube-apiserver to move one minor at a time, before the controller manager, scheduler and kubelets. Plan a stepwise path through each intermediate minor and confirm that every kubelet stays within three minors of the API server.
Removed APIs found after upgrade
Manifests, Helm charts and controllers that call an API version removed in the target minor fail only after the control plane is upgraded. Run deprecation scans against live cluster objects and source repositories on a recurring schedule. Record each finding with an owner and a fix date before the change window opens.
Add-ons and CNI left behind
CNI plugins, ingress controllers, CSI drivers and policy engines each declare which Kubernetes minors they support. An unsupported pairing can break pod networking or storage once the control plane moves. Keep a compatibility matrix with a named owner, and confirm each target version with its vendor before the upgrade starts.
Etcd restore never tested
Many teams take etcd snapshots but have never restored one into a copy of the cluster. A restore with etcdutl often exposes missing certificates, encryption configuration or PKI files that the snapshot does not contain. Rehearse a full restore in a staging copy before each minor upgrade, and time it against your recovery target.
Air-gapped certificate and image gaps
Offline clusters depend on mirrored control plane, add-on and base images, along with certificates that the target release expects. A missing image or an expired certificate can stop kubeadm upgrade on the first node. Run kubeadm config images list before each change, and keep a private registry copy of every add-on image in the plan.
Undocumented ownership after handover
When an implementation project ends, upgrade runbooks, compatibility matrices and rollback criteria can leave with the people who wrote them. Name an owner for each upgrade decision and store the runbook and written rollback decision point in your own repository. Confirm who may stop or reverse an upgrade before the next minor release window.
How the work changes by starting point
The cluster runs the previous minor release, so the upgrade is a single hop. The work is mostly verification, because the change is small and the risk sits in add-ons, admission webhooks and workloads.
- Confirm the target is one minor above the current version and follow the version skew order: kube-apiserver first, then kube-controller-manager and kube-scheduler, then kubelets.
- Rehearse the upgrade in a staging cluster built from the same manifests, add-on versions and node pools as production.
- Check every ingress controller, CNI plugin, CSI driver and webhook against the target release before the change window.
- Run a deprecated API check against manifests and Helm releases, since removed APIs are the most common surprise in a single hop.
- Take a fresh etcd snapshot and set a rollback decision point before the production window opens.
Each minor release must be reached in sequence, so the plan has one stage per hop. Every stage carries its own deprecated API remediation, add-on compatibility check and rollback point, and the cluster may run mixed versions while the plan is in progress.
- Map the full path of hops and assign each stage a rehearsal in staging before the next stage starts.
- Fix deprecated API usage in workloads and GitOps repositories for every release between the current version and the target.
- Confirm kubelet versions against the apiserver at each stage, since kubelets may trail the apiserver by up to three minor versions.
- Replace or re-pin add-ons that do not support the intermediate releases, so each stage can be reproduced.
- Ask the partner to show the stage plan, the owner of each stage and the criteria for stopping between hops.
The cluster runs a minor release the project no longer maintains, so the decisions concern urgency and accepted risk. Upstream patch support ends on a published date, and the schedule must be set against that date. For example, the project lists 1.35 with end of life on February 28, 2027, as of September 2026, but confirm the date for your version on the official releases page.
- Set the upgrade sequence in writing, including how many hops are needed before the cluster returns to a supported version.
- Record any risk accepted for a defined period, with a named owner, a review date and an exit date.
- Prioritize security patching for control plane and node components, and document compensating controls such as restricted API exposure and tighter network policy.
- Confirm with your distribution or provider whether any extended support exists, because upstream patch support does not continue past the published date.
- Apply the several-minors stage plan to the sequence, since the hops still need rehearsal and deprecated API checks.
The upgrade method and version list come from the provider, so the plan follows its documentation and support matrix. A vendor distribution means you run the upgrade. A managed service means the provider runs part of it, so the division of responsibility must be confirmed in writing.
- For a vendor distribution, follow the vendor's upgrade procedure and confirm which Kubernetes versions the vendor supports under your subscription.
- For a managed service, confirm which control plane steps the provider performs, which node pool and add-on upgrades remain yours, and how much notice the provider gives.
- Check whether bundled add-ons update automatically, and whether that changes your test window.
- Ask whether the provider's path requires one hop at a time and whether it matches the version skew rules.
- Confirm who owns etcd backups and rollback for each model, since the answer differs between a distribution you operate and a service the provider operates.
No images, charts or packages can be pulled during the change, so everything the upgrade needs must be mirrored into the private environment first. Certificate handling also becomes a planned step that is checked before the control plane restarts.
- List the control plane and add-on images for the target version with kubeadm config images list, and mirror them to the private registry before the change.
- Mirror add-on and chart repositories as well, and verify image digests, because one missing image can stop an upgrade partway through.
- Check the expiry of cluster certificates and confirm how renewal works for your topology, rotating them before the window if needed.
- Confirm that the kubeadm upgrade points at the private image repository, and test the full sequence on an offline staging cluster.
- Ask the partner for the mirror manifest, the offline test results and the rollback procedure for a missing or corrupted image.
What the client needs to provide
The client needs to provide four things before an upgrade plan can be written: access, an inventory, backup evidence and decisions. Missing owners and undocumented add-ons are the most common reasons upgrade plans slip, so the owner list and add-on inventory deserve the most attention in the first week. Access means a kubeconfig or a role that can read the production cluster and a staging copy, node access for the kubelet and OS checks, read access to the Git repositories that hold manifests and Helm values, and pull access to the container registry. Confirm which of these exist today. A shared admin kubeconfig is the usual gap, and it should be replaced with a named role before work starts.
The inventory should list the current cluster version and the version of every node pool. For each add-on, record the chart name, the chart version and the image tags, along with every operator and the custom resource definitions it owns. Ask for the output of a live list of installed Helm releases and CRDs rather than a document that may be out of date. This is what lets the team check each component against the supported minor version range and the deprecated API list.
Backup evidence is the basis for any rollback decision. Provide the schedule and the location of recent etcd snapshots, and the record of the last restore test, including the date it was run and who ran it. For persistent volumes, provide the backup status and the last verified restore for each stateful workload. An upgrade should not start if no restore has ever been tested, because the rollback plan depends on it.
Decisions and named owners close the gap. The client must set maintenance windows, the downtime each workload can accept, the rollback criteria that trigger a return to the previous version, and the approval chain that signs off each step. Each workload and each add-on needs one named owner who answers for testing and sign-off. Confirm these names and decisions in writing before the staging rehearsal is scheduled, since an unassigned add-on will hold up the whole plan.
Frequently asked questions
How often does a Kubernetes cluster need an upgrade?
Plan around the release cycle: Kubernetes ships about three minor releases per year, roughly every 14 weeks. The project maintains only the three most recent minor releases, and each patch line receives about one year of patch support, roughly 14 months including the pre-release period. As of September 2026, 1.35 reaches end of life on February 28, 2027, 1.36 on June 28, 2027, and 1.37 on October 28, 2027. Confirm the current list on the Kubernetes releases page before you set an upgrade calendar, because the supported set moves with each release.
Can a cluster skip a minor version during an upgrade?
No. The version skew policy requires kube-apiserver to move one minor version at a time, so a cluster on 1.35 steps to 1.36 before it reaches 1.37. The control plane components kube-controller-manager and kube-scheduler follow the API server, and kubelets come last. Kubelets may run up to three minor versions behind kube-apiserver, which gives you room to upgrade worker nodes in batches. That flexibility does not remove the need to pass through each minor version, so plan the full path and rehearse each step.
How do we find deprecated APIs before an upgrade?
Check two places. First, compare the API versions used in your manifests, Helm charts and GitOps repositories against the removals listed in the release notes for each target minor version. Second, scan the live cluster, because workloads applied years ago may still reference retired APIs. Custom resource definitions and operators need separate checks, since their API versions depend on the vendor. Confirm each operator's supported Kubernetes versions before you upgrade, and repeat the scan after the staging rehearsal.
What drives the cost of a Kubernetes upgrade?
Scope drives most of the cost: the number of clusters and environments, node count, the distribution in use, and how many add-ons, operators and custom resources need compatibility checks. Stateful workloads, air-gapped environments with mirrored images, and the number of staging rehearsals also add effort. Costs fall into labor for planning, rehearsal, execution and validation, plus any vendor subscription terms. Planning and rehearsal are one-time work per upgrade, while each new minor cycle recurs. Ask any provider for an itemized quote per cluster, the rehearsal count, the rollback plan and the handover deliverables.
Can our own team run the Kubernetes upgrade without a partner?
Yes, many teams do, if they have experienced Kubernetes operators, a staging environment that mirrors production, and time to read each release's changes. Assign a named owner, take an etcd snapshot before each step, keep an add-on compatibility matrix, and write a runbook with rollback steps. A partner adds the most value through repeatable rehearsals, documented decisions and handover to your team. DeployOpen implements, upgrades and documents platforms inside your own cloud accounts, data centers or air-gapped networks, so the work stays under your control.
How DeployOpen scopes, delivers and supports upgrades
DeployOpen plans Kubernetes upgrades as a written, fixed-scope engagement inside infrastructure you control, then delivers them through staging rehearsals and documented runbooks. Ongoing support for later upgrades is available as a retainer.
How we scope
- The written scope names the clusters, distribution, current and target minor versions, and the node pools each upgrade step touches.
- We inventory kubelet, control plane and add-on versions so every upgrade step follows the one-minor-version-at-a-time order.
- The scope lists the deprecated API checks, add-on compatibility tests and rollback conditions that must be met before production work starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins. Ask for the scope to state which items sit outside it.
How we build
- We run each upgrade step in a staging cluster that mirrors production topology, including etcd members, load balancers and node pools.
- Deprecated API usage is checked against the target version and affected manifests, charts and controllers are updated and retested.
- Add-on compatibility for ingress, CNI, CSI, metrics and policy components is verified in staging before any production change.
- Each rehearsal produces a timed runbook with preflight checks, etcd snapshot steps, validation commands and a documented rollback path.
How we hand over
- You receive the executed runbook, the staging rehearsal results and a record of every version and add-on change made.
- Upgrade documentation covers the version skew rules that apply to your cluster and the sequence your operators must follow next time.
- Handover includes the etcd backup verification evidence taken before each step, so your team can show what was protected and when.
- Your staff walk through the runbook with us so the next upgrade can be run in house or booked as a new scoped engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for clusters that change on a regular cadence.
- Under a retainer we track the upstream release calendar and the end-of-life dates for the minor versions you run, and raise upgrade work in advance.
- Each support cycle reviews add-on releases, deprecated API findings and CIS benchmark drift so changes are planned rather than discovered in production.
- Ask any provider to confirm response expectations, change windows and what is covered by the retainer before signing, because these are set in the written agreement.
