Kubernetes 1.34 brings 59 enhancements with zero deprecations, making this a pretty upgrade path.

Scheduled for release on August 27, 2025, this version delivers production-ready GPU management, enhanced security controls, and significant performance improvements.

The release represents a maturity milestone with 23 features graduating to stable and 12 new alpha capabilities, emphasizing production stability while introducing functionality for AI workloads, advanced scheduling, and declarative policy.

OCI Artifact Volumes simplify secure artifact distribution

#4639

Kubernetes 1.34 introduces OCI Artifact Volumes, enabling Pods to mount artifacts directly from OCI-compliant registries into containers as read-only volumes. Unlike container images, which bundle application code and runtime dependencies, OCI artifacts can be used to distribute non-image resources such as:

• Configuration files

• Seccomp, AppArmor, or SELinux profiles

• Machine learning models

• Binary executables or policy bundles

This feature provides a secure, standardized way to deliver cluster-wide content without resorting to custom init containers, sidecar downloaders, or baked-in application images.

PodCertificateRequest enables native Pod X.509 certificates

#4317

Kubernetes 1.34 (Alpha) introduces a new resource, PodCertificateRequest, which allows Pods to obtain short-lived X.509 certificates directly from the Kubernetes API server.

How it works

• A Pod creates a PodCertificateRequest object specifying identity requirements (for example, DNS names).

• The kube-apiserver issues a signed, short-lived certificate.

• The certificate is delivered into the Pod via a projected volume.

This feature provides a Kubernetes-native way for Pods to obtain X.509 certificates without relying on external certificate distribution mechanisms. It simplifies workload identity management and enables secure Pod-to-Pod communication using short-lived credentials.

Dynamic resource allocation reaches production readiness

Stable

Dynamic Resource Allocation (DRA) core functionality graduates to stable in 1.34, transforming how Kubernetes handles specialized hardware like GPUs, FPGAs, and custom devices. This marks a significant shift from the rigid node-level resource model to flexible, workload-specific allocation.

The stable DRA implementation introduces the resource.k8s.io/v1 API with four new resource types: ResourceClaim, DeviceClass, ResourceClaimTemplate, and ResourceSlice. Unlike traditional resource requests that rely on simple quantity-based allocation, DRA uses structured parameters and CEL expressions for sophisticated device filtering and selection.

Example:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-request
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-a100
      selectors:
      - cel:
          expression: 'device.driver == "nvidia.com/gpu" && device.attributes["memory"] >= "80GB"'

For teams managing AI/ML workloads, this enables precise hardware matching based on memory capacity, compute capabilities, or vendor-specific features. The centralized device categorization through DeviceClass resources simplifies resource management across heterogeneous clusters.

Device Binding Conditions (Alpha - KEP-5007) complement stable DRA by preventing premature Pod scheduling before fabric-attached devices become ready. The new BindingConditions mechanism ensures GPU initialization completes before application startup, eliminating the manual intervention previously required for complex hardware configurations.

Read about the user stories that will demonstrate how the logic works.

ServiceAccount tokens improves image pull security

ServiceAccount token integration for kubelet credential providers graduates to beta and enables by default in 1.34, addressing a long-standing security concern with static image pull secrets. This enhancement automatically provides short-lived, Pod-scoped authentication tokens that rotate without manual intervention.

The implementation leverages OIDC-compliant ServiceAccount tokens, with each token scoped to a single Pod and automatically managed by the kubelet. This eliminates the operational overhead of managing long-lived registry credentials while significantly improving security posture.

Example:

apiVersion: v1
kind: Pod
spec:
  serviceAccountName: image-puller
  containers:
  - name: app
    image: private-registry.com/my-app:latest
  # No imagePullSecrets required - handled automatically via ServiceAccount token

CEL-based policies eliminate webhook complexity

CEL-based Mutating Admission Policies introduce declarative resource modification capabilities that can replace many external admission webhooks. Graduating from alpha to beta in 1.34, this feature uses Common Expression Language to define resource mutations directly within Kubernetes API machinery.

Feature Gate Required: MutatingAdmissionPolicy=true (enabled by default in beta)

The updated admissionregistration.k8s.io/v1beta1 API provides MutatingAdmissionPolicy and MutatingAdmissionPolicyBinding resources that eliminate the operational overhead of maintaining external webhook services while improving policy lifecycle management.

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingAdmissionPolicy
metadata:
  name: add-security-context
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - operations: ["CREATE"]
      apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
  mutations:
  - patchType: JSONPatch
    jsonPatch:
      expression: |
        [
          {
            "op": "add",
            "path": "/spec/securityContext/runAsNonRoot",
            "value": true
          }
        ]

This approach simplifies debugging and policy management compared to external webhooks while providing better integration with Kubernetes RBAC and audit systems. The declarative nature makes policies more transparent and easier to version control alongside other cluster configurations.

Production-grade observability with native tracing

Kubelet Tracing (KEP-2831) and API Server Tracing (KEP-647) both graduate to stable in 1.34, providing production-ready OpenTelemetry integration for comprehensive cluster observability. These components instrument critical operations including gRPC calls to the Container Runtime Interface and API request processing.

