EnDe
Contact us
Home
Contact us
blog-logo

Kubernetes 1.36: Deep dive into new alpha features

8 April 2026
By Kirill Kononovich, technical writer
Kubernetes v1.36 release

The Kubernetes 1.36 release, scheduled for April 22nd, introduces a diverse set of new alpha features focused on three core areas: workload performance, API scalability, and efficient resource usage. This update brings many cool, long-awaited features, including workload-aware preemption for AI/ML jobs, sharded API streams for large-scale clusters, and deep integration of Dynamic Resource Allocation (DRA) into the scheduler.

Our overview covers 20 new enhancements, added to Kubernetes as alpha features (i.e. disabled by default), from node-level gRPC APIs to graceful leader transitions, that provide a glimpse into the future of container orchestration.

Note: We do our best to announce the actual changes. However, given the ever-changing nature of the Kubernetes feature landscape, some of the Kubernetes Enhancement Proposals (KEPs) discussed in this article may be removed from the milestone as the release date approaches.

Nodes

DRA: Device Attributes in Downward API

  • KEP #5304 (issue)
  • Feature gate: none. The framework provides a boolean flag (e.g., --enable-device-metadata) that drivers integrate into their CLI.

KEP-5304 introduces a standard way for a DRA driver to populate device metadata. The framework then automatically passes this metadata into the container by mounting it as a JSON file at a specified path. This means you no longer have to invent custom controllers to do this or have your workloads query the Kubernetes API directly just to get these details.

In the current version of DRA, to get information about allocated devices (e. g., PCIe bus addresses for GPUs or UUIDs for mediated devices), you have to read the ResourceClaim‘s status, find the matching ResourceSlice, and then parse the attributes. Obviously, it’s a pain. KEP-5304:

  • allows the DRA driver to hand over the device metadata directly in PrepareResourceClaims;
  • lets kubelet then write this data to a JSON file and mount it into the container at a specified path.

As a result, the application inside the container just needs to read a file like /var/run/dra-device-attributes/{claimName}/{requestName}/{driverName}-metadata.json to get all the device attributes it needs.

New kubelet gRPC API with endpoint returning local pods information

Currently, to get a Kubernetes Pod’s latest status (to determine whether it’s ready, its IP address, and its labels), components running on the same node (e.g., CNI plugins or monitoring agents) must query the Kubernetes API server. This causes various problems. For example, related to:

  • reliability: if a node loses connectivity to the control plane, local components won’t be able to retrieve up-to-date Pod information, even though this information is available via the locally running kubelet;
  • scalability: lots of requests from agents on every node create extra load on the API server;
  • latency: a network call to the API server is always going to be slower than a local call on the node.

The KEP authors propose a new Pods’ gRPC API that will run directly on the node:

  • This API will be accessible via a UNIX socket at /var/lib/kubelet/pods/kubelet.sock.
  • For security reasons, only privileged users or processes will be able to access the socket file.
  • The API will return the most recent Pod information available to the kubelet, even if it has not yet been synced with the API server.
  • Clients will be able to request either the full Pod specification and status (PodSpec and PodStatus) or specific fields using google.protobuf.FieldMask.

The new API features three primary methods: ListPods, GetPod, and WatchPods (streams updates as Pod states change).

CRI List Streaming

Sometimes, the kubelet needs to retrieve a list of all containers on a node (e.g., for garbage collection). To do so, it sends a CRI request, such as ListContainers. The problem is that existing CRI RPC calls are unary, meaning the client (kubelet) sends a single request, and the server (container runtime) returns a single response containing the complete list of all requested objects. On busy nodes with thousands of containers running at once (say, from lots of short-lived CronJobs), this list can exceed 16 MB, the default maximum message size in gRPC. It turns out that you’re likely to hit that limit with just 11,000 containers (or 14,000 Pods).

