Kubernetes 1.37 and 1.38: What's New in 2026 and What Got Removed

I read every Kubernetes release blog the week it lands, mostly so I know which line in the "Deprecations and removals" section is going to page someone six months later. This post is the 2026 version of that habit: what shipped in Kubernetes 1.35, 1.36 and 1.37, which features actually reached GA, which removals will break an upgrade, how long each version is supported, and what Kubernetes 1.38 (scheduled for 16 December 2026) means for a platform team planning the next hop. As of today the latest Kubernetes release is v1.37.2, published on 28 October 2026, and 1.34 has just reached end of life.

What is the latest Kubernetes version in November 2026?

The current minor is 1.37 ("Garhwal"), released on 26 August 2026. Its latest patch is 1.37.2. The project keeps three minor branches alive at a time, so the supported set on kubernetes.io/releases is 1.37, 1.36 and 1.35, each patched on the same day in October: 1.37.2, 1.36.6 and 1.35.10.

Kubernetes 1.34 dropped off that list. Its end of life date in the release schedule data was 27 October 2026, and 1.34.13 went out a day later as the final patch. If you run self-managed clusters on 1.34, you are now on an unsupported release. Managed services such as EKS run their own calendars (see my EKS in 2026 explainer for the paid extended support angle), but upstream security fixes for 1.34 have stopped.

Next up is 1.38. The 1.38 release schedule puts v1.38.0 on Wednesday 16 December 2026, with code freeze on 16 November and the deprecations blog due on 23 November. The tag v1.38.0-beta.0 already exists, so you can start testing against it in a throwaway cluster.

Kubernetes release cadence and support windows explained

Kubernetes ships roughly three minor releases a year, on a cycle of about 15 to 16 weeks. The 2026 calendar fits that pattern: 1.35 in December 2025, 1.36 in April, 1.37 in August, 1.38 in December.

Each minor gets about 14 months of patch support: a 12 month standard period, then roughly two months of maintenance mode where only critical fixes land. Patch releases are monthly. In practice that means you have to move at least one minor version a year just to stay supported, and because kubeadm and the version skew policy only allow one minor version per control plane upgrade, falling two versions behind turns into two back-to-back upgrades.

Kubernetes 1.35, 1.36 and 1.37 at a glance

Here is the year in one table. Enhancement counts are the release team's own numbers from each release blog.

Release	Released	Enhancements (stable / beta / alpha)	Headline GA features	Breaking or deprecating	EOL	Source
1.35 "Timbernetes"	17 Dec 2025	60 (17 / 19 / 22)	In-place Pod resource resize, PreferSameNode traffic distribution, Job managed-by	cgroup v1 off by default, ipvs mode deprecated, last release for containerd 1.x	28 Feb 2027	v1.35 blog
1.36 "Haru"	22 Apr 2026	70 (18 / 25 / 25)	Fine-grained kubelet authorization, mutating admission policies, user namespaces, volume group snapshots	gitRepo volume permanently disabled, Service externalIPs deprecated	28 Jun 2027	v1.36 blog
1.37 "Garhwal"	26 Aug 2026	67 (16 / 23 / 27)	KYAML, metrics.k8s.io v1, Pod certificates, storage version migration, SELinuxMount	kube-dns deprecated, ipvs timeline set, static Pods lose Secret and ConfigMap refs	28 Oct 2027	v1.37 blog
1.38	16 Dec 2026 (planned)	Not final until release	Not final until release	Deprecations blog due 23 Nov 2026	Not published	1.38 schedule

Which Kubernetes features went GA in 2026?

The big one for most teams arrived at the end of 2025. In-place Pod resize reached GA in 1.35: you can change CPU and memory requests and limits on a running Pod without recreating it. Combined with VPA, that removes the main reason people refused to let anything touch resources in production. I covered the mechanics in Kubernetes requests and limits explained.

1.36 was a security release in all but name. Fine-grained kubelet API authorization went GA, which means monitoring agents no longer need the overly broad nodes/proxy permission to read kubelet endpoints. User namespaces in Pods went GA too, so a process running as root inside a container can map to an unprivileged user on the node. Mutating admission policies (CEL-based mutation without running a webhook) also graduated. If you run Kyverno or Gatekeeper for simple defaulting, it is worth checking whether a built-in policy now does the job.

1.37 graduated 16 enhancements. The ones I would actually use:

