Kubernetes v1.35: What’s New & Improved?

Kubernetes v1.35, also known as "Timbernetes (The World Tree Release)," adds a lot of new features that make Kubernetes stronger and better able to handle modern workloads at scale. There are 60 new features in this release. 17 of them are now Stable (GA), 19 are now Beta, and 22 are now Alpha. The "World Tree" theme shows how this version makes Kubernetes stronger at all levels, from its foundations to its core systems and extension points. This lets it handle a wide range of workloads, from AI/ML to stateful and edge workloads.

These are some of the features we’re most excited about in Kubernetes v1.35: gang scheduling support, in-place Pod resource updates, opportunistic batching in the scheduler, and more. These improvements make Kubernetes much better at optimizing performance, scaling well, and managing resources well.

Let’s discuss the major enhancements in Kubernetes v1.35:

Kubernetes v1.35 Stable Features

1. In-place Update of Pod Resources‍

Feature Group: SIG Node | KEP: #1287

In Kubernetes v1.35, in-place updates of Pod CPU and memory resources have graduated to General Availability (GA).

Before this feature, you had to recreate the Pod every time you changed .spec.resources.requests or .spec.resources.limits. Kubernetes treated resource changes as immutable fields, so even a small CPU or memory adjustment caused a full restart. This was disruptive for stateful services, long-running batch jobs, and latency-sensitive applications. Also, this causes downtime.

With v1.35,  Kubernetes lets you change the CPU and memory requests or limits of a running Pod without having to restart the Pod or its containers. You can now apply resource changes directly to the running container when the runtime and node configuration support it. The kubelet updates cgroup settings in place, and the Pod continues running. If a resource change cannot be applied safely, Kubernetes still falls back to recreating the Pod, preserving backward compatibility. This makes vertical scaling easier, safer, and more effective.

2. PreferSameNode Traffic Distribution

Feature Group: SIG Network | KEP:#3015

In Kubernetes v1.35, PreferSameNode traffic distribution has General Availability (GA). 

Before this change, Kubernetes had the PreferClose option under the trafficDistribution field. It was helpful, but not clear. PreferClose implicitly meant “prefer nearby endpoints,” which in practice meant proximity at the zone level, not at the node level.  There was no clear way for users to say that they wanted strict node-local preference, and the API did not clearly communicate the difference between node-level and zone-level routing behavior.

With v1.35, Kubernetes lets you choose where Service traffic goes. It can strongly prefer endpoints that are on the same node as the client Pod and only use remote endpoints when there are no local ones available. A new option, PreferSameNode, is introduced to prioritize endpoints on the same node. At the same time, PreferClose is renamed to PreferSameZone, making the API self-describing and clearer. PreferClose is still supported for backward compatibility, but PreferSameZone is now the preferred and explicit option for zonal routing. Together, these changes clearly separate node-level and zone-level traffic preferences.This is helpful for workloads that care about performance and want to reduce latency and cross-node traffic.

apiVersion: v1
kind: Service
metadata:
  name: node-local-service
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080
  trafficDistribution: PreferSameNode

‍

With this configuration, if a client Pod and a matching backend Pod run on the same node, Kubernetes will route traffic locally. Only when no local endpoints exist will traffic be sent to Pods on other nodes.

3. Configurable NUMA Node Limit for Topology Manager

Feature Group: SIG Node | KEP:#4622

‍In Kubernetes v1.35, the Topology Manager’s configurable NUMA node limit has graduated to General Availability (GA).

NUMA (Non-Uniform Memory Access) is a hardware architecture where a server is divided into multiple memory regions (NUMA nodes), each directly attached to a specific set of CPUs. The Topology Manager is a kubelet component that aligns CPU, memory, and device allocations so that workloads run on hardware that is physically close.

