By submitting this form, you agree to our 

Answer twenty questions about your artifact and supply chain practices. Get a custom report card showing your maturity score against key regulatory and compliance frameworks.

Artifact Security Maturity Assessment

 is scheduled for release on August 26th 2026, and it’s full of really exciting updates for security, DRA, networking and more! We exclude enhancements with the status of “

. What are we looking forward to in Kubernetes 1.37?

The 1.37 release includes 

’ in this Kubernetes release. From these, just 

 enhancement for DRA now graduating to GA.

A long list of 

 enhancements are in the tracker, including the ability to connect to a localhost NodePort service on NFTables (IPv4 & IPv6) using a userspace proxy (

 flag being added to StatefulSet rolling update strategies (

).

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.37.

Here are a few of the changes that Cloudsmith team are most excited about in the 1.37 release:

#6072 Standard numaNode device attribute for DRA

Kubernetes 1.37 introduces the standardisation of 

) as a globally recognised DRA device attribute. I’m excited to see this Alpha enhancement in 1.37. It unifies how hardware-specific memory topologies, like the memory controller, are exposed alongside existing attributes like 

. By establishing a single, consistent naming convention and introducing specialised helper functions into the 

 library, Kubernetes users should now be able to achieve seamless, cross-driver co-placement and advanced attribute matching (

 hardware configs where PCIe topologies alone were insufficient. Moving this complexity out of custom code and into a native standard means platform teams can finally guarantee high-performance, low-latency hardware alignment with absolute, cross-cloud portability.

Nigel Douglas - Head of Developer Relations




#5758 Per-container ulimits configuration

I am incredibly excited to see this enhancement land in Kubernetes 1.37 because it finally tackles a long-standing headache for anyone running heavy, production-grade workloads. This new KEP introduces a 

 within the Pod API. This grants users fine-grained, per-container control over 

 resource limits (such as open files and process counts) on Linux nodes. This native support eliminates the need for brittle, non-portable workarounds like modifying host configs or custom entrypoint scripts, allowing high-concurrency workloads and databases to optimise performance securely and in a scalable way in multi-tenant clusters. This change will propagate these limits directly to container runtimes via the CRI, utilising a runtime handler to dynamically detect node support. For years, platform engineers have had to jump through hoops just to prevent too many file open errors. Finally bringing this natively into the Pod API is a massive win for cluster security.

Jason Myers - Technical Content Marketer



#1710 Speed up recursive SELinux label change

) graduating to stable is great from a security standpoint. It fundamentally changes how volumes are attached to containers on systems with SELinux in enforcing mode. Traditionally, the container runtime had to recursively relabel every individual file and directory on a volume before a Pod could even start - a process that was notoriously slow for massive datasets, error-prone on near-full disks, and impossible on read-only filesystems. By switching the default behaviour to leverage the Linux kernel's native “

“ mount option, Kubernetes can now instantly assign the correct SELinux label to an entire volume at the mount point without a time-consuming file-system walk. While this drastically accelerates Pod startup times, its truest impact is defensive. By eliminating the need for the container runtime to dynamically change file permissions on the fly, this enhancement effectively blocks host-path exploitation techniques (like 

) where an attacker attempts to trick the cluster into relabelling and exposing critical host files.

