Week Ending May 3, 2026

Developer News

The Agent Sandbox subproject has published a Kubernetes blog post, Running Agents on Kubernetes with Agent Sandbox, and progressed to v0.4.3 since v0.1.1. Updates include default network isolation, persistent storage support, Python SDK improvements, a new Go client, and controller stability enhancements.

The Kubernetes v1.37 Release Team shadow application is open until May 15, 2026, with results announced on May 22. The release cycle is expected to run from May 18 to August 26. Learn more in the Release Team Overview, Shadows Guide, Role Handbooks, and Selection Criteria. Updates will be shared in the #sig-release Slack channel and kubernetes/sig-release repository.

KubeCon North America CFP closes on May 31. Submit your talks before the deadline.

KubeCon North America Maintainer Track CFP is also open. Submit your sessions by July 12.

Release Schedule

Next Deadline: Release Cycle Starts, soon

Cherry-picks for the next patch releases are due this Friday, May 8.

Featured PRs

138629: feat(validation-gen): add eachVal + maxBytes validation for resource string values

aaron-prindle has migrated handwritten per-item byte-length validation for ResourceSlice.spec.devices[*].attributes[*].strings[*] to declarative validation as part of KEP-5073: Declarative Validation with validation-gen. The PR was reviewed and approved by thockin and contributors from SIG API Machinery and WG Device Management, and is the first use of the +k8s:eachVal tag in the kubernetes/kubernetes API surface.

Declarative validation moves API field validation from hand-written Go code into machine-generated code driven by struct-tag annotations on the API types themselves. The benefit for contributors is that validation rules become co-located with the field they validate, far easier to audit, and consistent across all API versions. The benefit for users is reduced surface area for subtle validation drift between API versions and improved API server performance over time.

This PR adds the +k8s:alpha(since: "1.37")=+k8s:eachVal=+k8s:maxBytes=64 tag chain to the v1, v1beta1, and v1beta2 resource API types, regenerates the declarative validation code, and adds equivalence coverage tests verifying the byte-count semantics on both create and update boundary cases. Notably, the PR uses +k8s:maxBytes rather than +k8s:maxLength because the existing handwritten validation enforces a byte limit via Go’s len(string) and field.TooLong, so the tests use the two-byte UTF-8 character é to confirm byte-count behaviour. The handwritten validation remains authoritative; this migration begins the soak period required to graduate the +k8s:eachVal tag to StabilityLevelBeta.

KEP of the Week

KEP-5710: Workload-aware preemption

This KEP proposes enhancing the Kubernetes scheduler with workload-aware preemption, shifting from a pod-centric to a workload-centric approach. Building on KEP-4671’s Workload and PodGroup APIs, it introduces concepts like pod group priority and defining preemption units at the workload level, starting with a simple implementation based on existing pod preemption. The motivation stems from tightly coupled workloads such as AI training and multihost inference that depend on continuous coordination across multiple pods, where disruption of even a single pod halts overall progress. Current preemption mechanisms fail to account for this, especially in resource constrained environments where prioritization and efficient hardware utilization are critical. By standardizing workload-aware preemption within core Kubernetes, this proposal aims to better support such workloads, improve resource utilization, and enable deeper integration with other features like autoscaling and disruption management.

This KEP is currently in Alpha stage for Kubernetes v1.36.

Other Merges

kube-proxy does not perform full-sync operations when operating in large cluster mode (more than 1000 endpoints)
Fixed kubelet failure starting on ZFS due to missing cadvisor plugin
kubeadm: during kubeadm init, if the default admin.conf and super-admin.conf paths are used, load the files but construct in-memory kubeconfigs that point to the InitConfiguration.localAPIEndpoint instead of the ClusterConfiguration.controlPlaneEndpoint, resolving issues with delayed load balancers provisioned only after the first kube-apiserver instance starts
Introduce Deferred Gen concept to the Validation-gen framework
Improved CEL error messages in Dynamic Resource Allocation to provide guidance when accessing non-existent device attributes, with links to documentation on handling optional fields using orValue() and has()

Promotions

Several declarative validation tags to beta and GA

Version Updates

Subprojects and Dependency Updates

etcd released updates 3.6.11, 3.5.30, and 3.4.44, including a security fix for etcd auth, and allowing adding members with one member down

Shoutouts

Sayan Chowdhury: As I complete the final off-boarding steps for the v1.36 release, I would like to thank the whole team that was part of this journey with me to handle the Docs for the v1.36 release – I could not have asked for a more knowledgeable and brilliant team. We handled close to 70 KEPs this cycle and it was no easy feat. The team relentlessly made sure that we closed each deadline without any trouble and kept the release timeline on track – from making sure the dev-1.36 branch is synced, to the utmost care and eye for detail in the release notes PR creation and review. The team also made sure that everyone works collaboratively and no one ever falls behind and helping each other during followups and reminders phases. I’m absolutely happy to have been part of this team and to work among such amazing team members – a big hurrah to the v1.36 release, and thank you again @anshuman @Émile Savard @kernel-kun @Saurabh.

Last Week In Kubernetes Development (LWKD) is a product of multiple contributors participating in Kubernetes SIG Contributor Experience. All original content is licensed Creative Commons Share-Alike, although linked content and images may be differently licensed. LWKD does collect some information on readers, see our privacy notice for details.

You may contribute to LWKD by submitting pull requests or issues on the LWKD github repo.