Technical Insight Explanation

Kubernetes 1.36 - (Haru): What changes for production

Explore Kubernetes 1.36: key features, deprecations and operational changes, with practical considerations for your next cluster upgrade.

Kubernetes 1.36 - (Haru)
On this page

Kubernetes 1.36 “Haru”: Production Maturity, Stronger Isolation, and Workload-Aware Scheduling

Executive summary

Kubernetes 1.36, ハル (Haru), delivers 70 enhancements: 18 graduating to Stable, 25 entering Beta, and 25 graduating to Alpha. The release emphasizes production maturity across authentication, storage, node isolation, Dynamic Resource Allocation (DRA), observability, and scheduling, while also introducing important removals and upgrade actions.

The official theme connects Haru with spring, clear skies, and distant horizons. Inspired by Hokusai’s Fine Wind, Clear Morning, the release logo depicts Red Fuji, the Kubernetes helm, and two guardian cats, Stella and Nacho, alongside the calligraphy 晴れに翔け—“soar into clear skies.” See the official Kubernetes 1.36 release announcement for the complete theme and artwork description.

Key highlights and graduations

Security, authentication, and authorization

Stable: Fine-grained kubelet API authorization

The KubeletFineGrainedAuthz feature is now generally available. It replaces the need to grant the broad nodes/proxy permission for many monitoring and observability scenarios with more precise authorization over the kubelet HTTPS API.

For production clusters, this enables a stronger least-privilege model for monitoring agents, support tooling, and other clients that communicate with kubelets. The feature was Beta and enabled by default in Kubernetes 1.33 before reaching GA in 1.36.

Stable: External signing of ServiceAccount tokens

External ServiceAccount token signing is now a supported production option. Kubernetes can delegate projected ServiceAccount JWT signing to an external system while the API server discovers and caches public keys and validates externally signed tokens.

This is particularly relevant to platforms that centralize identity, signing, or key management. It reduces the need to maintain ServiceAccount signing keys directly within the control plane while preserving existing authentication and authorization flows.

Stable: User namespaces for Pods

User namespace support for Pods graduates to Stable. A container’s root user can be mapped to a non-privileged user on the host, adding defense in depth if a process escapes its container boundary.

The practical impact is strongest for multi-tenant clusters and other environments that require hardened workload isolation. Operators can now adopt this capability with GA-level API stability.

Beta: Constrained impersonation

The ConstrainedImpersonation feature reaches Beta. When enabled, an impersonating principal needs both permission to impersonate an identity and permission to perform the requested action on that identity’s behalf.

Existing impersonate rules continue to work, while the API server prefers the new constrained checks first. Platform teams using impersonation for support access, debugging tools, proxying, or node-level controllers should evaluate the feature as a way to reduce the consequences of overly broad impersonation RBAC.

Stable: DRA administrative access

Administrative access for DRA ResourceClaim and ResourceClaimTemplate resources reaches GA. Together with Stable prioritized alternatives in device requests, this gives administrators a durable mechanism for applying global hardware-management policies and predictable resource-selection behavior.

API machinery and control-plane architecture

Stable: Mutating admission policies

MutatingAdmissionPolicies graduates to Stable. Administrators can use Common Expression Language (CEL) policies in the API server to mutate incoming requests without deploying an external admission webhook for many common scenarios.

This can reduce webhook network dependencies, latency, and operational overhead. Mutation logic can instead be managed as declarative, versioned policy with GA-level stability.

Stable: Declarative validation with validation-gen

Declarative validation for native Kubernetes types using validation-gen reaches Stable. Kubernetes contributors can define validation rules through IDL marker comments such as +k8s:minimum and +k8s:enum in Go API type definitions.

The generator produces validation code at compile time, helping keep validation synchronized with the source types and reducing manually maintained validation logic.

Stable: Removal of the gogoprotobuf dependency

Kubernetes has completed the removal of the unmaintained gogoprotobuf runtime dependency for Kubernetes API types. The required generation logic is internalized in k8s.io/code-generator, preserving existing API behavior and serialization compatibility.