To avoid breaking backward compatibility by changing the existing unary calls, this KEP adds new server-side streaming RPCs. When the container runtime gets a streaming call, it doesn’t build the whole response in memory. Instead, it opens a gRPC stream and sends a StreamContainersResponse for each container one by one. kubelet reads from this stream until it’s closed. A special wrapper function then gathers all the pieces into a single list in memory before passing it on for further processing.

DRA: Resource Availability Visibility

As a developer, you might want to see which DRA resources are free in your Kubernetes cluster to troubleshoot a Pod that fails to schedule due to “insufficient DRA resources.” Alternatively, as an administrator, you might need to know how many GPUs are available to plan for future capacity. This is currently challenging for several reasons:

  • ResourceSlices are cluster-scoped and only show the total capacity of devices in a pool.
  • ResourceClaims are namespaced and track specific resource allocations. 
  • Users with limited permissions cannot view ResourceClaims outside their own namespace.
  • There is no API-level mechanism to view the ratio of available/allocated capacity.

This KEP adds a ResourcePoolStatusRequest API that follows the CertificateSigningRequest pattern:

  1. A user creates a ResourcePoolStatusRequest object, specifying a driver (mandatory) and a pool filter (optional).
  2. A controller in the kube-controller-manager watches for new requests and picks them up.
  3. The controller then calculates the pool’s availability and writes the result to the object’s status field.
  4. The user reads the status to determine the pool’s availability.
  5. To get an update, the user must delete the old request and create a new one.

Example for viewing the status of a DRA device pool. Create a request to check the status of all GPU pools and wait for it to complete:

$ kubectl create -f - <<EOF
apiVersion: resource.k8s.io/v1alpha1
kind: ResourcePoolStatusRequest
metadata:
  name: check-gpus-$(date +%s)
spec:
  driver: example.com/gpu
EOF
resourcepoolstatusrequest.resource.k8s.io/check-gpus-1707300000 created

$ kubectl wait --for=condition=Complete rpsr/check-gpus-1707300000 --timeout=30s
resourcepoolstatusrequest.resource.k8s.io/check-gpus-1707300000 condition met

View the results:

$ kubectl get rpsr/check-gpus-1707300000 -o yaml
apiVersion: resource.k8s.io/v1alpha1
kind: ResourcePoolStatusRequest
metadata:
  name: check-gpus-1707300000
spec:
  driver: example.com/gpu
status:
  observationTime: "2026-02-07T10:30:00Z"
  pools:
  - driver: example.com/gpu
    poolName: node-1
    nodeName: node-1
    totalDevices: 4
    allocatedDevices: 3
    availableDevices: 1
  - driver: example.com/gpu
    poolName: node-2
    nodeName: node-2
    totalDevices: 4
    allocatedDevices: 1
    availableDevices: 3
  conditions:
  - type: Complete
    status: "True"
    reason: CalculationComplete
    lastTransitionTime: "2026-02-07T10:30:00Z"

Pod Level Resource Managers

  • KEP #5526 (issue)
  • Feature gate: PodLevelResources and PodLevelResourceManagers

KEP-2837 made it possible to specify a unified resource budget (CPU, memory, etc.) for an entire Pod rather than per-container. This is really useful for Guaranteed QoS Pods, especially in HPC, AI/ML, and NFV workloads. The problem is that the current resource managers only operate at the container level, so they don’t know how to use pod.spec.resources to make NUMA alignment decisions.

With a newly introduced KEP-5526, the user can now select one of two resource management models (both support Guaranteed QoS Pods that may contain a mix of Guaranteed and non-Guaranteed containers):

  1. Pod Scope. The Topology Manager will assign a single resource pool from one NUMA node to the entire Pod, using pod.spec.resources as a guide. The CPU and Memory managers will then allocate exclusive segments from this pool for containers with specific Guaranteed requests, while the remainder will be available to a shared pool for all other containers.
  2. Container Scope. Resources will still be managed for each container individually, so pod.spec.resources will be ignored for placement decisions.

