Material update: 2 September 2026
The public title remains, but the operational decision has changed: Kubernetes 1.33 is no longer a valid upgrade target. It reached end of life on 28 June 2026 and no longer receives security or bug fixes. A team still running 1.33 needs a controlled path through each intervening minor release to a version supported by both the Kubernetes project and its platform provider.
Version 1.33 still matters as a migration boundary. Released on 23 April 2025, it contained 64 enhancements: 18 graduated to stable, 20 entered beta, 24 entered alpha, and two were deprecated or withdrawn. Those figures describe the release; they do not constitute an upgrade plan. A plan must start from the actual cluster, its application dependencies and the constraints of the managed service or installation method.
Replace the version goal with a support goal
Select the target first. On 2 September 2026, upstream maintains the three most recent minor branches—1.35, 1.36 and 1.37—according to the current Version Skew Policy. A managed Kubernetes service may expose a different schedule, patch set and addon matrix. The platform owner should confirm the target in provider documentation rather than assume the newest upstream release is immediately available.
Do not skip minor versions. The official kubeadm upgrade procedure explicitly treats that path as unsupported. A 1.33 cluster must therefore pass through 1.34 and any further required versions. Each step is a separate deployment and validation event even when the organisation chooses short intervals between maintenance windows.
Define the goal as the latest patch of the selected branch, with compatible addons and a dated plan to leave transitional versions. A green control plane on its own does not mean that the platform has returned to a supported state.
Build an evidence-backed cluster inventory
Before changing anything, capture enough information to reproduce the decision. The inventory should include kube-apiserver, kubelet and kubectl versions; control-plane topology; etcd mode; node operating systems and container runtimes; CNI; CSI; ingress or Gateway API; service mesh; autoscalers; policy engines; operators; and every CRD.
The second layer is API use. Inspect manifests in source control, live objects, deprecation warnings and calls made by controllers and scripts. Kubernetes 1.33 formally deprecated the core Endpoints API in favour of EndpointSlice. The project’s migration explanation makes clear that direct readers and writers are affected, so searching application YAML alone is insufficient.
Every dependency needs an owner and evidence of support for the next minor release. “It should work” is not a compatibility-matrix entry. Acceptable evidence can be a supported vendor version, a test on a representative cluster or an explicitly accepted replacement plan.
Remove API and addon blockers before production maintenance
Where the older cluster supports the replacement, ship compatibility work before the platform upgrade. This applies to API migrations, CRD revisions, admission webhooks, generated clients and feature-gate configuration. Doing so avoids combining a platform transition with a large application release inside one recovery window.
Kubernetes 1.33 removed status.nodeInfo.kubeProxyVersion, which had already been disabled by default, and withdrew experimental host-network support for Windows Pods. Check internal integrations, dashboards and automation rather than assuming the change concerns only users of an uncommon feature. An observability tool that reads a removed field may not stop the cluster, but it can remove a signal precisely when operators need it.
Make consequential defaults explicit as well. If scheduler, kubelet or controller behaviour matters to a service, encode the expectation in configuration and tests. Release notes are inputs to impact analysis, not a ready-made assessment of a particular estate.
Rehearse the exact sequence on a canary cluster
A useful canary resembles production in installation method, networking, storage, policy and critical workload classes. An empty test cluster proves that an installer can start components. It does not exercise DNS, service discovery, ingress, persistent volumes, autoscaling, disruption budgets, jobs, webhooks or telemetry. Use synthetic or sanitised workloads that cover those paths.
Run the same version sequence and commands planned for production. With kubeadm, upgrade a primary control-plane node, then remaining control-plane nodes, addons and workers. Drain workers one at a time or in small groups while retaining enough capacity for traffic and critical pods.
Canaries reduce uncertainty; they do not guarantee a safe rollout. Record actual drain time, rescheduling behaviour, storage recovery and metric stabilisation. Feed those observations back into the runbook instead of carrying estimates from another cluster or an earlier release.
Separate application rollback from control-plane recovery
Create and verify backups of critical state before the window, including etcd or the provider’s equivalent mechanism and application data. A completed snapshot job is not recovery evidence. A successful restore in an isolated environment, followed by integrity checks and timing, is.
Do not describe Kubernetes rollback like an ordinary application deployment. Stored API changes, etcd versions, component configuration and controller behaviour can limit a safe downgrade. For each step, identify the last point at which reversal remains supported and the recovery procedure after that boundary has been crossed.
Application migrations near the platform change should remain compatible with both platform versions. When that is impossible, assign a separate risk owner and choose an order that does not make control-plane recovery depend on an irreversible data migration.
Close each minor step with explicit evidence
Give every minor upgrade entry and exit criteria. Before starting: healthy control plane and etcd, ready nodes, sufficient drain capacity, a current backup, an approved compatibility matrix and no unresolved use of APIs being removed. After completion: expected component versions, no new deprecation warnings, successful critical journeys, correct data replication, stable service indicators and a completed observation interval.
Track time spent on unsupported releases, remaining deprecated API calls, the proportion of addons with confirmed support, node-drain duration, manual interventions and restore-test results. Success is not the message “upgrade complete”. It is a supported version with operational evidence and the next upgrade date already owned in the platform backlog.
Sources
- Kubernetes v1.33: Octarine — Kubernetes v1.33 Release Team, 23 April 2025.
- Kubernetes 1.33 release status — Kubernetes, EOL 28 June 2026.
- Version Skew Policy — Kubernetes, accessed 2 September 2026.
- Upgrading kubeadm clusters — Kubernetes, accessed 2 September 2026.
- Kubernetes v1.33: Continuing the transition from Endpoints to EndpointSlices — Kubernetes, 24 April 2025.