Consumers of Kubernetes API Go types should still review the official Kubernetes 1.36 changelog , especially if their code directly interacts with generated serialization behavior.

Beta: Controller staleness mitigation

Kubernetes 1.36 introduces Beta mechanisms to reduce controller reconciliation against stale cached state and improve visibility into controller behavior. This targets failure modes in which stale assumptions lead to conflicting updates or data corruption.

Controller authors should assess whether their reconciliation logic can use the new safeguards. Exact integration requirements should be verified against the full changelog and Kubernetes documentation.

Beta: Mixed-version API proxy

The mixed-version proxy, also known as the unknown-version interoperability proxy, reaches Beta. During mixed-version control-plane upgrades, an API request can be routed to an API server that serves the requested group, version, and resource.

The feature uses peer-aggregated discovery and adds metrics for rerouted traffic. This is intended to reduce request failures and 404 responses during multi-step or partial upgrades of highly available control planes.

Alpha: Manifest-based admission configuration

Manifest-based admission control configuration enters Alpha. It provides a structured, declarative model for configuring admission plugins rather than relying only on disparate command-line flags or separate configuration files.

Alpha features are not a commitment to production stability. Validate behavior, feature-gate requirements, and rollback procedures before testing them outside isolated environments.

Storage

Stable: Volume group snapshots

VolumeGroupSnapshot support is now GA. The extension APIs allow crash-consistent snapshots to be taken across multiple PersistentVolumeClaims at the same time and later restored to new volumes from a common recovery point.

This is valuable for stateful applications whose consistency boundary spans several volumes. Storage-driver and extension-API support remain necessary and should be validated before adoption.

Stable: Mutable CSI node allocatable limits

Mutable CSINode allocatable capacity reaches Stable. CSI drivers can dynamically update the maximum number of volumes a node can handle, and the kubelet can refresh that information periodically or in response to resource-exhaustion errors without requiring a component restart.

This gives the scheduler a more current view of storage capacity and reduces placement failures caused by stale attachment limits.

Stable: Faster SELinux labeling for volumes

SELinux volume-mount improvements are now GA. Instead of recursively relabeling files, Kubernetes can use the mount -o context=XYZ mechanism to apply the label at mount time, improving consistency and reducing Pod startup delays on SELinux-enforcing systems.

The behavior now defaults to all volumes, with Pods or CSI drivers opting in through spec.seLinuxMount. Workload authors are responsible for correctly setting securityContext.seLinuxChangePolicy and Pod SELinux labels. Incorrect settings can prevent Pods from starting when a volume is shared, particularly across privileged and unprivileged workloads.

Kubernetes 1.36 is therefore an important point at which to audit:

  • Pod and Pod-template SELinux settings;
  • securityContext.seLinuxChangePolicy;
  • CSI driver spec.seLinuxMount behavior;
  • volumes shared by workloads with different privilege or labeling requirements.

Other Stable storage graduations

The release’s complete GA list also includes:

  • Portworx in-tree-to-CSI migration;
  • CSI driver opt-in for ServiceAccount tokens through the secrets field.

Implementation-specific migration and compatibility details should be confirmed in the official changelog .

Node and resource management

Beta: Resource health status

The allocatedResourcesStatus field in Pod status reaches Beta and provides health reporting for allocated specialized devices. Administrators can use kubectl describe pod to determine whether a container failure is associated with an Unhealthy or Unknown device status.

The mechanism covers hardware allocated through traditional device plugins and DRA, improving diagnosis and automated recovery for GPU, accelerator, and other hardware-dependent workloads.

Stable: Pressure Stall Information on cgroup v2

Pressure Stall Information metrics for CPU, memory, and I/O graduate to Stable on cgroup v2 nodes. PSI helps distinguish a system that is merely busy from one whose workloads are actively stalling because of resource contention.

Operators can use these signals to improve workload sizing, vertical autoscaling analysis, and noisy-neighbor detection.

Stable: OCI image and artifact volume source

OCI volume sources reach Stable. The kubelet can pull and mount read-only content from an OCI-compliant registry, allowing application data, models, and static assets to use the same packaging, versioning, and registry workflows as container images.

