Kubernetes 1.36 Release: New Features, Stable APIs & Changes

Kubernetes v1.36, also known as "ハル (Haru)", is the first major Kubernetes release of 2026, released on April 22, 2026. In Japanese, the word “Haru” can mean many things: spring (春), clear weather (晴れ), or even a far horizon (遥か). In many ways, this release is a reflection of all these meanings.

This version brings 70 enhancements across the platform, with 18 features reaching Stable (GA), 25 moving into Beta, and 25 introduced as Alpha features. Kubernetes v1.36 is not focused on new APIs. Instead, it focuses on improving stability, simplifying operations, and making Kubernetes more reliable for real-world production use.

For us, this release is important. Features like HPA scale-to-zero, in-place pod resource resizing, workload-aware gang scheduling, and improvements in DRA for GPUs and hardware workloads make autoscaling and resource efficiency much better.

Let's walk through the major enhancements in Kubernetes v1.36.

Kubernetes v1.36 Stable Features

1. Support for User Namespaces in Pods

Feature Group: SIG Node | KEP: #127

User namespaces have finally reached General Availability (GA) in Kubernetes v1.36, after a journey that started in alpha with Kubernetes v1.25 back in August 2022.

Before this feature, running a truly rootless container in Kubernetes required third-party solutions like gVisor or Kata Containers, or accepting that a container process running as root was, in fact, root on the host node. If a container breakout happened, an attacker with UID 0 inside the container had real root-level access to the underlying node.

With Kubernetes v1.36, Kubernetes gives every Pod its own isolated user ID namespace. A process that appears to be root (UID 0) inside the container is mapped to an unprivileged user on the host. Even if someone escapes the container sandbox, they have almost no power on the node itself. You can enable this with a single field in your Pod spec.

spec:
  hostUsers: false
  containers:
  - name: app
    image: my-app

‍

This is native, stable, and production-ready. No extra tooling required. For multi-tenant clusters and any workload handling sensitive data, enabling user namespaces is now the right default choice.

2. Mutating Admission Policies (CEL-Based Mutations)

Feature Group: SIG API Machinery | KEP: #3962

Mutating Admission Policies have graduated to General Availability (GA) in Kubernetes v1.36, and this one changes how platform teams manage cluster-wide enforcement going forward.

Before this feature, if you wanted to mutate Kubernetes resources, inject default labels, enforce resource limits, and add standard annotations, you had to run a mutating admission webhook. That meant a TLS-secured HTTP server to manage, certificates to rotate, webhook latency to monitor, and failure modes that could block the entire API server if your webhook went down.

With Kubernetes v1.36, mutating admission policies bring CEL-based mutation directly into Kubernetes as native objects. No external server. No TLS. Just declarative policy objects applied directly through the API server. This also plays nicely with Server-Side Apply;  mutations merge cleanly with existing fields without overwriting user-specified values.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: set-default-resource-limits
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["pods"]
  mutations:
  - patchType: ApplyConfiguration
    applyConfiguration:
      expression: >
        Object{
          spec: Object.spec{
            containers: object.spec.containers.map(c,
              Object.spec.containers{
                resources: Object.spec.containers.resources{
                  limits: {"memory": "512Mi", "cpu": "500m"}
                }
              }
            )
          }
        }

‍

For platform teams enforcing resource governance across large clusters, this removes a whole class of operational overhead.

3. OCI VolumeSource

Feature Group: SIG Node / SIG Storage | KEP: #4639

OCI artifact volume support has reached General Availability (GA) in v1.36, and it quietly changes how you think about distributing content alongside your workloads.

Before this feature, the only way to get configuration files, model weights, WASM modules, or any artifact into a Pod alongside your application was to either bake them into the container image or use init containers and external download scripts. Both approaches bloat your images and slow down your CI/CD pipelines.

