Kubernetes 1.34: a summary for teams with little time
Updated: 2026-07-07
Kubernetes 1.34 shipped on August 27, closing the fifteen-week cycle the project has kept for years (three releases a year, not four, whatever people assume). Like recent rounds, it brings nothing revolutionary: a collection of incremental improvements worth reading carefully to separate what touches your cluster from what does not.
Key takeaways
-
The core of Dynamic Resource Allocation (DRA) graduates to stable: the
resource.k8s.io/v1API is now the default version for allocating GPUs and other specialized hardware. -
The scheduler gets faster: Queueing Hints are now stable, and asynchronous API calls reach beta, cutting retries and decision latency in large clusters.
-
Mutating Admission Policies reach stable: you can write mutation logic in CEL inside the apiserver itself, with no separate webhook to run.
-
Tracing for kubelet and the apiserver reaches stable, with end-to-end OpenTelemetry support for diagnosing latency.
-
No APIs are removed and there are no major deprecations this cycle. The one naming change is that
PreferCloseinTrafficDistributionbecomes an alias forPreferSameZone(beta).
Changes you can upgrade without much thought
Most changes in 1.34 are internal improvements that break nothing:
-
Scheduler: Queueing Hints (stable) skip unnecessary retries for pods that cannot be placed yet, and asynchronous API calls (beta) improve throughput in clusters with many nodes.
-
Windows kube-proxy: stable support for Direct Server Return (DSR) and overlay networking. If you run Windows clusters this is production-ready now; Linux is unaffected.
-
Volumes:
VolumeAttributesClassreaches stable, letting you adjust IOPS or throughput on a live volume without recreating the PVC. -
Kubelet environment variables: in beta, they now accept nearly any printable ASCII character except
=, avoiding workarounds for frameworks like .NET Core that use colons in configuration keys.
DRA reaches stable: for real, for production this time
The most relevant news for anyone running AI workloads is that the core of Dynamic Resource Allocation (DRA) graduates to stable. The ResourceClaim, DeviceClass, ResourceClaimTemplate, and ResourceSlice types now form the v1 API, which should not break in the near future.
DRA was proposed in 2023 and went through several alpha and beta rounds. The idea stays the same: instead of asking for two specific GPUs, a workload can ask for a resource that meets certain criteria, and the scheduler matches the request to the hardware available. This matters for GPUs and for specialized hardware like NPUs or FPGAs, where the classic device plugin model fell short.
Alongside the stable core, three extra pieces reach beta: admin access labelling (so only authorized users can reach devices already in use), prioritized lists (a workload can request several acceptable device types, in order of preference, and the scheduler tries each one), and kubelet reporting on which DRA resources are assigned to each pod, useful for monitoring. Sharing one physical device across multiple claims (consumable capacity) is still alpha, so do not count on it in production yet.
My advice changes from earlier versions: for new GPU-heavy AI workloads, the stable DRA core is now a reasonable foundation. If the classic device plugin works for you today and you have no advanced selection needs, there is no rush to migrate. For teams also working with large models, the GPU-allocation pattern in DRA fits well with the training cycles described in NVIDIA’s Blackwell GPUs.
Fewer webhooks, more CEL
The piece I liked most in 1.34 is that Mutating Admission Policies graduate to stable. Until now, mutating a resource in the admission flow needed a webhook: a separate HTTP server, TLS certificates, one more process that can go down. With MutatingAdmissionPolicy, the logic is expressed in CEL and the apiserver applies it directly, with no network call in the path.
(Declarative CRD validation via x-kubernetes-validations is not new to 1.34; it has been around for a while. What changes now is that you can also skip the webhook on the mutation side, in addition to the validation side.)
The benefit is twofold: a failure-prone component disappears (if the webhook was down, creates used to fail) and the network latency of the webhook call goes away. Migration means rewriting the logic in CEL, which has a learning curve but is not hard. Webhooks still earn their keep for validation that needs to look up other resources or external services, something CEL cannot do.
Diagram by MoreInput, Wikimedia Commons[1], CC BY-SA 4.0.
No major deprecations this time
Per the official release notes[2], 1.34 removes no major API and introduces no critical deprecations. If your memory says otherwise, you are probably thinking of batch/v1beta1 for CronJob: that was removed a while back, in version 1.25, not now.
The one naming change worth noting sits in TrafficDistribution: the PreferClose value is deprecated in favor of an explicit PreferSameZone (beta), though it stays as an alias for compatibility. Also arriving, in alpha and behind a feature gate that is off by default, is GracefulLeaderTransition: it lets kube-scheduler, kube-controller-manager, and the cloud-controller-manager release leadership without restarting the whole process. None of this forces you to touch existing manifests.
End-to-end tracing for operators
For anyone who writes or maintains operators, the most useful part of 1.34 is not a new API but an observability upgrade: tracing for kubelet and the apiserver graduates to stable, with end-to-end OpenTelemetry support from the control plane down to the gRPC calls into the container runtime. Traces export to Jaeger, Zipkin, or Grafana Tempo, so teams already running Parca, Beyla, and Grafana as their observability stack get this directly in their existing dashboards, instead of inferring latency from scattered logs.
What I would do this week
My checklist for teams running small or medium production clusters:
-
Do not hunt for removed APIs: there are none this time. Do check whether you use
PreferCloseon anyServicewithtrafficDistribution, so you can plan the move toPreferSameZonewithout rushing. -
If you maintain mutating webhooks for your own resources, consider migrating them to
MutatingAdmissionPolicyin the next iteration: not urgent, but it removes an operational component. -
If you run GPU workloads, check whether the stable DRA core covers your case; the more advanced pieces, like sharing one device across several claims, are still alpha.
-
Upgrade in pre-production first, watch it for a week, then move to production.
Managed providers (GKE, EKS, AKS) take several weeks to offer each new version, so if you use one you have plenty of room to prepare. On self-managed clusters, my rule stays the same: wait at least for the .2 patch before touching production, since the first patches tend to catch the minor bugs that only show up under real use.
My take
Kubernetes has been around for more than ten years and has been a CNCF graduated project[3] since 2018. It is in a calm maturation phase: releases no longer bring dazzling novelties, and that is healthy. What arrives now is polish: better scheduling, better observability, fewer accessory components. DRA finally having a stable core, after two years between alpha and beta, feels like the perfect example: it removes uncertainty without removing capability.
What does unsettle me a little is the growing number of alpha, beta, and stable feature gates that coexist in every release. For a team that follows Kubernetes closely this is manageable. For teams that touch the cluster twice a year, the cognitive load grows with every cycle.
Overall, 1.34 is a release to upgrade calmly, with no deprecations to fear this time because there are none. The exception is teams running AI workloads who already feel the rigidity of the classic device plugin: for them, having a stable DRA core is reason enough to prioritize the upgrade.
This article is also available in Spanish.
