Kubernetes 1.35 reaches GA in June 2026, consolidating work spanning 1.33, 1.34, and now 1.35. After the staging migrations of 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 lets new plugins for specialised hardware build on that same declarative API.

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. In general, 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 internal metrics, such as the scoring plugin prefix, 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_

The strategy that worked in staging:

  • 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.

  • 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.

  • Scale gradually: update the rest of the nodepool in 20-25% batches, with 24 hours of observation between batches.

  • 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 jump to 1.35 isn’t direct, it’s gradual. The path is 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.

Frequently asked questions

How do you declare a native sidecar in Kubernetes 1.35?

Define it as an initContainer with restartPolicy: Always; that field is the signal Kubernetes 1.35 uses to treat it as a sidecar with the full lifecycle. The sidecar then starts before the main container, is waited on until ready with its readiness probes respected, and is terminated after the main container finishes. The biggest beneficiary is a service mesh with an Envoy or Linkerd proxy, which no longer needs ordering tricks in initContainers.

What should I check before upgrading production to Kubernetes 1.35?

Three things. First: alpha features from 1.33-1.34 whose API changed subtly when promoted to beta, in general feature gates you activated explicitly. Second: StatefulSet behaviour on PVC failure, where the failure event ordering changes in some edge cases. Third: renamed scheduler metrics, such as the scoring plugin prefix moving from scheduler_plugin_ to scheduler_score_plugin_, which means reviewing your Grafana dashboards.

Can I jump straight from Kubernetes 1.30 to 1.35?

Not advisable: the accumulated risk of a direct jump is high. For clusters on 1.30 or earlier the strategy is gradual jumps, 1.30 to 1.31, 1.32, 1.33 and then 1.35, because each version has its own breaking changes. For clusters already on 1.33 or 1.34 the upgrade is incremental: canary in staging for two weeks, then one production node observed for a week. After that, the rest of the nodepool moves in 20-25% batches with 24 hours between them.