Before this feature, Kubernetes set a hard limit of 8 NUMA nodes whenever the Topology Manager was enabled. This safety measure was in place to stop state explosion during NUMA affinity calculations. As a result, kubelet would completely disable the Topology Manager on nodes with more than 8 NUMA nodes. This limitation meant that Kubernetes could not take advantage of large, multi-socket servers where precise CPU, memory, and device locality are critical for performance.

With v1.35, the max-allowable-numa-nodes policy option is now stable. Kubernetes allows cluster administrators to run the Topology Manager on machines with more than 8 NUMA nodes. This removes the artificial ceiling and lets Kubernetes coordinate CPU, memory, and device placement even on very large machines. While performance challenges still exist for extremely large NUMA systems, Kubernetes now gives operators the control to opt in based on their hardware and workload needs.

So, this feature enables Kubernetes to better utilize modern high-end servers commonly used for HPC, AI/ML, telecom, and low-latency workloads.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
topologyManagerPolicy: restricted
topologyManagerScope: pod
topologyManagerPolicyOptions:
  max-allowable-numa-nodes: "true"

‍

4. Add CPUManager Policy Option to Restrict reservedSystemCPUs

Feature Group: SIG Node | KEP: #4540

Before this feature, Kubernetes allowed administrators to reserve specific CPUs for system by using reservedSystemCPUs. However, this reservation was enforced only for Guaranteed Pods with integer CPU requests. Burstable and BestEffort Pods, as well as Guaranteed Pods with fractional CPU requests, could still consume CPU time from these reserved cores. In real-world clusters, this led to noisy-neighbor issues where application workloads interfered with system processes, causing node instability, scheduling delays, or degraded performance under load.

With Kubernetes v1.35, the strict-cpu-reservation option for the static CPUManager policy is now General Availability (GA). When enabled, Kubernetes strictly prevents all Pods, regardless of QoS class, from running on CPUs listed in reservedSystemCPUs. This makes CPU isolation predictable and reliable, ensuring system daemons always have dedicated CPU capacity. The result is more stable nodes and better performance for latency-sensitive and high-throughput workloads running alongside critical system components.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
cpuManagerPolicy: static
reservedSystemCPUs: "0-1"
cpuManagerPolicyOptions:
  strict-cpu-reservation: "true"

‍

With this configuration, CPUs 0-1 are exclusively reserved for OS and Kubernetes system daemons. No application Pod, whether BestEffort, Burstable, or Guaranteed, can run on these CPUs.

5. Kubelet Limit of Parallel Image Pulls

Feature Group: SIG Node | KEP: #3673

The kubelet parallel image pull limit controls how many container images a node is allowed to download at the same time. Image pulling is a network and disk-intensive operation.

Before this feature, kubelet behavior was effectively binary. When serializeImagePulls was set to true, images were pulled one at a time, which avoided resource contention but significantly slowed pod startup during scale-ups or node restarts. When serializeImagePulls was set to false, there was no upper limit on parallel image pulls. On busy nodes, this could flood the network, saturate disks, and delay other critical operations on the node.

With Kubernetes v1.35, the maxParallelImagePulls setting is now General Availability (GA). This allows administrators to define an explicit upper bound on concurrent image pulls. Kubernetes can now pull multiple images in parallel but only up to a safe, operator-defined limit. Any additional image pulls are queued until an ongoing pull completes, providing controlled concurrency instead of all-or-nothing behavior.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
serializeImagePulls: false
maxParallelImagePulls: 3

‍

With this configuration, the kubelet allows up to three images to be pulled simultaneously on a node.

6. Kubelet Image Garbage Collection After a Maximum Age

Feature Group: SIG Node | KEP:#4210

Before this feature, kubelet image garbage collection was primarily driven by disk usage thresholds. Images were removed only when disk usage crossed HighThresholdPercent, and cleanup continued until usage dropped below LowThresholdPercent. While effective for preventing disk exhaustion, this meant that rarely used or outdated images could remain on disk indefinitely as long as the node was not under disk pressure. Over time, this led to bloated image caches and inefficient disk utilization.