With Kubernetes v1.36, you can mount OCI registry artifacts directly as volumes in pods just like you'd mount a ConfigMap. Files stored in an OCI registry artifact are pulled at runtime and made available inside the container, completely decoupled from the application image itself.

apiVersion: v1
kind: Pod
metadata:
  name: model-serving-pod
spec:
  containers:
  - name: inference-server
    image: my-inference-server:latest
    volumeMounts:
    - name: model-weights
      mountPath: /models
      readOnly: true
  volumes:
  - name: model-weights
    image:
      reference: registry.example.com/ml-models/llm-weights:v2.1
      pullPolicy: IfNotPresent

‍

For AI/ML workloads, this is a great improvement. Teams can push model weights, Hugging Face checkpoints, or Helm chart artifacts as OCI images and swap them without rebuilding the application container. This shrinks image sizes, simplifies CI/CD pipelines, and reduces the attack surface by separating data artifacts from executable code.

4. Fine-Grained Kubelet API Authorization

Feature Group: SIG Auth / SIG Node | KEP: #2862

Fine-grained kubelet API authorization reaches General Availability (GA) in v1.36, marking a significant step forward in node-level security.

Before this feature, the kubelet API used a coarse authorization model, either a client could access node endpoints broadly or it couldn't. There was no way to precisely control which specific kubelet API endpoints an identity could call. This was a security gap, especially in multi-tenant clusters where different operators or monitoring tools needed access to specific node data without being granted broad node access.

With Kuberentes v1.36, Kubernetes introduces granular RBAC controls for individual kubelet API paths. Cluster administrators can now define exactly which identities can access which kubelet endpoints, for example, allowing a monitoring agent to query container metrics without giving it access to exec, log streaming, or other sensitive node operations.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-metrics-reader
rules:
- apiGroups: [""]
  resources: ["nodes/metrics", "nodes/stats"]
  verbs: ["get"]

‍

This is a meaningful security hardening improvement for any cluster running multiple teams or automated tooling that touches the kubelet API.

5. Node Log Query

Feature Group: SIG Node | KEP: #2258

Node Log Query has graduated to Stable in Kubernetes v1.36, and the NodeLogQuery feature gate is now locked to true by default.

Before this feature, diagnosing node-level issues, such as kubelet crashes, systemd service failures, and kernel events, required SSH access to the node or a privileged debug Pod. That's slow, risky, and often requires elevated permissions that most developers shouldn't have.

With Kubernetes v1.36, cluster administrators and operators can query system logs directly from node services using the kubelet API, without ever logging into the node.Before querying, make sure enableSystemLogQuery: true is set in your kubelet configuration.

kubectl get --raw "/api/v1/nodes/node-1/proxy/logs/?query=kubelet&sinceTime=2026-04-22T11:00:00Z"
kubectl get --raw "/api/v1/nodes/node-1/proxy/logs/?query=containerd&tailLines=100"

‍

6. CSI Volume Group Snapshots

Feature Group: SIG Storage | KEP: #3476

Volume Group Snapshots have reached the v1 stable API in Kubernetes v1.36, with the CSIVolumeGroupSnapshot feature gate now locked to enabled.

Before this feature, snapshotting stateful applications backed by multiple volumes was a manual, error-prone operation. If your database used separate volumes for data, WAL logs, and config, you had to snapshot each one independently and hope they were consistent with each other. Any gap in snapshot timing could mean a corrupt or unrestorable backup.

With Kubernetes v1.36, Volume Group Snapshots let you capture a consistent point-in-time snapshot across all volumes in a group atomically.

apiVersion: groupsnapshot.storage.k8s.io/v1
kind: VolumeGroupSnapshot
metadata:
  name: db-consistent-snapshot
spec:
  volumeGroupSnapshotClassName: csi-group-snapclass
  source:
    selector:
      matchLabels:
        app: postgres
        component: database

‍

This is a major improvement for anyone running stateful workloads with critical data integrity requirements.

7. CSI Service Account Token Secret Redaction

