Kubernetes Upgrade: Roadmap, End of Support and Emergency Guide

Cluster without support or an upgrade without a plan? WZ-IT upgrades Kubernetes clusters in maintenance windows, and where needed as a single engagement billed by effort without an ongoing contract. See Kubernetes Support or review ongoing operations including upgrades.

As of 28 October 2026: the Kubernetes project maintains the release branches 1.37, 1.36 and 1.35 (Releases). Kubernetes 1.34 reached end of life on 27 October 2026. This guide covers the release cycle, version skew rules, preparation, the pitfalls of the last minor jumps, the procedure per distribution and the path for clusters that already run without support.

Table of contents

• Release cycle and support windows
• Support windows by operating model
• Version skew: what may lag how far
• Preparation: six checks before the upgrade
• Pitfalls of the last minor jumps
• Procedure by distribution
• Rollback: what goes back and what does not
• Emergency: a cluster without support
• Planning maintenance windows
• Do it yourself or hire a service provider
• Our approach at WZ-IT
• Further guides
• Status and methodology

Release cycle and support windows

New minor versions appear about three times a year (Release Cycle). Each minor version receives patches for around 14 months: twelve months in the standard period, then two months in maintenance mode with CVE fixes, dependency updates and critical component issues (Patch Releases). The three most recent branches are maintained (Version Skew Policy).

The figures come from the release overview and the release announcements (1.37, 1.36, 1.35, 1.34, 1.33, 1.32). After the EOL date only the occasional release appears (non-active branch history); for 1.34, 1.34.13 still came on 28 October 2026. The start of maintenance mode is a good planning deadline: a cluster on 1.35 should be on 1.36 or higher by 28 December 2026.

Support windows by operating model

The upstream window applies to self-operated clusters; managed offerings add their own deadlines.

With managed offerings, the expiry date of your own version belongs in the calendar, not the upstream date.

Version skew: what may lag how far

The Version Skew Policy defines how far components may deviate from the kube-apiserver:

This gives the order: kube-apiserver first, then controller manager and scheduler, then kubelet and kube-proxy. The kube-apiserver does not skip a minor version, not even in a cluster with a single instance. Before a kubelet minor upgrade the node is drained; an in-place upgrade without a drain is not supported. Anyone holding nodes three versions behind permanently has to raise them before the control plane may move on. The prerequisites of the upgrade order name kubelets that are at most two minor versions behind the target version before an API server step; after two control plane steps the nodes are therefore raised before the third follows. Deployment tools may set stricter limits.

Preparation: six checks before the upgrade

1. Record the current state. Control plane, kubelet, container runtime and cgroup version per node:

   kubectl version
   kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion
   stat -fc %T /sys/fs/cgroup/   # cgroup2fs = cgroup v2
   

2. Find deprecated APIs. Since 1.19 every call to a deprecated API produces a warning header, an audit annotation and the metric apiserver_requested_deprecated_apis (Deprecation Policy). The query with the target version in the removed_release label shows which clients are affected:

   apiserver_requested_deprecated_apis{removed_release="1.37"} * on(group,version,resource,subresource) group_right() apiserver_request_total
   

   The separately installed kubectl convert plugin migrates manifests in the repository; whether a target version no longer serves an API can be tested on the staging API server with --runtime-config=<group>/<version>=false (migration guide).

3. Check add-ons against the target version. Every component has its own matrix. According to its installation documentation, Argo CD 3.5 is tested against Kubernetes 1.33 to 1.36; 1.37 is not listed there on 28 Oct 2026. The Flux installation documentation lists Kubernetes 1.35 and newer and does not support older versions. Talos 1.14 lists Kubernetes 1.33 to 1.37 (support matrix). Argo CD vs Flux compares the two GitOps tools. Admission webhooks must be able to process the data of the new API server version. Ingress NGINX has been retired since 24 Mar 2026, with no releases and no security fixes (Release 1.36); the way out is described in ingress-nginx to Gateway API.

4. Read the release notes of every intermediate version. The key points of the last jumps are in the next section.

5. Back up. An etcd snapshot is the basis of any recovery and is stored encrypted (etcd operations). kubeadm additionally writes backups of etcd data (the folder stays empty with external etcd) and manifests to /etc/kubernetes/tmp, which remain after the upgrade (kubeadm upgrade). Resources, volumes and databases are covered by the concept in Kubernetes backup: the four layers.

6. Check capacity and drain. A drain respects PodDisruptionBudgets; the unhealthy pod eviction policy AlwaysAllow is recommended in the PodDisruptionBudgets so that broken applications do not block the drain (Safely Drain a Node). Single-replica applications are briefly unavailable during the drain; a staging cluster with the production add-on state makes the run meaningful.

Pitfalls of the last minor jumps

