Kubernetes 1.34 reached upstream end of life on 27 October 2026. It had been in maintenance mode since 27 August 2026.
The date is easy to put on a calendar. The harder part is checking whether everything that runs on the cluster, and everything the cluster runs, can move with it.
A Kubernetes minor upgrade is rarely just a new API server version. It is a change to the contract between the control plane and your workloads, admission webhooks, CRD controllers, network and storage plugins, and the nodes themselves.
The short answer
Before upgrading a production cluster off an end-of-life Kubernetes version, inventory the APIs your workloads and tools actually call, your admission webhooks and CRD controllers, CNI and CSI compatibility, and the control-plane/node version-skew rules. Then confirm your managed provider's supported upgrade path, exercise a representative deployment on the target version and test your recovery procedure.
Upstream EOL is not your provider's deadline
Upstream end of life means the Kubernetes project no longer ships patch releases for that minor version. Security fixes and bug fixes land only in supported releases.
It does not automatically mean your managed Kubernetes service stops supporting 1.34 on the same day. Managed providers publish their own support windows, and they can be shorter, longer or tied to extended-support pricing. Some also restrict how far you can jump. UpCloud, for example, documents that its managed Kubernetes upgrades proceed one minor version at a time.
So there are two dates to check, and they are not necessarily the same deadline:
- The upstream EOL, which decides when you stop receiving upstream patches.
- Your provider's policy, which decides when you will be forced, charged or left unsupported.
Running an EOL version is a risk decision, not just an operations backlog item. If a vulnerability is fixed only in newer releases, the fix may never arrive for your version. That is why upgrade planning belongs in DevSecOps and supply-chain security work, not only in a platform team's ticket queue.
Step 1: find the APIs you actually use
Kubernetes removes deprecated API versions on a published schedule. The risk is not the API you remember using. It is the one in an old Helm chart, a forgotten CronJob manifest, a CI script or a third-party operator.
Check from several angles, because each one misses something:
- Live API server telemetry. The
apiserver_requested_deprecated_apismetric shows deprecated API groups and versions that clients are still requesting. Audit logs can also carry a deprecation annotation that identifies the caller. - Manifests and charts in Git. Scan rendered Helm output and Kustomize builds, not only raw templates. A chart value can switch an API version.
- Stored objects. Objects in etcd are served in the current preferred version, so "it's running" does not prove the manifest that created it will still apply.
- Tooling outside the cluster. CI pipelines, Terraform providers, GitOps controllers and internal scripts call the API too.
Telemetry only shows what was called during the window you watched. A monthly batch job or a disaster-recovery script may not appear at all.
Step 2: admission webhooks and CRD controllers
Admission webhooks sit in the request path. A mutating or validating webhook that fails on a new API server version can block deployments across the whole cluster, depending on its failurePolicy.
For each webhook, record:
- Which operator or product owns it.
- Its failure policy and which resources it intercepts.
- Whether its vendor supports the target Kubernetes version.
- What happens to deployments if it is unavailable during the upgrade.
CRD controllers deserve the same treatment. Cert managers, secret operators, ingress controllers, service meshes, policy engines and backup operators all ship their own compatibility matrices. A controller built against older client libraries may keep running and quietly stop reconciling some resources. Upgrade operators to versions that support both the current and target Kubernetes release before moving the control plane, where the vendor allows that.
Step 3: CNI and CSI compatibility
Networking and storage plugins are the dependencies most likely to turn an upgrade into an outage.
The CNI plugin handles Pod networking and often network policy. The CSI driver attaches and mounts volumes. Both run as privileged components on every node and both have version support matrices of their own.
Check the plugin version against the target Kubernetes version, the upgrade order the vendor recommends, and whether node images change at the same time. For stateful workloads, confirm volumes detach and reattach cleanly when nodes are drained and replaced. A drain that hangs on a volume or a PodDisruptionBudget is a common reason an upgrade window runs long.
Step 4: version skew rules
Kubernetes components tolerate limited version differences, and an upgrade passes through states where they differ.
The upstream version-skew policy says the control plane is upgraded one minor version at a time, and nodes must not be newer than the API server. The kubelet may lag behind the API server by a limited number of minor versions; check the policy for the exact versions you run rather than relying on memory. kubectl and other clients have their own supported range.
In practice this means:
- Upgrade the control plane first, then node pools.
- Do not skip minor versions on the control plane.
- Check that the node pools you leave behind are still inside the supported skew.
- Treat clients in CI and on engineers' laptops as part of the skew calculation.
If a cluster is several minor versions behind, the upgrade is several sequential upgrades, each with its own compatibility check. Budget for that.
Step 5: exercise a representative deployment
An upgrade ticket is not a validation plan.
Create or reuse a non-production cluster at the target version with the same CNI, CSI, admission webhooks and operators as production. Then deploy something representative through the real delivery path, not by hand:
- Deploy a typical stateless service through your CI/CD or GitOps pipeline.
- Deploy one stateful workload with a persistent volume.
- Confirm ingress, network policy, secrets and certificates behave as before.
- Drain and replace a node and watch rescheduling and volume reattachment.
- Check that monitoring, logs and alerts still arrive from the upgraded components.
This catches the problems that compatibility tables miss: a chart that renders differently, a policy that now rejects a field, a dashboard that silently loses a metric because a label changed.
Step 6: test the recovery procedure
Know what you will do if the upgrade goes wrong before you start it.
Control-plane minor upgrades are generally not something you roll back casually, and managed services often do not offer a downgrade at all. Recovery may mean restoring workloads into a new cluster from backups and Git. That procedure should be tested, with a measured duration, before the production change.
Our article on testing disaster recovery and failover covers what that test should prove. For an upgrade, the minimum is: backups of cluster state and persistent data exist, a restore has been tried recently, and the team knows who decides to stop and recover.
Failure modes to plan for
The upgrades that go badly usually fail in predictable ways:
- A removed API in an unmaintained chart blocks the next deployment after the upgrade, not the upgrade itself.
- A webhook with
failurePolicy: Failbecomes unavailable and blocks every create and update it covers. - A node drain hangs on a PodDisruptionBudget or a volume that will not detach.
- An operator stops reconciling some resources without crashing.
- Old node pools fall outside skew because a node pool upgrade was postponed.
- Monitoring breaks quietly, so the team loses visibility at the moment it matters.
What to measure
Make the upgrade observable. Track deprecated API requests before and after, deployment success rate through the real pipeline, webhook latency and error rate, node drain duration, Pod restart counts and controller reconcile errors. Compare them with a baseline captured before the change.
The engineering decision
Kubernetes 1.34 reaching upstream EOL is a prompt, not the plan. The useful output is a short list: which workloads and integrations need attention, in which order, and how you will recover if a step fails.
If that list does not exist yet, an infrastructure audit is a reasonable place to build it before anyone touches the control plane.