This approach gives you a lot of flexibility. The first model is perfect for workloads where you want all containers on the same NUMA node (like an ML training container with its sidecars for logging, data ingestion, and monitoring). The key advantage of the second model is that you can independently manage containers with different resource requirements within a single Guaranteed Pod. In this scenario, a Guaranteed container will receive exclusive, NUMA-aligned resources, while non-Guaranteed containers in the same Pod can run in the node’s shared resource pool. This was not previously possible, as all containers in a Pod had to be of the Guaranteed class for any single one of them to be able to use NUMA-aligned resources.

Scheduling

Workload-aware preemption

The Kubernetes scheduler can initiate preemption, the forced removal of one or more lower-priority Pods, when resources are scarce to schedule a high-priority Pod. The problem is, it does this on a Pod-by-Pod basis. However, workloads, particularly in AI/ML and HPC, often consist of a group of tightly-coupled Pods (e.g., for distributed model training). If even one Pod from such a group is preempted, the whole job stalls and just sits there wasting resources until that Pod comes back.

KEP-5710 brings in “workload-aware preemption.” This means that groups of related Pods (PodGroups) are now treated as a single entity for both scheduling and preemption. Rather than removing Pods one by one, the scheduler will figure out if it can make room for a whole high-priority group by preempting other, less important groups in their entirety.

A new DisruptionMode field is being added to the GangSchedulingPolicy to control whether Kubernetes can preempt individual Pods or if it has to preempt the whole group at once (PodGroup). Also, a PriorityClassName field is being added to the PodGroupSpec to set a priority for the entire group — it will be used for all scheduling and preemption decisions. This group priority takes precedence over any individual pod priorities. This KEP builds on the foundations recently introduced in KEP-4671 (Gang Scheduling support in Kubernetes).

Topology-aware workload scheduling

This KEP also builds on the ideas from KEP-4671 (Gang Scheduling Support) and the abovementioned KEP-5710. The classic Kubernetes scheduler makes scheduling decisions for each Pod individually. This is not always optimal for groups of interconnected Pods, as it makes sense to place them on the same node or at least on nodes that are close together to cut down on latency.

This new KEP-5732 makes the scheduler “topology-aware.” You can now tell it to place a group of Pods together within a certain area, or “topological domain,” defined by a common label (such as topology.kubernetes.io/rack).

DRA: List Types for Attributes

KEP-5491 updates the DRA API to handle more complex hardware setups. Previously, device attributes in a ResourceSlice could only have scalar values (string, number, boolean). That meant you couldn’t describe devices with multiple connections, such as a CPU connected to several PCIe buses.

Device drivers can now provide attributes in a ResourceSlice that contain lists of strings, numbers, or versions. The logic for processing resource requests in a ResourceClaim has also been updated:

  • matchAttribute now just needs the lists to have at least one value in common (non-empty intersection) — no need for a perfect match;
  • distinctAttribute now requires the lists to have nothing in common with each other (pairwise disjointness), instead of every value being unique across the board.

For example, suppose there are several DRA drivers with the device attribute resource.kubernetes.io/pcieRoot:

apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
  name: cpu
spec:
  driver: "cpu.example.com"
  pool:
    name: "cpu"
    resourceSliceCount: 1
  nodeName: node-1
  devices:
  - name: "cpu-0"
    attributes:
      resource.kubernetes.io/pcieRoot:
        list:
          string:
          - pci0000:01
          - pci0000:02
  - name: "cpu-1"
    attributes:
      resource.kubernetes.io/pcieRoot:
        list:
          string:
          - pci0000:03
          - pci0000:04
---
apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
  name: gpu
spec:
  driver: "gpu.example.com"
  pool:
    name: "gpu"
    resourceSliceCount: 1
  nodeName: node-1
  devices:
  - name: "gpu-0"
    attributes:
      # Assume this driver is a bit old that keeps exposing string for the attribute
      resource.kubernetes.io/pcieRoot:
        string: pci0000:01