A cluster that is three branches behind passes through all of these points one after another.

Procedure by distribution

Rollback: what goes back and what does not

The upgrade guides of RKE2 and k3s state that Kubernetes does not support downgrades of control plane components. The Deprecation Policy (Rule 4b), by contrast, requires that after an upgrade the way back to the previous release stays open without converting stored objects, as long as no new features were used. What can be planned is therefore a restore, not a downgrade command.

With a snapshot immediately before the upgrade and a change freeze during the window, the loss of a restore is limited to changes made within the window.

Emergency: a cluster without support

A cluster on a version that is no longer maintained keeps running but receives no security patches. Skipping several minor versions in one step is not intended for the control plane. The path leads through every intermediate version:

From 1.32, the control plane therefore runs through 1.33 and 1.34 to 1.35.

Procedure:

1. Restrict access. The Kubernetes API and admin services do not belong on the open internet; Access Kubernetes privately with NetBird describes the way.
2. Inventory and backup. Record versions, add-ons, CRDs and operators, check the etcd snapshot and volume backups. The checklist is in Taking over a Kubernetes cluster.
3. Step plan per minor version. For every intermediate version: add-on matrix, removed APIs, release notes, control plane, nodes, smoke tests. Nodes may lag three minor versions behind the API server, but the prerequisites of the upgrade order allow only two minor versions of distance to the target version before an API server step. Where the distribution allows it, the nodes therefore follow in one batch after at most two control plane steps.
4. Consider the alternative. With many steps, undocumented operators or many stateful workloads, a new cluster on the current version with the workloads migrated via GitOps and Velero is often easier to plan than a chain of in-place steps. This is our assessment, not a project requirement.
5. Mind managed deadlines. With AKS, EKS and hosters that enforce updates, the provider decides when the upgrade happens; the date is in the provider's documentation.

Planning maintenance windows

The length of a window comes from measured values, not rules of thumb: duration per control plane step, duration per node drain, and the number of nodes that PodDisruptionBudgets allow in parallel. The run in the staging cluster provides these values.

• Order: staging first, then production; with several clusters, a cluster of low criticality first.
• Separate windows: control plane, nodes and add-ons as separate steps, each with an abort criterion and a way back.
• Cadence: patch releases typically appear monthly, minor versions about three times a year. A cluster that is only upgraded once a year goes through about three minor steps in a row per run.

Do it yourself or hire a service provider

Our assessment: one or two minor steps are feasible in-house if the team has already run a minor upgrade on this very cluster and staging matches production. With three or more steps, no staging, undocumented operators or knowledge held by a single person, an inventory comes first; after that the decision is between external support and a rebuild. A quote for an upgrade should state inventory, step plan, way back and acceptance criteria in writing; the way back is rehearsed in staging before the production window.

Our approach at WZ-IT

Upgrades in maintenance windows are part of Managed Kubernetes operations from €590 net per cluster per month including 3 worker nodes; every additional worker node costs €129.90 (status October 2026). Monitoring runs 24/7; the response to P1 incidents follows the service level. Before taking over a cluster without support, the cluster audit from €1,490 net one-time records versions, add-ons, backups and restore. It is not a penetration test and can be credited against the first month of operations.

Single upgrade tasks without an ongoing contract are handled by Kubernetes Support billed by effort at €120 net per hour during service hours (Monday to Friday, 08:00 to 17:00), and at €240 outside them. Scope and effort frame are agreed in writing before work starts. Guaranteed response times come with Managed Kubernetes and a service level, not with support billed by effort.

Further guides

• Kubernetes backup: the four layers: secure etcd, resources, volumes and databases first
• Taking over a Kubernetes cluster: audit checklist: inventory of a foreign cluster
• Migrate from ingress-nginx to the Gateway API: replace an add-on past end of support
• Migrate from Helm 3 to Helm 4: package manager deadlines
• k3s vs. RKE2 vs. Talos: the distributions compared
• Argo CD vs Flux: choose a GitOps tool and check its Kubernetes matrix

Status and methodology

• Survey: 28 Oct 2026. The dates come from the release pages and release announcements of the Kubernetes project, the provider information from the respective documentation, retrieved on the same day.
• Calculations: days left = end of life minus 28 Oct 2026; steps = target version minus current version in minor units, because the kube-apiserver does not skip a minor version.
• Maintenance mode: two months before end of life, as stated on the patch release page for 1.34 to 1.37.
• Not covered: OpenShift and other vendor-specific lifecycles. The linked documentation is authoritative.

The tables may be reused with attribution and a link to this guide.

Cluster on 1.34 or older? A single engagement or ongoing operations with upgrades in maintenance windows: Kubernetes Support or Managed Kubernetes.

Related service: Kubernetes upgrade and end of life