Kubernetes 1.35 is fast approaching, and it’s a loaded update! Removing enhancements with the status of “Deferred” or “Removed from Milestone” we have 59 Enhancements in all listed within the official tracker. So, what’s new in 1.35?

Kubernetes 1.35 brings a whole bunch of useful enhancements, including 30 changes tracked as ‘Graduating’ in this Kubernetes release. From these, just 15 enhancements are graduating to stable, such as the addition of Kubelet option to specify the maximum age an image that will be kept around before it’s garbage collected. This is beneficial to cluster admins because unused images can now be garbage collected in a timely manner, no longer occupying disk space forever.

A whopping 14 new alpha features are also listed in the enhancements tracker, one of which introduces some new authorisation rules to restrict impersonation on specified resources with specified actions. We also see support for in-place resizing of pod-level resources, support for restarting all containers within the pod when a container exits as a containerRestartRule, and so much more in this release.

This is the most detailed Cloudsmith release notes to date, and our team is really excited about this release and everything that comes with it! Let’s jump into all of the major features, changes, and deprecations in Kubernetes 1.35.

Kubernetes 1.35 – Editor’s pick:

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

#3331 Structured Authentication Config

I’m excited to see structured auth config graduate to stable in Kubernetes 1.35 because it marks a major step forward in making cluster authentication both more flexible and maintainable. The current flag-based OIDC setup has long been a pain point, as it’s hard to extend, oftentimes difficult to manage, and is limited in how it maps identity claims. Moving to a versioned, structured configuration not only modernises this critical component but also unlocks long-requested capabilities like supporting multiple client IDs, richer claim mappings, and dynamic reloading of authentication settings without restarting the API server. This enhancement brings much-needed clarity and power to authentication workflows, simplifies life for operators, and sets a strong foundation for future innovations in identity and access control in Kubernetes.

Nigel Douglas - Head of Developer Relations

#5007 Device Binding Conditions in DRA

The feature I’m happy to see graduating to beta status in Kubernetes 1.35 is the binding conditions within Dynamic Resource Allocation. This looks to be a significant step towards making Kubernetes the definitive platform for demanding AI/ML workloads. This improvement provides the critical intelligence for schedulers to handle complex, disaggregated hardware like fabric-attached GPUs robustly, preventing failed deployments and enabling more efficient, dynamic resource allocation. The beta graduation signals that this powerful feature is almost stable and ready for broader adoption within the ecosystem, hopefully paving the way for more resilient, dedicated AI infra in Kubernetes.

Claire McDyre - Product Manager

#3673 Kubelet limit of Parallel Image Pulls

We are all delighted to see this new Stable update address the existing, ineffective method Kubernetes currently uses to limit container image pulls on a node. The existing QPS (Queries Per Second) and Burst limits are really confusing as they only control the rate of requests to the container runtime, not the number of concurrent pulls. This can sadly lead to an unlimited number of simultaneous downloads, potentially overwhelming a node's disk I/O and network bandwidth. This new change adds a more intuitive kubelet config field called maxParallelImagePulls. This setting establishes a clear, node-level limit on how many images can be pulled at the same time. Any pull request that exceeds this limit will be blocked until an ongoing pull completes - improving how cluster admins manage their resource consumption.

Ciara Carey - Solution Engineer

Apps in Kubernetes 1.35

#961 maxUnavailable for StatefulSets rolling updates

Stage: Graduating to Beta
Feature group: sig-apps

This Beta feature introduces a maxUnavailable setting for StatefulSet RollingUpdate strategies. Previously, when updating a StatefulSet, pods were terminated and recreated strictly one at a time, which could be very slow. This enhancement allows users to specify the maximum number of pods that can be unavailable during an update, either as an absolute number or a percentage. This means multiple pods can be updated simultaneously, dramatically speeding up the rollout process.

The primary motivation is to make StatefulSet updates faster and more flexible, bringing them closer to the functionality of Deployments. This is particularly useful for stateful applications that can tolerate multiple replicas being down at once (like a cluster with many followers) or for applications with long startup times (like cache loading). By allowing parallel updates, this feature helps users who prefer the stable network identities of StatefulSets but need the faster rollout capabilities typically associated with Deployments. The default value for maxUnavailable is 1, ensuring backward compatibility and maintaining the safe, one-by-one update behaviour for applications that require it.

#4368 Job API managed-by mechanism

Stage: Graduating to Stable
Feature group: sig-apps

This feature introduces a new managedBy field to the Kubernetes Job specification. Its primary purpose is to delegate the management and status synchronisation of a Job to an external controller, effectively telling the default Kubernetes Job controller to ignore it. This is a lightweight, per-Job mechanism designed to prevent conflicts when another system needs to take control. The main motivation for this is to support MultiKueue, a multi-cluster job dispatcher that runs a "mirror" copy of a Job on a separate worker cluster while managing the original Job on a central management cluster. The managedBy field allows the MultiKueue controller to sync the status from the worker cluster back to the management cluster without the default controller interfering.

A key design decision is that the managedBy field is immutable, meaning it can only be set when the Job is created and cannot be changed later. This choice was made to avoid complex issues and potential errors, such as "leaking" pods, which could occur if control of a running Job were switched between different controllers. This approach provides clear ownership throughout the Job's lifecycle and follows a pattern already used by other Kubernetes resources, making it a stable and predictable solution for developers of custom batch processing systems.

#5440 Mutable Container Resources when Job is suspended

Stage: Net New to Alpha
Feature group: sig-apps

This Kubernetes enhancement proposes allowing users to modify the container resource requirements (like CPU and memory) on a job's template while that job is suspended. Currently, this is not possible. The primary motivation is to give users, particularly those using queuing systems like Kueue, the flexibility to adjust a job's resource needs before it resumes, which can improve scheduling efficiency. While a proof-of-concept exists for standard resources, the implementation faces a significant hurdle with the newer Dynamic Resource Allocation (DRA) framework, as its resource templates are immutable, and a clear path forward for DRA support is still under discussion.

Initially, the team considered releasing this feature directly as a 'beta' version, enabled by default, viewing the risk as low. However, concerns arose about completing the necessary comprehensive testing within a short development cycle. Specifically, addressing potential race conditions, such as one user updating resources while another unsuspends the job was deemed critical but complex to test reliably. Given these challenges and the potential for unforeseen consequences when loosening API validation rules, the consensus shifted. It looks like the feature will now be introduced in an 'alpha' stage to allow for more iteration and the development of robust test coverage, ensuring the feature is stable and safe before being promoted.

API in Kubernetes 1.35

#4020 Unknown Version Interoperability Proxy

Stage: Net New to Alpha
Feature group: sig-api-machinery

Disabled by default, the Mixed Version Proxy aims to address the version skew issues within Kubernetes clusters during upgrades or downgrades by ensuring that clients always interact with a complete view of the cluster's capabilities. To achieve this, the proposal introduces a proxying mechanism where an API server, upon receiving a request for a built-in resource it cannot serve locally, identifies and forwards the request to a peer server that can. This prevents misleading "404 Not Found" errors. Simultaneously, the feature implements peer-aggregated discovery, which merges resource information from all peer API servers into a unified discovery document. This ensures that clients using the aggregated discovery endpoint receive a comprehensive list of all available resources across the cluster, regardless of which individual server they contact.