Add Recreate Update Strategy to StatefulSet

 for StatefulSets addresses a long-standing 

 that has plagued users for years. Previously, if a StatefulSet update was triggered with a broken config (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become 

 before proceeding. Even if a user reverted the config to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing users to manually delete the Pod to unblock the controller.

The new 

 strategy provides a more aggressive alternative to the standard 

. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the waiting for ready deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated pipelines can recover from misconfigurations without manual human intervention.



WAS: Integrate Workload APIs with Job controller

 sig-apps

The enhancement is a major step forward for native support to complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (

 object to act as a link between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.



 sig-apps

This enhancement introduces a 

 parameter (either an absolute number or a percentage) to the 

 strategy for Kubernetes StatefulSets. Currently, StatefulSet updates are limited to processing one pod at a time, which can severely slow down rollouts for large clusters or applications with long startup tasks. By allowing multiple pods to be updated simultaneously, this feature brings StatefulSets closer to feature parity with Deployments, enabling significantly faster rollout times for stateful clustered applications that can tolerate having multiple replicas or followers offline at once.

 sig-api-machinery

This enhancement seeks to optimise the 

 performance and simplify its codebase by eliminating the resource-heavy, traditional internal API types (

) that act as conversion and validation hubs. Because many APIs have matured to a stable v1 version, maintaining these distinct internal types is no longer necessary and incurs significant CPU, memory, and maintenance overhead during request processing and large list operations. The project will execute in two phases. First, it makes internal types memory-identical to preferred versioned types to achieve up to a 

 during conversions. Secondly, it replaces internal types entirely with Go type aliases before eventually removing them altogether.



 sig-api-machinery

This enhancement proposes enabling the 

 feature gate by default to resolve severe API server scaling and timeout issues during CRD version migrations. Currently, when a controller establishes a watch on a cold cache, the 

 fetches the stored CRD versions from etcd and converts them sequentially to the requested version before returning them. At high scale (like, with clusters over 10,000 workloads running Kueue), this sequential conversion process can take several minutes, triggering etcd timeouts and causing the API server to fail with 500 errors. Enabling this feature by default allows the API server to decode and convert these watch events concurrently, drastically reducing processing time and preventing cluster failures during large-scale version upgrades.



 sig-api-machinery

Added in v1.35 as beta (disabled by default), the in-tree Storage Version Migrator (

) controller within the Kube-Controller-Manager (

) is finally graduating to stable in v.1.37. This KEP simplifies and automates data rewrites for at-rest storage. Resource rewrites are essential when a preferred storage schema changes (like 

) or when encryption-at-rest keys are updated. Unfortunately, performing this manually via kubectl is error-prone and scales poorly. By migrating the original out-of-tree SVM migrator controller into the core codebase under a new 

 API group, this proposal allows users to easily trigger efficient data migrations utilising the garbage collection cache. Once a migration successfully completes, the controller also handles updating the CRD status to safely remove references to old, unused storage versions.



 sig-api-machinery

This proposal introduces support for the 

 data format in Kubernetes API servers and clients as a high-performance alternative to JSON. While native Kubernetes resources use 

 to minimise CPU time and heap churn, CRDs cannot easily use Protobuf due to its reliance on compile-time code generation. Adopting CBOR as a self-describing binary format solves this gap. The benchmarks show it can make custom resource encoding up to 

. The rollout includes standard content negotiation (

), support for streaming via CBOR sequences, and client-side feature gates with automatic JSON fallbacks to ensure seamless backward compatibility with older API servers.

 sig-cli

I mentioned back in the 1.34 release how the introduction of KYAML will 

. Finally graduating to Stable status in the 1.37 release, KYAML is a Kubernetes-compliant YAML output format that uses a specific subset of standard YAML (called flow style) that eliminates common syntax pitfalls. By always using curly brackets 

 quotes for strings, it removes whitespace sensitivity and type-coercion bugs while still allowing comments and trailing commas. This will definitely improve the overall reliability of Kubernetes going forward.

Allows setting any FQDN as the pod's hostname



, allowing users to set any arbitrary FQDN up to 64 bytes as a pod's hostname. Aimed at easing the migration of legacy applications (like Kerberos) that relied on specific hostnames for authentication or permissions, this feature bypasses default cluster-suffix restrictions and writes the custom FQDN directly to the pod's 

 file (excluding Windows containers). To mitigate kernel limits, validation will reject strings over 64 bytes or those violating RFC 1123 standards, and the field is strictly mutually exclusive with 

 sig-network

Graduating to Stable in 1.37, this relaxed ServiceName validation feature is an improvement designed to bring the naming constraints of Service resources into alignment with other standard Kubernetes objects. Historically, Services were restricted by a stricter 

), which prohibited names from starting with a numeric digit. This update transitions the validation to the more flexible NameIsDNSLabel standard, finally allowing users to create Services with names like 

localhost NodePort userspace proxy for NFtables



 sig-network

This net new enhancement introduces an opt-in userspace TCP proxy to the 

 kube-proxy backend. This proxy bridges a critical feature gap by allowing workloads to access NodePort services via localhost (IPv4 and IPv6) under nftables. This is a capability that currently exists for 

 equivalent. Activated explicitly via the 

 flag, this Layer 4 forwarder supports key features like 

 external traffic policies, while intentionally excluding non-TCP protocols (UDP/SCTP) and leaving the iptables and IPVS backends completely unchanged.



Make NFtables the default kube-proxy backend



 KEP mentioned above, Kubernetes 1.37 is laying the groundwork to eventually make 

 the default backend for kube-proxy. This will ultimately replace the older 

 systems entirely. Because this shift requires newer Linux kernels (version 5.13 or higher) and continuous stability testing, the 1.37 release focuses on preparing users rather than making an immediate switch. Starting in this version, Kubernetes will actively issue log warnings to clusters that rely on the default 

 setting, advising administrators to either explicitly lock in 

 before the official default switch occurs in 

. This all culminates with the removal of IPVS mode in kube-proxy (

 sig-auth

Graduating to beta, this enhancement aims to solve a long-standing issue where a resource that cannot be decrypted or decoded completely blocks Kubernetes API operations like 

 storage to fix it. The proposal introduces more informative retrieval error messages to pinpoint the broken data, along with a new 

 that allows admins to bypass storage checks and safely delete malformed resources directly through the K8s API. While this simplifies recovery in scenarios like lost encryption keys or stuck namespace deletions, it’s worth noting that forcefully deleting a broken resource will bypass finalisers and garbage collection, potentially leaving behind orphaned underlying processes.



 sig-auth

Graduating to stable, this enhancement introduced a secure and automated mechanism to deliver X.509 certificates directly to pods without using bearer tokens, which helps preserve the integrity of mTLS auth. It establishes two key components: a 

 API specifically for pod certificate issuance, and a 

 projected volume source that lets the kubelet provision keys and certs automatically. By shifting the responsibility of enforcing node security boundaries to the K8s API-Server, this mechanism makes it significantly easier and safer for both in-tree and third-party tools (like HashiCorp Vault) to issue client and server certificates via standard 

), a new cluster-scoped Kubernetes API designed to safely distribute X.509 trust anchors (root or intermediate certificates) to workloads. Previously, clusters relied on clumsy workarounds like copying a 

 into every namespace or hardcoding static CA certs.

To complement this, a new kubelet projected volume source allows workloads to easily consume these trust anchors directly from the container's filesystem, automatically updating them on the fly during certificate rotations without requiring application restarts.


 sig-node

This enhancement extends the Pod API to now support Pod-level resource requests and limits (specifically for CPU, memory, and hugepages) alongside existing container-centric settings. By allowing tightly coupled containers within a pod to share a unified resource pool, this feature simplifies resource management and eliminates the need for meticulous, per-container configs. Ultimately, this change enables dynamic intra-pod resource sharing, which reduces waste, improves overall resource utilisation, and better accommodates workloads with unpredictable or bursty demands.



Enable Writable cgroups for unprivileged containers

 sig-node

Introduced as an Alpha stage feature in 1.37, we’re seeing a new 

. This enhancement allows unprivileged containers to securely manage and write to their own sub-cgroups, providing fine-grained resource control directly through the Kubernetes API instead of relying on broad, less-secure runtime-level configurations.



 sig-node

Graduating to stable in 1.37, the proposed Node Declared Features framework allows Kubernetes nodes to dynamically advertise their active, feature-gated capabilities directly to the control plane. By exposing these features, components like the scheduler and admission controllers can automatically manage version-skew issues. This includes activities like ensuring pods are only scheduled on compatible nodes and blocking unsupported API operations, all without requiring users to manually configure complex taints, tolerations, or node labels.



 sig-node

Kubernetes 1.37 introduces a native 

 and the CRI. This allows users to configure fine-grained POSIX resource limits (like open files and process counts) per container, ultimately eliminating the need for host-level workarounds that could otherwise cause issues. To maintain system stability and cluster security, the proposal restricts the feature to the privileged (

) level, enforces strict validation, and even integrates with newly-graduated node-declared features to ensure pods requiring custom limits are only scheduled on compatible nodes.

 sig-node

By allowing drivers to specify at the 

 level that node-local setup is unnecessary, the kubelet can bypass standard gRPC preparation and unpreparation calls. This bypass speeds up the container lifecycle, allowing container startup & termination to proceed immediately for supported devices.



Resource Claim Status with possible standardised network interface data



 sig-node

Graduating to stable in 1.37, this KEP introduces a new 

 API. This allows DRA drivers to report arbitrary, driver-specific status data, such as operational conditions and standard networking details (IPs, MAC addresses, and interface names) directly to the resource claim. The enhancement improves observability, simplifies troubleshooting, and enables third-party controllers to integrate allocated resources into higher-level network services.



 sig-node

This framework-assisted method exposes DRA device metadata like PCIe addresses and mediated device UUIDs directly to workloads via standard JSON files mounted using the Container Device Interface (

). By allowing DRA drivers to populate a metadata field (either immediately during resource preparation or deferred via NRI hooks during sandbox creation), the framework automatically handles file generation, directory structuring, and container bind-mounting. This design provides proper container-level isolation per resource request, ensures backward compatibility, and eliminates the need for complex, error-prone custom controllers currently required by workloads like 

Scheduler Preemption for In-Place Pod Resize



 sig-scheduling

Updating the Kubernetes Scheduler to automatically actively create space for Deferred In-Place Pod Resizes by preempting (or evicting) lower-priority pods on fully-utilised nodes certainly aligns the behaviour with the preemption logic used for newly created pods. Currently, in-place resizes that exceed a node's capacity do not trigger preemption, resulting in deferred status and requiring manual intervention or risking disruptive external controller behaviours (like OOM-kills or node rescheduling). While the proposal aims to automate resource scaling and reduce workload disruptions, it intentionally keeps broader scheduling tasks (like binding) out of scope and highlights key risks, such as performance overhead from deferred pod queues, double-preemption during scheduler restarts, and the potential for over-preemption. This will all be addressed using aligned resource-fit calculation logic by Beta.



 sig-scheduling

Graduating to Stable in 1.37, this enhancement introduces device taints and tolerations to DRA. This improvement mirrors the existing node taint model to handle hardware issues gracefully. By applying taints via DRA drivers or user-defined 

, clusters can block new pods from scheduling onto degraded or offline hardware (

) or evict currently running pods for maintenance (

). Users can bypass specific taints by adding matching tolerations directly to their 

. This allows workloads to run on degraded devices or during testing at their own risk. All while informational taints can be published for hardware monitoring without altering scheduling.



 sig-scheduling

To eliminate the rigidity of exact attribute matching across different hardware vendors, this net new improvement introduces 

 to DRA. By evaluating scoped CEL expressions on candidate devices to synthesise virtual grouping keys, users can easily pair GPUs and NICs without waiting for vendors to standardise attribute names. Here’s a quick sample of bridging disparate schema within the 

Speed up recursive SELinux label change



 sig-storage

Graduating to Stable in the 1.37 release, speeding-up SELinux volume mounting by replacing the slow, recursive file-by-file relabelling process with the Linux 

 mount option is a huge improvement. This change applies the required SELinux context to an entire volume at once. Having been rolled out across Kubernetes 1.36 and 1.37 through feature gates like 

, the new default applies context mounting automatically while providing opt-out mechanisms (

) for edge cases that rely on traditional recursive relabelling.



 sig-storage

This Beta improvement proposes extending the Kubernetes 

 plugin to score nodes during dynamic persistent volume provisioning based on available storage capacity. Users can configure this global policy to either prioritise nodes with the most free space (the default, to allow for future volume expansion) or nodes with the least sufficient space (to pack workloads and reduce node count/costs).



Add user fields to atomic write volumes



 sig-storage

Graduating to Alpha in 1.37, we’re seeing optional 

) to allow setting custom owner UIDs on mounted files. This solves a long-standing issue for apps with strict file-ownership requirements (like MongoDB or SSHD) that currently default to root ownership. It’s also worth noting it enables non-root pods running under restricted security policies to set correct file permissions without needing privileged 

