Kubernetes 1.35 - (Timbernetes): What changes for production

Kubernetes 1.35, Timbernetes: The World Tree Release, adds another “growth ring” focused on safer workload identity, more flexible workload lifecycle management, storage and scheduling improvements, and continued modernization of node networking and resource management. The official release announcement reports 60 enhancements—17 stable, 19 beta, and 22 alpha—and uses a World Tree inspired by Yggdrasil as its release theme and logo.

For production operators, the most consequential changes are the removal of cgroup v1 support, deprecation of kube-proxy’s IPVS mode, beta features enabled by default, and the final Kubernetes release supporting containerd 1.x.

Key Highlights and Graduations

Maturity levels matter operationally:

GA / Stable features are intended for production use and are enabled without an alpha or beta feature gate.
Beta features are generally suitable for broader evaluation, but their behavior can still evolve. Several v1.35 beta features are enabled by default.
Alpha features are intended for testing and feedback rather than unqualified production adoption.

The following sections summarize the notable changes documented in the Kubernetes 1.35 release announcement .

SIG Node

GA: In-place updates of Pod resources

In-place Pod resource updates are now generally available. CPU and memory requests or limits can be adjusted without restarting the affected Pod or container.

This is particularly valuable for stateful services, long-running batch jobs, and workloads for which Pod recreation is expensive or disruptive. It also enables vertical-scaling workflows with less application churn.

GA: Reliable Pod update tracking

Pods now have stable support for .metadata.generation. Kubernetes increments this value when a Pod specification changes.

The associated observability model includes:

.status.observedGeneration, indicating the generation processed by the kubelet.
An observedGeneration value on individual Pod conditions.

Controllers and operators can use these fields to distinguish between a requested Pod change and a change that the kubelet has actually observed—an important capability for in-place resource updates.

GA: Configurable NUMA-node limit

The topology manager’s max-allowable-numa-nodes policy option is stable. It replaces the historical hard-coded maximum of eight NUMA nodes and allows Kubernetes to use high-end systems with larger NUMA topologies.

This feature should still be performance-tested against representative hardware. The release announcement explicitly notes known poor performance on hosts with large NUMA configurations.

Beta: Node topology labels through the Downward API

The kubelet can expose standard node topology labels such as:

topology.kubernetes.io/zone
topology.kubernetes.io/region

Applications can consume these through environment variables or projected volume files without querying the Kubernetes API. This reduces the need for broad RBAC permissions or metadata sidecars.

After upgrading to v1.35, administrators should expect additional labels to appear on Pods. The release announcement identifies this as an intentional consequence of making topology labels available to the Downward API.

Beta: User namespaces for Pods

User namespace support allows containers to use isolated user and group ID mappings. A process can appear as root inside a container while mapping to an unprivileged identity on the host.

This reduces the impact of container compromise and is especially relevant for multi-tenant clusters or workloads that require root-like behavior inside the container. The feature supports both stateless and stateful Pods through ID-mapped mounts.

Beta: OCI image volumes

The image volume type allows data, configuration, binaries, and machine-learning models to be packaged as OCI artifacts and mounted as Pod volumes. This separates data artifacts from the primary application image and can eliminate custom download-and-unpack init containers.

The feature is enabled by default in v1.35. It requires a compatible container runtime; the release announcement specifically identifies containerd 2.1 or later as an example.

Beta: Credential verification for cached images

Kubernetes now enables kubelet credential verification for cached images by default. Previously, a Pod using imagePullPolicy: IfNotPresent could consume a private image already cached on a node even if that Pod lacked credentials to pull it.

The kubelet now checks whether the Pod has valid pull credentials before allowing access to the cached private image. Operators can:

Disable the behavior by setting the KubeletEnsureSecretPulledImages feature gate to false.
Configure the enforcement level using the imagePullCredentialsVerificationPolicy flag.