Feature Group: SIG Storage | KEP: #5538

CSI Service Account Token Secret Redaction graduates to Stable in v1.36. 

Before this feature, when CSI drivers requested service account tokens for workload identity, those tokens were passed through the volume_context field of NodePublishVolumeRequest. The problem is that the protosanitizer tool that CSI drivers use to sanitize gRPC logs does not treat volume_context as sensitive data. So service account tokens ended up in driver logs whenever gRPC requests were logged; exactly what happened in CVE-2023-2878 (Secrets Store CSI Driver) and CVE-2024-3744 (Azure File CSI Driver).

With Kubernetes v1.36, CSI drivers can opt in to receive service account tokens through the secrets field of NodePublishVolumeRequest instead, which IS treated as sensitive by protosanitizer. Tokens no longer leak into logs. Drivers set serviceAccountTokenInSecrets: true in their CSIDriver spec to opt in.

8. DRA AdminAccess for ResourceClaims

Feature Group: SIG Node | KEP: #5018

DRA AdminAccess for ResourceClaims reaches General Availability (GA) in v1.36.

Before this feature, there was no API-level way for platform administrators to access devices that were already allocated to running workloads. If you needed to inspect a GPU's health, run diagnostics, or monitor device status without disrupting the workload using it, you were largely out of luck at the Kubernetes API level.

With Kubernetes v1.36, ResourceClaims created in privileged (admin) mode can access devices already in use by other workloads specifically for health monitoring, status inspection, and administrative diagnostics.

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-health-monitor
  namespace: kube-system
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: gpu.nvidia.com
      adminAccess: true

‍

For platform teams managing AI/ML infrastructure, this enables non-disruptive GPU health monitoring alongside production workloads.

9. Accelerated Recursive SELinux Label Change 

Feature Group: SIG Node | KEP: #1710

Recursive SELinux label change acceleration has reached General Availability (GA) in v1.36, after being in beta since Kubernetes v1.27.

Before this feature, SELinux-enabled clusters had a serious performance problem at Pod startup: when a Pod volume was mounted with seLinuxOptions, the kubelet had to recursively chown and relabel every single file in the volume tree. For volumes with hundreds of thousands of small files (common in data processing or ML workloads), this startup delay could stretch from seconds into minutes.

With v1.36, the kubelet uses bind mounts with the correct SELinux context instead of recursively relabeling files. The volume appears with the right label immediately, without touching individual files. Pod startup that used to take multiple minutes with large data volumes now completes in seconds.

This is a direct performance improvement; no code changes are needed on the application side.

Kubernetes v1.36 Beta Features

10. HPA Scale-to-Zero 

Feature Group: SIG Autoscaling | KEP: #2021

The HPAScaleToZero feature gate first appeared in Kubernetes v1.16 back in 2019. Seven years later, it is finally enabled by default in v1.36, and this is one of the most cost-impactful changes in this release.

Before this change, the Horizontal Pod Autoscaler had one hardcoded assumption: there is always at least one replica running. Scaling to zero required external tools like KEDA, Knative, or custom controllers with event-driven triggers. Most teams either paid for always-on idle pods or built complex autoscaling infrastructure on top of Kubernetes.

With v1.36, HPA can natively scale a Deployment all the way down to zero replicas when there is no workload demand and back up when demand returns. You still need an external metric source (like KEDA or a custom metrics adapter) to tell Kubernetes when to scale from zero back to one, but the heavy lifting is now built in.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: batch-processor
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: batch-processor
  minReplicas: 0   # Now natively supported -- no extra tooling needed
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue.depth
      target:
        type: AverageValue
        averageValue: "10"

‍

For staging environments, batch workloads, ML inference services, and any workload with predictable idle windows, this is a direct cloud cost reduction. Idle pods are wasted money. Now Kubernetes treats idleness as a valid, managed state, not a failure condition.

