How many upgrade runs a magnum-cluster-api cluster on 1.33, 1.34 or 1.35 needs, what each run requires, and what changes on nodes at 1.35 and 1.36.
Production Magnum clusters on Kubernetes 1.33 or 1.34 have a fixed date coming. Kubernetes 1.34 reaches end of life on October 27, 2026, and after that the upstream project ships no more 1.34 patches, security fixes included. 1.33 has been out of support since June 28. The work lands on the platform and DevOps teams who run these clusters on OpenStack.
Upstream Kubernetes doesn't let the API server skip a minor version, so a Kubernetes upgrade between minor versions moves a cluster one release at a time. On a Cluster API cluster, such as one built with magnum-cluster-api, each upgrade also replaces the nodes machine by machine. A 1.34 cluster is one upgrade away from 1.35. A 1.33 cluster is two.
Waiting doesn't shorten that list. A cluster on an end-of-life minor gets no upstream security fixes, and getting it back to a supported release still takes the same chain of upgrades, one minor and one node rollout at a time.
For each cluster, you need four answers: how many upgrade runs it needs, which version to target, what to check on its nodes first, and whether your team runs the upgrades or hands them to us. With magnum-cluster-api, our Cluster API driver for Magnum, each run is one openstack coe cluster upgrade command. You need a node image and a cluster template ready before you start.
The dates
Upstream Kubernetes maintains the three newest minor releases and gives each about a year of patch support. As of mid-September 2026, 1.33 is past its June 28 end of life. 1.34 entered maintenance mode on August 27 and reaches end of life on October 27. In maintenance mode, a branch's fixes are limited to vulnerabilities with an assigned CVE, dependency issues and critical core component issues, so 1.34 clusters are already on that reduced list.
1.35 enters maintenance mode on December 28, 2026 and reaches end of life on February 28, 2027. 1.36 reaches end of life on June 28, 2027. 1.37 came out on August 26, 2026 and is supported until October 28, 2027. The Kubernetes releases page has the full schedule.
What the driver is tested against
We run conformance jobs in CI for magnum-cluster-api release v0.38.2 on Kubernetes 1.33.12, 1.34.8, 1.35.5 and 1.36.1. Each version runs once with Calico and once with Cilium. The node images the driver boots come from our capo-image-elements project. Its last release before mid-September, 2026.05-7 from May 30, has images for those same patch versions on Debian 13, Ubuntu 22.04, Ubuntu 24.04 and Rocky Linux 9.
1.37 isn't in that CI matrix yet. Until a driver release adds it, target 1.35 or 1.36.
Atmosphere deploys magnum-cluster-api as its Magnum driver. The upgrade plan below applies to Kubernetes clusters on Atmosphere clouds too, limited to the driver release and node images that cloud has deployed.
From 1.33, 1.34 or 1.35
The upstream version skew policy says kube-apiserver moves one minor version at a time, even with a single control plane instance. Our upgrade docs describe a wider range for the driver: any minor release in the same series, or one major release ahead. Follow the upstream rule, since it's the stricter one, and plan one minor version per run.
- On 1.33: two runs get you to 1.35, through 1.34. If the first run checks out, do the second in the same maintenance window. 1.34 has six weeks of patches left, so there's no reason to leave the cluster there. A third run to 1.36 gives you the longest support window among the versions the driver's CI covers today.
- On 1.34: one run to 1.35 before October 27 keeps the cluster on a branch that still gets security fixes. A second run to 1.36 moves your next deadline from February 28 to June 28, 2027.
- On 1.35: no deadline this year. 1.35 enters maintenance mode on December 28. Schedule the 1.36 run before then to keep it off the critical path.
Between runs, check that every node reports the new version and that your workloads are healthy before you start the next one.
What each run needs
Each upgrade run needs:
- A node image in Glance for the target Kubernetes version. It has to be in Glance before you start the upgrade.
- A cluster template that points at that image, with its
kube_tag label set to the target version. You need one per hop: a 1.33 cluster going to 1.35 needs a 1.34 template and a 1.35 template. - The upgrade command, run against that template:
openstack coe cluster upgrade <cluster> <template>
The upgrade happens in place and rolls through the cluster. The driver keeps the existing cluster object and sets its Kubernetes version to the new kube_tag, and Cluster API replaces the machines at that version.
Your workloads will notice the machines being replaced. Pod disruption budgets, readiness probes and topology spread decide how much, so set them before the first upgrade.
Node and workload changes at 1.35 and 1.36
Each run replaces nodes. If a replacement node's kubelet won't start, the rollout stalls partway through the cluster, inside the maintenance window you booked. The Kubernetes deprecated API migration guide lists no API version removed after 1.32. Most of what changes on these upgrades is on the nodes:
- cgroup v1: starting with 1.35, the kubelet won't start on a cgroup v1 host by default. You can turn that off with the
failCgroupV1 setting, but the lasting fix is a node image that runs cgroup v2. - containerd 1.x: the 1.35 release post said 1.35 would be the last release to support it. The container runtime documentation, updated in May 2026, keeps the kubelet's fallback for containerd 1.x until 1.38, which drops it. Move to containerd 2.0 or later before that upgrade. The
kubelet_cri_losing_support metric shows which nodes have a container runtime that's losing support. - kube-proxy IPVS mode: deprecated in 1.35 but still available, and kube-proxy logs a warning when it starts. If your clusters use it, plan the move to nftables mode.
1.36 also brings one workload change: the gitRepo volume plugin is permanently disabled. Pods that still mount one need an init container or a git-sync style sidecar before that upgrade.
The Kubernetes 1.35 release post covers the node changes in detail. If you build your own node images, check their cgroup, containerd and kube-proxy settings before you put them in a 1.35 or 1.36 template.
Running the hops yourself
The alternative to the Magnum driver is to run Cluster API and its OpenStack provider directly. That's the setup behind our multi-region failover design. Nodes roll the same way. You also run the management cluster and its providers, and if you use ClusterClass-managed topologies, you maintain the ClusterClass definitions too.
Upstream ships about three minor releases a year and supports each for about a year. Each run moves one minor, so a cluster that stays supported needs about three of these runs a year. The question is who does that work. With the driver, each run is one Magnum API call, and the original announcement explains how we designed it.
Some workloads may not need a cluster at all. If you haven't decided between Kubernetes or plain VMs for them, deciding changes how many clusters you have to keep current.
On a self-service cluster, your team starts each upgrade. Nothing happens until an image and a template for the target version are available and someone runs the command.
With managed Kubernetes, our team runs the version upgrades and security patches. In the supported model, your team operates the clusters and our engineers are on call around the clock. For a one-off push through several clusters before October 27, send us the cluster list and current versions for our professional services team. Kubernetes upgrades are part of its scope.
After 1.36
A cluster that reaches 1.36 this autumn has its next forced minor upgrade in spring 2027, before 1.36 reaches end of life on June 28. Watch for the first magnum-cluster-api release that adds 1.37 to its CI matrix. 1.37 reaches end of life on October 28, 2027.
Then you decide whether to move to 1.37 as soon as the driver's CI covers it, or stay on 1.36 until spring. Moving early uses a winter maintenance window on a minor that's new to the driver's CI. Waiting until spring gets you a later 1.37 patch release. The October 28, 2027 end of life is the same either way.