This mechanism is critical for maintaining system stability and data integrity during version transitions. Without it, controllers like the Garbage Collector or Namespace Lifecycle Controller might act on incomplete information, potentially leading to the incorrect deletion of objects or operational deadlocks. By ensuring that requests yield either the correct resource or a safe "503 Service Unavailable" (rather than a "404"), the system protects against destructive actions while allowing valid operations to proceed. It is important to note that this peer-aggregation logic applies only to the aggregated discovery endpoint (/apis) and excludes the legacy core endpoint (/api), as the core/v1 group's top-level types are considered frozen and will not require dynamic merging.

#4006 Transition from SPDY to WebSockets

Stage: Graduating to Stable
Feature group: sig-api-machinery
Feature gate: AuthorizePodWebsocketUpgradeCreatePermission Default value: TRUE

In Kubernetes v1.35, a new Beta security feature for synthetic RBAC CREATE Authorisation checks has been introduced as part of this Stable graduation. This feature enhances security by forcing an additional authorisation check when a user attempts to establish a persistent, two-way connection to a pod using commands like kubectl exec, attach, or port-forward. Previously, these actions were authorised with a CONNECT permission; now, this update adds a check for a CREATE permission on the corresponding subresource. This ensures that only users with appropriate creation rights can initiate these powerful, interactive sessions with pods.

This security enhancement is part of a much larger and more significant update: the migration from the outdated SPDY protocol to modern WebSockets for streaming communication. The SPDY protocol has been deprecated since 2015 and is no longer supported by many modern proxies and load balancers, causing connectivity issues. By transitioning to WebSockets, a current industry standard, Kubernetes ensures better compatibility and reliability for essential developer commands. In essence, this update modernises a critical communication pathway in Kubernetes while simultaneously tightening the security around it.

#4192 Move Storage Version Migrator in-tree

Stage: Graduating to Beta
Feature group: sig-api-machinery

Kubernetes occasionally needs to rewrite stored resource data, a process essential for maintenance activities like upgrading a resource's schema version (example: from v1beta1 to v1) or re-encrypting data at rest after an encryption key change. The traditional method for this, using manual kubectl get or kubectl replace commands, is inefficient and impractical, especially for large resources like Secrets, and does not scale as the number of resources grows. This manual process is cumbersome and requires significant automation to be performed reliably across a cluster.

To address these challenges, this Kubernetes Enhancement Proposal (KEP for short) suggests integrating the logic from the existing Storage Version Migrator (SVM) tool directly into the Kubernetes Controller Manager (KCM). This would create a native, in-tree controller and API dedicated to storage migration. The primary goal is to provide administrators with a simple, reliable way to trigger these migrations without manual commands. This change would enable infrastructure providers to automate migrations in response to environmental events, such as a key rotation in a Key Management Service (KMS), and would streamline the process for users who currently rely on the external SVM tool. While the migration process will be simplified, the responsibility to initiate it will remain with the user.

#5589 Remove gogo protobuf dependency for Kubernetes API types

Stage: Major Change to Stable
Feature group: sig-api-machinery

In early October, the Kubernetes development team initiated a significant change by starting the process of removing a dependency called gogo protobuf. This component is a toolchain that Kubernetes has been using to automatically generate the Go code necessary for handling its REST API data structures. The core of this feature is to replace an unmaintained and outdated part of the Kubernetes system to enhance security, stability, and future maintainability.

The primary motivation for this change is that gogo protobuf has not been maintained since 2021, which introduces several risks. Relying on an unmaintained dependency means that any newly discovered security vulnerabilities or bugs cannot be easily fixed. Furthermore, every developer or business that uses Kubernetes' core libraries is forced to inherit this unmaintained dependency, creating a wider security concern. This change also aims to prevent accidental misuse of the API types with standard protobuf libraries, which has caused system crashes in other projects. By removing gogo, the generated code will be streamlined to include only what is essential for Kubernetes client and server operations, making the system more robust and secure.

#5004 Comparable Resource Version

Stage: Graduating to Stable
Feature group: sig-api-machinery

This now merged pull request formalises the behaviour of the resourceVersion field. Currently, clients are meant to treat resourceVersion as an opaque string, only allowing for equality checks. However, the internal Kubernetes API server implements it as a monotonically increasing integer. This enhancement officially defines that resourceVersion should be a comparable, monotonically increasing integer, allowing clients to reliably determine the order of resource updates, which is a growing need. The proposal includes adding a utility function for clients to safely compare two resource versions and adding conformance tests to ensure API servers adhere to this standard.

A key debate in the comments centred on how to handle non-compliant extension API servers. One alternative suggested was an opt-in mechanism where APIs could advertise their resourceVersion comparability through the discovery API. However, the consensus was that this added unnecessary complexity. Instead, the accepted approach pushes API server authors to either use a comparable integer (the preferred state) or a clearly non-integer string. The new client-side utility function would handle the latter case by returning an error, preventing misinterpretation. The enhancement proposal was ultimately approved and merged, strengthening the API contract for all clients.

CLI in Kubernetes 1.35

#3104 Separate kubectl user preferences from cluster configs

Stage: Graduating to Beta
Feature group: sig-cli

This proposal introduces an optional kuberc file for kubectl, designed to separate user-specific preferences from cluster credentials and server configurations, which are typically managed in kubeconfig files. The primary motivation is to allow users to define consistent client-side behaviours, such as command aliases, default flags, and security policies, that would apply across all clusters without altering the kubeconfig files used in different environments, like CI/CD pipelines. This separation ensures that personal settings, like enabling interactive delete confirmations or coloured output, don't break automated scripts, and preferences remain consistent even when switching between multiple kubeconfig files.

The kuberc file, located by default at ~/.kube/kuberc, is a versioned YAML file that enables users to create custom command aliases and set default options for standard kubectl commands. For example, a user could create a short alias for a complex get pods command or automatically enable the server-side applies and the interactive deletes. The proposal also includes a new kubectl kuberc command to help users safely view and manage these settings without manually editing the file. This feature is opt-in and aims to enhance the user experience by making kubectl more customisable and user-friendly.

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
  - name: getdbprod
    command: get
    prependArgs:
    - pods
    options:
    - name: labels
      default: what=database
    - name: namespace
      default: us-2-production
defaults:
  - command: apply
    Options:
      - name: server-side
        default: "true"
  - command: delete
    options:
      - name: interactive
        default: "true"
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
    - command: cloudplatform-credential-helper
    - command: custom-credential-script

#5295 Kubernetes YAML (KYAML)

Stage: Graduating to Beta
Feature group: sig-cli

Having gone from New State status to Alpha in Kubernetes 1.34, KYAML is now graduating to Beta status. If you missed this feature announcement in Kubernetes 1.34, KYAML is a new, opinionated output format for kubectl designed to be a stricter, less error-prone subset of standard YAML. It was created to address common frustrations with conventional YAML, such as its sensitivity to whitespace which complicates templating in tools like Helm, and its ambiguous data typing where unquoted strings like "NO" or "On" can be incorrectly interpreted as booleans (a problem known as the "Norway Bug"). While JSON is an alternative, it lacks crucial features like comments. KYAML aims to provide the best of both worlds by defining a "flow style" dialect that is 100% compatible with existing YAML parsers but enforces syntactical choices that increase clarity and reduce common user errors, making configuration files easier to write, read, and manage programmatically.