---
apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
  name: nic
spec:
  driver: "nic.example.com"
  pool:
    name: "nic"
    resourceSliceCount: 1
  nodeName: node-1
  devices:
  - name: "nic-0"
    attributes:
      # Assume this driver is a bit old that keeps exposing string for the attribute
      resource.kubernetes.io/pcieRoot:
        string: pci0000:01

You can now define a ResourceClaim that requests CPU, GPU, and NIC resources aligned with the PCIe topology:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
spec:
  requests:
  - name: "gpu"
    exactly:
      deviceClassName: gpu.example.com
      count: 1
  - name: "nic"
    exactly:
      deviceClassName: nic.example.com
      count: 1
  - name: "cpu"
    exactly:
      deviceClassName: cpu.example.com
      count: 2
  constraints:
    # "gpu-0", "nic-0" and "cpu-0" above can match
    # because
    # - "pci0000:01" is common.
    # - string attribute can be treated as a single value list
  - requests: ["gpu", "nic", "cpu"]
    matchAttribute: k8s.io/pcieRoot

DRA: ResourceClaim Support for Workloads

  • KEP #5729 (issue)
  • Feature gate: WorkloadPodGroupResourceClaimTemplate

DRA lets you use specialized resources such as GPUs, FPGAs, and custom network cards. For a Pod to access such a resource, a corresponding ResourceClaim had to be created. The problem was that if you had multiple Pods sharing a resource, the claims had to be made one after another, and you could only have up to 256 Pods in total (because of the status.reservedFor list limitation in the ResourceClaim).

KEP-5729 fixes this: ResourceClaims can now be defined at the PodGroup level. A PodGroup is just a way to group Pods that are part of the same job. Now you can make one claim for the whole group, and every Pod in it can use the resource. Pods in the group can even refer to the resource using a local group name (PodGroupResourceClaim) rather than its direct name. As a result, dynamically created Pods can access a shared resource that was automatically created for their group without needing to know its name beforehand.

DRA: Native Resource Requests

The introduction of DRA in Kubernetes created two independent resource accounting mechanisms. The problem is, they both manage the same underlying resources, leading to double accounting of: 

  • supply. The available CPU/memory capacity of a node is stored in two different places: in the kubelet’s Node.Status.Allocatable field and in the DRA driver’s ResourceSlice objects;
  • consumption. Pods can access those resources in two different ways:
    • by requesting them in the Pod specification (the spec.containers[].resources.requests and pod.spec.initcontainers[].resources.requests fields), which the NodeResourcesFit scheduler plugin checks;
    • via a ResourceClaim, which the DynamicResources plugin handles during device allocation.

KEP-5517 integrates DRA resources with the scheduler’s standard resource tracking mechanism, ensuring consistent resource accounting and preventing nodes from being overcommitted.

Let’s say you have an ML job that needs a GPU, so it makes a ResourceClaim. This specific GPU model also requires a certain amount of CPU and HugePages for the application to work properly. Previously, the user had to be aware of those additional CPU and HugePages requirements and specify them in the PodSpec. Now, the GPU device can be configured to declare these dependencies itself. When placing the Pod, the scheduler will account for the GPU’s CPU and HugePages needs in addition to the regular requests specified in the PodSpec.

WAS: Decouple PodGroup API

For jobs that need to start multiple Pods at once, Kubernetes has a feature called gang scheduling that makes sure all Pods in a group are scheduled together. The problem was that the gang scheduling logic was initially tightly coupled to a specific API implementation called PodGroup. This API was part of another object, Workload. This created a couple of issues:

  • Other projects in the Kubernetes ecosystem that also required gang scheduling (e.g., Kueue or JobSet) were forced to use this specific PodGroup API. They could not use their own custom resource definitions to describe groups.
  • Updating the status of a single small Pod group required reading and writing the entire Workload object, leading to performance issues and conflicts when you had lots of groups.