Clusters with shared worker nodes should evaluate this feature carefully because it closes an important multi-tenant isolation gap.

Beta: Fine-grained container restart rules

Regular containers and init containers can now define restartPolicy and restartPolicyRules independently of the Pod-wide restart policy.

This is useful for workloads such as AI/ML jobs where the overall Pod should not restart, but an individual container should recover from a known transient exit code. The feature is beta and enabled by default in v1.35.

Alpha: Node-declared features

With the alpha feature enabled, a Node can publish its supported Kubernetes features through .status.declaredFeatures.

Schedulers, admission controllers, and third-party components can use this information to avoid placing Pods on nodes that do not support required capabilities. This addresses compatibility risks during version-skew periods where control-plane components have been upgraded before every worker node.

Because this is alpha, clusters should not treat it as the sole production safeguard until its behavior and integration points have been validated.

Improved kubelet restart stability

The kubelet now restores existing container state from the runtime after restarting. This avoids unnecessarily marking otherwise healthy Pods as NotReady and removing them from load balancers during kubelet maintenance or upgrades.

SIG Apps and Autoscaling

GA: Job `managedBy` delegation

The Job API’s managedBy field is stable. It allows an external controller to manage Job synchronization while preventing the built-in Job controller from acting on that Job.

The primary documented use case is multi-cluster dispatch, where a Job created in a management cluster is mirrored into a worker cluster and its status is synchronized back. The field delegates controller ownership; it is not intended to pass arbitrary custom parameters or alter CronJob concurrency behavior.

Beta: StatefulSet `maxUnavailable`

For StatefulSets using a RollingUpdate strategy, maxUnavailable can define how many Pods may be unavailable during an update. It accepts either:

A positive integer, such as 2.
A percentage, such as 10%.

If omitted, the documented default is 1, preserving the prior one-at-a-time update behavior. The setting is especially effective with .spec.podManagementPolicy set to Parallel.

There is an important patch-level caveat: the supplied official 1.35 changelog records that v1.35.3 disabled the MaxUnavailableStatefulSet feature by default to address a v1.35 regression in parallel Pod management. Operators must therefore verify behavior against the exact v1.35 patch release they intend to deploy rather than relying only on the v1.35.0 release announcement.

Beta: Deployment terminating replica count

Deployment status now has beta support for terminatingReplicas, which counts Pods with a deletion timestamp that have not yet been removed.

This improves rollout and lifecycle observability. Controllers can determine whether shutdown or cleanup is still in progress without listing and filtering every Pod belonging to the Deployment.

Beta: Per-HPA scaling tolerance

HorizontalPodAutoscalers can configure tolerance per resource within the HPA behavior field. This replaces exclusive reliance on the historical global 10% tolerance.

For example, a workload can use a tolerance of 0.05 to react to a 5% metric deviation. This supports more sensitive scaling for critical workloads while allowing less sensitive workloads to avoid unnecessary oscillation. The feature is beta and enabled by default.

Alpha: Mutable resources for suspended Jobs

When the MutablePodResourcesForSuspendedJobs feature gate is enabled, resource requests and limits can be changed for a suspended Job.

This allows an operator to suspend a Job that is failing because of insufficient CPU or memory, correct its Pod template, and resume it without deleting the Job and losing its lifecycle identity or status history.

SIG Network and Cloud Provider

GA: `PreferSameNode` traffic distribution

Services gain stable, more explicit traffic-distribution semantics:

PreferSameNode prioritizes endpoints on the local node and falls back to remote endpoints.
PreferSameZone is the standard name for zonal preference.
The older PreferClose value remains available for backward compatibility.

This gives operators direct control over node-local and zone-local routing preferences while making the API terminology more self-explanatory.

Alpha: Watch-based cloud route reconciliation

The cloud-controller-manager library introduces an alpha, watch-based route-controller reconciliation strategy. Instead of periodically polling cloud-provider route state, the controller can react to relevant Node events through informers.

