--- title: "Kubernetes 1.37: Deep dive into new alpha features" id: "16170" type: "post" slug: "kubernetes-1-37-release-features" published_at: "2026-07-30T10:28:09+00:00" modified_at: "2026-07-30T10:37:36+00:00" url: "https://palark.com/blog/kubernetes-1-37-release-features/" markdown_url: "https://palark.com/blog/kubernetes-1-37-release-features.md" excerpt: "22 new features emerging in K8s v1.37 include CompositePodGroup API, nftables as the default kube-proxy backend, topology for volume snapshots, volume health monitor, Recreate update strategy for StatefulSets, and many others." taxonomy_post_tag: - "Kubernetes" - "trends" taxonomy_language: - "English" taxonomy_mailchimp: - "created_newsletter" taxonomy_author: - "kirill.kononovich" --- # Kubernetes 1.37: Deep dive into new alpha features 30 July 2026 By Kirill Kononovich, technical writer The Kubernetes 1.37 release, scheduled for August 26th, introduces a diverse set of new alpha features across various areas, including advanced workload lifecycle management, further DRA (Dynamic Resource Allocation) enhancements, better security and storage capabilities, and transition to nftables. Our overview covers all 22 alpha features introduced to Kubernetes for the first time, offering a comprehensive glimpse into the next evolution of container orchestration. ***Note**: We do our best to announce the actual changes. However, given the ever-changing nature of the Kubernetes feature landscape, some of the Kubernetes Enhancement Proposals (KEPs) discussed in this article may be removed from the milestone as the release date approaches.* ## Nodes ### Pod-Level Checkpoint/Restore - [KEP #5823](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5823-pod-level-checkpoint-restore) ([issue](https://github.com/kubernetes/enhancements/issues/5823) ) - Feature gate: `PodLevelCheckpointRestore` In Kubernetes, Pods are ephemeral: if a Pod crashes or gets moved to another node, it is deleted and restarted from scratch. Pod-Level Checkpoint/Restore changes this by letting you snapshot the entire Pod. Before, you could only snapshot individual containers ([KEP-2008](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2008-forensic-container-checkpointing) ), which really limited what you could do since containers share network and memory. The new mechanism allows you to “freeze” an entire Pod and its related resources (memory state, process hierarchies, open file descriptors, and Pod-level configuration/metadata), save this state to a file, and later restart it from the exact moment it was paused. The KEP helps address four practical tasks: 1. Eliminates startup delays for heavy applications (such as Java or ML workloads). You can launch the app once, wait for it to become ready (e.g., loading into memory, warming up caches), take a snapshot, and then instantly replicate it to other nodes. 2. Serves as a backup mechanism for long-running workloads by generating checkpoint snapshots. If a workload fails or needs to be migrated to another node, the snapshot lets you resume from the last saved state rather than restarting computations from scratch. 3. Makes server maintenance much easier: you can pause running Pods, safely move them to another machine, and keep them running without losing any progress. 4. Helps with debugging/forensics (which is actually what the abovementioned KEP-2008 was originally designed for): you can take a snapshot of a frozen Pod and send it to developers for in-depth analysis in a staging environment, without disrupting the original application. The feature itself runs at the kubelet level. kubelet coordinates with the container runtime (such as containerd or CRI-O), which invokes a Linux system utility called [CRIU](https://criu.org/Main_Page) (Checkpoint/Restore in Userspace). CRIU suspends processes and packages RAM, open files, and network connection states into an archive. Upon restoration, CRIU leverages Linux kernel features to recreate the process tree with the *original PIDs* and network environment, strictly respecting the system’s security rules. In the alpha version, the API is extended with two new methods: - `CheckpointPod` — to handle making checkpoints at the Pod level; - `RestorePod` — to restore the Pod sandbox from a saved checkpoint *(to learn more about what a Pod sandbox is, check out [this Kubernetes blog post](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes) )*. ### DRA Optional Node Preparation - [KEP #5945](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5945-dra-optional-node-preparation) ([issue](https://github.com/kubernetes/enhancements/issues/5945) ) - Feature gate: `DRAOptionalNodePreparation` This KEP addresses an architectural limitation in the Dynamic Resource Allocation (DRA) mechanism that makes it difficult to manage virtual or cloud resources. Previously, kubelet always attempted to communicate with the local driver via gRPC to prepare the device before container startup and clean it up after container completion. As a result, administrators had to deploy DaemonSets with dummy “no-op” drivers on all cluster nodes, even when physical hardware configuration on the servers was not required. KEP-5945 introduces a new boolean field, `SkipNodeOperations`, in the `ResourceSliceSpec` specification and the `DeviceRequestAllocationResult` struct. When the driver signals that node-side setup is unnecessary, kubelet skips searching for the local plugin, thereby avoiding redundant gRPC calls. This lets you use network, virtual, or cloud resources without having to run extra software. The KEP improves cluster reliability (by eliminating the need to deploy redundant local agents) and simplifies maintenance. Additionally, it reduces CPU and memory consumption and mitigates the risk of Pods getting stuck in the *Terminating* state due to local driver failures. Full backward compatibility is maintained for traditional devices that still require physical configuration on the node. ### DRA Device Compatibility Groups - [KEP #5963](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/5963-device-compatibility-groups) ([issue](https://github.com/kubernetes/enhancements/issues/5963) ) - Feature gate: `DRADeviceCompatibilityGroups` In the past, sharing specialized hardware like GPUs among Pods using DRA caused major scheduling problems. The Kubernetes scheduler only saw the total capacity of the physical device and subtracted the Pods’ requests. It had no idea if those requests were actually compatible on a hardware level. For example, you cannot run different virtualization profiles (like MIG and vGPU) on the same GPU at the same time. As a result, when the scheduler sent a Pod to a node with an incompatible Pod, the new Pod would get stuck in an error loop (such as `CrashLoopBackOff` or `UnexpectedAdmissionError`), and Kubernetes failed to automatically reschedule it to a different node. KEP-5963 introduces the concept of Device Compatibility Groups to Kubernetes. Now, when searching for a node to schedule a Pod, the scheduler considers not only available resource capacity but also the logical compatibility of configurations. If a physical device already has a Pod running that requires a specific mode, the scheduler will prevent a Pod with an incompatible mode from being scheduled there, even if the device has enough free capacity. To achieve this, the DRA API has been extended: a new field, `compatibilityGroups`, has been added to the description of available hardware resources (the *ResourceSlice* object). This field is a list of text labels generated by a specific hardware driver. Whenever a new Pod is scheduled, K8s checks if the new Pod’s compatibility groups intersect with those of the Pods already running on the device. If they don’t overlap, the scheduler rejects the node and looks for another one with the right hardware. ### Support Default Pod Sysctls in Kubelet - [KEP #5996](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5996-default-pod-sysctls) [(issue](https://github.com/kubernetes/enhancements/issues/5996) ) - Feature gate: `DefaultPodSysctls` Currently, Kubernetes allows users to configure `sysctl` parameters for individual Pods via the `securityContext.sysctls` field in the Pod specification. However, node administrators often need to apply kernel parameters consistently across all workloads on a node or node pool. High-performance networking apps, for example, might need a specific `net.*` or `kernel.shm*` values set globally for all containers on specialized nodes. Manually configuring these parameters for each Pod is inconvenient and error-prone. KEP-5996 addresses this issue by enabling kernel parameter configuration at the node level. Kubelet will automatically apply these settings to all Pods on the node when the Pod sandbox is created. A new `DefaultPodSysctls` field is added to the `KubeletConfiguration`. It is a `map[string]string` of key-value pairs. Kubelet merges these with the list from the Pod manifest. Still, settings explicitly defined in the Pod’s `spec.securityContext.sysctls` will override the node defaults. ### Dynamic resize of memory-backed volumes - [KEP #6030](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/6030-dynamic-resize-of-memory-backed-volumes) ([issue](https://github.com/kubernetes/enhancements/issues/6030) ) - Feature gate: `InPlacePodVerticalScalingMemoryBackedVolumes` In Kubernetes, you can mount temporary storage of the *emptyDir* type with a specified `sizeLimit` in a Pod and set its medium parameter to `Memory`. In this case, kubelet will create a tmpfs volume in RAM. Historically, the `sizeLimit` parameter for such volumes has been static, meaning you had to restart the Pod to change it. Now, with KEP-6030, you can resize in-memory volumes on the fly without having to recreate the Pod. To make this work, the `Pod.Spec.Volumes[].EmptyDir.SizeLimit` field becomes mutable when updated via the `/resize` subresource for existing Pods with `medium: Memory` set. On top of that, a new substructure within *VolumeStatus* lets you track the actual progress of the volume resize. ### DRA: Standard numaNode Device Attribute - [KEP #6072](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/6072-dra-standard-numanode) ([issue](https://github.com/kubernetes/enhancements/issues/6072) ) - Feature gate: none (requires `DRAListTypeAttributes`) In the current implementation of the DRA mechanism in Kubernetes, various drivers publish their NUMA node affinity information under five different vendor-specific attribute names. This inconsistency makes it impossible to write a single rule for the scheduler to allocate resources (like GPUs, NICs, and CPUs) on the same NUMA node to get the best data speeds. KEP 6072 addresses this issue by standardizing the `resource.kubernetes.io/numaNode` attribute. Devices can publish this attribute in two formats. The first is a simple integer (scalar) referencing a specific physical NUMA node (this one isn’t feature-gated). The second is a list of integers generated based on ACPI SLIT hardware latencies (requires enabling the `DRAListTypeAttributes` feature gate, see [KEP-5491](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/5491-dra-list-types-for-attributes) ). As a result, the Kubernetes scheduler can group compatible devices by finding the intersection of their supported sets. For instance, if a CPU is pinned to node 4, and a NIC says it works equally well with nodes [6, 4, 5, 7], the scheduler will find the intersection: 4. It will see the match and run the workload on the correct NUMA node. ### TLS Credentials in gRPC Probe - [KEP #4939](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4939-grpc-probe-with-tls) ([issue](https://github.com/kubernetes/enhancements/issues/4939) ) - Feature gate: `GRPCContainerProbeTLS` Kubernetes 1.23 introduced native gRPC support for liveness and readiness probes ([KEP-2727](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2727-grpc-probe) ), but it came with a catch: there was no TLS support. Since many companies use internal Certificate Authorities (CAs) and encrypt all traffic between microservices, a gRPC server configured to use TLS would reject plaintext probe requests from Kubernetes. This meant developers still had to invoke an external party utility via exec (see Example 1 below). KEP-4939 introduces a new mode field to the probe specification. It accepts two values: `Plaintext` (the default) and `TLS`, though certificate validity is not verified in the latter case. Example 1. Configuring probes the old way (via `exec`): ``` livenessProbe: exec: command: - "/bin/grpc_health_probe" # A third-party tool in the image - "-addr=:8443" - "-tls" - "-tls-no-verify" ``` Example 2. Configuring probes in a new way: ``` livenessProbe: grpc: port: 8443 mode: TLS # TLS mode livenessProbe: grpc: port: 50051 mode: Plaintext # Plaintext mode ``` ### Add bind mount options (noexec, nodev, nosuid) support on volumeMounts - [KEP #5855](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5855-noexec-emptyDir) ([issue](https://github.com/kubernetes/enhancements/issues/5855) ) - Feature gate: `VolumeBindMountOptions` In Kubernetes, running containers with a read-only root filesystem (`readOnlyRootFilesystem: true`) is a solid security practice. To let the application still write temporary files, you typically mount an empty volume, like an *emptyDir*, into `/tmp`. By default, Kubernetes mounts volumes without any restrictions. An attacker can upload a malicious script into the writable `/tmp` directory, mark it as executable, and run it. In this case, the read-only filesystem won’t stop them. KEP-5855 introduces a new `bindMountOptions` field to the `volumeMounts` section of a specific container within the Pod manifest. This field allows you to set the flags for mounting the volume into the container: - `noexec` — prevents the execution of any programs from this volume; - `nosuid` — prevents privilege escalation via files; - `nodev` — prevents the creation and use of device files. Example: ``` volumes: - name: tmp emptyDir: {} containers: - name: app volumeMounts: - name: tmp mountPath: /tmp bindMountOptions: [noexec, nosuid] ``` If the kubelet or the container runtime lacks support for mount options, the scheduler simply won’t place a Pod with `bindMountOptions` on that node. ### HTTP/2 cleartext (h2c) container probes - [KEP #5999](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5999-h2c-container-probes) ([issue](https://github.com/kubernetes/enhancements/issues/5999) ) - Feature gate: `H2CContainerProbe` KEP-5999 adds unencrypted HTTP/2 (h2c, HTTP/2 cleartext) support for container health checks, specifically for liveness, readiness, and startup probes. To make this work, a new `protocol` field is added to the existing *httpGet* probe mechanism. The field can be set to `HTTP1`, `HTTP2`, or `nil` (defaulting to `HTTP1`). If `protocol: HTTP2` is defined in the manifest (with the standard `scheme: HTTP`), the kubelet will execute HTTP GET requests using HTTP/2 cleartext (h2c). Here’s an example of a probe manifest: ``` readinessProbe: httpGet: port: 8080 path: /readyz protocol: HTTP2 # The new field httpHeaders: - name: Custom-Header value: my-value initialDelaySeconds: 5 periodSeconds: 10 ``` ## Scheduling ### Scheduler Preemption for In-Place Pod Resize - [KEP #5836](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/5836-scheduler-preemption-for-ippr) ([issue](https://github.com/kubernetes/enhancements/issues/5836) ) - Feature gate: `SchedulerPreemptionForPodResize` The [in-place Pod resize](/blog/in-place-pod-resizing-kubernetes/) feature lets you change a Pod’s CPU and memory requests without having to restart the Pod. But if the node doesn’t have enough spare resources, the request just gets stuck in a *Deferred* state, waiting for resources to free up naturally (such as when another Pod is deleted) or through manual admin action. While waiting for resources, the Pod could be OOM-killed, even if there were lower-priority Pods running on the same node that could have been preempted. KEP-5836 enables the Kubernetes scheduler to preempt lower-priority Pods to free up resources for the in-place resize of higher-priority Pods on the same node. When evaluating preemption candidates, the scheduler examines only the node hosting the target Pod, bypassing rules such as Node Affinity, Pod Anti-Affinity, or Topology Spread that were used for initial scheduling. On top of that, the scheduler uses the same `PriorityClass` and `preemptionPolicy` parameters as it does during the initial scheduling of new Pods. As the scheduler preempts lower-priority Pods, they return to the global queue as *Unschedulable*. This creates a resource shortage in the cluster and triggers the Cluster Autoscaler, which requests new nodes from the cloud provider. Furthermore, a `podPreemptionPolicy` setting is added to the Node object. It allows you to disable the preemption of lower-priority Pods on a specific node if that preemption is triggered by a Pod resize request. ### DRA: Derived Attributes - [KEP #6080](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/6080-dra-derived-attributes) ([issue](https://github.com/kubernetes/enhancements/issues/6080) ) - Feature gate: `DRADerivedAttributes` KEP-6080 addresses the rigidity issue in hardware binding within the DRA mechanism. Currently, to co-allocate devices — such as a GPU and a high-speed NIC on the same NUMA node — the scheduler needs attribute names and values that *match exactly* via the `matchAttributes` mechanism. Because different vendor drivers often describe topology in their own ways, linking this hardware is impossible without changing the driver code. To get around this, new KEP introduces the `derivedAttributes` mechanism within the resource request manifests (`.devices.requests`). You can now use CEL scripts to extract, parse, and standardize metadata from different drivers on the fly. This basically generates a shared virtual key (for example, a NUMA node ID), which is then used by the scheduler for hardware binding. Here’s an example of binding a GPU and a NIC to a single NUMA node: ``` apiVersion: resource.k8s.io/v1 kind: ResourceClaim metadata: name: gpu-numa-alignment-claim spec: devices: requests: - name: gpu exactly: deviceClassName: gpu.nvidia.com count: 8 # [NEW]: Compute virtual grouping key from GPU driver derivedAttributes: - name: shared-numa-node expression: "device.attributes['gpu.nvidia.com'].numa" - name: nic exactly: deviceClassName: dranet count: 1 # [NEW]: Compute virtual grouping key from dranet driver derivedAttributes: - name: shared-numa-node expression: "device.attributes['dra.net'].numaNode" constraints: # Match the derived attribute across both requests using existing matchAttribute - matchAttribute: shared-numa-node requests: [gpu, nic] ``` ### Workload Aware Scheduling Controller APIs - [KEP #6089](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/6089-was-controller-apis) ([issue](https://github.com/kubernetes/enhancements/issues/6089) ) - Feature gate: `WorkloadWithJob` *Workload-aware scheduling (WAS) has been under development in Kubernetes for some time. If you’d like to learn more about what it is, I highly recommend checking out the following documents: [KEP-4671](https://kep.k8s.io/4671) , [KEP-5710](https://kep.k8s.io/5710) , [KEP-5732](https://kep.k8s.io/5732) , [KEP-6012](https://kep.k8s.io/6012) , and [KEP-5547](https://kep.k8s.io/5547) .* The catch is that the *Workload* and *PodGroup* resources that underpin the WAS feature were primarily designed as intermediate APIs intended for interaction with the scheduler. Right now, there’s no obvious way for users of higher-level controllers (such as *Job*, *LWS*, *JobSet*, *RayJob*, etc.) to specify their scheduling needs in YAML manifests. To address this, KEP-6089 proposes a set of reusable API building blocks (structs in `scheduling.k8s.io`), a shared `workloadbuilder` Go library, and some architectural guidelines. This will make it significantly easier for controller owners to integrate features like Gang Scheduling, Topology-aware Scheduling, and Workload-aware Preemption. That is, developers will be able to provide a *consistent* UX to end users without requiring them to write custom logic. The KEP also expands the Job API, enabling users to state their scheduling preferences in a new scheduling block (if omitted, the default behavior is used). Here is an example of a Job manifest detailing configurations for Gang Scheduling, Zone Topology, and [Atomic Disruption](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/5710-workload-aware-preemption#preemption-unit) : ``` apiVersion: batch/v1 kind: Job spec: parallelism: 4 completions: 4 scheduling: # New API field - scheduling intent policy: gang: {} # MinCount is omitted: Job defaults MinCount = parallelism (4) constraints: topology: - level: "topology.kubernetes.io/zone" disruption: all: {} # DisruptionMode resolves to All (entire group must be disrupted together) template: spec: containers: - name: train-node image: training-image:v1 ``` ### CompositePodGroup API - [KEP #6012](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/6012-composite-podgroup-api) ([issue](https://github.com/kubernetes/enhancements/issues/6012) ) - Feature gate: `CompositePodGroup` Similar to the previous KEP, KEP-6012 builds on the ideas of workload-aware scheduling. This time around, the changes focus on supporting complex, hierarchical scheduling needs. Many modern Kubernetes workloads (such as AI training and ML) require a multi-level structure to support complex lifecycle dependencies (for instance, a workload might comprise N prefill groups and M decode groups). Workloads of this nature often require multi-level gang scheduling, meaning a parent group cannot be scheduled until a minimum number of its child groups have been scheduled. Essentially, the scheduling units are now entire child groups instead of individual Pods. Unfortunately, the current Workload and PodGroup APIs cannot handle this multi-level hierarchy, which is quite common across many out-of-tree Kubernetes APIs (like *JobSet* and *LeaderWorkerSet*). On top of that, in case these multi-level workloads experience partial failures, we need a mechanism to respond to failures across different segments of that specific workload. KEP-6012 introduces the new `CompositePodGroup` API for hierarchical scheduling. It allows you to build a tree structure made up of root groups and leaf components — `PodGroups` (these already contain the Pods themselves). Ultimately, this gives the K8s scheduler the power to process rules at multiple levels all at once. Kubernetes is now capable of multi-level: - Gang scheduling, meaning a root group will only be scheduled after a specific minimum of its child groups is ready; - Topology domain-aware scheduling; - Preemption/Disruption: The [DisruptionMode](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/6012-composite-podgroup-api#disruption-mode-priority-class-name-and-priority) dictates whether child groups can be preempted/disrupted independently or if they must be handled as a whole (for example, in AI, where losing one worker makes the rest of the training job completely useless). ## Storage ### Add user fields to atomic write volumes - [KEP #5936](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/5936-atomic-write-volume-user-fields) ([issue](https://github.com/kubernetes/enhancements/issues/5936) ) - Feature flag: `AtomicWriteVolumeUserFields` In Kubernetes, files originating from atomic writer volumes — such as *ConfigMap*, *Secret*, *DownwardAPI*, and *Projected* — are typically created with root (UID 0) as the owner. Many applications, like MongoDB, impose strict requirements on file ownership and may refuse to use root-owned files if the application itself is running under an unprivileged user. Administrators used to hack around this by spinning up root `initContainers` just to run `chown` and fix the permissions. However, strict Kubernetes Pod security policies forbid running root containers, meaning the old method no longer works. KEP-5936 introduces a native way to set file ownership in these volumes by adding optional `defaultUser` and `user` fields: - `defaultUser` is set at the volume level to define a default UID for *all* its files; - `user` is applied at the item level, letting you override the UID for a *specific* file. This KEP solely addresses UID configuration for atomic writer volumes. Group (GID) management continues to be handled via the existing `fsGroup` and `supplementalGroups` mechanisms. Support for Windows containers and Persistent Volumes is also out of scope of this KEP. ### Topology For Volume Snapshots - [KEP #5943](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/5943-topology-for-volume-snapshot) ([issue](https://github.com/kubernetes/enhancements/issues/5943) ) - Feature gate: `VolumeSnapshotTopology` Kubernetes clusters are often distributed across different physical availability zones and regions. Regular Kubernetes volumes already have topology support, meaning the system knows which zones or regions are eligible for creating and attaching a volume. Until now, though, *VolumeSnapshot* did not have this kind of data. The KEP introduces the `nodeAffinity` field to `VolumeSnapshotContent`. The CSI driver returns information regarding the topologies from which the snapshot is accessible via the `CreateSnapshot` response; the CSI snapshotter sidecar translates and persists this data into the aforementioned field. On top of that, administrators can explicitly specify the desired location when creating snapshots using `VolumeSnapshotClass.allowedTopologies`. The KEP authors also suggest a topology-aware mechanism for restoring volumes from snapshots, supporting two binding modes: - `WaitForFirstConsumer`: A dedicated out-of-tree scheduler plugin filters out all nodes that are incompatible with the snapshot’s `nodeAffinity` field; - `Immediate`: The external-provisioner checks where the snapshot is kept and matches it against where disks are allowed to be (`StorageClass.allowedTopologies`). A disk will be created only where these two intersect. If there is no overlap, volume provisioning will instantly terminate with an explicit topology mismatch error. In essence, this KEP prevents situations in which Kubernetes attempts to restore a volume from a snapshot into a zone where the snapshot is unavailable. ### EmptyDir Volume Permission Mode - [KEP #5502](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/5502-emptydir-volume-mode) ([issue](https://github.com/kubernetes/enhancements/issues/5502) ) - Feature gate: `EmptyDirVolumeMode` Currently, *emptyDir* volumes are always provisioned with 0777 permissions (read, write, and execute), and there is no built-in way to change this in Kubernetes. This leads to a number of issues. For example, if multiple containers in the same Pod share an *emptyDir* volume, one container can accidentally or intentionally delete files created by another container. KEP-5502 introduces a new optional `mode` field within the *EmptyDirVolumeSource* API for *emptyDir* volumes. This field allows specifying the Unix permissions for the created directory within the range of 0000 to 01777. Here goes a manifest example: ``` volumes: - name: app-data emptyDir: mode: 0750 ``` Several essential notes to consider: - Backward compatibility: if the `mode` field is omitted, Kubernetes will create the volume with 0777 permissions as usual. - Since Windows doesn’t support the Unix permissions system (including the sticky bit), this field will simply be ignored on Windows nodes. - The `fsGroup` settings in `securityContext` can modify the group and permissions on the volume, so the resulting mode might differ from what you set in `mode`. ### Volume Health Monitor - [KEP #1432](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor) ([issue](https://github.com/kubernetes/enhancements/issues/1432) ) - Feature gate: `CSIVolumeHealth` Kubernetes currently struggles with “silent” underlying storage failures. For instance: - An admin accidentally deletes a cloud disk, but Kubernetes still thinks it’s attached (since the PVC shows a *Bound* status). - A disk’s file system gets corrupted. - The disk performance drops, or a multipath connection is lost. CSI drivers are typically aware of these issues or can detect them, but Kubernetes lacks a standard mechanism to capture and store their signals. Without this, you just end up seeing stuck I/O operations or mount errors. KEP-1432, with its original ideas dating back to 2019(!), introduces 4 new RPC calls to the CSI specification. Using these, storage drivers can report volume and backend health. The requests are split into two levels: - Controller level. A dedicated sidecar container (*csi-external-health-monitor-controller*) sends the following requests to the driver: - Provide a list of all unhealthy volumes. - What is the status of this specific volume? - Node level. The kubelet on each node polls the local driver: - What is the health of this volume on the node? - What is the state of the backend from this node’s perspective? The KEP standardizes a specific set of statuses (`Inaccessible`, `DataLoss`, `Degraded`, `StorageUnreachable`, and `StorageDegraded`) but does not define how Kubernetes should react to them. ## Network ### nftables Localhost NodePort Userspace Proxy - [KEP #6032](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/6032-nftables-localhost-nodeport-userspace-proxy) ([issue](https://github.com/kubernetes/enhancements/issues/6032) ) - Feature gate: `KubeProxyNFTablesLocalhostNodePorts` KEP-6032 introduces an optional TCP proxy to kube-proxy for accessing NodePort services via localhost (127.0.0.1 and ::1) when using the nftables backend *(see KEP-5343 below)*. While IPv4 iptables can handle this using the Linux kernel’s `route_localnet` flag, nftables just doesn’t have a built-in equivalent. Since nftables will become the default backend in Kubernetes, workloads relying on `localhost:` might break. This feature is activated only when loopback addresses are explicitly specified in the `--nodeport-addresses` flag (for example, `--nodeport-addresses=primary,localhost`) or by specifying a loopback CIDR. Setting the value to `all` will not activate the proxy. The default nftables behavior (`primary`) remains unchanged. The proxy only supports TCP traffic. UDP and SCTP routing via localhost will not work. ### Make nftables the default kube-proxy backend - [KEP #5343](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/5343-nftables-to-default) ([issue](https://github.com/kubernetes/enhancements/issues/5343) ) - Feature gate: none (no functionality is being added or removed) KEP-5343 makes nftables the default kube-proxy backend instead of iptables. The transition is planned to be gradual: - Starting in Kubernetes 1.37, kube-proxy will log warnings and generate events if the proxy mode isn’t explicitly defined via `--proxy-mode` or the `mode` field, and it falls back to iptables. - Following a few K8s releases with these warnings, nftables will officially become the default. However, iptables support will be retained, and users will still be able to choose their preferred backend. ## Auth ### API Server Authentication to Admission Webhooks - [KEP #6060](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/6060-api-server-authentication-to-webhooks) ([issue](https://github.com/kubernetes/enhancements/issues/6060) ) - Feature gate: `APIServerWebhookAuthenticationToken` Currently, kube-apiserver does not authenticate its requests to admission webhooks by default. This enables anyone with access to the service network to spoof requests to a webhook on behalf of the API server, bypassing security policies (see, for example, [CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974) ). Existing protection mechanisms (mTLS, kubeconfig) require complex manual configuration and a restart of the API server, which makes them not very popular. KEP-6060 introduces a native way to authenticate the kube-apiserver and aggregated API servers against admission webhooks via short-lived JWT tokens. Here’s how it works under the hood: - The `AttestationClaims` field is added to the TokenRequest API, along with the `webhook-authentication.k8s.io/allowedAPIGroup` claim. This claim basically tells the webhook which API group the token holder is allowed to send an *AdmissionReview* for. - The core kube-apiserver receives broad access (`allowedAPIGroup: ["*"]`), whereas aggregated API servers can only request tokens for the API resource groups they manage. - Requesting a token requires the caller to have a create permission on `serviceaccounts/token` for a particular service account. Additionally, the service account receiving the token must be authorized to attest against the `webhook-authentication.k8s.io/apigroups` resource and the requested API group. - The webhook validates tokens locally (verifying the cryptographic signature, audience, and API group compatibility), without making requests to the kube-apiserver. The feature will be rolled out gradually. Existing webhooks that are not ready for validation will simply ignore the new `Authorization` header. Once webhook developers integrate the official Go library, they will start requiring a valid token. Existing kubeconfig-based authentication mechanisms are expected to continue to work as usual. This KEP targets admission webhooks exclusively and does not cover other types of webhooks (such as authentication, authorization, audit, or conversion). Tokens are cached and have a lifetime of no more than 10 minutes. ## Apps ### Add Recreate Update Strategy to StatefulSet - [KEP #3541](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/3541-add-recreate-strategy-to-statefulset) ([issue](https://github.com/kubernetes/enhancements/issues/3541) ) - Feature gate: `StatefulSetRecreateStrategy` By default, StatefulSets in Kubernetes use the `RollingUpdate` strategy. It is specifically tailored for stateful applications where data availability and integrity are critical. Therefore, it acts as cautiously as possible: the controller updates Pods one at a time (or based on `maxUnavailable`) and waits for the new Pod to become *Running* and *Ready*. The problem with this strategy is that if a Pod gets stuck during the update (such as in *ImagePullBackOff* or *Pending* states), the whole rollout stops. Fixing the issue doesn’t automatically resume the process, as the controller won’t delete the stuck Pod on its own. An admin has to step in and clear it manually using `kubectl delete pod `. This KEP introduces the `Recreate` update strategy to StatefulSets. With this strategy, a StatefulSet: 1. Deletes all old Pods at once (without deleting *PersistentVolumeClaims*, so volume data stays intact); 2. Waits for them to fully shut down (checking the `deletionTimestamp`); 3. Starts the new Pod versions according to the `spec.podManagementPolicy`. Since this strategy involves downtime, it is not suitable for all scenarios (see the [comparison table](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/3541-add-recreate-strategy-to-statefulset#comparison-with-existing-solutions) ). ***Note**: Modifying `spec.updateStrategy.type` does not automatically trigger a rollout. To activate the `Recreate` strategy, you must alter `.spec.template` or execute `kubectl rollout restart`.* ## API ### Eliminating Internal API Types - [KEP #6164](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/6164-internal-type-elimination) ([issue](https://github.com/kubernetes/enhancements/issues/6164) ) - Feature gate: none Historically, in Kubernetes, each resource (like a Pod) has a special `__internal` version in the code. Whenever a resource has multiple API versions (`v1alpha1`, `v1beta1`, `v1`), the API server takes any incoming request, converts the object to this `__internal` version for processing (such as validation), and then translates it back before saving it to etcd or returning it to the user. In the past, this meant you didn’t have to write translation logic for every version to every other version — everything just converted to `__internal`. This significantly reduced complexity since validation code only had to be written once for the `__internal` type. Today, though, it’s mostly a bottleneck. Most APIs are already stable (`v1`), making the conversion from `v1` to `__internal` pointless. On top of that, these operations consume a lot of resources, especially when you’re fetching a List of a large number of Pods. For this KEP’s implementation phase one, the authors suggest making the `__internal` data structures “memory identical” to the current stable versions, like `v1`. This allows conversion without going through element-by-element copying (thanks to Go language magic). According to the estimates, when processing a list of 1,000 Pods, the number of memory allocations will drop from 21,000 to merely 5. Processing speed will increase almost sixfold, while RAM consumption will be reduced by a factor of three. Then, in phase two (coming in K8s v1.38+), the plan is to convert `__internal` types into Go aliases for `v1` structures (e.g., `type PodSpec = v1.PodSpec`). Eventually, registering `__internal` types in `runtime.APIVersionInternal` will stop entirely, and the most stable resource version will serve as the foundation for converting and decoding. ## Non-alpha v1.37 release highlights While our article focuses on the new alpha features in Kubernetes v1.37, of course, this release also includes many other updates. We will follow our tradition and list the most prominent of them, as selected by Dmitry Shurupov, our co-founder and a CNCF Ambassador: 1. **Kubelet-in-UserNS aka Rootless mode** ([KEP-2033](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless) ) makes it to the Beta after 5+ years since its Alpha debut in Kubernetes v1.22! As its name suggests, this feature allows running all Kubernetes components (kubelet, kube-*, CRI, OCI, CNI) as a non-root user on the host. 2. Another feature that has been in development since v1.22, **Memory QoS support for K8s with cgroups v2**([KEP-2570](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2570-memory-qos) ), reached Beta and is now enabled by default. 3. **KYAML** ([KEP-5295](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/5295-kyaml/README.md) ) becomes stable. It is a YAML dialect compatible with existing tooling that adds an opinionated formatting approach to avoid common YAML pitfalls, such as the “Norway bug”. 4. **Pod certificates** ([KEP-4317](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/4317-pod-certificates/README.md) ) and **Cluster Trust Bundles** ([KEP-3257](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3257-cluster-trust-bundles) ) become stable. The `certificates.k8s.io` API group implements a flexible mechanism for requesting X.509 certificates for Pods to authenticate to kube-apiserver using mTLS. This API’s *ClusterTrustBundle* object enables in-cluster certificate signers to communicate their trust anchors (a root of trust) to workloads. 5. **Node-declared features** ([KEP-5328](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/5328-node-declared-features) ), which allow nodes to declare the availability of Kubernetes features, are now stable as well. But even with this addition, it’s not the *complete* list of changes introduced in Kubernetes v1.37. If you fancy the most comprehensive information, please follow the official [enhancements tracker](https://github.com/orgs/kubernetes/projects/264/views/1) and [changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md) . ## P.S. Our huge thank you to all the Kubernetes contributors for yet another milestone release! Interested in other alpha features recently added to Kubernetes? Check out our other deep dives: - [Kubernetes v1.36](/blog/kubernetes-1-36-release-features/) (April 2026); - [Kubernetes v1.35](/blog/kubernetes-1-35-release-features/) (December 2025); - [Kubernetes v1.34](/blog/kubernetes-1-34-release-features/) (August 2025). ## Related articles 18 March 2022 ### [Kubernetes and containerization trends (according to the reports of 2021)](https://palark.com/blog/kubernetes-and-containers-market-trends-2021/) 14 March 2023 ### [Cloud-native projects usage stats in 2022 based on CNCF Survey data](https://palark.com/blog/cncf-cloud-native-projects-usage-stats-2022/) 8 April 2026 ### [Kubernetes 1.36: Deep dive into new alpha features](https://palark.com/blog/kubernetes-1-36-release-features/)