This can simplify delivery pipelines for read-only content and reduce the need for a separate storage backend in suitable use cases.

Stable: Node log query

Node log query reaches GA and is enabled by default through the NodeLogQuery kubelet feature gate. The feature supports retrieving node-service logs through the kubelet API and a kubectl plugin, reducing the need for direct SSH access in some troubleshooting scenarios.

Two operational requirements remain:

  • services or nodes must write logs under /var/log;
  • the kubelet configuration option enableSystemLogQuery must also be enabled.

Some node failures will still require direct host access.

Beta: Memory QoS on cgroup v2

Memory QoS improvements for Linux cgroup v2 nodes refine how the kubelet programs memory.high and memory.min. The release also adds metrics, livelock safeguards, and configuration options for tuning memory protection.

Operators should validate the new behavior under representative memory pressure before changing production resource-management policies.

Alpha: CRI list streaming

CRI list streaming enters Alpha. New internal streaming operations allow the kubelet to process container or image list results incrementally rather than waiting for a single large response from the container runtime.

The intended impact is lower peak kubelet memory usage and reduced latency on high-density nodes.

Scheduling, workloads, and DRA

Alpha: Workload-Aware Scheduling

Kubernetes 1.36 introduces a suite of Alpha Workload-Aware Scheduling capabilities. These integrate the Job controller with a revised Workload API and a decoupled PodGroup API so that related Pods can be treated as one logical scheduling unit.

The new PodGroup scheduling cycle can evaluate a group atomically: either all Pods in the group are bound together or none are. This extends the earlier gang-scheduling model, which focused on ensuring that a minimum number of Pods were schedulable before binding began.

The feature targets distributed computing, AI, HPC, and batch workloads, but its Alpha status makes it appropriate for controlled evaluation rather than general production adoption.

Beta: Mutable resources for suspended Jobs

MutablePodResourcesForSuspendedJobs reaches Beta and is enabled by default. Container CPU, memory, GPU, and extended-resource requests and limits can be changed while a Job is suspended.

Queue controllers can therefore suspend a Job, adapt its resource requirements to current capacity or quota, and then resume it. Mutability is restricted to suspended Jobs, or Jobs whose Pods have terminated following suspension, to avoid disruptive changes to running Pods.

Beta: DRA expansion

Several DRA capabilities graduate to Beta and are enabled by default, including:

  • partitionable devices;
  • consumable capacity;
  • device taints and tolerations;
  • ResourceClaim device status;
  • ensuring device attachment before Pod scheduling;
  • integration with extended resources.

The release blog describes this as a production-ready alternative to the legacy device-plugin model for sophisticated AI and HPC resource management. Operators should nevertheless verify driver readiness, RBAC, and patch-level fixes before broad deployment.

Alpha: Additional DRA capabilities

Alpha DRA work includes:

  • native ResourceClaim support for workloads;
  • DRA-native resources for CPU-management flexibility;
  • exposing resource attributes through the downward API;
  • improved resource-availability visibility;
  • list types in device attributes.

Networking

Beta: Strict IP and CIDR validation

StrictIPCIDRValidation reaches Beta. It tightens validation for API fields containing IP addresses and CIDR prefixes, reducing malformed values in Services, Pods, NetworkPolicies, and other resources.

Controllers canonicalize IP addresses they write and warn when they encounter invalid values already stored in the API. Operators should investigate these warnings before stricter validation exposes latent configuration defects.

Ingress NGINX retirement

Ingress NGINX was retired on March 24, 2026. Existing deployments continue to function, and installation artifacts remain available, but the project no longer receives releases, bug fixes, or security-vulnerability updates.

This is a community lifecycle change rather than a Kubernetes API removal, but it has significant security implications. Organizations still operating Ingress NGINX should plan and validate a replacement.

Observability and CLI

Beta: Component /statusz

The ComponentStatusz feature gate reaches Beta and is enabled by default across core control-plane components and node agents. The /statusz endpoint exposes details including:

  • component start time and uptime;
  • Go and binary versions;
  • emulation version;
  • minimum compatibility version.

It provides human-readable output and a structured config.k8s.io/v1beta1 representation through content negotiation. Access is granted to the system:monitoring group.