The core principle of KYAML is to use syntax that removes ambiguity and reliance on indentation. It achieves this by always using curly brackets ({}) for maps and structs, square brackets ([]) for lists, and double quotes for all string values. This approach makes the format insensitive to whitespace, similar to JSON. However, unlike JSON, KYAML is more human-friendly, allowing for comments, trailing commas in lists and maps, and unquoted keys where safe. The proposal includes introducing a new kubectl get -o kyaml command and updating all official Kubernetes documentation and examples to promote this safer, more consistent format throughout the ecosystem.

For example, here is a KYAML output for a Kubernetes Service which can be generated by running kubectl get -o kyaml svc <service-name>:

---
{
  apiVersion: "v1",
  kind: "Service",
  metadata: {
    creationTimestamp: "2025-11-11T11:11:11Z",
    labels: {
      app: "hostnames",
    },
    name: "hostnames",
    namespace: "default",
    resourceVersion: "37697",
    uid: "7aad616c-1686-4231-b69e-5ec68a738bba",
  },
  spec: {
    clusterIP: "10.0.162.160",
    clusterIPs: [
      "10.0.162.160",
    ],
    ports: [{
      port: 80,
      protocol: "TCP",
      targetPort: 9376,
    }],
    selector: {
      app: "hostnames",
    },
    type: "ClusterIP",
  },
  status: {
    loadBalancer: {},
  },
}

#859 Include kubectl command metadata in HTTP request headers

Stage: Graduating to Stable
Feature group: sig-cli

This new enhancement in K8s v.1.35 suggests adding contextual HTTP headers to requests sent from kubectl to the kube-apiserver. The goal is to give cluster administrators better visibility into how users are interacting with the cluster for debugging and telemetry purposes. Currently, while the API server sees requests from kubectl, it doesn't know the specific command that initiated them (like apply, delete, run). This proposal introduces new headers, primarily Kubectl-Command and Kubectl-Session, to solve this. The Kubectl-Command header will contain the full command path (for example, create secret tls), and Kubectl-Session will provide a unique ID to group all API requests that originate from a single kubectl command invocation.

This added information is intended purely for out-of-band analysis, such as identifying the use of deprecated commands, understanding usage patterns to inform tooling decisions, or simplifying debugging. It is explicitly stated that the API server should not make any decisions based on these headers. Flag values and command arguments will not be included to protect sensitive information.

For example, running a kubectl patch command would generate API requests that include the proposed new headers, which could then be seen in the API server's audit logs.

# User runs this command:
$ kubectl patch pod my-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new-image"}]'

# The resulting HTTP request to the kube-apiserver would include:
PATCH /api/v1/namespaces/default/pods/my-pod HTTP/1.1
Host: your-cluster-endpoint
User-Agent: kubectl/v1.29.0

# New headers added by the proposal:
Kubectl-Command: patch
Kubectl-Session: 3a9e1d84-c817-48a2-9a25-a6e5b4b1fde0
Content-Type: application/json-patch+json
...

Kubernetes 1.35 Networking

#4762 Allows setting any FQDN as the pod's hostname

Stage: Graduating to Beta
Feature group: sig-network

In K8s 3.14, this feature moved from Net New to Alpha. Now graduating to Beta stage in Kubernetes 1.35, this new feature introduces a new field, hostnameOverride, which allows you to set an arbitrary Fully Qualified Domain Name (FQDN) as a pod's internal hostname. Essentially, it lets you bypass Kubernetes' default hostname convention (example: pod-name.subdomain.namespace.svc.cluster.local) and assign a custom name like app-server.cloudsmith.com directly to the pod. This is particularly useful for migrating legacy applications that rely on specific, hardcoded hostnames for tasks like authentication, licensing, or configuration. For instance, a Kerberos daemon might require its hostname to match a specific service principal name to function correctly.

When you use the hostnameOverride field in your pod's specification, Kubernetes sets that value as the pod's hostname and adds a corresponding entry to its internal /etc/hosts file. This new field takes precedence over the existing hostname and subdomain fields. It's important to note that this feature only changes the pod's internal identity - it in no way automatically creates a corresponding DNS record that would make the hostname resolvable from outside the pod. You would still need to manage DNS separately.

Here is an example code snippet of a Pod YAML definition using this new hostnameOverride field to set a custom FQDN.

apiVersion: v1
kind: Pod
metadata:
  name: legacy-app-pod
spec:
  # This field sets the pod's internal hostname to 'kdc1.example.com'
  hostnameOverride: "kcd.example.com"
  containers:
  - name: my-legacy-app
    image: my-kerberos-app:1.0

#5311 Relaxed validation for Services names

Stage: Graduating to Beta
Feature group: sig-network
Feature gate: RelaxedServiceNameValidation Default value: false

This proposal suggests relaxing the validation rules for Kubernetes Service names to align them with other Kubernetes resources. Currently, Service name validation is unusually strict, preventing names from starting with a digit. The proposed change would adopt a more lenient validation standard (NameIsDNSLabel), simplifying the codebase and allowing users to apply consistent naming conventions across all their resources.

To ensure a safe transition, the change will be introduced behind a new feature gate called RelaxedServiceNameValidation, which will be disabled by default. The proposal acknowledges risks, particularly how this change might affect components that rely on Service names, such as DNS records and Ingress controllers. To mitigate this, the plan includes compatibility testing with downstream systems and a careful implementation strategy to support cluster downgrades, ensuring stability even if the feature gate is later disabled.

#3015 PreferSameNode Traffic Distribution

Stage: Graduating to Stable
Feature group: sig-network

In K8s 3.14, this feature graduated to Beta. In v.3.15 this will graduate to Stable. The KEP should address some of the ambiguity of the PreferClose traffic distribution setting. After concluding that any attempt to modify its behaviour would be unreliable, the proposal suggests deprecating PreferClose and introducing two more explicit values.

• First, PreferSameZone is introduced as a new name for the old "prefer same zone" behaviour, with PreferClose becoming a deprecated alias for it.
• Second, a new value, PreferSameNode, is added to allow traffic to be preferentially routed to endpoints on the same node as the client, falling back to other endpoints only when a local one isn't available.

The primary goals are to make traffic distribution less ambiguous and to provide administrators with finer control, such as ensuring DNS requests are efficiently handled by a local pod whenever possible.

Kubernetes 1.35 Authentication

#3331 Structured Authentication Config

Stage: Stable
Feature group: sig-auth

Structured auth config was originally an Alpha release target in v1.29 and reached Beta release target v1.30. It was scheduled for stable release in Kubernetes 1.34, but is finally getting the Stable tag in 1.35. This feature introduces a new, dynamic method for configuring OpenID JWT connect tokens in the Kubernetes API server via a structured configuration file (AuthenticationConfiguration). It replaces the older, more rigid command-line flags and allows for much greater customisation without needing to restart the kube-apiserver.

Key enhancements include the ability to configure multiple OIDC providers, create advanced claim validation rules, and define complex mappings from JWT claims to user attributes like username and groups using a powerful expression language. This provides fine-grained control over authentication logic, such as ensuring a token's lifetime is within a specific limit or transforming claim data before it's used to identify a user. A short code snippet demonstrating a custom validation rule looks like this:

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: https://example.com
    # ... other settings
  claimValidationRules:
  - expression: 'claims.exp - claims.nbf <= 86400'
    message: "token lifetime must not exceed 24 hours"