With Kubernetes v1.35, the imageMaximumGCAge setting is now stable, allowing kubelet to garbage collect images that have not been used for a specified duration, regardless of disk usage. Administrators can define a maximum age for unused images, expressed as a duration. Once an image exceeds this age without being used, it becomes eligible for deletion. This complements existing disk-based GC and makes image cleanup proactive instead of reactive.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
imageMaximumGCAge: 24h
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 70

‍

With this configuration, any container image that has not been used for 24 hours can be removed by the kubelet, even if disk usage is below the high threshold.

7. Job API managedBy Mechanism

Feature Group: SIG Apps | KEP:#4368

Before this feature, every Job object was always reconciled by the built-in Job controller. Even if an external system (like a custom controller or multi-cluster scheduler) wanted to manage execution or status, Kubernetes would still create Pods, update Job conditions, retry failures, and enforce completion semantics. This made advanced use cases such as mirroring Jobs across clusters, requiring annotations, controller workarounds, or suppression logic to avoid conflicts.

With Kubernetes v1.35, the managedBy field is now General Availability (GA). When set, Kubernetes treats the Job as externally managed and does not reconcile its Pods or status. This enables systems like MultiKueue, where a Job is created in a management cluster, executed in a worker cluster, and status is synchronized back without interference from the native Job controller. The feature is intentionally limited: it enables delegation of Job management but does not change Job semantics, CronJob behavior, or pass configuration to the external controller.

apiVersion: batch/v1
kind: Job
metadata:
  name: delegated-job
spec:
  managedBy: kueue.x-k8s.io/multikueue
  ........

‍

8. Pod Generation (Reliable Pod Update Tracking)

Feature Group: SIG Node | KEP: #5067

Before this feature, Pods did not have a metadata.generation field like higher-level objects such as Deployments or StatefulSets. While controllers could update a Pod’s spec, there was no built-in, monotonic way to know whether the kubelet had already processed a given change. This made it difficult to reliably detect whether a Pod update was still pending, partially applied, or fully reflected in status - especially for in-place updates and fast, successive changes.

With Kubernetes v1.35, Pod generation tracking is now General Availability (GA). Each Pod starts with metadata.generation: 1, and every update to a mutable field in the Pod spec increments this value. The kubelet records the generation it has acted upon in status.observedGeneration. This makes it explicit whether the Pod’s current status reflects the latest desired spec or an earlier version. External controllers can safely compare these two fields to determine if reconciliation is complete, without relying on timing or guesswork.

Kubernetes v1.35 Beta Features

9. Configurable tolerance for HorizontalPodAutoscalers

Feature Group: SIG Autoscaling | KEP: #4951

The Horizontal Pod Autoscaler (HPA) automatically adjusts the number of Pod replicas in a workload based on observed metrics such as CPU or memory usage.

Before this feature, the HPA used a fixed, cluster-wide 10% tolerance when deciding whether to scale. This value was not configurable per workload. As a result, highly sensitive applications could fail to scale when they needed to react to small load increases, while other workloads could experience unnecessary scaling or oscillations. Adjusting this behavior required changing a global controller flag, impacting every HPA in the cluster.

With Kubernetes v1.35, configurable tolerance has graduated to Beta and is enabled by default. You can now define tolerance values per HPA and per scaling direction using the behavior field. This gives fine-grained control over autoscaling sensitivity without affecting other workloads. Operators can tune critical services to scale aggressively while keeping less sensitive workloads stable.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

‍

With this configuration, the HPA scales up only when CPU utilization exceeds 65% (5% above the target).

10. Mutable Volume Attach Limits

Feature Group: SIG Storage | KEP:#4876

Volume attach limits define how many storage volumes can be attached to a node at a given time. Kubernetes relies on this information to decide where to schedule Pods that use persistent volumes. CSI drivers report these limits through the CSINode object.

