Kubernetes 1.36 Haru: What's Actually Worth Upgrading For

Kubernetes 1.36, codenamed Haru, shipped April 22, 2026, and if you’re looking for the one feature that changes how you run clusters, there isn’t one. That’s not a knock on the release. It’s 70 enhancements, mostly features that spent a cycle or two proving themselves in Beta and are now graduating to Stable, which makes this exactly the kind of release worth checking your cluster config against rather than skimming past.

The headline number, and why it undersells the release

Eighteen enhancements reached Stable, 25 moved to Beta, and 27 landed at Alpha, contributed by 491 people across 106 companies over a 15-week cycle. Release notes that lead with a count like that tend to read as filler, but in this case the count is the story: Haru is a consolidation release. The Kubernetes project itself described it as bringing “long-planted seeds into bloom” rather than introducing a new architectural direction, and after several years of releases built around a single headline (Gateway API, sidecar containers, in-place pod resizing), a release built around finishing what’s already in flight is worth taking seriously precisely because it’s not trying to get your attention.

External ServiceAccount token signing reaches Stable

This is the change most platform teams should actually look at. Historically, the Kubernetes control plane manages its own signing keys for ServiceAccount tokens, which means a cluster running alongside an external identity provider (Okta, an internal PKI, a cloud IAM system) ends up with two separate sources of truth for identity: one for humans, one for workloads. External ServiceAccount token signing lets you delegate that signing to the same external system, so workload identity and human identity live in one place instead of two.

For teams that have already invested in a centralized identity story, this closes a gap that’s existed for a long time. For teams still managing ServiceAccount tokens the default way, it’s a reason to have the conversation about whether that gap is worth closing now that the tooling to close it is Stable rather than an experimental flag.

Constrained impersonation, and the privilege-escalation path it closes

Kubernetes impersonation exists so that support tooling and some controllers can act as another identity, which is genuinely useful for debugging and for certain multi-tenant control-plane patterns. The problem is that unrestricted impersonation rights let a compromised or misconfigured controller effectively grant itself any permission in the cluster, by impersonating whatever identity holds that permission. Constrained impersonation, moving to Beta in 1.36, lets an administrator scope exactly which identities a given actor is allowed to impersonate.

If your cluster has any controller or support tool with cluster-wide impersonation rights today, that’s worth an audit independent of whether you adopt this specific feature yet. Beta means it’s not the default and needs to be explicitly enabled, but the underlying risk it addresses is already live in any cluster granting broad impersonation rights, with or without this fix.

What’s genuinely lower priority

Twenty-seven Alpha-stage enhancements landed in this release, and almost none of them belong in a production rollout plan yet. Alpha in Kubernetes means the API can still change or the feature can be dropped entirely; treat these as things to read about and maybe test in a throwaway cluster, not things to schedule. The useful signal from an Alpha feature isn’t “adopt this,” it’s “this is the direction the project is heading,” which is worth knowing when you’re making longer-term architecture decisions but not worth a sprint right now.

The thing that matters more than this release

Ingress NGINX was retired earlier in 2026, and if your cluster is still running it, that migration outranks everything in Haru. A retired ingress controller stops receiving security patches, and ingress sits directly in your request path, which makes it a worse place to be running unpatched software than almost anywhere else in the stack. We’ve covered service mesh options if you’re re-architecting your ingress layer anyway, and this is a reasonable moment to make that decision rather than doing a like-for-like swap and revisiting it again in a year.

What to actually do

Audit your cluster for two things before you touch the upgrade itself: any controller with broad impersonation rights, and whether you’re still on Ingress NGINX. Neither of those requires 1.36 to fix, but 1.36 is a good forcing function to finally look. Once you’re on 1.36, external ServiceAccount token signing is worth adopting if you already run a centralized identity provider; if you don’t, it’s a reasonable prompt to ask why not. Everything else in this release can wait for the next one without real cost, which is a fine place for a release to land. Not every upgrade needs to be dramatic to be worth doing carefully, and teams that treat platform upgrades as routine infrastructure work rather than emergencies tend to have fewer emergencies overall.