As Kubernetes v1.35 nears release, the project continues its evolution through strategic deprecations, removals, and feature enhancements designed to strengthen overall system health. This article examines the key changes planned for v1.35 that cluster administrators and developers should understand to maintain operational continuity and stay current with platform developments. Note that all information reflects the current release status and may shift before final availability.
Deprecations and removals for Kubernetes v1.35
cgroup v1 support
Linux-based container runtimes have long depended on cgroups (control groups) for resource management. Kubernetes achieved stable cgroup v2 support in v1.25, offering a modern alternative to the original v1 implementation. The legacy v1 architecture, while foundational, exhibited documented inconsistencies and architectural constraints. The v2 implementation delivers a unified control hierarchy, enhanced resource isolation, and infrastructure for contemporary features—making v1 support obsolete.
This removal affects administrators operating nodes on older Linux distributions lacking cgroup v2 support. On incompatible systems, the kubelet will fail to initialize. Migration to cgroup v2-enabled distributions is required. Detailed compatibility guidance will appear in a dedicated blog post following the v1.35 launch.
For technical background, consult the cgroup v2 documentation and track implementation progress through KEP-5573: Remove cgroup v1 support.
Deprecation of ipvs mode in kube-proxy
The ipvs mode in kube-proxy was introduced to deliver high-performance service load balancing with superior throughput compared to iptables mode. However, maintaining feature parity across proxy modes proved increasingly complex due to technical constraints and divergent architectural requirements. This created substantial technical debt and hindered integration with emerging networking capabilities.
Kubernetes v1.35 will deprecate the ipvs mode to streamline the kube-proxy codebase. For Linux nodes, nftables is now the recommended mode.
Full details are available in KEP-5495: Deprecate ipvs mode in kube-proxy.
Kubernetes is deprecating containerd v1.y support
While Kubernetes v1.35 maintains compatibility with containerd 1.7 and other LTS releases, SIG Node has established a definitive support timeline for containerd v1.X. Following automated cgroup driver detection improvements, v1.35 marks the final release supporting containerd 1.X (aligned with containerd 1.7 end-of-life).
Administrators running containerd 1.X must upgrade to version 2.0 or later before advancing to the next Kubernetes release. The kubelet_cri_losing_support metric enables monitoring of nodes using soon-to-be-unsupported containerd versions.
Additional context is available in the official announcement and KEP-4033: Discover cgroup driver from CRI.
Featured enhancements of Kubernetes v1.35
The following enhancements represent likely inclusions in v1.35, though final release content remains subject to change.
Node declared features
Kubernetes currently relies on node labels, taints, and tolerations to match workload requirements with node capabilities. During cluster upgrades, version skew between control plane and nodes complicates feature compatibility management, potentially causing Pods to land on nodes lacking required features—resulting in runtime failures.
The node declared features framework introduces a standardized mechanism for nodes to advertise supported Kubernetes features. When enabled, nodes report capabilities to the control plane via a new .status.declaredFeatures field. The kube-scheduler, admission controllers, and third-party components can then leverage these declarations to enforce scheduling and validation constraints, ensuring Pods execute only on compatible nodes.
This mechanism eliminates manual node labeling, improves scheduling precision, and proactively prevents incompatible placements. It also integrates with Cluster Autoscaler for informed scaling decisions. Feature declarations are ephemeral and tied to Kubernetes feature gates, enabling safe rollout and cleanup.
Targeting alpha in v1.35, node declared features addresses version skew scheduling challenges by making node capabilities explicit, enhancing reliability and stability in heterogeneous environments.
Pre-release technical details are available in KEP-5328.
In-place update of Pod resources
Kubernetes is promoting in-place Pod resource updates to General Availability. This capability allows runtime adjustment of cpu and memory allocations without Pod or Container restarts. Previously, resource modifications required Pod recreation, disrupting workloads—particularly stateful or batch applications.
Earlier releases introduced the ability to modify infrastructure resource settings (requests and limits) for running Pods, enabling smoother vertical scaling, improved efficiency, and simplified solution architecture.
The Container Runtime Interface (CRI) has been enhanced with an extended UpdateContainerResources API supporting Windows and future runtimes, while ContainerStatus now reports real-time resource configurations. These improvements make Kubernetes scaling faster, more flexible, and disruption-free.
The feature debuted as alpha in v1.27, advanced to beta in v1.33, and targets stable graduation in v1.35.
See KEP-1287: In-place Update of Pod Resources for complete details.
Pod certificates
Microservices architectures frequently require Pods to establish strong cryptographic identities for mutual TLS (mTLS) authentication. While Kubernetes provides Service Account tokens, these are designed for API server authentication rather than general workload identity.
Prior to this enhancement, operators depended on external solutions like SPIFFE/SPIRE or cert-manager for certificate provisioning and rotation. KEP-4317 enables native workload identity by allowing the kubelet to request and mount certificates for Pods via projected volumes.
This provides built-in workload identity with automated certificate rotation, dramatically simplifying service mesh deployment and zero-trust network policy implementation. The feature launched as alpha in v1.34 and targets beta in v1.35.
Technical specifications are in KEP-4317: Pod Certificates.
Numeric values for taints
Kubernetes is expanding taints and tolerations with numeric comparison operators including Gt (Greater Than) and Lt (Less Than).
Previously, tolerations supported only exact (Equal) or existence (Exists) matching, inadequate for numeric properties such as reliability SLAs.
This enhancement enables Pods to use tolerations for threshold-based node selection. For instance, a Pod can require nodes with SLA taint values exceeding 950 (operator: Gt, value: "950").
This approach surpasses Node Affinity by supporting the NoExecute effect, enabling automatic Pod eviction when node numeric values fall below tolerated thresholds.
Details are in KEP-5471: Enable SLA-based Scheduling.
User namespaces
While securityContext enables privilege reduction, containers frequently run as root (UID 0). This creates security exposure, as container UID 0 maps directly to the host's root user.
Before this enhancement, container breakout vulnerabilities could grant attackers full node root access. KEP-127 provides native Linux User Namespaces support, enabling dynamic remapping of container root users to unprivileged host users. This isolates container and host user/group IDs, allowing processes to maintain root privileges (UID 0) within their namespace while executing as non-privileged, high-numbered UIDs on the host.
Released as alpha in v1.25 and beta in v1.30, this feature continues maturing through beta, enabling truly rootless containers that substantially reduce attack surfaces for entire vulnerability classes.
See KEP-127: User Namespaces for implementation details.
Support for mounting OCI images as volumes
Pod provisioning often requires bundling data, binaries, or configuration files for containers. Traditionally, this data was embedded in container images or required custom init containers to download and unpack files into emptyDir volumes.
Kubernetes v1.31 introduced the image volume type, enabling Pods to pull and unpack OCI container image artifacts into volumes declaratively, treating data artifacts like container images from OCI registries.
This capability streamlines the distribution of data, binaries, and machine learning models through standard OCI registry tooling. By decoupling data from container images, teams can eliminate the complexity of init containers and custom startup scripts. The feature has been available in beta since Kubernetes v1.33, with general availability expected by default in v1.35.
Explore the beta implementation of image volumes in the official documentation, or review the technical specification in KEP-4639: OCI Volume Source.
Want to know more?
Each Kubernetes release includes detailed documentation of new features, enhancements, and deprecations. The complete changelog for Kubernetes v1.35 will provide comprehensive coverage of all changes when the release ships.
Kubernetes v1.35 is scheduled for release on December 17, 2025. Watch for additional announcements as the date approaches.
For context on recent platform evolution, review the changelogs from previous releases:
Get involved
Contributing to Kubernetes starts with joining a Special Interest Group (SIG) aligned with your expertise or interests. To share ideas with the broader community, participate in the weekly community meeting or engage through any of the channels below.
- Follow @kubernetes.io on Bluesky for project updates
- Participate in technical discussions on Discuss
- Connect with the community on Slack
- Ask or answer questions on Server Fault and Stack Overflow
- Share your Kubernetes implementation story
- Read project news and technical deep dives on the Kubernetes blog
- Learn about release processes from the Kubernetes Release Team