Newly introduced KEP-5832 decouples PodGroup from Workload: PodGroup becomes a standalone object in Kubernetes, while Workload serves as a static template that defines the overall policy and structure for creating groups. Higher-level controllers, such as Job, JobSet, and LeaderWorkerSet, now automatically create PodGroup instances based on the Workload template, and then create the Pods belonging to that PodGroup.

The Pod spec now has a field (spec.schedulingGroup.podGroupName) that points directly to its PodGroup, so the scheduler knows which group the Pod belongs to. The scheduler itself no longer watches Workload objects; instead, it works directly with a stream of PodGroup objects.

API

Stale Controller Mitigation

In Kubernetes, controllers (e.g., kube-controller-manager) operate on a reconciliation loop. They continuously monitor the cluster’s state, compare the desired state with the actual state, and synchronize them.

Controllers use a local cache of the cluster state to avoid overloading the central API server with constant requests. This cache gets updated by “watching” for changes from the API server. It’s an “eventually consistent” process, so changes get there eventually, but nobody knows how long “eventually” is. The delay can range from a few milliseconds to several minutes.

This problem gets particularly bad in large, high-load Kubernetes clusters. A controller might create a Pod and, a second later, receive a request to reconcile that same object. However, because its cache has not yet been updated, it “does not see” the newly created Pod and may attempt to create it again or do something else it shouldn’t.

KEP-5647 introduces two key changes:

  1. In the informer, a new BookmarkFunc is introduced, with the sole job of notifying listeners that an update has occurred. Along with the regular Add, Update, and Delete functions, this helps the controller know how fresh its cache is.
  2. Improved controller logic. After a successful write operation (CREATE or UPDATE), it saves the object’s new resourceVersion. Before starting the next reconciliation for that object, it checks if its informer has processed a resourceVersion that is at least as recent as the one it saved. If so, the cache is up to date, and the controller can proceed safely. If not, the cache is stale. The controller then skips the reconciliation logic and instead requeues the object to try again later. This retry process occurs with exponential backoff to avoid unnecessary load while the cache catches up to the actual state.

Graceful Leader Transition

In high-availability Kubernetes clusters, multiple replicas of key control plane components, such as kube-controller-manager and kube-scheduler, typically run concurrently. To prevent conflicts, they use a leader election mechanism. The issue with the old mechanism was that upon losing leadership, the component’s process would terminate immediately via os.Exit(). Kubelet would notice it died and restart it. This led to excessive resource consumption, plus the component couldn’t shut down gracefully.

KEP-5366 introduces a smarter way for control-plane components to hand off leadership without requiring a full restart. The implementation is divided into several stages:

  • The controller code is refactored to ensure all its internal processes (goroutines) are cleanly terminated. This is critical to avoid leaking resources if a component switches roles many times.
  • The process of releasing the leader’s “lease” is improved. Instead of waiting for the lease TTL to expire, the outgoing leader now actively releases the lock upon shutdown, thereby accelerating the new leader election process. This feature is controlled by the ControllerManagerReleaseLeaderElectionLockOnExit flag.
  • The final stage (enabled by the GracefulLeaderTransition flag) alters the component’s core logic. Upon losing leadership, it no longer terminates via os.Exit() but instead transitions to a follower state and attempts to become the leader again.

Server-side Sharded List and Watch

In Kubernetes clusters, controllers continuously monitor the state of resources (Pods, Services, etc.) via LIST and WATCH mechanisms. As clusters grow, scaling these operations becomes a challenge. Most controllers, like kube-controller-manager, can only scale vertically because they can’t split up the watch stream. Some controllers, like kube-state-metrics, have figured out how to perform horizontal sharding on the client side. The downside is that every replica still gets all the events for a resource, deserializes everything, and then discards the data that isn’t for its shard. This creates unnecessary network load and wastes CPU resources.