Configurable tolerance for Horizontal Pod Autoscalers



 sig-autoscaling

The Horizontal Pod Autoscaler (

) currently uses a fixed, cluster-wide default tolerance of 10% to prevent rapid scaling churn - called "

". Unfortunately, this is a global setting and is often too coarse. Especially for large or sensitive workloads where minor percentage shifts represent hundreds of pods or delay critical scale-ups. This KEP adds an optional, per-HPA tolerance field (within 

) that allows users to override the global default on a per-workload basis. By letting devs fine-tune scaling thresholds independently for scale-up and scale-down actions, HPAs can become significantly more responsive without altering the core scaling algorithm or introducing major operational risk.



Support scaling to/from zero pods for object/external metrics



 sig-autoscaling

In the Kubernetes 1.37 release, there were improvements to the existing Beta release, natively allowing the HPA to scale workloads down to zero replicas (

) and back up based on object or external metrics (such as message queue length). The key change to Beta introduces an explicit 

 status condition on the HPA object. This enables the controller to differentiate between an automated scale-to-zero event and a manually paused deployment. The changes here also expanded end-to-end and integration test suites to ensure safe cluster behaviour.

Native Histogram Support for Kubernetes Metrics



 sig-instrumentation

Graduating from Alpha status to Beta in 1.37, this KEP introduces a 

 feature gate to expose Prometheus Native Histograms across Kubernetes control plane components alongside existing classic metrics. By transitioning from fixed bucket boundaries to dynamic exponential buckets, Native Histograms deliver a ~10x reduction in time series storage overhead and significantly sharper latency resolution for detecting performance issues. The dual-exposition model ensures full backward compatibility, allowing team-level migration without breaking existing dashboards or alerts.

 sig-network