Before this feature, the volume attachment capacity reported in CSINode.spec.drivers[*].allocatable.count was static. Once a CSI driver registered its attach limit at startup, Kubernetes assumed that value was always accurate. If volume slots were consumed later - due to external operations, node restarts, or transient failures - the scheduler could still place Pods on nodes that no longer had capacity. This resulted in Pods getting stuck in ContainerCreating because the volume could not actually be attached.

With Kubernetes v1.35, the allocatable volume attach limit is now mutable and the feature is Beta, enabled by default. CSI drivers can dynamically update a node’s available attachment capacity at runtime. Kubernetes also introduces a configurable refresh interval via the CSIDriver object, allowing drivers to control how frequently allocatable counts are recalculated. In addition, Kubernetes automatically updates the allocatable count when it detects attachment failures caused by insufficient capacity. This makes scheduling decisions more accurate and significantly reduces failed or stuck Pod startups.

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example.csi.storage
spec:
  attachRequired: true
  nodeAllocatableUpdatePeriodSeconds: 30  # Note: minimum is 10 seconds

‍

This configures periodic kubelet calls to the CSI driver's NodeGetInfo endpoint every 30 seconds to refresh CSINode.spec.drivers[].allocatable.count

11. Opportunistic batching

Feature Group: SIG Scheduling | KEP: #5598

Opportunistic batching is a scheduler optimization that improves performance when Kubernetes schedules many Pods with identical or equivalent scheduling requirements. 

Before this feature, the kube-scheduler processed Pods one by one, with scheduling complexity proportional to the number of Pods multiplied by the number of Nodes. Even when multiple Pods were identical from a scheduling perspective - same resource requests, affinities, and constraints - the scheduler repeated the same filtering and scoring computations for each Pod. This led to redundant work and slow scheduling, especially for batch jobs, ML workloads, and large-scale replica creation.

With Kubernetes v1.35, opportunistic batching is introduced as a Beta feature, enabled by default. The scheduler now computes a pod scheduling signature, which captures all scheduling-relevant aspects of a Pod, including pod specs, node attributes, and cluster state. When Pods with the same signature arrive back-to-back in the scheduling queue, the scheduler batches them together. It caches the scheduling results from the first Pod and reuses them for subsequent Pods with the same signature, avoiding repeated computation. The cache is short-lived and automatically refreshed to ensure correctness as cluster state changes.

This optimization works transparently - no user configuration is required and primarily benefits workloads with many identical Pods, such as Jobs, parallel ML workers, and large-scale deployments. By reducing redundant scheduling work, Kubernetes can place Pods faster and scale workloads more efficiently under high load.

12. maxUnavailable for StatefulSets

Feature Group: SIG Apps | KEP: #961

A StatefulSet manages a set of Pods that require stable identities, ordered startup and termination, and persistent storage.

Before this feature, StatefulSets using the RollingUpdate strategy updated Pods strictly one at a time, starting from the highest ordinal. There was no way to control how many Pods could be unavailable during an update. Even if a stateful application could tolerate multiple Pods being temporarily down, Kubernetes still enforced serialized updates, leading to long rollout times for large StatefulSets.

With Kubernetes v1.35, the maxUnavailable field for StatefulSet rolling updates is now Beta and enabled by default. This allows operators to specify how many Pods can be unavailable during an update, either as an absolute number or a percentage of replicas. When combined with podManagementPolicy: Parallel, Kubernetes can update multiple Pods at once while still respecting availability constraints. If not set, the default remains 1, preserving the previous behavior.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  replicas: 10
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 20%
      ........

‍

13. Deployment Status: Count of Terminating Replicas

Feature Group: SIG Apps | KEP: #3973

A Deployment manages rolling updates and scaling of Pods, and its status is used by operators and automation to understand rollout progress. 

