Foreword¶

The Kubernetes community continues to release updates on a six-month cadence. Per the official Kubernetes Contributors Release Calendar, v1.37.0 is scheduled for official release on Wednesday, August 26, 2026. As of the writing of this article (August 1, 2026), the release cycle has entered its 12th week: the release-1.37 branch has been created, v1.37.0-rc.0 has been released, Docs Freeze completed just on August 5–6, and there are less than four weeks remaining until GA.

Key directions repeatedly highlighted by the community in SIG Release Discussion #3051 and the release highlights summaries from each SIG include: Graduation of multiple Dynamic Resource Allocation (DRA) capabilities, AI/ML-oriented Workload API and CompositePodGroup, the phased transition of kube-proxy to nftables, as well as security and node-side improvements such as Pod Certificates and Kubelet Rootless. The official Enhancement tracker shows that this milestone includes approximately 86 enhancements (excluding Deferred / Removed from Milestone entries), with around 22 new features entering Alpha for the first time.

If you are planning cluster upgrades, evaluating GPU/AI training scheduling solutions, or following the kube-proxy backend migration, the following sections organize verified key changes and practical operational points by topic.

Release Cadence: From Code Freeze to GA¶

The v1.37 release cycle started on May 18, 2026, with several key milestones as follows:

After KubeCon Japan, each SIG submitted release highlights in GitHub Discussions, which the Comms team will use to write the official release blog post; the Feature Blog series is scheduled to launch sequentially starting the day after GA (August 27). If you are using RC images for pre-verification, we recommend following subsequent rc versions on the release-1.37 branch.

DRA: Device Taints GA and Extended Resource Maturity¶

Since its introduction in 1.26, Dynamic Resource Allocation has been an important path for scheduling dedicated hardware such as GPUs, NICs, and FPGAs. SIG Scheduling and SIG Node continued to advance the DRA ecosystem in 1.37, with the following changes confirmed in release highlights:

Capabilities graduated to GA (Stable):

• DRA device taints and tolerations: Similar to the Node taint mechanism, this allows drivers or administrators to mark devices as unavailable or restrict them to specific workloads only, with the scheduler respecting these constraints when allocating ResourceClaims.
• DRA extended resources: The extended resource model is officially stabilized, facilitating integration with the existing resources.limits/requests system.
• DRA: Resource Claim Status with standardized network interface data (KEP-4817): Network DRA drivers can use standardized fields to describe mounted network interfaces, making it easier for CNI or upper-layer applications to consume the data.

Still in Alpha but noteworthy new DRA features:

• DRA Device Compatibility Groups (KEP-5963): Resolves scheduling conflicts caused by mutually exclusive configurations such as MIG / vGPU on the same GPU — the scheduler will no longer only check capacity, but also verify that device compatibility groups do not overlap.
• DRA Derived Attributes (KEP-6080): Uses CEL expressions to derive unified keys (such as NUMA node ID) from vendor-specific driver attributes, enabling cross-driver matchAttribute binding.
• DRA Optional Node Preparation (KEP-5945): Cloud/virtual resources can declare SkipNodeOperations, allowing the kubelet to skip local gRPC driver calls without needing to deploy a dummy DaemonSet on every node.
• Standard numaNode Device Attribute (KEP-6072): Unifies the resource.kubernetes.io/numaNode attribute name, facilitating co-location of GPUs, NICs, and CPUs with the same NUMA domain.

For teams running AI inference/training workloads that have already applied for GPUs via DRA, 1.37 means production-grade taint isolation and more granular hardware topology scheduling are now ready; Alpha features are suitable for testing compatibility groups and derived attributes in a test cluster first.

AI/ML Batch Scheduling: Workload API and CompositePodGroup¶

Kubernetes scheduling has long been centered around individual Pods; scenarios such as distributed training and separated inference Prefill/Decode workflows require Gang Scheduling (waiting for the entire group to be ready before starting together) and multi-level topology constraints. Starting from 1.36, the Workload API and PodGroup have provided the foundation for flat batch scheduling; 1.37 significantly builds on this foundation.

Workload API and Job Integration (Beta / Alpha)¶

Per the highlights from SIG Scheduling and SIG Apps:

KEP-6089 provides reusable scheduling.k8s.io structures and the workloadbuilder library for controllers such as Job, allowing users to declare scheduling intentions in Job manifests, such as Gang, topology domains, and unified disruption policies:

apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-train
spec:
  parallelism: 4
  completions: 4
  scheduling:
    policy:
      gang: {}   # MinCount defaults to parallelism
    constraints:
      topology:
        - level: "topology.kubernetes.io/zone"
    disruption:
      all: {}    # Disrupt the entire group simultaneously
  template:
    spec:
      containers:
        - name: train-node
          image: training-image:v1
          resources:
            limits:
              nvidia.com/gpu: "1"

Feature gate: WorkloadWithJob (needs to be explicitly enabled in Alpha stage).

CompositePodGroup: Hierarchical Gang Scheduling (Alpha)¶

KEP-6012 introduces the CompositePodGroup API (Feature gate: CompositePodGroup), used to express tree-based workload structures: a root group contains multiple child PodGroups, and each PodGroup then contains specific Pods. Typical scenarios include:

• Hierarchical dependencies between N Prefill groups + M Decode groups in AI training;
• Parent groups needing to wait for a minimum number of child groups to be ready before overall scheduling (multi-level gang scheduling);
• Cross-level topology awareness and preemption/disruption policies (DisruptionMode determines whether child groups can be preempted independently).

Current Alpha limitations: All nodes within the same CompositePodGroup tree must share the same priority and PriorityClassName; cross-priority policies will be reserved for Beta.

