Upgrade hop
Kubernetes 1.34 → 1.35
1 · Fix removed APIs first
Only alpha or off-by-default beta versions are removed in this hop.
| Kind | API version | Stops being served | Use instead |
|---|---|---|---|
| VolumeAttributesClass | storage.k8s.io/v1alpha1 alpha · off |
1.35 | storage.k8s.io/v1 |
Check your files with the manifest checker; in a live cluster, the API server metric apiserver_requested_deprecated_apis shows which deprecated APIs clients still call.
2 · Other changes that can bite
Removed in 1.35
- cgroup v1 support is retired: on nodes without cgroup v2 the kubelet will fail to start, so migrate those nodes before upgrading.
Deprecated in 1.35
- kube-proxy ipvs mode is deprecated. It still works but logs a warning at startup; nftables is the recommended replacement on Linux.
- v1.35 is the last release supporting containerd 1.x; move to containerd 2.0 or later before the next upgrade.
- Outside the release itself: Ingress NGINX gets only best-effort maintenance until March 2026, then will be archived. Gateway API is the recommended path.
Our summary of the 1.35 release announcement (CC BY 4.0). Read the full changelog for your components.
3 · Upgrade in this order
- Prepare. Move every node to 1.32 or newer if any are older: a 1.35 API server supports kubelets back to 1.32 only. Upgrade to the newest 1.34 patch,
1.34.13. - kube-apiserver to 1.35 (in HA clusters, one instance at a time; old and new may differ by one minor during the roll). Use the newest patch,
1.35.10. - kube-controller-manager, kube-scheduler, cloud-controller-manager to 1.35, once every API server is on 1.35.
- kubelet on each node (drain first). Optional in this hop: kubelets from 1.32 to 1.35 all work with a 1.35 control plane.
- kube-proxy: no newer than the API server, and within the same window as the kubelet it runs beside.
- kubectl: 1.34 to 1.36 all talk to a 1.35 API server.
From the official version skew policy. Managed services run the control-plane steps for you; node pools are still yours to schedule.