• KYAML is stable, and kubectl get -o kyaml with it. It is a stricter subset of YAML, every KYAML file is valid YAML, and nothing forces you to adopt it. It is nice for diffs in review.
• metrics.k8s.io v1 finally left beta after nearly nine years. v1beta1 keeps working through the transition.
• Pod certificates and ClusterTrustBundles are GA. A signer controller you deploy issues X.509 certificates to Pods through a podCertificate projected volume, which is a native building block for workload identity and mTLS.
• StorageVersionMigration (storagemigration.k8s.io/v1) is GA and on by default, so rewriting stored objects after a CRD version change or an encryption key rotation is no longer a script you maintain.
• SELinuxMount is GA, which speeds up volume mounts on SELinux hosts but is flagged ACTION REQUIRED in the 1.37 changelog because it can break workloads that share volumes across different SELinux labels.

On the beta side, HPA scale to zero is now enabled by default in 1.37. With object or external metrics you can set spec.minReplicas: 0 and let a queue consumer or GPU worker sit at zero until there is work. CPU and memory metrics cannot drive it, for the obvious reason that an idle zero-replica workload reports nothing. If you already run KEDA for this, nothing forces a change, but the autoscaling explainer has the trade-offs.

There is also a steady drumbeat of work for accelerator workloads: more Dynamic Resource Allocation features reached GA in 1.36 and 1.37, gang scheduling is beta in 1.37, and Pod-level checkpoint and restore arrived as alpha with new CheckpointPod and RestorePod CRI calls. That last one is close to my own work: I build PandaStack, a Firecracker microVM cloud where snapshot and restore is the core feature, so I will be reading the KEP carefully, but alpha means you should not plan around it yet.

Deprecations and removals that break Kubernetes upgrades

This is the section that matters before you press the button. None of these are removed API versions, which is unusual. The deprecated API migration guide lists nothing removed after 1.32, when flowcontrol.apiserver.k8s.io/v1beta3 stopped being served. Alpha and beta groups are the exception: 1.37 dropped scheduling.k8s.io/v1alpha2 entirely, and Pluto's version data marks several older resource.k8s.io (DRA) versions as removed between 1.34 and 1.36, which matters if you adopted DRA early. Otherwise the risk in 2026 moved from YAML apiVersions to node and networking behaviour.

cgroup v1. Since 1.35 the kubelet's failCgroupV1 setting defaults to true, so a node still on cgroup v1 fails to start the kubelet unless you set an explicit override. The 1.37 blog calls that override short-term and says cgroup v1 support will be removed in a future release. Old distributions and some long-lived VM images are where this bites.

containerd 1.x. The 1.35 blog said 1.35 is the last release to support the containerd 1.x series and that you must move to containerd 2.0 or later before going further. The cleanup of the related kubelet flags has since been pushed back twice, from 1.36 to 1.37 and then to 1.38, per the changelogs. Read that as extra time, not as a reprieve: kubeadm 1.37's preflight already warns when the runtime lacks the RuntimeConfig call, and the kubelet_cri_losing_support metric tells you which nodes need attention.

kube-proxy ipvs mode. Deprecated in 1.35. The 1.37 blog sets the timeline: ipvs is expected to be disabled by default by 1.40 and removed by 1.43, and nftables is the recommended replacement on Linux. kubeadm now writes mode: iptables explicitly when you leave it empty, because the default is going to move to nftables in a later release.

Service .spec.externalIPs. Deprecated in 1.36, with removal planned for 1.43. The field has been the vector for CVE-2020-8554 for years. LoadBalancer Services or Gateway API are the replacements, and if you are also still on ingress-nginx, which upstream retired in March 2026, the Gateway API migration explainer covers both moves.

gitRepo volumes. Permanently disabled in 1.36, with no feature gate to turn them back on. Use an init container or git-sync.

kube-dns. Deprecated in 1.37; no new packages are expected after 1.40. CoreDNS has been the default since 1.13, so this mainly affects very old clusters that were upgraded in place for years.

Static Pods referencing Secrets or ConfigMaps. Blocked in 1.37, and the PreventStaticPodAPIReferences gate that let you opt out is gone. Static Pods were never supposed to read the API.

kubeadm v1beta3 config. Removed in 1.37. If you keep kubeadm configs in Git, migrate them to v1beta4 with kubeadm config migrate before you upgrade, using a pre-1.37 kubeadm binary, since kubeadm 1.37 no longer reads v1beta3.

What platform teams should check before upgrading to 1.37 or 1.38

Most of the checks above can be scripted in a few minutes. This is the audit I would run against every cluster before scheduling the upgrade. It is read-only and assumes kubectl access plus jq.

#!/usr/bin/env bash
# Pre-upgrade audit for Kubernetes 1.36 -> 1.37 (or 1.37 -> 1.38). Read-only.
# Tested against kubectl v1.37.2 and jq 1.7.
set -euo pipefail

