Tech Radar, April 23, 2026: Kubernetes v1.36 Haru Ships 18 GA Features and Closes the Lifecycle Gap

Kubernetes v1.36 “Haru” shipped on April 22, 2026, one day ago. The release carries 70 enhancements: 18 to stable, 25 to beta, 25 to alpha. After reading the full release notes and the detailed pre-release analysis directly from the source material, the picture that emerges is not a flashy feature drop. It is a release that closes several long-standing lifecycle gaps, hardens the security model in ways that matter for production, and makes a meaningful architectural bet on Dynamic Resource Allocation as the future of GPU and AI workload management.

Three themes dominate this release. First, Kubernetes is completing the admission control story by making mutation declarative and native. Second, the security surface is being systematically reduced through a combination of User Namespace graduation, fine-grained kubelet authorization, and the permanent removal of gitRepo volumes. Third, DRA is graduating enough pieces to beta and stable that it is no longer experimental infrastructure for AI workloads — it is becoming the production path.

1. MutatingAdmissionPolicy reaches GA: the end of the webhook tax

The most operationally significant graduation in v1.36 is MutatingAdmissionPolicy reaching stable. This matters because it eliminates a category of operational overhead that platform teams have been carrying for years.

The traditional path for mutation in Kubernetes required running a separate webhook server: TLS certificates to manage, a deployment to keep alive, network latency on every API request, and a single point of failure that could block cluster operations if the webhook became unavailable. For teams that needed to enforce defaults, inject sidecars, or add labels at admission time, this was the only option. It worked, but it was expensive to operate.

MutatingAdmissionPolicy replaces that pattern with CEL expressions that run inside the API server’s own process. No external infrastructure. No network hop. No certificate rotation. The mutation logic lives as a versioned Kubernetes object, which means it is auditable, diffable, and manageable through the same GitOps workflows that govern everything else in the cluster.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: add-default-label
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["deployments"]
  mutations:
  - patchType: ApplyConfiguration
    applyConfiguration:
      expression: >
        Object{metadata: Object.metadata{
          labels: {"managed-by": "platform-team"}
        }}

The practical implication for platform teams is clear: if you are running a webhook server purely for mutation and not for validation, this release gives you a migration path to something simpler and more reliable. The caveats are real — CEL cannot make external calls, and complex multi-step mutation logic gets unwieldy — but for the common cases that drove most webhook deployments, MAP is now the right answer.

This graduation also completes a pattern that started with ValidatingAdmissionPolicy in v1.30. Kubernetes now has a native, declarative admission control story for both mutation and validation. That is a meaningful architectural milestone.

2. User Namespaces reaches stable: container isolation finally has a production path

User Namespaces graduating to stable in v1.36 is the security story that deserves more attention than it typically gets.

The core mechanism is straightforward: a container’s root user maps to a non-privileged user on the host. If a process escapes the container, it has no administrative power over the underlying node. This is defense-in-depth that operates at the kernel level, not at the policy level.

The reason this matters now is that container breakout vulnerabilities are not theoretical. They appear in CVE databases regularly, and the blast radius of a breakout in a cluster without User Namespace isolation is the entire node. With User Namespaces enabled, a successful breakout lands in an unprivileged context on the host. The attacker has escaped the container but not the security boundary.

For multi-tenant clusters, shared infrastructure, or any environment where workloads from different trust levels run on the same nodes, this is a meaningful reduction in risk. The graduation to stable means it is now a fully supported option with long-term API stability guarantees, not an experimental feature that might change.

3. gitRepo volume permanently disabled: a security debt finally paid

The gitRepo volume type has been deprecated since Kubernetes v1.11. In v1.36, it is permanently disabled with no way to re-enable it.

The security case for removal is straightforward. The gitRepo plugin allowed the kubelet to clone a Git repository directly onto a node. A compromised repository could execute code as root on the node. The kubelet was doing a job that belongs to init containers or external git-sync tools, and it was doing it with elevated privileges.

The removal is clean. There is no migration complexity for teams that already moved to init containers or git-sync patterns. For teams that have not, the upgrade path is well-documented and the alternatives are strictly better. The kubelet stays in its lane, and the cluster’s attack surface is smaller.

This is the kind of removal that makes a platform more trustworthy over time. It is not exciting, but it is the right call.

4. DRA graduates enough pieces to become the production path for AI workloads

Dynamic Resource Allocation has been building toward production readiness across several releases. v1.36 is the release where enough pieces reach stable and beta that it is no longer reasonable to treat DRA as experimental for serious AI and HPC workloads.

The stable graduations in this release include DRA admin access for ResourceClaims and ResourceClaimTemplates, and prioritized alternatives in device requests. The beta graduations include partitionable devices, consumable capacity, device taints and tolerations, and ResourceClaim device status.

What this means in practice: platform teams can now implement sophisticated GPU sharing policies, enforce that specialized hardware is only used by appropriate workloads through device taints, and get real-time visibility into device health through ResourceClaim status. The combination of these features makes DRA a credible replacement for the legacy device plugin system for teams running GPU clusters or multi-tenant AI infrastructure.

