Kubernetes 1.34 for Platform Teams

The Problem#

Kubernetes releases contain many changes, but platform teams need to know which ones affect cluster policy, workload identity, AI hardware, and developer experience.

Why It Matters#

Kubernetes 1.34 made Dynamic Resource Allocation stable and added important security and workload-management features. These matter for GPU-heavy workloads, private image pulls, and stronger workload identity.

Core Concepts#

Dynamic Resource Allocation lets workloads request devices such as GPUs through structured claims. Pod certificates introduce a native path for pod mTLS identity. Projected service account tokens for image credential providers reduce long-lived image pull secrets. Runtime env files help init containers pass generated values to app containers.

Implementation#

Platform teams should test feature gates and policies in a staging cluster:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: gpu-claim
spec:
  spec:
    devices:
      requests:
        - name: gpu
          deviceClassName: nvidia-gpu

Pair this with admission policies that control who can request scarce hardware.

Real Project Scenario#

An internal ML platform lets teams request GPUs for batch jobs and model serving. Without policy, one namespace can consume scarce accelerators and block critical workloads. DRA gives a structured way to request devices, but platform teams still need quotas, admission rules, and dashboards.

Production Setup#

Roll new Kubernetes features through a staging cluster first. Validate scheduler behavior, autoscaler behavior, device plugin compatibility, monitoring, and rollback. For GPU workloads, track pending pods, device allocation time, utilization, and failed claims by namespace.

Common Mistakes#

• Upgrading control planes without validating cluster add-ons.
• Treating GPU allocation as only a scheduler problem.
• Leaving image pull credentials as broad, long-lived secrets.
• Enabling alpha features without an owner and rollback plan.

Production Considerations#

Inventory workloads that use devices, private registries, and custom admission controllers. Test node upgrades, autoscaling, and monitoring before production rollout.

Security#

Move toward short-lived workload identity wherever possible. Pod certificates and audience-bound tokens reduce credential lifetime and blast radius.

Performance#

DRA helps express device requirements, but capacity is still finite. Track pending pods, claim allocation time, and GPU utilization by team.

Summary#

Kubernetes 1.34 is especially relevant for platform teams running AI, GPU, or security-sensitive workloads. Treat the upgrade as a policy and operations change, not only a version change.