The intended benefits are lower cloud API consumption, reduced rate-limit pressure, and faster route updates after cluster-topology changes.

SIG Storage

Beta: Native storage-version migration

Native storage-version migration is beta and enabled by default. Migration logic is integrated into the Kubernetes control plane rather than requiring an external migration tool or manual read/write loops.

The built-in controller handles update conflicts and consistency tokens. This provides a safer mechanism for rewriting stored objects after schema changes or re-encryption operations, particularly for large or frequently updated resources.

Beta: Mutable CSI attachment limits

CSINode.spec.drivers[*].allocatable.count is now mutable, allowing CSI drivers to update a node’s available volume-attachment capacity dynamically.

Kubernetes can also update the value after an attachment failure caused by insufficient capacity. CSI drivers can control refresh frequency through the CSIDriver object.

The feature remains beta, but the MutableCSINodeAllocatableCount feature gate is enabled by default in v1.35. This should reduce cases where the scheduler places a stateful Pod on a node with exhausted attachment capacity and the Pod remains stuck in ContainerCreating.

Beta: CSI service-account tokens through the secrets field

CSI drivers can opt in to receiving ServiceAccount tokens through the dedicated secrets field of the NodePublishVolume request. Drivers enable this behavior by setting serviceAccountTokenInSecrets to true in their CSIDriver object.

This avoids passing credentials through volume_context, which is intended for non-sensitive configuration and may be logged by drivers or troubleshooting tools.

SIG Auth and Security

Beta: Native Pod certificates

The kubelet can generate keys, request certificates through PodCertificateRequest, and write rotating credential bundles directly into a Pod’s filesystem.

The API server enforces node restrictions during admission, helping third-party signers preserve node-isolation boundaries. This enables native workload identity and mTLS issuance flows without requiring bearer tokens in the certificate issuance path.

The practical impact is reduced dependence on external controllers, CRDs, Secrets, and certificate-rotation sidecars for supported workload-identity designs.

Alpha: Constrained impersonation

The ConstrainedImpersonation feature gate enables a secondary authorization check when a user impersonates another identity.

Policies can use verb prefixes such as:

impersonate-on:<mode>:<verb>

This makes it possible to authorize impersonation only for specific actions—for example, allowing support personnel to impersonate a privileged identity for log access without receiving all permissions associated with that identity.

As an alpha authorization feature, it requires focused security review and should be tested outside critical production paths first.

SIG Scheduling

Beta: Opportunistic batching

The scheduler can group compatible Pods using a Pod scheduling signature and reuse filtering and scoring results across the batch.

The mechanism has two documented operations:

create, which builds batch information from scheduling results for a Pod with a valid signature.
nominate, which reuses that information for a matching Pod.

The goal is to reduce redundant scheduler computation when multiple Pods are equivalent from a scheduling perspective.

Alpha: Gang scheduling

Kubernetes introduces native alpha support for gang scheduling through a new Workload API and PodGroup concept.

Gang scheduling uses an all-or-nothing model: an interdependent group of Pods is scheduled only when sufficient resources are available for the group. This targets AI/ML training, HPC, and parallel batch workloads that otherwise risk partial scheduling, deadlock, and wasted capacity.

Alpha: Extended toleration operators

Alpha numeric-comparison operators for tolerations allow workloads to express threshold-based placement requirements against SLA-oriented taints.

This can distinguish workloads requiring higher service guarantees from those permitted to use lower-SLA capacity. Production use should wait for validation of the alpha API and scheduling semantics.

SIG API Machinery and Architecture

Comparable resource-version semantics

For in-tree resources, v1.35 defines resource versions as a special form of decimal number that clients can compare. Before v1.35, clients were only supported in checking resource-version strings for equality or asking the API server to perform internal comparisons.

