Kubernetes 1.34 stabilizes Dynamic Resource Allocation
Dynamic resource allocation is now a stable feature of the new Kubernetes release. The Kubernetes project Metal3.io has also announced an innovation.
(Image: Da Da Diamond/Shutterstock.com)
The new Kubernetes version 1.34 is available as a final release and makes Dynamic Resource Allocation (DRA) generally available – which, among other things, opens up new configuration options for GPUs and TPUs. The release brings a total of 58 new features: 23 features are now considered stable, while 22 have reached the beta phase and 13 the alpha phase. Meanwhile, Metal3.io has achieved CNCF Incubating Project status.
The CLC program, from 18 to 20 November 2025 in Mannheim, covers all topics related to platform engineering and developer experience. Tickets and further information on the CLC website.
Dynamic Resource Allocation reaches stability
Dynamic Resource Allocation (DRA) is now generally available as a stable feature. As the Kubernetes team states in the announcement on GitHub, DRA is intended to open up more powerful ways of selecting, assigning, sharing and configuring devices such as Graphics Processing Units (GPUs), Tensor Processing Units (TPUs) and Network Interface Cards (NICs).
There are also new features for DRA in alpha and beta status: as a beta feature, controlled admin access via the adminAccess field in ResourceClaims or ResourceClaimTemplates enables cluster operators to access devices that are already in use for monitoring or diagnostics. The alpha features include the observability of the health status of devices and extended resource mapping.
Other stable features in this release include the creation of replacement pods by job controllers. By default, these immediately create a replacement pod when a pod starts to terminate. As a result, both pods run simultaneously, which can lead to difficulties – such as not enough available nodes for the replacement pod or problems in dealing with machine learning frameworks such as TensorFlow and JAX –. The Kubernetes team is therefore providing a remedy with the .spec.podReplacementPolicy feature in jobs. This allows you to specify that replacement pods should only be created when a pod is completely terminated (.status.phase: Failed.) using the .spec.podReplacementPolicy: Failed setting.
Videos by heise
Metal3.io now in the CNCF incubator
The Technical Oversight Committee (TOC) of the Cloud Native Computing Foundation (CNCF) has added Metal3.io to the CNCF Incubator. Once the result of a collaboration between Red Hat and Ericsson in 2019, Metal3.io (pronounced "metal cubed") has been in the CNCF sandbox since 2020. It is an open source project that offers a set of tools to manage bare metal infrastructure using Kubernetes.
According to TOC sponsor Ricardo Rocha, Metal3.io addresses a critical need in cloud-native infrastructure by making bare metal as manageable and Kubernetes-native as any other platform. Its steady growth, technical maturity and strong integration into the Kubernetes ecosystem made it a clear choice for incubation, according to Rocha. The roadmap for 2025 includes support for multi-tenancy and other architectures beyond x86_64, such as ARM.
(mai)