The Kubernetes release train runs on a three-month cycle — and right on time for the end of the year, the next version is due on December 16, 2026: Kubernetes 1.38. While 1.37 “Garhwal” introduced the AI and security turnaround with Gang Scheduling beta, HPA scale-to-zero, and pod certificates, 1.38 is shaping up to be a release that moves these developments to stable status and further consolidates the platform for modern workloads. Those who are planning their cluster platform strategically should know the roadmap now.

Current status: Beta.0 is out, code freeze approaching

The development cycle for Kubernetes 1.38 began on August 31, 2026. On September 29, the enhancement freeze passed — after that, no new KEPs could be submitted for the release. Since November 4, 2026, v1.38.0-beta.0 is available, and on November 16, 2026 (AoE), the code freeze follows: after that, only critical bug fixes will be accepted. The SIG Release roadmap includes the following milestones:

Milestone Date
Beta.0 November 4, 2026
Code Freeze November 16, 2026 (AoE)
KubeCon NA November 9–12, 2026
Deprecations/Removals Blog November 23, 2026
rc.0 December 3, 2026
GA (Release) December 16, 2026

With the code freeze and the planned deprecations blog at the end of November, the feature list will be cemented by GA. As of the end of October, 87 KEPs were tracked for the milestone (15 stable, 27 beta, 42 alpha, 3 without stage labels) — a scope that makes 1.38 the strongest release of the year.

Gang scheduling and workload-aware preemption become GA

The most important feature from a production perspective: Gang scheduling (KEP-4671) and workload-aware preemption (KEP-5710) are targeting stable status. Gang scheduling was introduced in 1.37 as beta (disabled by default, feature gate GenericWorkload). It solves a classic problem of distributed AI/ML/HPC workloads: if a scheduler distributes the pods of a training unit across multiple nodes, the slowest pod blocks the entire job — GPU cycles are wasted. Gang scheduling ensures that a pod group is only scheduled together (“all-or-nothing”).

The combination with workload-aware preemption in 1.38 makes it possible to enforce prioritized AI jobs at the expense of lower-priority batch runs. Both features communicate via the workload API and the PodGroup concept that Kubernetes has provided since 1.37. For operators of GPU clusters and CI farms, this is the production-relevant improvement — eliminating deadlocks in distributed training directly saves infrastructure costs.

DRA grows up: device binding, partitioning, and capacity management

Dynamic Resource Allocation (DRA) went GA in 1.34. In 1.38, three follow-up KEPs are being moved toward stable:

  • Device Binding Conditions (KEP-5007): Pods can be bound to concrete device instances (GPU UUID, NPU serial number) — a prerequisite for license-bound AI hardware and deterministic device assignment.
  • Partitionable Devices (KEP-4815): A physical device (e.g., an NVIDIA H200) can be divided into partitions, allowing multiple pods to share a device without interfering with each other.
  • Consumable Capacity (KEP-5075): Resources such as VRAM are modeled as consumable quotas rather than binary “present/not present” flags.

These three KEPs make DRA truly practical — they close the gap between “GPU as a number” and “GPU as a manageable device with divisibility and binding.”

Platform improvements and convenience

In addition to the big AI topics, 1.38 brings several improvements for daily operations:

  • kuberc (KEP-3104) becomes stable: After seven years of alpha/beta status, kubectl users finally get a stable configuration file (~/.kube/kuberc) for aliases, default flags, and credential plugin policy. This replaces workarounds with shell aliases.
  • Pod-level resources become stable (KEP-2837/5419): CPU and memory specifications at the pod level become stable — including in-place resize without pod recreation (previously only stable at the container level). This enables vertical autoscaling without pod churn.
  • SPDY → WebSockets (KEP-4006): kubectl exec, attach, and port-forward switch from SPDY to WebSockets — an infrastructure change that mainly affects clusters with modern load balancers and firewalls.
  • Hermetic network-isolated pods and in-place container probe updates are candidates on the tracking board; their status will be decided by the code freeze.

What remains: cgroup v1, IPVS, and the long-term cleanup work

The deprecations blog for 1.38 is scheduled for November 23, 2026, so the final list of removals will only be determined then. What is clear: the long-term migrations already initiated in 1.35–1.37 are continuing:

  • cgroup v1: failCgroupV1 has already defaulted to true since 1.35 (kubelet does not start on cgroup-v1 hosts). The code removal in a future release (KEP-5573) has been decided; 1.38 does not set a new date here, but the pressure on operators of old node images is increasing.
  • IPVS → nftables: The IPVS mode of the kubelet proxy layer is on its way out. If you still have IPVS hardcoded in your platform templates, you should include the switch to nftables in your upgrade planning.
  • End of support for 1.35: When 1.38 is released, Kubernetes 1.35 leaves the three-branch support cycle and will only receive critical security patches.

Conclusion

Kubernetes 1.38 will not be a “big release” with a single new feature, but rather the stabilization run for the AI and platform turnaround that began with 1.35. Gang scheduling, workload-aware preemption, and DRA follow-ups make Kubernetes fit for GPU workloads and deterministic device management — exactly what platform teams need for production AI operations. At the same time, long-standing pain points such as kuberc and pod-level resources are finally being cleared away.

For cluster operators: don’t wait for GA, but start migrating the node base to cgroup v2 and containerd 2.x now. If you are on 1.35, you should plan the upgrade path via 1.36 → 1.37 → 1.38 — and mark December 16, 2026 on your calendar.

Sources