Haru dropped with a Hokusai painting and a calligraphy inscription. Buried underneath all that poetry is a release that rearranged how your cluster actually works.
There’s a tradition in Kubernetes releases where the changelog reads like a corporate memo dry, dense, and written for people who already know what they’re looking for. Kubernetes 1.36 broke that tradition in the most unexpected way. The release is named Haru a Japanese word that carries three meanings at once: spring, clear skies, far-off horizons. The logo is a reimagining of Hokusai’s Red Fuji, with the Kubernetes helm floating in the sky above the mountain. The calligraphy brushed across it translates to
“soar into clear skies; toward tomorrow’s sunrise.”
And I’m sitting here like okay, K8s. We’re doing this now.
The poetry is earned though, because underneath it, 1.36 is one of the more consequential releases in recent memory. Not because it introduced a dozen shiny new alpha features (it did that too), but because it finally graduated things that have been in progress for years, killed things that should’ve died ages ago, and gave platform engineers actual tools to stop duct-taping their clusters together.
TL;DR: Mutating Admission Policies are GA and webhooks are on notice. User Namespaces finally hit stable after four years in alpha. Ingress NGINX is officially retired not deprecated, retired. DRA grew up for real GPU scheduling. OCI volumes made ML model distribution less embarrassing. HPA scale-to-zero is now a thing. And the gitRepo volume type is gone, eight years after everyone was told it was going away.
Webhooks: cooked
If you’ve run admission webhooks in production, you already know the drill. Every API request hits your webhook server on the way in. That server lives outside the cluster, needs its own deployment, its own TLS, its own on-call rotation. And when it goes down and it will go down pod scheduling stops. Not degrades. Stops.
I once spent a week chasing a stalled CI/CD pipeline. Deployments failing with no clear pattern, logs noisy but useless. Root cause: an OPA Gatekeeper webhook silently dropping pod CREATE requests under load. A week. For a dropped request.
That entire class of problem disappears with MutatingAdmissionPolicies, which hit GA in 1.36. Instead of an external service, you write mutation logic as CEL expressions evaluated inline inside the API server. No external server. No TLS certs to rotate. No 3am pages because the webhook pod got evicted. Define it as a Kubernetes object, version-control it in Git, ship it through your normal GitOps flow.
The asterisk: if your mutation logic needs to call an external service, you still need a webhook. But that’s maybe 20% of real-world use cases. Label injection, sidecar prepending, field defaulting all of that is now native and in-process.
Webhooks aren’t gone. They’re just no longer the only option. And for most teams, that’s a massive operational relief.
Root inside a container was always fiction
Here’s something nobody likes to say out loud: when your container runs as root, it’s running as root on the host too. The container boundary exists, sure but if something escapes it, it lands on your node with full administrative power. That’s not a hypothetical. Container breakout vulnerabilities are real, documented, and have CVEs attached to them.
The fix has existed in Linux for years. User Namespaces let you map UID 0 inside the container to an unprivileged user on the host. Your process thinks it’s root. The kernel knows it isn’t. If it escapes, it lands with essentially nothing.
Kubernetes has been working toward this since v1.25 in August 2022. Four years of alpha, beta, validation on production workloads, and edge case hunting. In 1.36 it’s finally Stable. You enable it with one field:
spec:
hostUsers: false
That’s it. That’s the fence with a lock.
Before this, running genuinely rootless containers in Kubernetes meant layering on gVisor, Kata Containers, or some combination of third-party tooling and crossed fingers. Now it’s native, stable, and production-ready with no extra dependencies.
One watch-out: Images built assuming real root privileges may behave unexpectedly under UID remapping. Test on non-critical workloads first before rolling it cluster-wide.
Ingress NGINX is dead. Not deprecated. Dead.
On March 24, 2026, Kubernetes SIG Network and the Security Response Committee officially retired Ingress NGINX. No more releases. No bug fixes. No security patches. If you’re running it today, you’re running unsupported software in production and the maintainers have left the building.
This isn’t a soft deprecation with a two-release runway. There’s no “we recommend migrating by v1.38.” It’s done. The flaws were too deep, the maintainer bandwidth wasn’t there, and the Security Response Committee signed off on pulling the plug.
The uncomfortable part is how many production clusters are still running it. Ingress NGINX became the default answer to “how do I route traffic in Kubernetes” for years. It was good enough, it was everywhere, and nobody had a strong reason to migrate until now.
The migration path is Gateway API v1.5. It gives you structured routing, cross-namespace references, and a proper separation between infrastructure concerns and developer concerns things Ingress never cleanly handled. The Ingress2Gateway project hit 1.0 in March 2026 specifically to help with this transition. The tooling exists. The excuses don’t.
If you’re on Ingress NGINX, this is the conversation to have with your team this sprint, not next quarter.
DRA grew a brain. GPU scheduling makes sense now.
If you’ve ever tried to schedule GPU workloads on Kubernetes before Dynamic Resource Allocation existed, you know what it felt like. Node selectors, custom labels, resource limits that didn’t reflect actual hardware topology, vendor-specific device plugins that all invented their own interfaces. It worked, technically. The way duct tape works, technically.
DRA has been Kubernetes’ answer to this for a few releases now a proper framework for scheduling specialized hardware like GPUs, accelerators, and custom silicon. 1.36 is the release where it stops feeling experimental.
A few things landed here that matter. Taints and tolerations for hardware devices: you can now take a specific GPU offline for maintenance without touching the rest of the cluster. Same mental model you already use for nodes, applied to individual devices. Resource Health Status is now surfaced through standard Kubernetes tooling if a GPU is unhealthy, it shows up like any unhealthy pod or node. No custom monitoring stack per vendor. No guessing. Just a status field that’s either green or it isn’t.
Per-pod DRA resource visibility is also locked to GA, meaning monitoring tools, billing systems, and operators can reliably query exactly what hardware each pod has been allocated. That matters a lot when your GPU cluster costs more per hour than most engineers’ daily rate.
The AI/ML infra angle here is obvious. Training jobs are expensive. Scheduling a 12-hour run onto a degraded GPU because your health checks lived in a vendor sidecar that missed a signal is the kind of thing that ends sprints. 1.36 starts fixing the foundation.
Shipping ML models in init containers was embarrassing
Getting a large model into a container has always been an exercise in picking the least bad option. Bake it into the image and watch your pull times become a running joke. Use an init container to download it at runtime and accept the complexity and failure modes that come with that. Fight ConfigMap size limits trying to get config artifacts in. Build a custom distribution pipeline and maintain that forever.
None of these are good. All of them are common.
OCI VolumeSource hits GA in 1.36 and it’s the answer that should’ve existed earlier. Reference any OCI image as a volume. Kubernetes pulls it and mounts the contents into your pod exactly like a regular volume. Your 40GB model lives in its own OCI artifact, versioned and distributed through the same registry infrastructure you already use. Your app container stays lean. Updates to the model don’t require rebuilding the app image.
volumes:
- name: model-weights
image:
reference: registry.example.com/models/llama-weights:v3
For AI/ML workloads specifically this is a meaningful quality-of-life change. Model and code have different update cadences, different owners, and different size profiles. Treating them as separate artifacts that get composed at runtime is just the correct architecture. OCI VolumeSource makes that native instead of something you have to engineer around Kubernetes to achieve.
HPA scale-to-zero: serverless K8s without the serverless tax
Every team has them. Pods sitting at 0.3% CPU at midnight, burning compute budget, waiting for a queue message that won’t arrive until morning. You know you should scale them down. You also know that wiring up a custom scaler, a KEDA setup, or a managed FaaS layer just to handle idle workloads is its own operational surface area to maintain.
1.36 introduces alpha support for HPA scale-to-zero for Object and External metrics. minReplicas: 0 is now a real configuration, not a validation error.
spec:
minReplicas: 0
maxReplicas: 50
metrics:
- type: External
external:
metric:
name: sqs_queue_length
target:
type: AverageValue
value: 10
Queue hits zero, pods go to zero. Message arrives, HPA spins them back up. Combine with Karpenter and the node drains too. That’s native scale-to-zero serverless architecture without handing control to a managed FaaS platform or bolting on a separate autoscaling tool.
It’s alpha, so you need to enable the HPAScaleToZero feature gate explicitly. More importantly audit your existing HPAs. If you're not explicitly setting minReplicas: 1 somewhere, your workloads may now behave differently than you expect. That's the kind of silent change that shows up in a production incident, not a code review.
SSH-ing into nodes to check logs was always shameful
You know the sequence. Something’s wrong on a node. You find the bastion host. You SSH in. You navigate to the worker node. You run journalctl -u kubelet and scroll through walls of output trying to find the one line that explains why your pods aren't scheduling. Meanwhile the incident is live and your team is waiting.
Every engineer who’s run Kubernetes in production has done this at least once. Most have done it more times than they’d like to admit.
Node log queries hit GA in 1.36. With NodeLogQuery enabled on the kubelet and enableSystemLogQuery set in your kubelet config, you can query node-level logs kubelet logs, system service logs directly through kubectl. No SSH. No bastion. No explaining to your security team why you needed direct node access during an incident.
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/logs/kubelet"
It’s not glamorous. It’s not the kind of feature that gets a conference talk. But the number of minutes lost per engineer per year to that SSH chain in production is genuinely non-trivial, and now it’s gone.
This was SIG Windows work through KEP-2258, which also means Windows nodes get full parity here something that’s historically lagged behind Linux in the observability tooling space.
The kubelet was handing out too much access. Fixed.
The kubelet exposes a gRPC API that monitoring agents, device plugins, and observability tools use to query what’s running on a node which pods are scheduled, what hardware resources they’ve been allocated, container states. Useful stuff. Stuff that a lot of tools legitimately need.
The problem was access granularity. Getting a monitoring tool the access it needed often meant granting broad kubelet permissions. In regulated environments PCI-DSS, FedRAMP, SOC 2 that’s not a risk you can quietly accept. It’s a finding waiting to happen.
Fine-grained kubelet API authorization hits GA in 1.36. Tools get exactly the permissions they need, scoped to the specific API surfaces they actually call. Nothing broader. The least-privilege model that should’ve been there from the start is now the stable, production-ready default.
External ServiceAccount token signing also graduates to GA in this release. If your compliance framework requires key management outside Kubernetes’ default signing setup or you’re running in an environment where the control plane’s signing keys need to live in an external KMS this gives you a native, stable path to that without third-party workarounds.
Neither of these features will show up in a demo. Nobody’s going to tweet about kubelet auth granularity. But for teams running Kubernetes under any kind of compliance requirement, these two graduating to stable quietly removes two items from the audit findings list that have been sitting there for a while.
Your PVCs now tell you when they were last used
Orphaned PersistentVolumeClaims are one of those slow, invisible cost drivers that nobody notices until someone pulls up the storage bill and starts asking uncomfortable questions. PVC gets created, workload gets deleted or redeployed, claim sits there bound and unused, and the underlying disk keeps billing. Multiply that across a busy cluster over a few months and it adds up faster than you’d think.
Before 1.36, identifying idle PVCs meant either building a custom controller, running a third-party cleanup tool, or doing periodic manual audits none of which are things anyone actually wants to own.
1.36 adds an unusedSince timestamp field to PersistentVolumeClaimStatus. The PVC protection controller now stamps it when the last pod referencing that claim is deleted or hits a terminal state. When a new pod mounts it again, the field clears back to nil.
status:
phase: Bound
unusedSince: "2026-03-10T14:22:00Z"
Two states. Either it has a timestamp idle since that moment or it’s nil, meaning it’s currently mounted or has never been used. Simple, native, queryable through standard kubectl and the API.
It’s alpha, so it’s not on by default yet. But the pattern it enables list all PVCs where unusedSince is older than 30 days, review, clean up is something teams have been building custom tooling to approximate for years. Now it's just a field.
The gitRepo volume: eight years after deprecation, finally gone
Deprecated in v1.11. June 2018. That’s not a typo.
For eight years the gitRepo volume type lived in the Kubernetes codebase like a haunted house nobody wanted to deal with. It let you populate a volume directly from a Git repository at pod startup which sounds convenient until you think about what that actually means. Arbitrary git clone operations running with pod-level permissions, no real sandboxing, a well-documented attack surface. It was deprecated almost immediately after people understood the implications.
And yet there it sat. Release after release. Deprecation notice in place, removal perpetually deferred.
1.36 finally pulls it out. If you’re somehow still using gitRepo volumes in 2026, this is the migration you should have done in 2019. Init containers with a proper git clone step, or a CI/CD pipeline that bakes artifacts into the image, are both better in every dimension.
Also worth flagging in the same breath: externalIPs in the Service spec is deprecated in 1.36, with full removal planned for v1.43. It's been a known attack vector since CVE-2020-8554. If it's in your configs, start the conversation now rather than doing it in a panic seven releases from now.
The broader signal here is worth noting. Kubernetes is enforcing its own deprecation timeline now, not just suggesting it. That’s good for the project’s long-term hygiene and a sign the maintainers are serious about not carrying dead weight forever.
Haru didn’t come to play
There’s a version of this release that gets written off as a maintenance drop. No dramatic new directions, no paradigm-shifting alpha features with a flashy demo. Just a lot of things graduating, a lot of debt getting cleared, and a handful of quiet improvements that compound over time.
That reading misses the point entirely.
1.36 is the release where Kubernetes starts filling its own gaps instead of expecting you to build scaffolding around them. Admission webhooks were a workaround that became an institution MAPs replace the institution. Container root isolation required third-party tooling for years User Namespaces makes it native. GPU scheduling was a patchwork of vendor plugins and custom controllers DRA gives it a real foundation. ML model distribution was genuinely embarrassing OCI volumes fix the architecture.
None of these are new ideas. All of them are ideas that finally graduated from “you can kind of do this if you squint” to “this is stable and production-ready.”
The Ingress NGINX retirement and the gitRepo removal are the most underrated signals in the release. They tell you the project is serious about what Kubernetes should and shouldn’t be and serious about not carrying CVE-adjacent code forever because migration is inconvenient.
DRA’s trajectory over the next two or three releases will define how Kubernetes handles the AI infrastructure wave. The bones being laid in 1.36 matter more than they look.
Haru means spring. New season, cleared skies, distant horizon. The release name was earned.
Which of these 10 changes hits closest to home for your cluster? Drop it in the comments.