11. DRA Partitionable Devices 

‍Feature Group: SIG Node | KEP: #4815

Partitionable device support in Dynamic Resource Allocation (DRA) advances to Beta and is enabled by default in v1.36. 

Modern GPUs like the NVIDIA A100 support MIG (Multi-Instance GPU), the ability to slice a single physical GPU into smaller, independent logical units. Before this feature, DRA treated each physical device as an atomic unit. If your workload only needed a fraction of a GPU's capacity, you still had to allocate the whole thing. This led to significant GPU waste in clusters running mixed workload sizes.

With v1.36, DRA understands partitioned devices. A single physical GPU can be advertised as multiple allocatable logical partitions, and workloads can request exactly the slice they need.

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: small-gpu-request
spec:
  devices:
    requests:
    - name: gpu-slice
      deviceClassName: mig.nvidia.com
      selectors:
      - cel:
          expression: 'device.attributes["memory"].isGreaterThan(quantity("10Gi"))'

‍

For teams running heterogeneous AI/ML workloads, this directly improves GPU utilization and reduces the cost of underused hardware.

12. Resource Health Status for DRA Devices in Pod Status 

Feature Group: SIG Node | KEP: #4680

Resource health status for DRA-allocated devices advances to Beta in v1.36.

Before this feature, when a container entered CrashLoopBackOff due to a faulty GPU or other DRA-managed device, there was no way to tell from the Kubernetes API whether the crash was caused by a hardware failure, an unhealthy device, or an application bug. You had to dig through kubelet logs and vendor-specific tooling to find out.

With v1.36, Pod status now includes health information for DRA-allocated devices. When a device is in an Unhealthy or Unknown state, that information surfaces directly in the Pod's status and is visible through standard kubectl commands.

kubectl describe pod my-gpu-pod

# Output includes device health information:
# Resource Claims:
#   Name: gpu-resource
#   Device:
#     Health: Unhealthy
#     Reason: "NVIDIA ECC error detected on device gpu-0"

‍

For platform teams managing AI/ML infrastructure, this dramatically shortens the time to root-cause GPU and accelerator failures; no more guessing why a workload keeps crashing.

13. Pod-Level In-Place Resource Resize 

Feature Group: SIG Node | KEP: #5419

Pod-level in-place resource resize advances to Beta in v1.36, extending the in-place Pod update capability (which reached GA in v1.35) to handle aggregate resource specifications at the Pod level.

Before this feature, in-place resource resize only worked at the individual container level. For Guaranteed QoS pods common in HPC, AI/ML, and NFV workloads, you often need to adjust the overall resource budget for the entire Pod, not just individual containers. Doing this still required a Pod restart.

With v1.36, you can now resize CPU and memory at the Pod level in-place for cgroupv2 environments.

apiVersion: v1
kind: Pod
metadata:
  name: data-processor
spec:
  resources:                   # Pod-level resource specification
    requests:
      cpu: "4"
      memory: "8Gi"
    limits:
      cpu: "8"
      memory: "16Gi"
  containers:
  - name: worker
    image: data-processor:latest

‍

This enables vertical scaling of pods without restarts, which is exactly what PerfectScale's right-sizing automation needs at the platform level: live resource adjustment without disruption.

Note: This feature requires four feature gates enabled together: PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, and NodeDeclaredFeatures. It only works on cgroupv2 nodes.

14. CRI List Streaming 

Feature Group: SIG Node | KEP: #5825

CRI List Streaming advances to Beta in v1.36, directly addressing memory pressure and latency spikes that appear on high-density nodes.

Before this feature, when the kubelet needed to list containers or images, it sent a single, monolithic gRPC request to the container runtime interface (CRI) and waited for a single massive response containing all the data. On nodes running hundreds of containers, these responses could be gigabytes in size, causing memory spikes in the kubelet process and noticeable latency in node management operations.

