Kubernetes 1.35 is primarily an operations-focused release: it graduates in-place pod resource updates to GA, strengthens native workload identity and certificate automation, and signals deprecation paths for legacy networking and runtime components. For platform teams and managed-service operators, these changes reduce day-to-day toil but require disciplined upgrade, testing, and migration work.
In-place pod resource updates (GA)
What changed
Kubernetes 1.35 graduates in-place updates to Pod resources: spec.containers[].resources can be modified and the kubelet will apply the new cgroup settings to running containers without restarting the container process. This enables vertical tuning of long-lived workloads (stateful services, inference servers) without rolling pods.
How it works
The control plane accepts a Pod spec update and the kubelet uses the container runtime interface (CRI) to apply updated CPU/memory limits/requests to the running container. Because the process is not restarted, liveness/readiness probes remain uninterrupted, but application-level behavior may still be affected (for example, JVM heap size does not reconfigure itself without app support).
Operational considerations
- Ensure your kubelet and CRI/runtime support in-place updates end-to-end before rolling out (check your distro or managed-provider notes).
- VPA behavior changes: VPA controllers can recommend and, where permitted by policy, apply resource changes without forcing restarts. Update VPA configuration and policies accordingly.
- Not every change is safe: reducing memory can cause OOMs; CPU throttling can affect latency-sensitive services.
Example: patch a pod in-place and verify no restart
# Increase requests/limits in-place on a Pod (Kubernetes 1.35+)
kubectl patch pod my-app-0 -n prod \
--type='merge' \
-p '{"spec":{"containers":[{"name":"my-app","resources":{"requests":{"cpu":"500m","memory":"512Mi"},"limits":{"cpu":"1000m","memory":"1Gi"}}}]}}'
# Confirm the container didn't restart
kubectl get pod my-app-0 -n prod -o jsonpath='{.status.containerStatuses[0].restartCount}\n'
# Inspect the Pod spec to confirm the new resource values
kubectl get pod my-app-0 -n prod -o jsonpath='{.spec.containers[0].resources}\n'Before rolling out broadly, add these tests to CI: kubelet/CRI compatibility checks, application-level memory/CPU scaling tests (JVMs, native binaries), and observability verification that metrics and logs remain intact after in-place changes.
Native workload identity and automated certificate rotation
What changed
1.35 formalizes stronger, native workload identity patterns and improves certificate lifecycle automation. The TokenRequest API and projected service account tokens with audience constraints are the standardized primitives for workload identity, reducing reliance on long-lived service-account secrets or external file-based keys. Certificate controllers gain richer rotation automation and improved status surfaces for expiry visibility.
Operational advice
- Audit existing cloud-provider integrations and long-lived secrets. Migrate where possible to projected, audience-bound tokens and short-lived credentials.
- Ensure admission controllers, sidecars, and libraries accept and validate TokenRequest-style tokens and audience fields.
- Replace ad-hoc certificate cronjobs with alerting based on the enhanced certificate status fields and controller metrics. Verify CSR controllers and certificates.k8s.io components are healthy and instrumented.
Scheduling and scaling improvements
What changed
The scheduler and related scaling heuristics are tuned to reduce thrash under bursty scale-up patterns common to batch and model-serving workloads. Scoring and backoff heuristics receive adjustments to avoid excessive requeueing and to improve placement for resource-dense nodes.
Operational implications
- Expect fewer pointless scheduling cycles for short-lived unschedulable pods due to improved backoff/requeue behavior.
- If you run device-plugin workloads (GPUs/NPUs), verify your plugin uses the PodResources API and that scheduler predicates/scoring consider device topology.
- Re-evaluate interactions between HPA, VPA, and the scheduler: in-place updates affect VPA restart behavior, but HPA still creates new pods and drives scheduling pressure. Test mixed scale-up scenarios.
Platform shifts: kube-proxy IPVS deprecation and containerd v1.x
kube-proxy IPVS deprecation
1.35 marks kube-proxy IPVS mode as deprecated. The release encourages moving to modern alternatives such as nftables-based proxying (where supported) or eBPF-based dataplanes (Cilium and similar projects) that provide richer observability and policy capabilities.
Migration checklist
- Validate kernel nftables support and module availability on all node SKUs before switching modes.
- Test service connectivity, session affinity, and performance under the replacement proxy.
- Evaluate eBPF CNIs for feature parity (load-balancing, connection tracking, DNS interception) and migration complexity.
containerd v1.x
The release signals a removal path for older containerd v1.x releases in a later version. If your nodes run containerd v1.x, begin planning upgrades to a supported runtime version per your distribution or vendor guidance. Validate CRI compatibility, the availability of pause images, and node-level tooling (metrics, logging, image pruning).
Upgrade and testing guidance
- Treat 1.35 as a candidate where benefits (in-place tuning, identity, cert automation) can reduce ops toil, but only adopt after canary testing.
- Build a test matrix that covers in-place resource updates, mixed HPA/VPA scale-ups, device-plugin scheduling, and mutating admission behavior. Test both application-level reactions (heap resizing, thread pools) and infra-level telemetry (cgroup metrics, kubelet logs).
- If you depend on kube-proxy IPVS, schedule migration work. Prototype nftables or eBPF alternatives and validate session affinity and latency under representative workloads.
- Replace long-lived credentials and mounted secrets with projected, audience-bound tokens; audit admission and sidecar tooling to prevent token leakage into logs or metrics.
- Replace manual certificate cronjobs with monitors and alerts based on the enhanced certificate status fields and controller metrics.
Managed clusters
If you run managed clusters (GKE or other providers), align upgrades with the provider's release notes. Managed platforms may surface provider-side features (observability defaults, certificate expiry insights, admission policy changes) that affect your upgrade and bootstrapping processes.
Summary
Kubernetes 1.35 emphasizes operational stability: GA in-place resource updates reduce the need to restart long-lived containers for vertical tuning, native workload identity and automated cert rotation reduce secret-handling toil, and deprecations (kube-proxy IPVS, older runtimes) signal migration work ahead. Capture the benefits by planning canary upgrades, expanding CI tests, and validating networking and runtime compatibility before cluster-wide rollouts.