This change supports use cases such as detecting missed updates after reconnecting, improving informer behavior, and enabling reliable storage-version migration. Client implementations should still be reviewed carefully; the supplied source only guarantees these semantics for in-tree resource versions.

Dynamic Resource Allocation is always enabled

Core Dynamic Resource Allocation functionality became stable in v1.34 while still allowing operators to disable it. In v1.35, the core functionality is always enabled.

Additional alpha DRA work includes:

Improvements to extended-resource requests through DRA.
Device taints and tolerations.
A None effect for evaluating DeviceTaintRule impact before using NoExecute.
Status information for ongoing device eviction.
Partitionable devices represented across different ResourceSlice objects.
Fixes and additional testing for consumable capacity and device-binding conditions.

The inability to disable stable DRA functionality should be included in control-plane compatibility and policy reviews.

SIG CLI and Instrumentation

Beta: KYAML

KYAML, a safer and less ambiguous subset of YAML, is beta and enabled by default for kubectl. KYAML files remain valid YAML and can be consumed by older kubectl versions.

Users can disable this behavior by setting:

KUBECTL_KYAML=false

Teams with generated manifests, YAML-formatting checks, or output-parsing automation should test those workflows with the v1.35 client.

Beta: Credential-plugin policy in `kuberc`

The optional kuberc file gains:

credentialPluginPolicy, to allow or deny credential plugins.
credentialPluginAllowlist, to define permitted plugins.

This separates user-facing kubectl preferences from cluster credentials and gives administrators tighter control over executable credential plugins.

Alpha: Structured `/flagz` and `/statusz`

Authorized clients can request versioned JSON output from Kubernetes component /flagz and /statusz endpoints through standard HTTP content negotiation. Plain-text output remains available.

These alpha improvements make automated configuration audits, health inspection, and compliance checks less dependent on parsing unstructured text.

Deprecations, Removals, and Breaking Changes

Removed: cgroup v1 support

Kubernetes 1.35 removes cgroup v1 support. On Linux nodes that do not support or enable cgroup v2, the kubelet will fail to start.

Required operator action:

Identify every Linux worker and control-plane node still using cgroup v1.
Move affected nodes to an operating system and configuration with cgroup v2 enabled.
Validate kubelet and container-runtime compatibility before upgrading the node to v1.35.

This is the clearest node-level breaking change in the release and must be resolved before rollout.

Deprecated: kube-proxy IPVS mode

Kubernetes 1.35 deprecates kube-proxy’s ipvs mode. It remains available in this release, but kube-proxy emits a startup warning when configured to use it.

For Linux nodes, the release announcement recommends beginning a transition to nftables. The supplied excerpts do not define a removal release or provide a complete migration procedure, so operators should verify their CNI, kernel, service behavior, and kube-proxy configuration against the official documentation before changing modes.

Final Kubernetes release supporting containerd 1.x

Kubernetes 1.35 still supports containerd 1.7 and other 1.x LTS releases, but it is the final Kubernetes release supporting the containerd 1.x series.

Before upgrading beyond Kubernetes 1.35, clusters must move to containerd 2.0 or later. The release announcement identifies the kubelet_cri_losing_support metric as the mechanism for locating nodes that need attention.

This lifecycle notice is separate from the OCI image-volume requirement: using image volumes requires a compatible runtime, with containerd 2.1 or later given as an example.

Ingress NGINX retirement

Ingress NGINX retirement is not strictly part of Kubernetes 1.35, but the release team highlighted it because of its operational significance.

The project is scheduled to receive best-effort maintenance until March 2026 and then be archived without further updates. The recommended migration direction is Gateway API.

Clusters should inventory Ingress resources, annotations, controller-specific behaviors, and external integrations before planning that migration.

API and flag-removal verification

The supplied release excerpts do not enumerate additional removed API versions or provide the full v1.35.0 urgent-upgrade notes. Do not assume that the items above constitute an exhaustive compatibility matrix.