With v1.36, the kubelet uses streaming RPC calls instead. It processes container and image data incrementally as results stream in, rather than waiting for the entire response. The peak memory footprint of the kubelet drops significantly on high-density nodes, and node management responsiveness improves measurably as container counts grow.

This is a platform-level performance improvement. It works transparently once the feature is enabled by default.

15. HPA External Metrics Fallback on Retrieval Failure

Feature Group: SIG Autoscaling | KEP: #5679

HPA External Metrics Fallback advances toward Beta in v1.36.

Before this feature, if your HPA relied on an external metric, a cloud queue depth, a Datadog metric, a Prometheus query via a custom adapter, and that metric source returned an error or went down, the HPA froze completely. It stopped making scaling decisions. For availability-sensitive workloads, that is exactly the wrong time to stop autoscaling.

With v1.36, you can configure a fallback value directly on the HPA metric spec. When the external metric cannot be retrieved, the HPA uses the configured fallback value instead of halting. The workload keeps scaling based on a safe default rather than being left in a frozen state during a metrics outage.

For any team relying on external metrics from Datadog, cloud provider queues, or custom metrics servers, this removes one of the most common causes of silent autoscaling failures during infrastructure incidents.

Kubernetes v1.36 Alpha Features

16. Workload-Aware Scheduling (WAS) and Gang Scheduling

Feature Group: SIG Scheduling / SIG Apps | KEP: #5832, #5710

Kubernetes v1.36 introduces a suite of Workload-Aware Scheduling (WAS) features in Alpha, building on the gang scheduling foundation introduced in v1.35. This natively integrates the Job controller with a revised Workload API and a new decoupled PodGroup API.

Before this work, Kubernetes scheduled Pods one by one, with no awareness that a set of Pods belonged to the same distributed job. For tightly coupled workloads, distributed ML training, MPI jobs, and batch processing, this caused partial scheduling: some workers started while others stayed pending. Partially started jobs wasted CPU and GPU resources while blocking other workloads from getting scheduled.

With v1.36, Kubernetes treats related Pods as a single logical entity. The scheduler holds the entire group and only places Pods when the required minimum can all run together. If the cluster can't satisfy the requirement, none of the Pods are bound.

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: distributed-training-group
spec:
  minMember: 8            # All 8 workers must be schedulable before any starts
  minResources:
    cpu: "32"
    memory: "128Gi"
    nvidia.com/gpu: "8"

apiVersion: v1
kind: Pod
metadata:
  name: trainer-0
  labels:
    scheduling.x-k8s.io/pod-group: distributed-training-group
spec:
  containers:
  - name: trainer
    image: pytorch-training:latest
    resources:
      requests:
        cpu: "4"
        memory: "16Gi"
        nvidia.com/gpu: "1"

‍

For AI/ML teams running distributed training jobs, this eliminates deadlock scenarios and resource waste from partial job placement.

17. Server-Side Sharded Watch and List 

Feature Group: SIG API Machinery | KEP: #5866

Server-Side Sharded Watch and List is introduced as an Alpha feature in v1.36, addressing a fundamental scalability challenge for horizontally scaled controllers.

Before this feature, all horizontally scaled controllers (operators with multiple replicas for high availability) received the full stream of every Kubernetes event for the resource types they watched. Even if you ran 10 controller replicas, each one processed 100% of all events, with coordination logic handling deduplication. This created redundant API server load and network overhead.

With v1.36, clients can request a filtered LIST/WATCH stream based on hash ranges. The API server filters events at the source, so each controller replica only receives the events it is responsible for.

# Controller replica 1 watches the first half of objects (by hash of UID)
GET /api/v1/pods?watch=true&shardSelector=shardRange(object.metadata.uid,'0x0000000000000000','0x8000000000000000')

# Controller replica 2 watches the second half
GET /api/v1/pods?watch=true&shardSelector=shardRange(object.metadata.uid,'0x8000000000000000','0xFFFFFFFFFFFFFFFF')