Before this feature, Deployment status only reported fields like replicas, updatedReplicas, readyReplicas, and availableReplicas. Pods that were terminating were not explicitly visible in the Deployment status. This made it difficult to tell whether a Deployment was truly stable or still had Pods cleaning up in the background. Operators and controllers had to list Pods manually and filter by deletionTimestamp, which was error-prone and inefficient.

With Kubernetes v1.35, the status.terminatingReplicas field is promoted to Beta and enabled by default (with the DeploymentReplicaSetTerminatingReplicas feature gate enabled on the API server and controller manager). This field reports the number of Pods that are terminating but not yet fully removed. It improves observability during rollouts and scale-down events and provides a foundation for future improvements in Deployment behavior, such as smarter Pod replacement policies that account for shutdown progress.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
status:
  replicas: 5
  updatedReplicas: 5
  readyReplicas: 4
  availableReplicas: 4
  terminatingReplicas: 1
  ........

‍

14. Expose Node Topology Labels via the Downward API

Feature Group: SIG Node | KEP:#4742

Node topology labels describe where a Pod is running in the infrastructure, such as the region or availability zone of the node.

Before this feature, Pods could not directly access node topology information. Workloads that needed zone or region data had to query the Kubernetes API server, rely on sidecars, or be granted additional RBAC permissions. This increased operational complexity and introduced security risks by expanding the permissions of application Pods beyond what they actually needed.

With Kubernetes v1.35, node topology labels are now injected into Pods and exposed through the Downward API, with the feature in Beta and enabled by default. The kubelet propagates standard labels such as topology.kubernetes.io/zone and topology.kubernetes.io/region from the node to the Pod, making them available as environment variables or projected files. This enables workloads to become topology-aware without API access, simplifying configuration and respecting the principle of least privilege.

apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", “env”]
    env:
    - name: ZONE
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['topology.kubernetes.io/zone']
    - name: REGION
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['topology.kubernetes.io/region']

‍

With this configuration, the Pod automatically receives the zone and region of the node it is running on.

Kubernetes v1.35 Alpha Features

15. Gang scheduling support in Kubernetes

Feature Group: SIG Scheduling | KEP: #4671

Before this feature, Kubernetes scheduled Pods individually. For tightly coupled workloads, this resulted in partial scheduling: some Pods would start running while others remained pending due to resource shortages. These partially scheduled jobs could deadlock, waste cluster resources, and block other workloads, forcing users to rely on external schedulers or custom controllers to enforce gang semantics.

With Kubernetes v1.35, native gang scheduling is introduced as an Alpha feature using the new Workload API and pod group policies. Users define a Workload that groups Pods together and specifies a minCount requirement. The scheduler holds Pods until the group is complete, then attempts to place them together. If it cannot schedule at least the required number of Pods within a timeout, none are bound, and the Pods wait until sufficient resources are available. This brings first-class, scheduler-level support for gang semantics directly into Kubernetes.

Example:

Workload defining a gang of Pods

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: ml-training
spec:
  podGroups:
  - name: workers
    policy:
      gang:
        minCount: 4

Pod linked to the Workload:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  workloadRef:
    name: ml-training
    podGroup: workers
  containers:
  - name: trainer
    image: <your-image>

With this config, Kubernetes schedules the Pods only when at least four workers can run together. If the cluster cannot satisfy that requirement, none of the Pods are started.

‍

16. Extended Toleration Operators for Threshold-Based Placement

Feature Group: SIG Scheduling | KEP: #5471

Taints and tolerations are used in Kubernetes to control where Pods can run. Nodes use taints to say “don’t place Pods here,” and Pods use tolerations to say “I am allowed to run on this node.”

Before this feature, tolerations supported only basic operators such as Exists and Equal. This meant Pods could either tolerate a taint or not, but they could not express degrees of tolerance. For example, a workload could not say “run only on nodes with SLA ≥ 99.9” or “avoid nodes with reliability below a certain threshold.” As a result, clusters that wanted SLA-aware placement had to rely on custom schedulers, multiple node pools, or complex admission logic.

