Kubernetes 1.35 GA: an operations-side balance sheet

Actualizado: 2026-05-03

Kubernetes 1.35 reaches GA in June 2026, consolidating work spanning 1.33, 1.34, and now 1.35. After migrating several staging clusters in recent weeks, these are the points that matter to operators.

Key takeaways

• Native sidecar containers are fully GA, with polished lifecycle management eliminating race conditions from the classic initContainer pattern.
• Dynamic Resource Allocation (DRA) moves from experimental to available for non-GPU cases (FPGAs, NPUs, custom accelerators).
• The new scheduler “dynamic scoring” reduces resource waste in heterogeneous clusters by 15-25% in tests.
• Three items require review before migrating production: subtle API changes in alpha features, StatefulSet behaviour with volumes, and renamed scheduler metrics.
• Recommended strategy: canary in staging for two weeks, then one production node, observe a week, scale.

Sidecar containers fully GA

Native sidecar container support, which hit beta in 1.28 and stable in 1.33, is now GA with polished lifecycle management. It allows:

• Starting sidecars before the main container.
• Waiting for them to be ready (readiness probes respected).
• Terminating them after the main container finishes.

This is a big shift from the classic initContainer pattern with race conditions. The typical beneficiary use case: service mesh with proxy sidecar (Envoy, Linkerd), which now starts without ordering tricks in initContainers.

# Kubernetes 1.35: native sidecar
spec:
  initContainers:
  - name: proxy-sidecar
    image: envoy:v1.29
    restartPolicy: Always  # this makes it a sidecar, not an init container
  containers:
  - name: app
    image: myapp:latest

The restartPolicy: Always field on an initContainer is the signal Kubernetes 1.35 uses to treat it as a sidecar with the full lifecycle.

Generalised Dynamic Resource Allocation (DRA)

DRA has moved from experimental to available for non-GPU cases:

• FPGAs: declarative allocation of Intel or Xilinx FPGAs.
• NPUs: inference accelerators like the Apple Neural Engine or third-party equivalents.
• Custom accelerators: any hardware exposing a DRA driver can now integrate with the same declarative API as other resources.

Workloads needing specialised resources are now allocated with the same declarative API as other resources:

spec:
  resourceClaims:
  - name: fpga-claim
    resourceClaimTemplateName: fpga-template
  containers:
  - name: inference
    resources:
      claims:
      - name: fpga-claim

The existing device plugin ecosystem continues working, but DRA considerably simplifies developing new plugins for specialised hardware.

Scheduler improvements

The scheduler handles mixed workloads better with new “dynamic scoring”. In clusters with heterogeneous nodes (CPU-only nodes, GPU nodes, high-memory nodes), dynamic scoring distributes work more efficiently without requiring manual taints/tolerations for every workload combination.

Test results:

• 15-25% reduction in resource waste (unused CPU or memory on nodes where the workload doesn’t fit well) in mixed clusters.
• Less fragmentation: the scheduler packs workloads more densely when possible, freeing complete nodes for scale-down.

This improvement is transparent for most workloads — no manifest changes required.

Changes to check before migrating

Three items requiring review before updating production:

API changes in alpha features: some features in alpha in 1.33-1.34 have subtly changed API when promoted to beta in 1.35. Review release notes to detect if any alpha feature you used has changed schema. Usually affects feature gates explicitly activated.

StatefulSet behaviour with volumes: some edge cases in how Kubernetes 1.35 handles PVC failure in StatefulSets change the failure event ordering. StatefulSets depending on specific rollback behaviour on volume failure should be explicitly tested.

Renamed scheduler metrics: the scheduler has renamed several internal metrics to align with the new scoring system. Grafana dashboards using scheduler metrics must be reviewed:

• scheduler_queue_incoming_pods_total → unchanged
• scheduler_scheduling_duration_seconds → reviewed with new result labels
• Scoring plugin metrics: prefix changed from scheduler_plugin_ to scheduler_score_plugin_

Recommended migration strategy

The strategy that worked in staging:

1. Canary in staging for two weeks: run real production workloads on the 1.35 cluster. Validate critical sidecars, review scheduler dashboards, confirm StatefulSets behave correctly.
2. Migrate one production node: update one nodepool node, cordon the rest, observe for a week. If the scheduler assigns workloads to the 1.35 node without incidents, proceed.
3. Scale gradually: update the rest of the nodepool in 20-25% batches, with 24 hours of observation between batches.
4. Don’t migrate the whole fleet at once: scheduler changes can surprise in specific workloads with complex affinities or anti-affinities.

For clusters on 1.30 or earlier

For those still on 1.30 (or earlier versions no longer receiving active patch support), the strategy isn’t a direct jump to 1.35 but gradual jumps: 1.30 → 1.31 → 1.32 → 1.33 → 1.35. Each version jump has its own breaking changes and accumulated risk of a direct jump is high.

Conclusion

Kubernetes 1.35 is a consolidation release: doesn’t break big things but gathers improvements that together justify upgrading. For clusters already on 1.33 or 1.34, the upgrade is incremental with clear value — especially for clusters with service mesh (sidecars GA) or specialised hardware (generalised DRA). For anyone still on 1.30 or earlier, plan gradual jumps rather than a direct leap.