Kubernetes 1.36 ships 70 enhancements under the Haru release

The Kubernetes release team published version 1.36, named Haru, on April 22. The official announcement reports 70 enhancements across stable, beta, and alpha work, alongside deprecations and removals. The category breakdown printed in the post does not sum to that total, so the headline figure should be read as the release team’s attributed count rather than reconstructed from those subtotals.

The release broadens several operating contracts

Among the highlighted changes, resource health status moves to beta, giving allocated devices a native way to report health information. Workload-aware scheduling continues to develop, and Dynamic Resource Allocation gains more drivers and features. The release also internalizes required Protobuf generation logic in k8s.io/code-generator rather than moving Kubernetes API types to standard generation, a choice the team says avoids compatibility risks.

The removals deserve equal attention. The long-deprecated gitRepo volume plugin is permanently disabled in 1.36. Workloads that still rely on it need an init-container or another maintained synchronization pattern. The release announcement also points readers to the full notes for other deprecations rather than presenting the highlights as a complete upgrade guide.

Upgrade work begins with an inventory

Before changing a cluster, operators should compare the full 1.36 notes with API usage, admission policies, storage drivers, device plugins, and node runtime versions in their environment. A canary control plane and node pool should run representative scheduling, eviction, storage, and rollout tests.

Feature maturity labels also shape adoption. Stable functionality can still have environment-specific prerequisites; beta features need an explicit owner and rollback plan; alpha features should remain isolated from production assumptions. Kubernetes 1.36 offers a large set of improvements, but the practical value comes from selecting the few that solve a measured problem and treating removals as migration tasks before the upgrade window.