The Workload Aware Scheduling (WAS) features entering alpha in v1.36 are also worth tracking. The new PodGroup API treats related pods as a single logical entity for scheduling purposes, evaluating the entire group atomically. Either all pods in the group are bound together, or none are. For distributed training jobs, inference serving clusters, or any workload where partial scheduling creates resource waste or deadlock, this is the right primitive.

# Suspend a training job, update GPU node selector, resume
kubectl patch job ml-training-job -p '{"spec":{"suspend":true}}'
kubectl patch job ml-training-job -p '{
  "spec": {
    "template": {
      "spec": {
        "nodeSelector": {"node-type": "gpu-h100"}
      }
    }
  }
}'
kubectl patch job ml-training-job -p '{"spec":{"suspend":false}}'

The mutable scheduling directives for suspended Jobs, now enabled by default in v1.36, make this pattern practical. Suspending a job, adjusting its resource requirements to match available capacity, and resuming it is now a first-class operation rather than a workaround.

5. Volume Group Snapshots and SELinux mount relabeling reach GA: storage operations get safer and faster

Two storage features reaching GA in v1.36 address real production pain points.

Volume Group Snapshot allows crash-consistent snapshots across multiple PersistentVolumeClaims simultaneously through an atomic freeze request to the storage backend via the CSI driver. For stateful workloads where data consistency across multiple volumes matters — databases with separate data and WAL volumes, for example — this eliminates the time gap between individual snapshots that could corrupt a recovery point.

SELinux mount relabeling reaching GA is a performance fix that matters at scale. The previous behavior relabeled each inode individually on mount, which meant minutes of container startup delay on large volumes. The new approach assigns a virtual label to the entire mount point via mount -o context=..., completing in milliseconds regardless of disk size. For clusters running SELinux in enforcing mode, this is a meaningful improvement in pod startup latency.

6. Fine-grained kubelet API authorization reaches stable: node compromise blast radius shrinks

Fine-grained kubelet API authorization graduating to stable in v1.36 closes a long-standing gap in the node security model.

Previously, granting access to the kubelet API was effectively all-or-nothing. A compromised node credential implied full kubelet access. The new model allows precise control over which clients can call which kubelet endpoints. A monitoring agent that needs to read pod logs does not need the same permissions as a component that needs to manage pod lifecycle.

The practical effect is that a compromised node credential no longer implies full kubelet access. The blast radius of a node-level compromise is meaningfully contained. For clusters where node credentials are distributed broadly — edge deployments, large-scale managed clusters, environments with many node agents — this is a real security improvement.

7. Notable removals and deprecations to act on before upgrading

Two items require attention before upgrading to v1.36.

gitRepo volume: permanently disabled. Audit workloads before upgrading. There is no flag to re-enable it.

IP/CIDR validation tightening (beta): non-canonical IP formats like 010.000.001.005 and ambiguous CIDRs like 192.168.1.5/24 are now hard rejections, not warnings. If any tooling in the pipeline generates IP or CIDR values programmatically, audit it before upgrading.

Service externalIPs deprecation: the externalIPs field in Service spec is deprecated in v1.36, with removal planned for v1.43. This field has been a known security issue since CVE-2020-8554. Teams relying on it should plan migration to LoadBalancer services, NodePort, or Gateway API.

Ingress NGINX retirement: this happened on March 24, 2026, before this release, but it is worth noting for teams still running it. No further releases, no security patches. Existing deployments continue to function, but the migration clock is running.

A compact view of the release

What this release says overall

Kubernetes v1.36 is a release that pays down security debt, completes architectural stories that have been in progress for multiple cycles, and makes a clear bet on DRA as the production path for AI infrastructure.

The MutatingAdmissionPolicy graduation completes the declarative admission control story. The User Namespaces graduation gives multi-tenant clusters a production-grade isolation primitive. The DRA graduations give AI platform teams a stable foundation for GPU resource management. The gitRepo removal closes a security hole that should have been closed years ago.

None of these are individually revolutionary. Together, they describe a platform that is becoming more trustworthy, more operable, and more capable of handling the workload mix that 2026 actually demands: traditional services, batch jobs, and GPU-intensive AI workloads running side by side with strong isolation and predictable resource semantics.

Radar takeaway

Watch MutatingAdmissionPolicy if you are running webhook servers for mutation. The migration path is now clear and the operational benefits are real.

Watch DRA if you are running GPU clusters or planning AI infrastructure. The beta graduations in v1.36 make it the right foundation to build on, not a future bet.

Watch Workload Aware Scheduling in alpha. Gang scheduling for distributed workloads is a primitive that matters for serious AI training infrastructure, and v1.36 is the release where it enters the Kubernetes core.

Act on gitRepo and IP/CIDR validation before upgrading. Both are breaking changes that require cluster-specific audit work.

This Tech Radar bulletin is automatically curated by the OpenClaw AI network and technically supervised by Senior System Architect @TuanAnh. Data is extracted real-time from trusted sources.

📚 Related Reading:

• GitOps at Scale with K8s & ArgoCD