Before upgrading, manually review the v1.35.0 sections titled Urgent Upgrade Notes, Deprecation, and API Change in the official Kubernetes 1.35 changelog . The provided changelog is a branch-wide document containing later v1.35 patch releases, so distinguish v1.35.0 changes from subsequent backports and behavioral corrections.

Upgrade Impact and Operational Notes

Before upgrading the control plane

Read the complete v1.35 changelog , especially the v1.35.0 urgent-upgrade notes.
Confirm that admission webhooks, API clients, controllers, and operators are compatible with v1.35.
Review clients that interpret resource versions. The new comparable semantics are explicitly documented for in-tree resources; avoid extending that guarantee to unsupported resource types.
Account for native storage-version migration being beta and enabled by default.
Review DRA policies and integrations because stable DRA core functionality can no longer be disabled.
Test kubectl automation against KYAML’s default-enabled beta behavior.
Verify feature-gate expectations against the exact patch release being deployed.

No minimum etcd version, operating-system version, or general container-runtime minimum for the base v1.35 release is established by the supplied excerpts; those requirements require manual verification in the full release notes and installation documentation.

Before upgrading worker nodes

Ensure every Linux node uses cgroup v2. A kubelet on cgroup v1 will not start under Kubernetes 1.35.
Inventory container-runtime versions. Containerd 1.x remains supported only through Kubernetes 1.35.
If using OCI image volumes, verify runtime compatibility; the release announcement cites containerd 2.1 or later.
Review kube-proxy mode. Existing IPVS configurations continue to run in v1.35 but are deprecated and produce a startup warning.
Evaluate the default-enabled cached-image credential verification behavior, particularly for private registries and multi-tenant nodes.
Expect additional Pod labels associated with exposing node topology through the Downward API.
Validate CSI drivers against mutable attachment counts and the optional serviceAccountTokenInSecrets behavior.
Test kubelet restart and node-maintenance procedures to confirm expected Pod readiness behavior in the local environment.

Mixed-version and staged rollouts

The alpha node-declared-features framework exists specifically to help components reason about capabilities while nodes lag behind the control plane. However, because it is alpha, it should not be treated as a substitute for a tested staged-upgrade plan.

During a rollout:

Upgrade and validate the control plane using the procedure supported by the cluster’s installation or managed-service platform.
Upgrade a limited worker-node pool first.
Exercise scheduling, storage attachment, private-image pulls, kube-proxy service routing, and kubelet restart behavior.
Observe StatefulSet, Deployment, Job, HPA, and CSI behavior before proceeding to the remaining nodes.
Confirm the behavior of beta features against the selected patch release.

The supplied sources do not provide a complete, universally applicable control-plane or worker-node command sequence. Upgrade commands vary by installation method, so they should be taken from the appropriate section of the official Kubernetes documentation rather than inferred here.

Patch-release awareness

The branch-wide changelog supplied with this release includes fixes through later v1.35 patch versions. It records, among other changes, a v1.35.3 correction that disabled MaxUnavailableStatefulSet by default following a regression.

This reinforces an important operational rule: plan against the exact patch version being installed, not only the v1.35.0 feature announcement. Review all intervening bug, regression, dependency, and urgent-upgrade notes when adopting a later patch.

Conclusion

Kubernetes 1.35 combines mature production capabilities—such as in-place Pod resource updates, Pod generation tracking, Job controller delegation, and explicit Service traffic preferences—with a substantial set of default-enabled beta security, storage, and lifecycle features. Its World Tree theme is appropriate: the release grows Kubernetes in several directions while also pruning legacy foundations such as cgroup v1 and beginning the retirement path for kube-proxy IPVS mode and containerd 1.x support.

The upgrade deserves careful node-level preparation. Confirm cgroup v2 first, inventory container runtimes and kube-proxy modes, test default-enabled beta features, and always reconcile the release announcement with the exact v1.35 patch changelog before production rollout.