Kubernetes 1.37 outlines the deprecation and eventual removal of the under-maintained 

, steering users instead toward the newer 

 backend as older kernels phase out of LTS by the end of 2026. Rather than archiving the code in a separate repository, the project plans a clean, multi-release removal via the 

 feature gate. The transition spans five stages: starting with deprecation warnings and documentation updates back in v1.35 (Stage 1), introducing the current feature gate in v1.37 (Stage 2), before disabling IPVS by default in v1.40 (Stage 3), and fully removing the IPVS codebase in v1.43 (Stage 4). The release team cleaned up the feature gate itself in v1.46 (Stage 5).

Add Resource Health Status to the Pod Status for Device Plugin and DRA



, with past milestones including the start of the cycle back in May and the 

 on June 16th. Upcoming technical milestones involve the 

 on July 22nd - the week before Kubecon Japan. The official v1.37 release comes out on Wednesday the 26th August.

Kubernetes 1.37 – What you need to know

Kubernetes 1.36 – What you need to know

Kubernetes 1.35 – What you need to know

Kubernetes 1.34 – What you need to know

Kubernetes 1.33 – What you need to know

Nigel Douglas

Head of Developer Relations

 will be the first Kubernetes major release of 2026, and it’s full of really exciting updates for security, AI hardware, and more! As always, removing enhancements with the status of “

