Kubernetes

See [kubernetes-announce@](https://groups.google.com/forum/#!forum/kubernetes-announce). Additional binary downloads are linked in the [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md). See the [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md) for more details.

See [kubernetes-announce@](https://groups.google.com/forum/#!forum/kubernetes-announce). Additional binary downloads are linked in the [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md). See the [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md) for more details.

Automatically adjust resources for your workloads

## Changes by Kind ### API Change - Add validation to the verticalpodautoscaler.spec.resourcePolicy.containerPolicies.controlledResources field. A warning will be returned on updates of any existing VPA that uses invalid values ([#9951](https://github.com/kubernetes/autoscaler/pull/9951), [@adrianmoisey](https://github.com/adrianmoisey)) ### Feature - Add reactive CPU startup boost unboosting ([#10087](https://github.com/kubernetes/autoscaler/pull/10087), [@omerap12](https://github.com/omerap12)) - Adds a Prometheus counter metric (inplace_cache_pods_total) to track pods that were skipped from in-place updates because the infeasible result was already cached. ([#9819](https://github.com/kubernetes/autoscaler/pull/9819), [@omerap12](https://github.com/omerap12)) - Make status lease configurable ([#10119](https://github.com/kubernetes/autoscaler/pull/10119), [@dippynark](https://github.com/dippynark)) - VPA updater metric added to expose admission controller status: vpa_updater_admission

## Changes by Kind ### Other (Cleanup or Flake) - Bump Go to 1.26.8 ([#10264](https://github.com/kubernetes/autoscaler/pull/10264), [@adrianmoisey](https://github.com/adrianmoisey)) - Bump VPA to 1.7.2 ([#10338](https://github.com/kubernetes/autoscaler/pull/10338), [@adrianmoisey](https://github.com/adrianmoisey)) ### Bug or Regression - VPA InPlace: treat transient kubelet ResizeError as deferred, not permanent infeasibility, so a later higher recommendation is not skipped until Updater restart. ([#10104](https://github.com/kubernetes/autoscaler/pull/10104), [@iho](https://github.com/iho)) **Full Changelog**: https://github.com/kubernetes/autoscaler/compare/vertical-pod-autoscaler-1.7.1...vertical-pod-autoscaler-1.7.2

See [kubernetes-announce@](https://groups.google.com/forum/#!forum/kubernetes-announce). Additional binary downloads are linked in the [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md). See the [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md) for more details.

As Kubernetes adoption has grown, the conversation has shifted beyond running containers to managing increasingly complex application lifecycles. Modern platforms support stateless web services, stateful databases, batch processing, AI workloads, and platform services. At the same time, they must remain reliable during upgrades, scaling events, and infrastructure failures. Every Kubernetes user relies on SIG Apps, whether they realize it or not. Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs form the foundation of how applications are deployed, updated, scaled, and operated across the Kubernetes ecosystem. SIG Apps is focused on improving workload resilience, refining application lifecycle management, and addressing the operational challenges that emerge when applications encounter node failures, rollout disruptions, and increasingly complex infrastructure environments. In this spotlight, we sit down with two of the three SIG Apps chairs Janet Kuo and Maciej Szulik to discus

Kubernetes v1.37 promotes the PersistentVolumeClaimUnusedSinceTime feature gate to Beta (enabled by default). With this feature, the PersistentVolumeClaim (PVC) protection controller adds an Unused condition to each PVC, telling you whether any running pod currently references it — no custom tooling or cross-referencing required. For the API definition of PVC conditions, see the PersistentVolumeClaim API reference . Read on to learn how the Unused condition works and how to use it. Why track PVC usage? In large-scale Kubernetes clusters, it is common for users to create PVCs and then delete the associated pods without cleaning up the storage, because Kubernetes does not automatically delete PVCs when their pods are removed (to protect against accidental data loss). Over time, these orphaned PVCs may accumulate, silently consuming storage capacity and driving up cloud costs. Before Kubernetes v1.37, it was easy to identify an unused PersistentVolume, but much harder to determine whether

Kubernetes v1.37 brings important storage security features: emptyDir permission modes and bind mount options. They help application programmers and security professionals implement rigorous security policies, for example, prohibiting deletion of files across containers or execution of arbitrary binaries from writable volumes, directly in Kubernetes without any complicated circumvention. Linux storage and permission fundamentals Before diving into the new Kubernetes features, let us briefly review the low-level Linux security mechanisms that make them possible. Bind mount flags When Linux mounts or remounts a directory, Virtual File System (VFS) flags control what actions are permitted on that filesystem: noexec : Do not permit direct execution of any binaries on the mounted filesystem. nosuid : Do not allow set-user-identifier or set-group-identifier bits to take effect. nodev : Do not interpret character or block special devices on the file system. Directory permissions and the stick

With the release of Kubernetes v1.37, the Pod-Level Resource Managers feature has graduated to Beta status (disabled by default)! First introduced as an Alpha feature in Kubernetes v1.36 , this enhancement builds on Pod-Level Resources by equipping Kubelet's Topology Manager, CPU Manager, and Memory Manager to use Pod-level resource declarations ( .spec.resources ) directly when making hardware placement decisions. Bringing pod-level resources to node managers Before this feature, obtaining exclusive NUMA-aligned CPU cores or memory for latency-critical applications forced cluster operators into an all-or-nothing choice: assign integer resource requests to every container in the Pod, or forfeit exclusive NUMA alignment entirely. For modern workloads running lightweight sidecars (such as logging agents or telemetry exporters), allocating dedicated physical cores to auxiliary containers was wasteful. Pod-Level Resource Managers solves this challenge by enabling hybrid allocation models.

Material Event filed 2026-09-15