Beta: Component /flagz

The ComponentFlagz feature also reaches Beta and is enabled by default. The /flagz endpoint exposes effective component command-line flags in human-readable or structured config.k8s.io/v1beta1 form.

Access is granted to system:monitoring, and sensitive values can be redacted. This provides a direct way to verify whether a configuration rollout took effect after component restart.

Beta: Separate kubectl preferences in .kuberc

The .kuberc feature remains Beta and enabled by default. The ~/.kube/kuberc file separates personal aliases and default flags from kubeconfig files containing cluster endpoints and credentials.

Kubernetes 1.36 adds policies for credential plugins, including allowlists and denylists. The functionality can be disabled with either:

  • KUBECTL_KUBERC=false;
  • KUBERC=off.

Alpha: Native histograms

Native histogram support for Kubernetes metrics enters Alpha. Core components can export sparse histograms whose resolution adapts to observed data, avoiding some of the accuracy-versus-cardinality trade-offs of fixed Prometheus histogram buckets.

Autoscaling

Alpha: HPA scale to zero

The HPAScaleToZero feature remains Alpha and disabled by default. It allows the HorizontalPodAutoscaler to scale a workload to zero when using Object or External metrics and to scale it back up when those metrics indicate new demand.

Because the capability is feature-gated and Alpha, operators should treat it as an experimental cost-optimization mechanism.

Deprecations, removals, and breaking changes

Service .spec.externalIPs is deprecated

The Service API field .spec.externalIPs is deprecated in Kubernetes 1.36. It remains functional, but API users receive deprecation warnings, and removal is planned for Kubernetes 1.43.

The field has security concerns associated with traffic interception. Depending on the use case, the release announcement recommends planning migration to:

  • LoadBalancer Services for cloud-managed ingress;
  • NodePort for simple port exposure;
  • Gateway API for more flexible external traffic handling.

Inventory all Services that depend on .spec.externalIPs and begin migration before the field is removed.

The gitRepo volume driver is permanently disabled

The gitRepo volume type, deprecated since Kubernetes 1.11, is permanently disabled in 1.36 and cannot be re-enabled. The removal addresses a security issue that could allow code execution as root on a node.

Workloads using gitRepo volumes must migrate before upgrading. Supported patterns identified by the release announcement include:

  • cloning through an init container;
  • using an external git-sync-style tool.

Direct access to metav1.FieldsV1.Raw is deprecated

Code that directly constructs or reads metav1.FieldsV1.Raw should migrate to the following accessors:

  • NewFieldsV1(string);
  • GetRawBytes();
  • GetRawString();
  • SetRawBytes().

This primarily affects Kubernetes API clients, controllers, and other Go integrations.

Credential-plugin allowlist field rename

AllowlistEntry.Name has been renamed to AllowlistEntry.Command in the credential-plugin allowlist. Review .kuberc credential-plugin policies and any tooling that generates them.

Kubeadm no longer integrates FlexVolume setup

Kubeadm’s integrated support for FlexVolume has been removed. Users were advised to migrate away from FlexVolume beginning with Kubernetes 1.22.

Clusters that must temporarily retain FlexVolume require all of the following before upgrading:

  • a custom kube-controller-manager image not based on distroless;
  • the kube-controller-manager flag --flex-volume-plugin-dir;
  • a mount for /usr/libexec/kubernetes/kubelet-plugins/volume/exec in the kube-controller-manager static Pod, configured through kubeadm extraVolumes.

Kubeadm no longer creates that mount automatically merely because the flag is present.

Monitoring metric renames

Two metric changes require dashboard and alert updates:

Previous metricKubernetes 1.36 metric
volume_operation_total_errorsvolume_operation_errors_total
etcd_bookmark_countsetcd_bookmark_total

Search monitoring rules, recording rules, dashboards, and SLO definitions for the old names before upgrading.

Scheduler PreBind plugin interface change

The scheduler framework can now run PreBind plugins in parallel. Plugin implementations must return PreBindPreFlightResult from PreBindPreFlight.