KEP-5866 moves the filtering logic to the API server. It introduces a new shardSelector parameter that allows clients to subscribe to a specific data shard. This parameter defines the hash range the client is interested in. For example, a client can make the following request:

GET /api/v1/pods?watch=true&shardSelector=shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')

In this case, the API server will use the fast FNV-1a algorithm to compute a hash for each object’s unique identifier (metadata.uid). If the hash falls within the specified range (from 0x00… to 0x80… in the example), the event associated with that object will be sent to the client. This allows each replica to subscribe to a unique hash range and get a clean, non-overlapping stream of data.

Manifest Based Admission Control Config

This new KEP fixes a major startup vulnerability in Kubernetes. Typically, all request validation rules, such as admission webhooks (MutatingAdmissionWebhook and ValidatingAdmissionWebhook) and access policies are just API objects inside the cluster. This creates a dangerous window of opportunity: when the API server starts (or if etcd is unavailable), requests may be processed before these security rules are loaded. On top of that, any user with elevated privileges could, intentionally or accidentally, delete these admission policies over the network.

KEP-5793 adds a way to set up security policies using local manifest files on the control plane server’s disk. These files are loaded and applied before the server even starts listening for network traffic.

The API server continuously monitors the local manifest directory. When a file on the disk is modified, Kubernetes immediately detects the change, validates it, and applies it without restarting any components. If validation fails, the server rejects the new manifest, logs a warning, and reverts to the last known good configuration.

Apps

WAS: Integrate Workload APIs with Job controller

In Kubernetes, the Job controller is responsible for running jobs. It spins up Pods, but there’s no guarantee they’ll all start altogether. That is a real challenge for distributed workloads (e.g., AI/ML or MPI jobs), where everything must start at the same time.

KEP-5547 enhances the Job controller to natively support gang scheduling (KEP-4671) via the Workload and PodGroup APIs. When a Job matching specific criteria is created (for the alpha, that’s a Job with parallelism > 1, completionMode: Indexed, and parallelism = completions), the controller automatically:

  • Creates a Workload object that defines the scheduling policy for the Pod group, specifying a gang.minCount equal to the Job’s parallelism value;
  • Creates a PodGroup object using the template defined in the Workload;
  • When creating Pods for the Job, the controller adds the schedulingGroup.podGroupName field to their specifications, linking the Pods to the corresponding PodGroup.

The scheduler sees that the Pods are part of a PodGroup, so it waits for an opportunity to start all the Pods specified in minCount (the minimum number required to start the workload) in one go.

Storage

Report last used time on a PVC

  • KEP #5541 (issue)
  • Feature gate: PersistentVolumeClaimUnusedSinceTime

Over time, Kubernetes clusters tend to accumulate PersistentVolumeClaims (PVCs) that are no longer in use. When an application is deleted, migrated, or simply stops running, its associated PVCs often remain in the cluster, continuing to consume storage space and increase costs.

Right now, there’s no easy way in Kubernetes to see when a PVC was last used. KEP-5541 addresses this by adding a new field, UnusedSince, to the PVC’s status (PersistentVolumeClaimStatus). The PVC protection controller sets this field to:

  • The current time (metav1.Now) when the last pod referencing the PVC is deleted or enters a terminal state;
  • nil when a new Pod begins to reference this PVC.

Various

Support scaling to/from zero pods for object/external metrics

In the past, the Horizontal Pod Autoscaler in Kubernetes couldn’t scale applications down to zero replicas. It relied on metrics from active Pods, like CPU or memory usage, so it always needed at least one Pod running to gather data.

This new KEP introduces support for external and object metrics, allowing the HPA to make decisions based on external indicators, such as the length of a message queue. When there are no tasks to process, it can scale down the number of application Pods to zero, effectively shutting it down.

The HPA records this state in a special status field called ScaledToZero. It prevents the HPA from accidentally scaling up an application that an administrator has manually scaled to zero by setting replicas: 0. As soon as a new task appears (like a message in the queue), the HPA spins up the first replica.