‍

For large clusters with many controllers and high object counts, this directly reduces API server load and controller memory usage.

18. Resource Pool Status Request API 

Feature Group: SIG Node / DRA | KEP: #5677

The Resource Pool Status Request API is introduced as an Alpha feature in v1.36, solving a visibility gap in how cluster operators understand DRA device availability.

Before this feature, users with limited permissions had no API-level way to understand how many GPUs or other DRA-managed devices were available versus allocated in the cluster. There was no equivalent of kubectl top nodes for DRA device capacity. Platform teams had to rely on vendor-specific tooling or cluster-admin-level queries to answer "how many GPUs are free right now?"

With v1.36, any user can create a ResourcePoolStatusRequest object to query device pool availability. A controller in kube-controller-manager watches for requests, computes availability, and writes results back to the object's status.

# Create a request to check GPU availability across the cluster
kubectl create -f - <<EOF
apiVersion: resource.k8s.io/v1alpha1
kind: ResourcePoolStatusRequest
metadata:
  name: check-gpu-availability
spec:
  driver: gpu.nvidia.com
EOF

# Read the result
kubectl get resourcepoolstatusrequest check-gpu-availability -o yaml
# Status shows per-pool available/allocated/total device counts

‍

For capacity planning and cost reporting in AI/ML clusters, this gives platform teams the visibility they need without requiring elevated cluster permissions.

19. Stale Controller Mitigation 

Feature Group: SIG API Machinery | KEP: #5647

Stale Controller Mitigation is introduced as an Alpha feature in v1.36.

Before this feature, the kube-controller-manager's internal informer cache could become stale under certain conditions, such as etcd slowdowns, apiserver restarts, or high cluster churn. When the cache was stale, controllers would make reconciliation decisions based on outdated state, potentially creating incorrect or duplicate objects without knowing the current cluster truth.

With v1.36, Kubernetes adds metrics and read-your-own-write semantics for key controllers to detect when their informer cache is lagging behind actual cluster state. When staleness is detected, the controller can pause reconciliation or take corrective action rather than acting on stale data. This improves reliability for Deployments, StatefulSets, and other core workload controllers during high-load scenarios.

Deprecations and Removals

20. gitRepo Volume Plugin

The gitRepo volume plugin, deprecated since Kubernetes v1.11, has been permanently disabled in v1.36 (KEP #5040). This volume type cloned Git repositories directly into Pods, but carried a critical security vulnerability: arbitrary code execution as root on the underlying node. It can no longer be re-enabled via feature gate.

So, consider migrating to init containers that run your own git clone logic, or use OCI volumes (now stable in v1.36) to distribute repository content as artifacts. Any workloads still using gitRepo volumes will fail to start after upgrading to v1.36.

21. IPVS Mode in kube-proxy 

IPVS mode in kube-proxy, deprecated in Kubernetes v1.35, is removed in v1.36. Kubernetes now officially recommends iptables mode or eBPF-based CNI implementations for cluster networking.

Check your kube-proxy configuration before upgrading. If you are running mode: ipvs, switch to mode: iptables or evaluate eBPF-based networking solutions like Cilium.

22. Ingress-NGINX 

While not a Kubernetes core removal, SIG Network and the Security Response Committee officially retired the Ingress-NGINX project on March 24, 2026. There will be no further releases, no bug fixes, and no security patches. Existing deployments continue to work, but any team relying on Ingress-NGINX in production should plan a migration to the Gateway API or an actively maintained ingress controller.

Kubernetes v1.36 "Haru" ships 70 enhancements. Of these, 18 are now Stable (GA), 25 are entering Beta, and 25 are new Alpha features. Beyond the highlights covered here, there are important security hardening improvements, storage reliability fixes, and networking refinements across the release.

We encourage you to review the full Kubernetes v1.36 release notes and the complete CHANGELOG-1.36.md for the full picture before upgrading.