A plugin opts into parallel execution by returning AllowParallel: true. Returning nil preserves sequential behavior. Operators using custom scheduler plugins must ensure those plugins are compatible with the updated interface before deploying Kubernetes 1.36 schedulers.

DRA status authorization changes

When the Beta DRAResourceClaimGranularStatusAuthorization feature gate is enabled, DRA drivers, schedulers, and controllers need more granular RBAC permissions:

  • schedulers and controllers require update or patch on resourceclaims/binding;
  • DRA drivers require associated-node:update or arbitrary-node:update, or the corresponding patch permissions, on resourceclaims/driver;
  • driver permissions must be restricted through the relevant resourceNames.

Clusters using DRA should review these permissions before enabling the gate or upgrading an environment in which it is already active.

Upgrade impact and operational notes

The supplied release sources do not define a universal control-plane and worker-node upgrade sequence or new minimum host, container-runtime, or operating-system versions. Follow the procedures for your cluster lifecycle tool or managed Kubernetes provider and verify them against the Kubernetes documentation .

Before upgrading the control plane

  1. Read the v1.36.0 Urgent Upgrade Notes in the official changelog .
  2. Update dashboards and alerts for the two renamed metrics.
  3. Validate custom scheduler PreBind plugins against the new PreBindPreFlightResult interface.
  4. Review API clients that directly access metav1.FieldsV1.Raw.
  5. Review credential-plugin policies for the AllowlistEntry.Command rename.
  6. If using DRA, verify granular ResourceClaim status RBAC.
  7. If using kubeadm with FlexVolume, migrate or implement the documented custom kube-controller-manager requirements before the upgrade.
  8. Consider the Beta mixed-version proxy when planning a highly available, mixed-version API-server rollout, but verify its exact configuration in the official documentation.

The Kubernetes 1.36 changelog also records an etcd client-library update to v3.6.8; the supplied sources do not state a new minimum external etcd version, so no external dependency requirement should be inferred from that library change alone.

Before upgrading workers

  1. Remove any use of gitRepo volumes; they cannot be re-enabled in 1.36.
  2. Audit SELinux volume labeling, especially shared volumes and Pod templates used by Deployments, StatefulSets, DaemonSets, and custom resources.
  3. Validate cgroup v2 behavior before relying on Stable PSI metrics or Beta Memory QoS.
  4. Confirm CSI driver behavior for mutable node attachment limits, volume group snapshots, SELinux mounts, and ServiceAccount token integration.
  5. For node log query, remember that NodeLogQuery is enabled by default but enableSystemLogQuery must also be enabled and logs must be available under /var/log.
  6. For DRA workloads, verify driver compatibility and review the full maintenance changelog for fixes related to scheduling, allocation, and kubelet resource preparation.

Workload and platform checks

  • Inventory Services using .spec.externalIPs.
  • Migrate away from the retired Ingress NGINX implementation.
  • Test stricter IP/CIDR validation against existing manifests and stored objects.
  • Validate suspended-Job resource mutation with queue controllers.
  • Treat Workload-Aware Scheduling, HPA scale-to-zero, CRI list streaming, native histograms, manifest-based admission configuration, and Alpha DRA additions as experimental.
  • Use kubectl describe pod when investigating whether a crash-looping hardware-dependent container has an Unhealthy or Unknown allocated device.

Conclusion

Kubernetes 1.36 is a broad maturity release. Its most immediate production benefits come from GA user namespaces, fine-grained kubelet authorization, external ServiceAccount token signing, mutating admission policies, volume group snapshots, mutable CSI limits, PSI metrics, OCI volume sources, and stronger SELinux volume-mount behavior. At the same time, Workload-Aware Scheduling, expanded DRA, richer component diagnostics, and stricter network validation show where the platform is heading next.

The upgrade requires deliberate preparation: remove gitRepo volumes, address FlexVolume usage, update renamed metrics, audit SELinux settings, migrate away from Service .spec.externalIPs, and validate custom scheduler and DRA integrations.

Official resources

Related Articles

Stay ahead

Get the latest insights.

Insights on cloud, AI and open source — delivered to your inbox.

Email subscriptions are coming soon.