#5284 Constrained Impersonation

Stage: Net New to Alpha
Feature group: sig-auth

Another net new proposal in Kubernetes 1.35 introduces a new constrained impersonation mechanism in Kubernetes that offers more granular access control and mitigates the security risks associated with the existing "unrestricted" impersonation. The current system allows an entity with impersonate permissions to gain all the powers of the user they are impersonating, which is too permissive for many use cases, such as controllers needing to perform specific actions on behalf of a node or user. This new, opt-in feature requires an impersonator to have two distinct sets of permissions: one to define who they can impersonate and another to define what specific actions they are allowed to perform while impersonating.

This is accomplished by introducing new RBAC verbs. Verbs like impersonate:user-info and impersonate:associated-node grant permission to impersonate a user or the node a pod is running on, respectively. Correspondingly, verbs prefixed with impersonate-on:<mode>: (for example impersonate-on:user-info:list) grant permission to perform a specific action (like list) on a resource while impersonating. For a request to be approved, the API server verifies both permissions, ensuring the impersonator can only perform explicitly delegated actions. The legacy impersonation flow remains unchanged for backward compatibility.

To understand this advancement better, the following Kubernetes RBAC configuration demonstrates how to allow a default service account to impersonate a user named nigel only for the purpose of listing and watching pods in the default namespace.

First, a ClusterRole grants the permission to impersonate the specific user.

# Permission to impersonate a specific user
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: constrained-impersonate-only-someuser
rules:
- apiGroups: ["authentication.k8s.io"]
  resources: ["users"]
  resourceNames: ["nigel"] 
  verbs: ["impersonate:user-info"]
—
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: constrained-impersonate-only-someuser
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: constrained-impersonate-only-someuser
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

Next, a Role grants permission for the specific actions that can be performed during the impersonation.

# Permission for the specific actions allowed during impersonation
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: impersonate-allow-only-listwatch-pods
  namespace: default
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs:
  - "impersonate-on:user-info:list"
  - "impersonate-on:user-info:watch"
—
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: impersonate-allow-only-listwatch-pods
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: impersonate-allow-only-listwatch-pods
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

#4317 Pod Certificates

Stage: Graduating to Beta
Feature group: sig-auth

Launched to alpha in Kubernetes 1.34, pod certificates will upgrade to Beta status in 1.35 with the addition of the spec.userConfig field. The PodCertificateRequest API introduces a streamlined, secure, and automated way for Kubernetes pods to obtain X.509 certificates directly through the cluster’s control plane. Unlike the existing CertificateSigningRequest API, which is more general-purpose, the PodCertificateRequest is purpose-built to handle certificate issuance for individual pods without relying on bearer tokens or external secrets. This ensures stronger mutual TLS (mTLS) guarantees by keeping private keys on the node and removing the need for human or token-based approvals.

At its core, the new mechanism defines two main components:

1. PodCertificateRequest, a new resource type in certificates.k8s.io/v1alpha1, which formally represents “pod X requesting a certificate from signer Y.” It includes pod metadata, a public key and proof of possession, and a desired certificate lifetime.
2. PodCertificate projected volume, which allows the kubelet to automatically generate a key pair, submit a PodCertificateRequest, and inject the resulting certificate chain into the pod’s filesystem.

This system simplifies secure certificate management across workloads by shifting node restriction enforcement into the API server, thus reducing the complexity of building secure third-party signers. It supports both client and server certificate issuance, but deliberately excludes features like Hardware Security Modules (HSM) integrations, certificate sharing across pods, or manual approval workflows to maintain simplicity and automation.

The following example demonstrates how an application pod can request and mount an automatically issued SPIFFE-compatible certificate for authenticating to an external service:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: pod-certificates-example
spec:
  restartPolicy: OnFailure
  automountServiceAccountToken: false
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: spiffe-credentials
      mountPath: /run/workload-spiffe-credentials
  volumes:
  - name: spiffe-credentials
    projected:
      sources:
      - podCertificate:
          signerName: "row-major.net/spiffe"
          keyType: ED25519
          credentialBundlePath: credentialbundle.pem

With this setup, the pod automatically receives a private key and a signed certificate chain at /run/workload-spiffe-credentials/credentialbundle.pem, ready for use in mTLS authentication, without the fear of exposing credentials or requiring manual intervention.

#4872 Harden Kubelet Serving Certificate Validation in Kube-API server

Stage: Net New to Alpha
Feature group: sig-auth
Feature gate: KubeletCertCNValidation Default value: disabled

This is an exciting new proposal in Kubernetes 1.35. It ultimately aims to strengthen the security of the Kubernetes API server by addressing a vulnerability where a node could impersonate another. Currently, when the API server connects to a kubelet (a node agent), it primarily validates the connection using the node's IP address within its serving certificate. This method is insecure in dynamic environments where IPs can be reassigned, or in on-premises setups where an attacker could use techniques like ARP poisoning to spoof an IP address. A malicious actor could exploit this to intercept sensitive information from commands like kubectl exec or kubectl logs. The proposed solution is to add a new validation step: the API server will check that the certificate's Common Name (CN) matches the expected node name, using the format system:node:<nodename>. This ties the certificate's identity directly to the node name rather than its potentially transient IP address.

To ensure a smooth rollout and maintain backward compatibility, this new validation will be an opt-in feature. It will be managed by a feature flag and a command-line flag, preventing disruption in clusters that use custom certificates not adhering to the new naming convention. To assist administrators in adopting this security enhancement, new metrics and logs will be introduced. These tools will help identify which nodes have non-compliant certificates, allowing administrators to reissue them before enabling the feature. This approach allows clusters to incrementally improve their security posture against node impersonation attacks without causing immediate breakage.

Kubernetes 1.35 Nodes

#4639 VolumeSource: OCI Artifact and/or Image

Stage: Graduating to Stable
Feature group: sig-node

We mentioned in the Editor’s Pick section of the Kubernetes 1.34 release notes why this feature is so exciting for the Kubernetes community. This feature is now going Stable in Kubernetes 1.35. This native image volume type is a significant improvement for building modular applications. It allows users to package files (like config data, binary artifacts, or large machine learning models) into an OCI-compliant image and mount them directly as a read-only volume in a pod. This really is great because it decouples data from the application's container image, leading to some key benefits, like:

1. Your main application image remains lightweight and has a reduced attack surface because it doesn't need to bundle bulky or sensitive data.
2. You can use the same mature OCI registry infra and tooling you already use for container images to distribute and manage app dependencies and AI/ML models. For example, a data scientist can update and version an LLM independently of the model-serving container, which should drastically simplify your overall deployments.
3. And finally a single, generic app image can be used in multiple contexts by simply mounting different OCI volumes containing the necessary configurations or data.

#2535 Ensure secret pulled images

Stage: Major Change to Beta
Feature group: sig-node
Feature gate: KubeletEnsureSecretPulledImages Default value: disabled

A major change in Kubernetes is being introduced to enhance container image security on multi-tenant nodes. Previously, if a private image was pulled onto a node using credentials, other pods could potentially use that same image without authorisation by setting their imagePullPolicy to IfNotPresent or Never. This new feature closes that security gap by having the Kubelet track which images were pulled with specific credentials. Now, even if an image is locally present, the Kubelet will force a re-authentication check if a new pod attempts to use it without the same, previously successful credentials. For pods with an IfNotPresent policy, this triggers a re-pull to verify access, while for a Never policy, the pod creation will fail, mirroring the behaviour as if the image wasn't on the node at all. This allows administrators to ensure image authorisation without incurring the performance overhead of forcing the Always pull policy for all workloads.