echo "== Server and node versions (kubelet may lag the API server by up to 3 minors)"
kubectl version
kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion,KERNEL:.status.nodeInfo.kernelVersion

echo "== Nodes still on containerd 1.x (need containerd 2.0+)"
kubectl get nodes -o json | jq -r '.items[] | select(.status.nodeInfo.containerRuntimeVersion | test("containerd://1\\.")) | .metadata.name'

echo "== kube-proxy mode (ipvs is deprecated; nftables is the replacement)"
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:' || echo "mode not set (kubeadm now writes iptables explicitly)"

echo "== Services using deprecated spec.externalIPs"
kubectl get svc -A -o json | jq -r '.items[] | select(.spec.externalIPs != null) | "\(.metadata.namespace)/\(.metadata.name)"'

echo "== Pods using the removed gitRepo volume type"
kubectl get pods -A -o json | jq -r '.items[] | select(any(.spec.volumes[]?; has("gitRepo"))) | "\(.metadata.namespace)/\(.metadata.name)"'

echo "== kube-dns still deployed?"
kubectl -n kube-system get deploy kube-dns 2>/dev/null || echo "no kube-dns deployment"

echo "== Deprecated APIs clients are still calling (apiserver metric)"
kubectl get --raw /metrics | grep '^apiserver_requested_deprecated_apis' || echo "none reported"

# cgroup version must be checked on each node: 'cgroup2fs' means v2, 'tmpfs' means v1.
#   stat -fc %T /sys/fs/cgroup/

Beyond the script, three habits help. First, read the "Urgent Upgrade Notes" block of the changelog, not just the release blog; it is where items like the SELinuxMount change and the eventRecordQPS behaviour fix live. Second, upgrade staging on the first patch release after a minor ships, then production on the second or third, since early patches tend to carry fixes for regressions found in the wild. Third, keep a removed-API scan in CI, even though no API versions were removed this year, because CRDs and Helm charts from vendors still ship old apiVersions.

If you run kubeadm clusters, the step-by-step version of all this, including the etcd snapshot, the pkgs.k8s.io repository switch and drain order, is in my companion kubeadm cluster upgrade guide. For EKS the equivalent is the EKS 1.37 upgrade guide.

Does the release pace still matter in the AI era?

A fair question I hear from teams that now spend more time on model serving than on cluster plumbing. My answer is that it matters more. A lot of the 2026 work (DRA, gang scheduling, workload-aware scheduling, HPA scale to zero, checkpoint and restore) is aimed squarely at GPU and batch workloads, and you only get it by staying current. The cluster that sits on an end-of-life minor because nobody owns upgrades is the same cluster that cannot schedule a multi-GPU training job sensibly. Upgrades are a platform team's most boring recurring job, and doing them on a calendar is still the cheapest way to avoid an emergency one. I made the broader version of that argument in Is Kubernetes still worth it in 2026?

FAQ

What is the latest stable Kubernetes version?

Kubernetes 1.37 is the latest minor release, and 1.37.2 (28 October 2026) is its latest patch. The supported minors are 1.37, 1.36 and 1.35. Kubernetes 1.34 reached end of life on 27 October 2026.

When is Kubernetes 1.38 released?

The SIG Release schedule targets Wednesday 16 December 2026 for v1.38.0. Code freeze starts on 16 November and the deprecations and removals blog is due on 23 November. Release dates occasionally slip by a few days, so check the schedule before you plan around it.

How long is a Kubernetes version supported?

About 14 months upstream: 12 months of standard patch support, then around two months of maintenance mode for critical fixes. Managed services such as EKS, GKE and AKS set their own windows and sometimes offer paid extended support beyond that.

Can I skip Kubernetes versions when upgrading?

Not for the control plane. The version skew policy and kubeadm both allow only one minor version per control plane upgrade, so 1.35 to 1.37 means going through 1.36. Kubelets can lag the API server by up to three minor versions, which lets you upgrade the control plane twice before touching the nodes, although I would not make a habit of it.

This quarter I would get every self-managed cluster off 1.34 and onto 1.36 or 1.37, fix any cgroup v1 or containerd 1.x nodes while doing it, and stand up a scratch cluster on 1.38.0-beta.0 to read its deprecations against our manifests before the final release in December. None of that is exciting work. It is the work that means the 1.38 upgrade in January is a ticket, not an incident.

Related: Is Kubernetes Still Worth It in 2026?, How to Upgrade an EKS Cluster to 1.37 Safely and Ingress NGINX Is Retired: What Replaces It.