” we are seeing 80 enhancements in all listed within the 

Kubernetes 1.36 brings a whole bunch of useful enhancements, including 36 changes tracked as ‘

 are currently graduating to stable, such as 

 enhancements graduating to that GA status.

 features are also listed in the enhancements tracker, one of which introduces the ability to report when a PVC was last used in 

. A simple by powerful use-case where users can now see if a PVC is sitting unused, so in larger clusters this would really help DevOps teams to get rid of any unused and unwanted PVCs.

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.36.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:


It’s becoming a regular comment in these recent Kubernetes release notes, but the DRA API is seeing a LOT of exciting enhancements in the 1.36 update. [

 all updated in this release]. This led the Cloudsmith team to add dedicated 

 updates. Anyways, this specific DRA enhancement is exciting because it brings more granularity and automation to hardware management, allowing admins to take specific devices offline for maintenance without disrupting the entire cluster. By introducing taints and tolerations for hardware, similar to what we already have for pod deployments, we can all benefit from automatically rescheduling pods away from failing devices while still letting specialised test pods access them for daily troubleshooting activities.

Nigel Douglas - Head of Developer Relations


I am absolutely thrilled to see OCI image volumes finally hitting Stable status in Kubernetes 1.36 because, as a Product Manager working on the OCI format support at Cloudsmith, I can see this enhancement turning existing container registries into universal artifact hubs. For years, dev teams have been forced into the so-called fat image anti-pattern, where they’re basically bundling massive 

, static assets, and binary plugins directly into their application images, which ultimately creates a nightmare for security patching and bloats deployment times. By graduating this to Stable, we’re now seeing a native, high-performance way to decouple user data from your logic. Devs can now push Hugging Face LLM weights or commercial signatures as independent OCI artifacts and mount them as a 

 just as easily as a ConfigMap. This doesn't just simplify CI/CD pipelines by allowing platform teams to swap content without rebuilding the base engine, but it also drastically shrinks your potential attack surface for the platform teams who are managing these deployments. It’s a massive win for the ecosystem that transforms the OCI registry from a basic storage location for apps into a more dynamic, structured delivery system for any content that a pod needs to succeed.

#5793 Manifest-based Admission Control configuration


As a CSM, I’m genuinely stoked for this 1.36 feature because it finally lets platform teams secure their actual admission control configs. When we think about moving mission-critical policies from the API to static files on the control plane disk, platform teams can now prevent the scary security blindspot where the cluster was vulnerable during the startup. Based on what I'm hearing from the teams I work with, this means vital guardrails (like blocking privileged containers) are now immune to accidental 

 crashes. It’s a massive win for their platform stability, providing platform engineers with a somewhat tamper-proof approach to keeping the 

 secure from the very first second the API server wakes up.