Native Histogram Support for Kubernetes Metrics

The way histograms work in Prometheus right now involves predefined “buckets.” A developer has to set up value ranges in advance. For instance, for request latency, the following buckets might be defined: up to 10 ms, up to 50 ms, up to 100 ms, and up to 500 ms. If a request completes in 49 ms, the system increments the counter for the “up to 50 ms” bucket. This approach has two primary drawbacks:

  • Ambiguity, because it is impossible to know the precise distribution of values within a bucket. For example, did all requests complete in 11 ms, or did they all complete in 49 ms? This information is lost.
  • Redundancy, since the system transmits data for all predefined buckets, even if no values fall into them. This eats up resources and requires additional disk space for storage.

Prometheus v2.40 introduced the Native Histograms (and they became stable in v3.8.0), which use smart, auto-adjusting exponential buckets. KEP-5808 integrates Prometheus Native Histograms into the metrics of Kubernetes components.

Handling undecryptable resources

Encryption of API resources “at rest” has long been used in Kubernetes. Unfortunately, cluster encryption does occasionally fail due to mishandling or failures in an external system.

If a single object of a specific resource type cannot be decrypted, listing resources of that type in a path prefix containing the object always fails, even if the remaining resource instances are accessible. The problem is that you cannot delete a corrupted object via the Kubernetes API — the administrator must manually delete the data from etcd.

KEP-3926 proposes a method for identifying resources that cannot be decrypted or decoded into an object, and introduces a new DeleteOption, IgnoreStoreReadErrorWithClusterBreakingPotential, which allows a resource to be deleted even if its data cannot be read.

Non-alpha v1.36 release highlights

This article intentionally focuses on revealing the newly introduced alpha features in Kubernetes v1.36 to give an idea of where the development is heading. At the same time, each K8s release comes with many other updates that involve alpha features introduced earlier or those currently in beta/stable state. We’ll list the most prominent of them, as selected by Dmitry Shurupov, our co-founder and a CNCF Ambassador:

  1. Device taints and tolerations support in DRA (KEP 5055) and DRA support for partitionable devices (KEP 4815) were promoted to Beta, meaning these features are now enabled by default.
  2. OCI VolumeSource (KEP 4639) became stable. It’s a new (emerged in K8s v1.31) VolumeSource that supports OCI images, i.e., allows storing files and sharing them among containers in a Pod without including them in the main image.
  3. User namespaces support in Pods (KEP 127) became stable. It started as alpha in v1.25 (August 2022) and is now finally declared as GA.
  4. Mutating Admission Policies (KEP 3962) were promoted to stable. This feature extends mutating admission webhooks with mutating admission policies based on CEL expressions.
  5. Accelerated recursive SELinux label change (KEP 1710) finally went stable as well. This feature has been in beta since Kubernetes v1.27 (April 2023).
  6. The gitRepo volume plugin is removed (KEP 5040) to prevent a critical security issue of running code as root on the K8s node.

Some alpha features introduced in K8s v1.35 and earlier releases, such as gang scheduling support and user namespaces in HostNetwork Pods, have seen significant improvements for v1.36 but were kept in their alpha state.

Still, it’s not the complete list of changes introduced in Kubernetes v1.36! For the most comprehensive information, refer to the official enhancements tracker and changelog.

Conclusion

The Kubernetes 1.36 release significantly expands the orchestrator’s toolkit, introducing various enhancements focused on performance, security, and ease of use. By integrating gang scheduling and advanced resource management, Kubernetes is becoming increasingly tailored to modern, distributed workloads and large clusters, while simultaneously optimizing its core APIs. Thank you to all the KEP developers and authors who made Kubernetes 1.36 possible. You, gals and guys, rock!

Interested in other alpha features recently added to Kubernetes? Check out our deep dives into:

Comments

Your email address will not be published. Required fields are marked *

Related articles