This enhancement, which addresses a long-standing request (Issue #18787), was formally accepted in late 2024, with the alpha implementation merged in March 2025. It's managed via a feature gate named KubeletEnsureSecretPulledImages and introduces a new Kubelet configuration, imagePullCredentialsVerificationPolicy, which gives cluster administrators granular control over this behaviour. The Kubelet will persist the authentication data on the node's disk, ensuring the security posture is maintained across reboots. This provides a much-needed security improvement by default, while still offering flexibility for different operational needs.

#4210 Kubelet image GC after a maximum age

Stage: Graduating to Stable
Feature group: sig-node
Feature gate: ImageMaximumGCAge Default value: 0 (disabled)

Graduating to stable, the Kubelet feature ImageMaximumGCAge enhances how unused container images are managed. Currently, the Kubelet only performs image Garbage Collection (GC) reactively when disk usage hits a certain threshold. This new feature adds a proactive, time-based condition, allowing administrators to specify a maximum duration for an image to remain on a node without being used. After this time expires, the image will be garbage collected, regardless of the current disk usage.

The primary motivation is to prevent old images, such as those left behind after cluster upgrades, from needlessly consuming disk space. The feature will be controlled by a feature gate and a new configuration field, ImageMaximumGCAge, which will be disabled by default. A key risk is that setting this value too low could cause frequently used images (e.g., for a weekly cron job) to be deleted and re-pulled unnecessarily, so administrators must configure it carefully.

#3673 Kubelet limit of Parallel Image Pulls

Stage: Graduating to Stable
Feature group: sig-node

Finally graduating to stable, this hotly-anticipated addition addresses the ineffective method Kubernetes currently uses to limit container image pulls on a node. The existing QPS/burst limits are confusing as they only control the rate of requests to the container runtime, not the number of concurrent pulls. This can lead to an unlimited number of simultaneous downloads, potentially overwhelming a node's disk I/O and network bandwidth.

To solve this, this proposal thankfully introduces a new, more intuitive kubelet configuration field called maxParallelImagePulls. This setting establishes a clear, node-level limit on how many images can be pulled at the same time. Any pull request that exceeds this limit will be blocked until an ongoing pull completes. This gives DevOps teams in charge of the cluster direct control over their resource consumption, allowing them to speed up workload startup with parallel pulls without negatively impacting the node's overall performance. I can see that this KEP also outlines validation logic to ensure this new setting works coherently with the existing SerializeImagePulls flag.

#5573 Remove cgroup v1 support

Stage: Net New to Beta
Feature group: sig-node

In the upcoming Kubernetes 1.35 release, the removal of cGroups (Control Groups) v1 support will graduate to Beta. It was previously moved to maintenance mode in v.1.31. This change means the kubelet will now fail to start by default on nodes that are using cgroup v1, effectively making cgroup v2 a requirement. This move is driven by the broader ecosystem's deprecation of cgroup v1, most notably its removal from systemd in upcoming operating system releases, and the widespread adoption of cgroup v2 by major cloud providers. This Beta stage formally marks cgroup v1 as unsupported, with a complete removal of its code planned for a future release.

Scheduling in Kubernetes 1.35

#5007 Dynamic Resource Allocation (DRA) Device Binding Conditions

Stage: Graduating to Beta
Feature group: sig-scheduling

There are a whole bunch of major changes to existing DRA features in Kubernetes 1.35. Partitionable Devices (Alpha: #4815), Prioritised alternatives in Device Requests (Beta: #4816), Device Taints and Tolerations (Alpha: #5055), and Consumable Capacity (Alpha: #5075) are all experiencing Quality of Life improvements in this update. The one exciting graduating-to-Beta feature related to DRA in v.1.35 is Device Binding Conditions.

The new BindingConditions feature is designed to improve the reliability of scheduling pods that require specialised hardware like GPUs or FPGAs. The core problem it solves is that some hardware isn't instantly ready - it might need to be physically connected via a fabric or undergo a time-consuming setup. Currently, the Kubernetes scheduler assumes resources are ready immediately, which can cause the Pod to fail if the hardware isn't prepared in time.

BindingConditions introduces a waiting mechanism. Instead of immediately assigning a Pod to a server, the scheduler can now pause and wait for signals confirming the hardware is fully prepared. External device controllers are responsible for sending these "ready" signals. If a signal indicates a failure or the preparation times out, the scheduler will abort the assignment and attempt to reschedule the Pod elsewhere. This prevents Pods from getting stuck on nodes with unusable resources, making the scheduling process for complex, high-performance workloads much more robust and predictable.

#5278 Use NominatedNodeName to express the expected pod placement

Stage: Graduating to Beta
Feature group: sig-scheduling

The NominatedNodeName field in a pod's specification is being enhanced to broadcast the scheduler's placement decision before the pod is officially bound to a node. This addresses a critical information gap where the scheduler's internal choice is not visible to other cluster components. The primary motivation is to prevent race conditions with the Cluster Autoscaler, which might mistakenly identify a target node as underutilised and delete it while the pod is waiting for resources like storage volumes to be prepared. By setting NominatedNodeName early in the binding cycle, the scheduler effectively places a public "reservation" on the node, signaling to other components that it is about to be used.

This mechanism also improves the scheduler's resilience. If the scheduler restarts during a lengthy pre-binding process, the new instance can read the NominatedNodeName field and attempt to place the pod on the same node, thus resuming its work instead of starting over. To avoid performance degradation from excessive API calls, this feature is only activated when necessary, specifically, when PreBind or Permit plugins indicate that a delay is expected. This ensures that the scheduler's intent is communicated for long-running pod startups without adding overhead to simple, fast bindings.

#4671 Gang Scheduling Support in Kubernetes

Stage: Net New to Alpha
Feature group: sig-scheduling

This proposal introduces native Gang Scheduling to the core kube-scheduler, enabling "all-or-nothing" scheduling for tightly coupled parallel workloads like AI training, MPI jobs, and StatefulSets. The mechanism relies on a new core API resource called Workload, which acts as a policy definition for a group of pods. Instead of scheduling pods individually as they appear, the scheduler identifies pods belonging to a Workload and waits until a defined minimum number (minCount) reaches the scheduling/binding cycle simultaneously. If the group cannot be scheduled together within a specific timeout, all resources are released, preventing "partial starts" where expensive compute resources sit idle waiting for peers that never arrive.

The Workload object allows the scheduler to understand complex application structures without taking over the responsibility of pod creation from existing controllers (like Jobs or LeaderWorkerSets). This shift moves gang scheduling from external extensions (like Volcano or Kueue) into the standard Kubernetes distribution, ensuring portability. Furthermore, the Workload API is designed as a foundational building block that will evolve to support topology-aware scheduling in future iterations, allowing pods to not only start together but also be placed topologically close to one another for performance.

The following snippet demonstrates the relationship between the new Workload policy and a standard Job. The Job references the Workload via the new spec.template.spec.workload field.

# 1. The Workload defines the "Gang" policy
apiVersion: scheduling/v1alpha1
kind: Workload
metadata:
  name: training-gang-policy
  namespace: default
spec:
  podGroups:
    - name: "pg1"
      policy:
        gang:
          # The scheduler waits until 10 pods are ready to bind at once
          minCount: 10
----
# 2. The Job creates pods that reference the Workload
apiVersion: batch/v1
kind: Job
metadata:
  name: ml-training-job
  namespace: default
spec:
  completions: 10
  parallelism: 10
  template:
    spec:
      # Link the Pods to the Workload defined above
      workload:
        name: training-gang-policy
      containers:
      - name: cuda-worker
        image: awesome-training-program:v1
        resources:
          limits:
            nvidia.com/gpu: 1
      restartPolicy: OnFailure

#5471 Extended Toleration Operators for Threshold-Based Placement

Stage: Net New to Alpha
Feature group: sig-scheduling

This KEP introduces numeric comparison operators, Gt (Greater Than) and Lt (Less Than), to Kubernetes pod Tolerations, enhancing how pods are scheduled on nodes with specific numeric Taints. The primary goal is to allow pods to opt-in to nodes based on metrics like Service Level Agreements (SLA) or failure probability (for example node.kubernetes.io/sla=950). While NodeAffinity can select nodes based on labels, this new feature offers superior operational control. Taints establish a "repel by default" policy, forcing workloads to explicitly tolerate placement on certain nodes (like low-SLA spot instances). More importantly, this mechanism supports the NoExecute effect, which automatically evicts pods from a node if its SLA rating drops below a required threshold, providing a critical capability for high-availability services that NodeAffinity cannot provide.

The feature is particularly beneficial for managing mixed-reliability clusters, especially for AI/ML workloads and DRA. For example, latency-sensitive inference services can be restricted to high-SLA nodes and automatically evicted if a node's reliability degrades. At the same time, cost-effective, checkpoint-able training jobs can be scheduled on cheaper spot instances by tolerating a lower SLA. This enables a more granular, policy-driven approach to resource allocation, ensuring that critical workloads receive the most reliable hardware while maximising the utilisation of all available capacity. The implementation is backward-compatible and confined to the scheduler's existing TaintToleration plugin, ensuring zero performance impact on current scheduling logic.

# High-SLA on-demand node tainted to repel workloads that don't meet SLA
apiVersion: v1
kind: Node
metadata:
  name: ondemand-node-1
spec:
  taints:
  - key: node.kubernetes.io/sla
    value: "980" # Represents 98.0% SLA
    effect: NoExecute
---
# Inference service deployment requires and enforces high SLA
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-service
spec:
  template:
    spec:
      tolerations:
      # Pod tolerates nodes with an SLA value greater than 950
      # If node's taint value changes to be <= 950, pod is evicted
      - key: node.kubernetes.io/sla
        operator: Gt
        value: "950"
        effect: NoExecute
        tolerationSeconds: 30

Above is a config example where an inference service requires a node with an SLA greater than 95% and will be evicted within 30 seconds if the node's SLA drops.

#5598 Opportunistic batching

Stage: Net New to Beta
Feature group: sig-scheduling

This KEP introduces an opportunistic batching mechanism to the Kubernetes scheduler, designed to significantly improve performance for large-scale workloads like Batch and ML jobs. By implementing a Pod Scheduling Signature, the system identifies pods that share identical scoring and feasibility properties. This allows the scheduler to calculate a result for a single pod and reuse that nominated node for subsequent pods with the same signature, bypassing the existing computationally expensive algorithm currently in use.

Beyond immediate performance gains, this feature establishes the necessary infrastructure for future Gang Scheduling (see #4671) capabilities without introducing immediate dependencies on the Workload API. The proposal prioritises maintainability and backward compatibility; while out-of-tree plugins will continue to function, the batching optimisation will simply be disabled (falling back to standard scheduling) if a plugin cannot generate a valid signature. Initially targeting simple constraints and 1-pod-per-node environments, the goal is to eventually expand this optimisation to a wider range of workloads.

Storage in Kubernetes 1.35

#5381 Mutable PersistentVolume Node Affinity

Stage: Net New to Alpha
Feature group: sig-storage

The associated KEP suggests making the PersistentVolume.spec.nodeAffinity field mutable. Currently, this field is set only when a volume is created and cannot be changed. This immutability causes problems when a volume's accessibility changes, for instance, during a data migration from a single zone to a regional storage backend or when a new feature is enabled that isn't supported by all nodes. These situations can lead to an inaccurate nodeAffinity, causing the Kubernetes scheduler to make poor decisions. As a result, pods can get stuck in a Pending state (unable to be scheduled on nodes that can now access the volume) or a ContainerCreating state (scheduled to nodes that can no longer access the volume).

By allowing this field to be updated, storage providers and cluster operators can dynamically inform the scheduler about the latest accessibility requirements of a volume. This ensures that stateful workloads are scheduled more reliably and allows for seamless infrastructure upgrades and data migrations without interrupting running applications. For example, a volume's affinity could be updated to reflect its migration from a specific availability zone to an entire region, broadening where its associated pod can be scheduled. This change would be reflected by modifying the nodeAffinity in the PersistentVolume spec.

For example, a user might change the affinity from a specific zone:

# Previous nodeAffinity
spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          Values:
          - cn-beijing-g

To a broader region, you could improve availability:

# New nodeAffinity
spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/region
          operator: In
          Values:
          - cn-beijing

#5538 CSI driver opt-in for service account tokens via secrets field

Stage: Net New to Alpha
Feature group: sig-storage

We see this enhancement addressing serious security vulnerabilities where sensitive Service Account Tokens are inadvertently exposed in logs by introducing an opt-in mechanism to move these tokens from the volume_context to the dedicated secrets field in NodePublishVolumeRequest. Previously, mixing sensitive tokens with non-sensitive volume attributes led to security gaps (such as CVE-2023-2878) because standard sanitisation tools often overlook the volume context.

On a side note, you can use the dedicated Kubernetes CVE Feed API to learn more about the status of individual CVEs in the Kubernetes project:

curl -Ls https://kubernetes.io/docs/reference/issues-security/official-cve-feed/index.json | jq '.items[] | select(.id == "CVE-2023-2878")'

To implement this change, a new boolean field named serviceAccountTokenInSecrets is added to the CSIDriver spec. Setting this to true directs the kubelet to inject tokens strictly into the secrets field using the standard key csi.storage.k8s.io/serviceAccount.tokens. The default value remains false to maintain backward compatibility, ensuring that existing drivers continue to function without modification while allowing updated drivers to opt for improved security.

The following manifest illustrates how you could configure the CSIDriver to opt-in to the new security feature:

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example-csi-driver
spec:
  tokenRequests:
    - audience: "example.com"
      expirationSeconds: 3600      
  # New Opt-in Field: 
  serviceAccountTokenInSecrets: true

Autoscaling in Kubernetes 1.35

#5030 Integrate CSI Volume attach limits with cluster autoscaler

Stage: Net New to Alpha
Feature group: sig-autoscaling

This KEP makes the Cluster Autoscaler significantly smarter by integrating CSI volume attachment limits into its scaling logic. Previously, the autoscaler might add a large new node based on CPU and memory requests, only to find that pending pods couldn't be scheduled because the node had reached its maximum number of attachable volumes (for example AWS EBS or GCP PD limits). This enhancement makes the autoscaler aware of these storage constraints, allowing it to predict whether pods requiring persistent volumes can be accommodated on a potential new node. As a result, it will make more accurate and efficient scale-up decisions, ensuring that stateful workloads are not blocked by underlying storage limitations and improving overall cluster resource utilisation.

#4951 Configurable tolerance for Horizontal Pod Autoscalers

Stage: Graduating to Beta
Feature group: sig-autoscaling
Feature gate: HPAConfigurableTolerance Default value: false

This enhancement addresses a limitation in Kubernetes where HPA uses a single, cluster-wide tolerance setting (defaulting to 10%) to prevent rapid, minor scaling adjustments, often called "flapping." This global setting is often too coarse, especially for large-scale deployments where a 10% tolerance can represent a significant number of underutilised pods or for workloads that require faster scaling responses to traffic surges. The proposed solution is to introduce an optional tolerance field directly into the HPA behavior spec. This allows operators to define a custom scaling tolerance on a per-HPA basis and even set different values for scaling up versus scaling down.

This change offers more granular control over autoscaling behaviour without altering the core algorithm. It will be implemented in the autoscaling/v2 API behind a feature gate named HPAConfigurableTolerance. If the new tolerance field is not specified in an HPA definition, the system will continue to use the existing global default, ensuring backward compatibility. This enhancement provides a more flexible and efficient way to manage resource allocation and responsiveness for specific workloads.

Instrumentation in Kubernetes 1.35

#1602 Structured Logging

Stage: Graduating to Beta
Feature group: sig-instrumentation

This improvement addresses the challenge of inconsistent and unstructured logs within the Kubernetes control plane, which makes them difficult to parse, query, and analyse. The solution is to introduce structured logging by adding new methods to the klog library, such as InfoS and ErrorS. These methods enforce a standard format of a log message followed by key-value pairs. This initiative also standardises how Kubernetes objects are referenced in logs using helper functions (KObj, KRef) to create a canonical namespace/name format, improving query-ability and correlation.

A key feature of this proposal is the option to output logs in JSON format, which simplifies ingestion into third-party logging and analysis tools. This is enabled through a new --logging-format flag, allowing administrators to switch between the default text format and the new json format. The migration to structured logging is designed to be incremental, starting with the most common and impactful log messages and eventually covering all components. The long-term goal is to deprecate the old string-based logging methods and make structured, machine-readable logs the default for Kubernetes.

Deprecations in Kubernetes 1.35

#5495 Deprecate IPVS mode in kube-proxy

Stage: Deprecation/Removal
Feature group: sig-network

The deprecation of the IPVS proxy mode in kube-proxy in Kubernetes 1.35 is interesting because it marks a significant strategic shift in the evolution of Kubernetes networking. For years, IPVS (IP Virtual Server) was touted as the high-performance backend for kube-proxy, especially beneficial for clusters with a vast number of services, as it uses a more efficient hash table for lookups compared to the sequential rule processing of IPtables. Its deprecation signals that this performance advantage is no longer compelling enough to justify its maintenance cost. This move is primarily driven by a lack of developers with deep expertise in the IPVS codebase, making it difficult to fix existing bugs and maintain the feature effectively. It reflects a deliberate choice by the Kubernetes networking group (SIG-Network) to consolidate their efforts and reduce the support burden of maintaining three separate Linux backends (iptables, ipvs, and nftables).

This decision is also a strong endorsement of the NFtables backend as the future of Kubernetes service routing on Linux. The discussion in the provided text reveals that nftables has matured to the point where it is not only more actively maintained but also considered more performant and conformant than IPVS. The deprecation serves as an official warning to the community, urging users who rely on ipvs for its historical performance benefits to begin planning their migration to nftables. This move streamlines the project's focus, allowing developers to concentrate on enhancing a single, modern backend rather than dividing their attention across multiple, aging implementations. This ensures a more robust, secure, and sustainable networking layer for the future of Kubernetes.

Removed from Milestone

#4781 Fix inconsistent container ready state after kubelet restart

Stage: Deprecation/Removal
Feature group: sig-node

This feature was scheduled to be deprecated in Kubernetes 1.35 because its original behaviour of resetting container readiness states after a kubelet restart was actually causing inconsistencies and disruptions in workload availability that were difficult to justify maintaining. Specifically, the mechanism often marked containers as temporarily unready even when they were still healthy and running, leading to unnecessary endpoint removals, service disruptions, and poor upgrade resilience during kubelet restarts. The newer logic introduced in the discussion link fixes this by ensuring container “Started” and “Ready” states are consistently inherited from the API server after a kubelet restarts, eliminating transient status flaps. As a result, the older implementation has been marked for deprecation to simplify kubelet behaviour, improve state persistence, and align with the community’s goal of making restarts transparent to workloads.

#3541 Add EnforcedRollingUpdate to StatefulSet rolling updates

Stage: Net New to Alpha
Feature group: sig-apps
Status: Removed from Milestone

The EnforcedRollingUpdate strategy introduces a crucial new piece of logic. When this alpha feature is enabled, the StatefulSet controller can now proactively delete a pod that is not Ready if that pod's specification does not match the latest version of the StatefulSet. So why is that important?

This feature addresses a common and frustrating problem where a StatefulSet rolling update becomes stalled or "stuck" due to a bad configuration, such as a non-existent container image. In the standard rolling update process, the StatefulSet controller replaces pods one by one. It waits for a new pod to become "Ready" before moving on to the next one. If you push an update with a typo in the image name, the first pod to be updated will be terminated and its replacement will get stuck in a state like ErrImagePull or ImagePullBackOff. Because this new pod never becomes Ready, the entire rolling update halts, leaving your application in a partially updated and broken state.

The core issue this feature solves is the deadlock that occurs when you try to fix the bad configuration. Before this feature, if you corrected the image name in the StatefulSet spec, the controller would see the broken, non-Ready pod and refuse to touch it. It was still waiting for that pod, which was based on the old, bad configuration in order to become Ready. The controller had no mechanism to recognise that the pod was permanently broken and that a newer, valid configuration was available. This forced operators to manually intervene by running kubectl delete pod on the broken pod to un-stall the update.

In short, the new EnforcedRollingUpdate feature gives the controller permission to delete the broken pod. Once deleted, the StatefulSet naturally recreates it using the latest, corrected specification. The new pod starts successfully, becomes Ready, and the rolling update automatically continues. This eliminates the need for manual intervention and makes recovering from a failed rollout a seamless, automated process.

#3973 Consider Terminating Pods in Deployments

Stage: Graduating to Alpha
Feature group: sig-apps
Status: Removed from Milestone

This proposal addresses an inconsistent behaviour in Kubernetes Deployments where the number of active pods can temporarily exceed the configured amount. This happens because new pods are often created before old pods, which are in a "terminating" state, have fully shut down. This oversight can lead to problems like resource shortages, scheduling delays, and unnecessary cloud costs from autoscaling nodes to handle the temporary surge in pods, especially when pods have a long termination period.

To solve this, the proposal suggests adding a new field, .spec.podReplacementPolicy, to the Deployment specification. This new field will allow users to explicitly define the desired behaviour. They can configure it to wait for terminating pods to be completely gone before creating replacements, ensuring a predictable number of running pods. Alternatively, they can opt for the current behaviour, which creates new pods immediately for faster rollouts and scaling. The goal is to provide users with consistent control over resource usage and pod lifecycle management during updates and scaling events.

#3926 Handling undecryptable resources

Stage: Graduating to Beta
Feature group: sig-auth
Status: Removed from Milestone

This new beta feature addresses a long-standing operational issue related to encryption at rest for API resources. While Kubernetes has supported encrypted storage for some time, occasional issues such as key mismanagement or external system failures can leave certain resources in an unreadable or corrupted state. When even a single object of a given resource type cannot be decrypted, it prevents listing or managing other healthy objects of that type through the Kubernetes API. Currently, the only way to fix such cases is for administrators to access etcd directly and manually remove the broken data, a process that is both risky and cumbersome.

The enhancement proposes two key improvements to resolve this. First, it enhances error reporting to clearly identify resources that fail decryption or decoding, making it easier for administrators to locate problematic objects. Second, it introduces a new DeleteOption that allows users to delete corrupted or unreadable resources directly through the Kubernetes API, essentially bypassing the need for etcd-level intervention. This option enables the removal of data that cannot otherwise be transformed or decoded due to encryption or data corruption issues.

While this feature improves resilience and administrative convenience, it must be used cautiously. Unconditional deletion of malformed resources can disrupt garbage collection, ignore finalisers, or bypass cleanup processes tied to those objects. Therefore, safeguards such as client-side prompts (like kubectl) are planned to ensure users understand the risks before proceeding. In essence, this KEP will eventually enhance cluster reliability and manageability by allowing safer and more transparent recovery from encryption-related failures.

#4412 Projected service account tokens for Kubelet image credential providers

Stage: Major Change to Beta
Feature group: sig-auth
Status: Removed from Milestone

Originally released as an Alpha enhancement in Kubernetes 1.33, the feature received a major change when the 1.34 Beta release was scheduled for the upcoming 1.35 update. In Kubernetes v1.36 or later, a major change should finally be introduced to how container image pulls are authenticated, specifically, the ability to use ephemeral Kubernetes Service Account (KSA) tokens instead of long-lived secrets. Historically, pulling images from private registries like Cloudsmith required storing static image pull secrets within the Kubernetes API or using node-level credentials managed by the Kubelet. Both approaches carried security and operational drawbacks: static credentials were difficult to rotate and increased the risk of credential leaks, while node-scoped credentials allowed broader access than necessary.

Although pushed-out for now, Kubernetes will introduce a new mechanism that enables the Kubelet to use workload-specific, short-lived KSA tokens when fetching image credentials from an external credential provider plugin. This effectively brings the same “secretless” model that pods already enjoy at runtime (for service account tokens) to the image-pulling phase, before the pod is even started.

The change works by extending the Kubelet’s credential provider configuration to support a new tokenAttributes field. When configured, the Kubelet generates a service account token bound to the specific pod and its service account, then passes that token (along with selected annotations) to the credential provider plugin. The plugin can then use this token to authenticate with an image registry or exchange it for temporary credentials (for example, from a cloud provider vault). This design means each workload can authenticate using its own identity, reducing secret sprawl and improving security isolation between pods.

Later releases will also see the introduction of a stronger audience validation for KSA tokens through the ServiceAccountNodeAudienceRestriction feature in the API server, ensuring that kubelets can only request tokens for authorised audiences. Together, these changes make image pulls more secure, auditable, and easier to manage by removing the need for long-lived, hard-coded secrets. This ultimately completes Kubernetes’ broader shift toward ephemeral, identity-based authentication across the cluster lifecycle.

#5365 ImageVolume with an image digest

Stage: Net New to Alpha
Feature group: sig-node
Status: Removed from Milestone

This proposal will eventually address the gap in Kubernetes' ImageVolume feature, which allows a container image to be used as a source for a pod's volume. Currently, unlike standard container images, the unique digest (a specific version identifier) of an ImageVolume isn't reported in the pod's status. The proposal is to add a new ImageRef field to the pod's status to expose this digest.

The primary motivation is to enhance monitoring, security, and operational consistency. Exposing the digest allows administrators to verify the exact image versions in use, which is critical for security scanning and GitOps workflows that rely on precise image identifiers. A key use case is improving the reliability of KubeVirt's live migration, where virtual machines are moved between nodes. For a successful migration, both the source and destination pods must use the identical disk image, a guarantee that only the image digest can provide.

#2021 Support scaling to/from zero pods for object/external metrics

Stage: Net New to Alpha
Feature group: sig-autoscaling
Status: Removed from Milestone

Pushed out to 1.36, the enhancement status of the Horizontal Pod Autoscaler's (HPA) scale-to-zero capability is significant because it marks the feature's complete journey from a risky experiment to a finally Alpha, staging-ready feature. It was originally planned to be introduced as an Alpha feature in version 1.16, but has faced significant delays. It’s now an opt-in capability enabled by a feature gate (HPAScaleToZero). This initial status signalled that while the feature offered powerful cost-saving potential, it was not yet fully vetted and could have bugs or breaking changes. Operators using it did so at their own risk, primarily in testing environments.

In v1.36, the feature should hopefully be enabled by default and integrated into the ecosystem. This maturity allows operators to confidently use minReplicas: 0 in staging or test-related environments to drastically reduce costs for intermittent workloads, knowing it's a reliable and core component of Kubernetes autoscaling.

#5325 Improve pod selection accuracy in HPA across workload types

Stage: Net New to Alpha
Feature group: sig-autoscaling
Status: Removed from Milestone

In K8s v.1.36, a new alpha feature should address the long-standing issue where HPA can make incorrect scaling decisions. Previously, the HPA selected pods to monitor based on label selectors, which could inadvertently include metrics from unrelated pods (like completed jobs or pods from other workloads) that shared the same labels. This often resulted in inaccurate scaling, such as a deployment getting stuck at its maximum replica count even when its actual resource usage was low. The enhancement refines this logic to ensure the HPA only considers metrics from pods directly managed and owned by the target workload, thereby improving pod selection accuracy and making autoscaling more reliable and predictable.

Timeline of v.1.35 Kubernetes Release

Kubernetes users can expect the v1.35 release process to unfold throughout October 2025, with key milestones including two release candidates on August 6th and 20th, followed by the official v1.35.0 release on December 17th.

Frequently Asked Questions (FAQ)

1. When will Kubernetes 1.35 be released?
   The official release date is December 17, 2025.
2. What are the Alpha features in Kubernetes 1.35?
   Kubernetes 1.35 introduces key alpha enhancements focused on advanced resource management and workload control. This includes significant updates to DRA, adding support for consumable capacity, partitionable devices, and device taints. Scheduling and resource handling are further refined with new Pod Level Resource Managers and support for Gang Scheduling. Additionally, workload lifecycles get more granular control through alphas like restarting all containers on exit and enabling mutable resources for suspended Jobs, while node performance is boosted with features like Kubelet Evented PLEG.
3. What features have been deprecated since Kubernetes 1.35?
   Kubernetes 1.35 sees the deprecation of IPVS mode in kube-proxy as well as fixing inconsistent container start behaviour and the ready state after kubelet restarts.

Kubernetes Release Archive

Kubernetes 1.35 – What you need to know
Kubernetes 1.34 – What you need to know
Kubernetes 1.33 – What you need to know