Mutable Container Resources when Job is suspended


This proposal seeks to enhance Kubernetes Batch Job management by relaxing the immutability of a Job’s Pod template while it is in a 

 flag, this change would allow higher-level queue controllers to mutate resource specifications (specifically 

) before a Job is unsuspended and pods are created. By allowing these updates, cluster administrators and automated controllers can dynamically optimise resource allocation based on real-time cluster capacity, current queue priorities, and actual workload utilisation, ensuring that expensive hardware like GPUs is used efficiently.

The design ensures that these mutations are only permitted when a Job is fully suspended and has no active pods, mitigating the risk of disrupting running workloads. While the proposal does not include implementing a specific queue controller or supporting in-place pod updates, it provides the necessary API primitives for external tools (like 

) to perform checkpointing and resizing. This flexibility allows a Job to be suspended, its resource requests lowered to match actual usage, and then resumed, thereby improving overall cluster throughput and reducing resource waste.

Add Recreate Update Strategy to StatefulSet


Starting in Kubernetes 1.36, the introduction of the 

 that has plagued users since 2018. Previously, if a StatefulSet update was triggered with a broken configuration (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become 

 before proceeding. Even if a user reverted the configuration to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing administrators to manually delete the Pod to unblock the controller.

 strategy (moving to Alpha in this update) provides a more aggressive alternative to the standard RollingUpdate. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the 

 deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated CI/CD pipelines and operators can recover from misconfigurations without manual human intervention.

WAS: Integrate Workload APIs with Job controller


The feature represents a major step in Kubernetes' evolution to natively support complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (gang scheduling). This feature introduces the 

 object to act as a link between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.

For the Kubernetes 1.36 Alpha update, the proposal focuses on standardising this integration and refining the API surface. Key changes include introducing the PodGroup as a standalone runtime object and renaming the embedded field within the Workload spec to 

 to ensure a cleaner, more extensible hierarchy. Specifically for the Job controller, the 1.36 update aims to enable the creation of Workload and PodGroup objects by default for 

 Jobs (those where parallelism does not change). This release also seeks to resolve a critical debate on 

, which is whether the release team should maintain separate 

 policies or to unify them into a single parameter where a 

 equal to the total replicas represents strict gang scheduling.

 marked a simple, formal separation of two different KEPs that were previously managed as a single unit: 

 (the Deployment pod replacement policy). The split was justified because the #3973 enhancement which introduced the 

 field to track pods in the process of shutting down moved through the development cycle faster than the more complex pod replacement policy. By decoupling them, the 

 team can now track their graduation through Alpha, Beta, and Stable stages independently, preventing the progress of one from being stalled by the other.

The merged changes include updated documentation and readiness reviews (PRRs for short) for both features. Key technical discussions during the PR focused on ensuring proper version skew policies, specifically requiring that the 

 to avoid status synchronisation issues. While the terminating replicas feature is already seeing implementation in recent releases, the specific API and logic for the pod replacement policy remain in progress, now neatly organised under its own dedicated proposal for future tracking in the 1.36 update.

Graduating to stable, Mutating Admission Policies introduce a declarative, in-process alternative to traditional mutating admission webhooks by leveraging 

. This enhancement allows cluster administrators to define resource modifications (such as injecting sidecar containers, enforcing image pull policies, or setting default labels) directly within Kubernetes using 

 objects. By using CEL's object instantiation alongside 

, the API server can perform these mutations internally, significantly reducing the operational overhead, latency, and webhook fatigue associated with maintaining external infrastructure.

Beyond simplicity, this native approach offers superior performance and reliability. Because the mutations are in-process, the 

 can introspect changes to optimise execution order and safely re-run policies to ensure 

. While it does not aim for 100% feature parity with webhooks, specifically excluding external calls, it covers the vast majority of common use cases while providing a safety field to validate that mutations remain consistent. This move effectively brings the power and efficiency of 

 to the mutation phase, creating a more robust and integrated policy management framework within the Kubernetes ecosystem.

Cloudsmith Blog

Kubernetes 1.37 – What you need to know

Kubernetes 1.36 – What you need to know

LLMs on Kubernetes: same cluster, different threat model

Kubernetes 1.35 – What you need to know

Kubernetes 1.34 – What you need to know

Kubernetes 1.33 – What you need to know

Streamline Kubernetes Workflows with Cloudsmith