With Kubernetes v1.35, tolerations gain numeric comparison operators (such as greater-than or less-than semantics) and graduate as part of extended scheduling. Nodes can expose SLA-oriented taints (for example, reliability scores or fault-domain quality), and Pods can specify tolerations that match only if the node’s taint value satisfies a numeric condition. This allows critical workloads to target high-SLA nodes, while best-effort workloads can intentionally run on lower-cost, lower-SLA infrastructure that improves utilization without sacrificing reliability.

Node taint expressing an SLA level:

kubectl taint nodes node-a 
servicelevel.org.example/agreed-service-level=800:NoSchedule

Pod tolerating only nodes with sufficient SLA:

apiVersion: v1
kind: Pod
metadata:
  name: sla-tolerant-pod
spec:
  tolerations:
  - key: servicelevel.org.example/agreed-service-level
    operator: LessThan
    value: "900"
    effect: NoSchedule
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "echo running on lower-SLA node"]

‍

With this configuration, the Pod will only be scheduled onto nodes whose SLA taint value is lower than 900.

17. Mutable Container Resources When a Job Is Suspended

Feature Group: SIG Apps | KEP: #5440

A Kubernetes Job runs a task until it finishes successfully and makes sure it completes.

Before this feature, the Pod template inside a Job was effectively immutable. If a Job failed due to insufficient CPU or memory (for example, repeated OOM kills), users had no way to adjust resource values on the existing Job. The only option was to delete the Job and create a new one with updated resources, which meant losing Job history, status, and any tooling that tracked progress or retries.

With Kubernetes v1.35, Jobs that are in a suspended state can have their container resource requests and limits modified, when the MutableJobPodResourcesForSuspendedJobs feature gate is enabled. Users can suspend a failing Job, update the Pod template with appropriate resource values, and then resume the Job. Kubernetes continues execution using the updated configuration while preserving the Job’s identity and lifecycle state, making recovery from misconfigured resources much smoother.

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processor
spec:
  suspend: true
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo processing && sleep 30"]
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "2Gi"

‍

After updating the resources, the Job can be resumed by setting spec.suspend to false. The Job continues with the new CPU and memory values, without deleting or recreating the Job.

18. Node Declared Features Before Scheduling

Feature Group: SIG Node | KEP: #5328

Before this feature, Kubernetes assumed that nodes were broadly compatible with the control plane, within the supported version skew. When new features were enabled at the control plane level, the scheduler could still place Pods using those features onto older nodes that did not yet support them. This resulted in runtime failures, subtle misbehavior, or Pods getting stuck after scheduling, even though the placement decision itself appeared valid.

With Kubernetes v1.35, an Alpha feature introduces a formal mechanism for nodes to declare their supported features through a new status.declaredFeatures field on the Node object. When enabled, nodes publish the set of Kubernetes features they understand. The scheduler, admission controllers, and external components can then use this information to validate Pods and restrict scheduling to compatible nodes, preventing feature skew issues before Pods are bound.

Dynamic Resource Allocation (DRA) - Ongoing Work

Feature Group: SIG Node / SIG Scheduling

Dynamic Resource Allocation (DRA) is Kubernetes’ native framework for managing specialized hardware resources (such as GPUs, accelerators, and devices) in a scheduler-aware and lifecycle-safe way. It replaces many limitations of traditional device plugins by integrating device allocation directly into the Kubernetes scheduling and binding process.

Before Kubernetes v1.35, the core DRA functionality had already reached stable in v1.34.

With Kubernetes v1.35, DRA is always enabled and several important alpha features have matured significantly. The focus in v1.35 is not new APIs, but making existing DRA concepts more complete, reliable, and observable.

Let’s discuss:

Extended Resource Requests via DRA

Extended resource requests allow Pods to request devices with richer semantics, including reuse across init containers and better scoring during scheduling.‍