The implementation supports end-to-end trace propagation from control plane components through kubelet operations to container runtime interactions. This visibility proves invaluable for debugging complex scheduling decisions, node-level performance issues, and container lifecycle problems

# Enable kubelet tracing (now stable, no feature gate required)
kubelet --tracing-config=/etc/kubernetes/tracing-config.yaml

# Example tracing configuration
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
tracing:
  endpoint: "http://jaeger-collector:14268/api/traces"
  samplingRatePerMillion: 100000

The stable status means these tracing capabilities can be safely enabled in production environments without concerns about API stability or performance impact. For teams debugging node-level issues or optimizing cluster performance, this provides unprecedented visibility into Kubernetes internal operations.

KYAML addresses configuration safety concerns

KYAML output format (Alpha - KEP-5295) introduces a Kubernetes-specific YAML dialect designed to eliminate common configuration errors caused by YAML's type coercion behavior. Available through kubectl get -o kyaml, this format addresses the notorious "Norway problem" and other YAML parsing edge cases.

KYAML always double-quotes string values, uses explicit {} for mappings and [] for sequences, and employs flow-style syntax to reduce whitespace sensitivity issues. All KYAML files remain valid YAML while being significantly safer to parse and modify. 

Example:

# Traditional YAML output (problematic)
kubectl get service my-app -o yaml
# country: NO    # Parsed as boolean false
# version: 3.10  # Parsed as float 3.1

# KYAML output (safe)
kubectl get service my-app -o kyaml  
# country: "NO"   # Explicitly a string
# version: "3.10" # Explicitly a string

For teams managing complex configurations, KYAML provides safer defaults for automated processing and reduces the likelihood of configuration drift caused by YAML parsing inconsistencies.

kubectl and kubeadm improvements

kubectl gains several productivity enhancements including the KYAML output format and .kuberc configuration file support (Beta). The .kuberc file separates user preferences from cluster configurations, enabling shareable user settings across different cluster contexts.

Example:

# Enable .kuberc support
export KUBECTL_KUBERC=true
kubectl config set-preference editor vim
kubectl config set-preference output yaml

kubeadm introduces External Key Management Integration (Alpha) supporting HSMs and cloud KMS services through a new gRPC API (ExternalJWTSigner). This enhancement enables ServiceAccount JWT signing without requiring kube-apiserver restarts, improving certificate lifecycle management in security-conscious environments.

Enhanced deployment control and autoscaling precision

Pod Replacement Policy for Deployments (Alpha - KEP-3973) introduces fine-grained control over rolling update behavior through a new spec.podReplacementPolicy field. This feature addresses the trade-off between rollout speed and resource consumption during deployments. 

The TerminationStarted policy creates new pods immediately when old pods begin terminating, enabling faster rollouts at the cost of temporary resource spikes. The TerminationComplete policy waits for full pod termination before replacement, providing controlled resource consumption but slower updates.

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  podReplacementPolicy: TerminationStarted  # Fast rollouts
  replicas: 100
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

HPA Configurable Tolerance graduates to beta with the HPAConfigurableTolerance feature gate enabled by default. This enhancement allows per-HPA tolerance configuration, overriding the cluster-wide 10% default that often proves inadequate for large deployments.

Example:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  behavior:
    scaleUp:
      tolerance: 0.05  # 5% tolerance instead of default 10%
    scaleDown:
      tolerance: 0.15  # 15% tolerance for scale-down operations

Asynchronous API Calls (Alpha - KEP-5229) addresses scheduler bottlenecks in large clusters by eliminating synchronous API call dependencies. The new APIQueue component manages asynchronous operations through a hybrid cache-mediated approach, allowing operations to be skipped or combined when circumstances change. Palark

This optimization particularly benefits clusters experiencing scheduler delays during high Pod churn periods. Operations like unschedulable status updates can be cancelled if a Pod gets successfully bound before the update completes, reducing unnecessary API server load. 

Enhanced NominatedNodeName field (Alpha - KEP-5278) improves scheduling predictability by creating bidirectional communication between the scheduler and external components like Cluster Autoscaler or Karpenter. This prevents resource waste during long Pod binding processes by maintaining scheduling decisions throughout the binding cycle.

Network and storage enhancements for modern workloads

Traffic Distribution Preferences are now generally available, with options like PreferSameZone and PreferSameNode for Service.spec.trafficDistribution fields. The PreferSameNode preference optimizes latency by prioritizing endpoints on the same node as the client, while PreferSameZone maintains the existing PreferClose behavior but with clearer semantics.

apiVersion: v1
kind: Service
spec:
  trafficDistribution: PreferSameNode  # Optimize for node-local traffic
  selector:
    app: cache-service

VolumeAttributesClass introduces dynamic, cloud-provider-agnostic management of volume performance attributes. This new resource type enables non-disruptive performance updates by switching volume classes without recreating persistent volumes, addressing the previous limitation of immutable StorageClass performance parameters.