Kubernetes 1.34: a summary for teams with little time

Actualizado: 2026-05-03

Kubernetes 1.34 was released in mid-July, following the project’s usual quarterly cadence. Like recent versions, it brings nothing revolutionary but a collection of incremental improvements that require careful note-reading to separate what affects your cluster from what does not.

Key takeaways

• The scheduler improves node ranking with complex affinities, reducing decision latency in large clusters.
• IPv6 dual-stack moves to GA — no longer an experiment and can be treated as stable configuration.
• Dynamic Resource Allocation (DRA) advances to beta with device sharing, advanced selectors, and per-attribute accounting — useful for GPU and NPU.
• Declarative CEL validation in CRDs eliminates the need for admission webhooks for most rules, with measurable latency gains.
• Critical deprecation: batch/v1beta1 for CronJob is removed definitively in 1.34 — any manifest using it simply will not apply.

Changes you can upgrade without much thought

Most changes in 1.34 are internal improvements that break nothing and enable immediate benefits:

• Scheduler: improvements in node ranking when complex affinities are involved, reducing decision latency in large clusters.
• kube-proxy: better iptables rule handling when services have many external IPs — a scenario that previously degraded performance visibly.
• IPv6 dual-stack at GA: no longer an experiment and can be treated as stable. Calico, Cilium, and Flannel plugins need no update.
• kubelet with improved cgroups v2: already default on Debian 13 and Ubuntu 24.04. Legacy cgroups v1 cleanup is announced for 1.36.

Dynamic resource allocation: progress, not closure

The most visible novelty for anyone working with AI workloads is progress on Dynamic Resource Allocation (DRA). In 1.34 several missing features move to beta:

• Sharing devices between pods
• Claims with advanced selectors
• Accounting by device attributes

This matters a lot for GPU and specialized hardware like NPU or FPGA, where the traditional device plugin abstraction fell short. DRA was proposed in 2023 and has gone through several alpha and beta iterations. The idea is to let a workload say I need a resource meeting these criteria rather than I need two GPUs, and let the scheduler match criteria with available devices.

In 1.34 the API is more stable but not yet GA. My production advice is to stick with the classic device plugin if it works. For new deployments on complex AI workloads, DRA is worth the risk.

Declarative validation: the less visible, more useful change

The piece I liked most in 1.34 is declarative validation for custom resources. Until now, validating a CustomResource with complex rules required an admission webhook, with added latency and an external dependency that could fail. With declarative validation, rules are expressed in CEL inside the CRD itself, and the apiserver evaluates them directly without network calls.

The benefit is twofold:

• A failure component is eliminated: if the webhook was down, creates failed.
• Latency of custom resource creation is reduced — in a cluster with five operators validating CRDs via webhook, kubectl apply latency dropped between 150 and 400 ms per resource after migrating to CEL validation.

Migration requires rewriting validation logic in CEL, which has a learning curve but is not hard. Where webhook still wins is validation that requires consulting other resources or external services.

Deprecations worth marking in red

The 1.34 deprecation list is not long but is important:

• batch/v1beta1 for CronJob: removed definitively in 1.34. Any manifest using that version simply will not apply. If your GitOps has old CronJobs, migrate to batch/v1 before upgrading.
• --feature-gates flag in several subcomponents: in 1.34 a warning appears in logs; in 1.35 the flag will be ignored; in 1.36 it will prevent the process from starting.
• PodSecurityPolicy v1: deprecated since 1.21 and removed in 1.25, appears now with a firm reminder for those still carrying references in code.

The change that affects operators

For teams writing or maintaining operators, 1.34 brings a notable improvement in the leader election lifecycle. The API received an improvement in expiration handling that reduces double-leader windows — a classic problem when a controller briefly loses apiserver connectivity. The API is backward compatible, but recompiling the operator against client-go 1.34 is recommended to get the improvement.

What I would do this week

My checklist for teams with small or medium production clusters:

1. Verify no manifests use APIs removed in 1.34 before upgrading — batch/v1beta1 and some remaining extensions/v1beta1. A simple search in the GitOps repo catches 90% of cases.
2. If you use validation webhooks for your own CRDs, plan migration to CEL validation for the next iteration — not urgent but clearly better.
3. If you run GPU workloads in production, read DRA docs but do not migrate yet if the current system works.
4. Upgrade in pre-production, watch for a week, and then production.

Time between a release and availability on managed clusters like GKE, EKS, AKS is usually six to twelve weeks. If you run self-managed clusters, my practical rule is to wait at least until the .2 patch before production — the first two patches close 70% of minor bugs discovered in early weeks.

My take

Kubernetes is in a calm maturation phase. Releases no longer bring dazzling novelties, and that is healthy. The project is ten years old and most critical functionality exists since 1.20 or earlier. What comes now is polish: better scheduling, better security, better telemetry, fewer accessory components. Declarative validation is a good example: it removes an external system without removing capability.

Overall, 1.34 is a release to upgrade calmly, verify nothing is broken in deprecations, and relax. The only exception is teams with AI workloads using device plugin and frustrated by the old model’s rigidity: for them, DRA in beta is enough reason to prioritize the upgrade. Everyone else can wait until the next cycle without missing anything.