‍Before Kubernetes v1.35, DRA lagged behind device plugins in some scenarios. For example, devices could not be reused cleanly between init containers and app containers, and scheduling decisions lacked proper scoring signals for certain device types.

Now with Kubernetes v1.35, these gaps have been addressed. Device reuse across init containers works correctly, and scheduling logic better evaluates device placement. This makes DRA viable for more complex Pod lifecycles and multi-stage workloads.

Device Taints and Tolerations

Device taints allow individual devices—not entire nodes—to express conditions that affect scheduling and eviction, similar to node taints.

Before Kubernetes v1.35 , Device taints were limited and lacked safe ways to evaluate their impact before enforcing evictions. Any taint with NoExecute would immediately evict Pods using the device.

Now with Kubernetes v1.35, A new effect: None is introduced. This allows operators to perform a dry run. You can inspect how many pods would be affected and switch to NoExecute only when ready.

Additionally, DeviceTaintRule now reports status information, making evictions observable and safer to operate.

Partitionable Devices

Partitionable devices are physical devices that can be divided into smaller logical units (for example, GPU slices).

Before, all partitions of a device had to be defined within a single ResourceSlice, limiting flexibility in how devices were modeled and advertised.

Now with Kubernetes v1.35, Devices belonging to the same partitionable device can be defined across multiple ResourceSlices. This improves modeling flexibility and aligns better with how modern hardware exposes partitioned resources.

Consumable Capacity

Consumable capacity tracks device resources that are gradually depleted rather than allocated exclusively (for example, memory bandwidth or limited-use accelerators).

Early implementations had correctness issues and incomplete test coverage, limiting trust in scheduling and accounting behavior.

Now (v1.35), multiple bugs have been fixed and test coverage expanded. Capacity consumption and release behavior is now more reliable, making this feature safer for experimentation.

Device Binding Conditions

Binding conditions define when and how a device allocation becomes final during Pod scheduling and admission.

Before, edge cases existed where binding behavior could be ambiguous or incorrectly handled under failure scenarios.

Now (v1.35), Several fixes and validations improve correctness. Binding decisions are more predictable and resilient, especially during retries and partial failures.

Comparable Resource Version Semantics

Resource versions allow clients and controllers to track changes to Kubernetes objects over time.

Before Kubernetes v1.35, resource versions could only be compared for equality, not order. Clients could not reliably determine whether one version was newer than another without server-side help.

Now with Kubernetes v1.35, all in-tree resource versions follow a strict, comparable numeric format. Clients can safely compare versions themselves. This enables better informer performance and more reliable controllers. This change is foundational and enables multiple higher-level improvements across Kubernetes.

Deprecations / Removals

Removal of cgroup v1 support

cgroups are used by Kubernetes to manage CPU and memory for containers. Earlier versions supported both cgroup v1 and v2, mainly for backward compatibility.

In v1.35, cgroup v1 support is fully removed, and cgroup v2 is mandatory.

Deprecation of IPVS mode in kube-proxy

kube-proxy routes Service traffic to Pods using different backend modes. IPVS mode is deprecated in v1.35 due to operational complexity and overlap with modern dataplanes.

Kubernetes now encourages iptables mode or eBPF-based CNIs for scalable networking.

This reduces maintenance overhead and improves long-term networking reliability.

Final call for containerd v1.x

Containerd is the default container runtime used by Kubernetes.
Older containerd v1.x versions are nearing end-of-support.
Kubernetes v1.35 signals a final call to upgrade to newer containerd releases.

Kubernetes 1.35 brings a total of 60 Kubernetes Enhancement Proposals (KEPs). These enhancements include Kubernetes functionalities, flexibility, resource management, observability, and more.

Beyond the major changes we've discussed, there are other features added by the k8s team. We encourage you to have a look at the Kubernetes v1.35 release notes and check this for more details.