If you use out-of-tree controllers such as JobSet or LeaderWorkerSet, CompositePodGroup provides a standard anchor for the in-tree _scheduler to understand multi-level structures, which is expected to reduce the cost of subsequent controller integrations.

kube-proxy Transition to nftables¶

The network change that most concerns operations teams is KEP-5343: Make nftables the default kube-proxy backend. Note: 1.37 will not immediately switch the default backend to nftables, but will initiate a phased migration:

1. Starting with 1.37: If no proxy mode is explicitly specified via --proxy-mode or the mode field in the ConfigMap, kube-proxy will still fall back to iptables, but will log warnings and generate Events to remind administrators to explicitly configure the mode as soon as possible.
2. In subsequent releases: After continued warnings, nftables will become the default value; the iptables backend will still be retained, and users can continue to manually select it.

In addition, SIG Network has confirmed the following related changes:

• KEP-6032 (Alpha): Adds localhost NodePort user-space TCP proxy for the nftables backend. iptables can use route_localnet to access NodePort on 127.0.0.1, but nftables has no equivalent kernel capability; enabling requires turning on the Feature gate KubeProxyNFTablesLocalhostNodePorts at the same time, and setting parameters such as --nodeport-addresses=primary,localhost. The default primary behavior remains unchanged.
• kube-proxy’s list operations for nftables now directly access the kernel via netlink instead of relying on the nft CLI, improving list efficiency (kubernetes #137536).
• KEP-5495: kubeadm adds deprecation warnings for IPVS mode; warnings related to empty mode fields actually belong to KEP-5343, not the removal of IPVS itself.

Operational Recommendations: Before and after upgrading to 1.37, check the kube-proxy DaemonSet/ConfigMap, and explicitly write mode: iptables or mode: nftables to avoid relying on implicit defaults; if your business depends on localhost:<NodePort>, evaluate the Alpha configuration of KEP-6032 on the nftables backend.

Security and Nodes: Pod Certificates GA, Kubelet Rootless Beta¶

Pod Certificates and ClusterTrustBundles (GA)¶

SIG Auth confirms:

• KEP-4317 Pod Certificates graduates to GA: Workloads can request X.509 certificates from a specified signer via PodCertificateRequest, and mount them via projected volumes, supporting scenarios such as mTLS and reducing reliance on Bearer Tokens.
• KEP-3257 ClusterTrustBundles graduates to GA: Signers can distribute trust anchors via the cluster-level API, with Pods mounting them on demand, eliminating the need to replicate ConfigMaps in every namespace.

This substantially simplifies integration with external issuers such as service meshes and Vault, as well as in-tree integrations.

Kubelet-in-UserNS (Rootless Mode, Beta)¶

KEP-2033, which entered Alpha in v1.22 and has gone through multiple versions, is promoted to Beta in 1.37. This feature allows node components such as kubelet, CRI, and CNI to run as non-root users in a user namespace (what the community often refers to as Rootless mode). This version adds:

• The NodeSystemInfo.RunningInUserNamespace field;
• The node label node.kubernetes.io/running-in-user-namespace.

Enabling requires turning on the Feature gate in the KubeletConfiguration:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletInUserNamespace: true
cgroupDriver: "cgroupfs"

Prerequisites include Cgroup v2, correct /etc/subuid and /etc/subgid configurations, etc. For details, see the official documentation. Rootless mode is meaningful for reducing the attack surface of multi-tenant edge nodes and development machine clusters, but production deployment still requires attention to compatibility with storage, Device Plugin, and DRA drivers.

Other Notable GA / Beta Changes¶

For the sake of brevity, the following items also come from official release highlights and can be included in upgrade planning:

Regarding API removals, 1.37 will clean up some expired beta/alpha API versions (such as v1alpha1 ClusterTrustBundles under certificates.k8s.io, some beta resources under networking.k8s.io, etc.). Before upgrading, please use pluto or kubectl convert to check the API versions in your manifests.

Upgrade and Validation Recommendations¶

1. Read the Release Notes and Deprecations Blog Post: The official full announcement will be released during the GA week; the Feature Blog will be launched in batches starting August 27.
2. Enable target Feature gates in test clusters: Especially CompositePodGroup, WorkloadWithJob, and new DRA Alpha features, avoid enabling them by default in production directly.
3. Explicitly configure kube-proxy mode: Eliminate the iptables implicit fallback warning in 1.37 and prepare for the future nftables defaulting.
4. AI/ML Workloads: If you are already using JobSet/LWS, track the controller integration progress of CompositePodGroup and Job scheduling fields; DRA GA taints can be used for production-grade GPU isolation.
5. Security and Compliance: Evaluate whether Pod Certificates can replace TLS materials mounted via some Secrets; Rootless nodes are suitable for pilots in non-critical/edge scenarios.

Conclusion¶

Kubernetes 1.37 is not a single explosive change, but a convergence of several main lines: DRA productionization, workload-aware scheduling, network stack modernization (nftables), and workload identity (Pod Certificates). Among the 86 enhancements, CompositePodGroup, Workload API Beta, and DRA taints GA, which are most relevant to AI/ML and dedicated hardware, may be the pieces that have the greatest impact on platform teams in this release.

There are still several weeks until GA on August 26, so we recommend using RC images to verify kube-proxy configurations, DRA driver versions, and API deprecation lists in a pre-production environment. Please refer to official information from the kubernetes.dev Release page and the Enhancements tracker; the facts in this article have been cross-referenced with SIG Release Discussion #3051 and community technical interpretations, and feature stages shall be subject to the final Release Notes.