Kubernetes 1.34 Reaches End of Life on October 27

Kubernetes 1.34 reaches end of life on October 27, 2026. After that the project stops releasing patches for it, so security fixes ship for newer lines and skip your cluster. If a customer's GPU or model-serving stack still runs 1.34, you have nine days to plan.

Kubernetes 1.34 end of life: the dates that matter

The Kubernetes patch releases page lists four active branches right now:

• 1.34: entered maintenance mode on August 27, 2026. End of life is October 27, 2026.
• 1.35: maintenance mode December 28, 2026. End of life February 28, 2027.
• 1.36: maintenance mode April 28, 2027. End of life June 28, 2027.
• 1.37: released August 26, 2026. Maintenance mode August 28, 2027. End of life October 28, 2027.

Once 1.34 drops off, 1.35, 1.36 and 1.37 are the supported lines. Landing on 1.35 only buys you until February 28, 2027, so aim higher. On a managed service, your provider's support calendar is the one that binds you, so check that too.

Plan the Kubernetes upgrade: three hops, not one

You can't jump from 1.34 to 1.37. The kubeadm upgrade guide says skipping minor versions is unsupported, so you go through 1.35, 1.36, then 1.37, control plane first and nodes second.

The version skew policy gives some slack: a kubelet may be up to three minor versions older than the kube-apiserver, never newer. You can finish the control plane first and rotate GPU nodes in a second pass. That is slack, not a destination, because a 1.34 kubelet is still on an end-of-life version.

Check the GPU stack before you upgrade GPU workloads

GPU nodes add a second question: does the GPU software still match? NVIDIA's GPU Operator platform support page for the 26.7 line lists Kubernetes 1.33 to 1.37 and marks 25.10.x and lower as end of support. Upgrade an old operator as its own change. If you run a DRA driver for GPUs, read its docs before each hop instead of assuming.

Inventory first on Monday morning

# Control plane and kubelet versions
kubectl version
kubectl get nodes -o wide

# GPU Operator chart version, to compare with NVIDIA's support table
helm list --all-namespaces

The VERSION column in kubectl get nodes -o wide is the kubelet version, so a node stuck on an old minor stands out. Do this for every customer cluster, not just the one you are working on.

Upgrade one minor at a time

This is the kubeadm sequence from the docs, shown for the first hop to 1.35:

# First control plane node (install the matching kubeadm package first)
sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.35.x   # replace x with the target patch version

# Every other node
sudo kubeadm upgrade node

# Each node, one at a time, GPU nodes included
kubectl drain <node-to-drain> --ignore-daemonsets
# upgrade the kubelet and kubectl packages, then:
sudo systemctl daemon-reload
sudo systemctl restart kubelet
kubectl uncordon <node-to-uncordon>

The docs require a drain before any minor kubelet upgrade. On GPU nodes that means evicting inference and training pods, so schedule around them. After the first control plane node, upgrade your CNI plugin if its docs say so.

What Kubernetes 1.37 adds for AI workloads

None of this is a reason to rush, but three items are worth knowing:

• HPA scale to zero is Beta and on by default (HPAScaleToZero). Set minReplicas: 0 with an object or external metric such as queue lag. CPU and memory can't wake a workload with no pods, and Services don't buffer requests, so this fits queue workers, not HTTP endpoints. See the official post.
• DRA extended resource support is GA. Per the DRA post, drivers can satisfy requests like example.com/gpu without a separate device plugin, and existing workloads keep working. Device taints also reached GA.
• Gang scheduling is Beta but off by default. The Workload and PodGroup APIs are scheduling.k8s.io/v1beta1 behind GenericWorkload. The scheduling post says the alpha API was replaced and disruptionMode changed, so older alpha manifests need rework.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_consumer_lag
        selector:
          matchLabels:
            name: worker_tasks
      target:
        type: Value
        value: "30"

This is the Kubernetes post's example. An external metrics adapter has to serve queue_consumer_lag, and the API server rejects minReplicas: 0 without an object or external metric.

Gotchas

• Don't create minReplicas: 0 HPAs mid-upgrade. Wait until both kube-apiserver and kube-controller-manager have the gate, or a controller manager without it treats zero replicas as a manual pause.
• A cluster whose kubelets sit persistently three minors behind must upgrade them before the control plane can move on.
• GenericWorkload and DRAWorkloadResourceClaims are disabled by default in 1.37.

An unpatched Kubernetes line under a GPU workload is a risk you inherit from the customer, so get the inventory done before October 27 and put the GPU stack on a supported pairing first.