Kubernetes v1.32: What's New and Improved?

Kubernetes v1.32, codenamed "Penelope," arrives as the final release of Kubernetes’ first decade, symbolizing a reflective yet forward-thinking milestone in its development journey. Much like the mythological figure Penelope, known for her persistent weaving, Kubernetes’ development reflects a similar cyclical process of continuous improvement. This release introduces 44 enhancements, including 13 stable features, 12 features moving to beta, and 19 new alpha features.

Let's discuss the major enhancements in Kubernetes v1.32:

Kubernetes v1.32 Stable Features

1. Custom Resource Field Selectors

Feature Group: SIG API Machinery | KEP: #4358

Field selectors are used to filter Kubernetes objects by their field values. For example, you can list all Pods in a namespace that have a specific status. Until now, this capability was limited to certain predefined fields in core Kubernetes objects, but Kubernetes v1.32 allows users to define and customize these selectors for their own CRDs enabling precise querying and enhanced API efficiency.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.clothing.example.com
spec:
  group: clothing.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
    shortNames:
    - shrt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
              fabric:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    - jsonPath: .spec.fabric
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string
    - jsonPath: .spec.fabric
      name: Fabric
      type: string

Once this CustomResourceDefinition (CRD) is applied, you can use kubectl get commands to filter custom resources based on the color, size, and fabric fields. For example, To list all Shirt objects where the color is blue, run:

kubectl get shirts --field-selector spec.color=blue

NAME       COLOR   SIZE    FABRIC
alpha      blue    M       cotton
beta       blue    L       polyester

2. Support for Dynamic Memory-Backed Volumes

Feature Group: SIG Node | KEP: #1967

With Kubernetes v1.32, support for dynamic memory-backed volumes has reached general availability (GA). This feature allows the size of emptyDir volumes with medium: "Memory" to be dynamically determined based on a pod’s resource limits. Prior to this change, the size of memory-backed emptyDir volumes was linked to the node's allocatable memory, which resulted in unpredictable and inefficient memory utilization.

With the new enhancement, the size of a memory-backed emptyDir volume is set to the lesser of the pod's memory limit or an explicitly defined sizeLimit for the volume. This approach ensures that volume sizes are predictable resulting in better resource allocation, enhanced workload portability, and improved node resource utilization.

‍

3. Bound Service Account Token Enhancements

Feature Group: SIG Auth | KEP: #4193

The Bound Service Account Token enhancement in Kubernetes v1.32 introduces improved security and flexibility in how service account tokens are issued, validated, and revoked. This change allows tokens to be bound to specific API objects, making it possible to tie the validity of a token to the lifecycle of other objects, such as Pods, Secrets, or Nodes.

When a token is bound to an object, the metadata.name and metadata.uid of that object are included as private claims within the issued JWT token. The Kubernetes API server (kube-apiserver) will extract and verify these claims when the token is used for authentication. If the object referenced by the token no longer exists or if its UID changes, the token becomes invalid.

Example:

To create a service account token bound to a pod, use the following command:

kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod"

You can verify the token's private claims using the TokenReview API. Here is an example of a TokenReview manifest:

apiVersion: authentication.k8s.io/v1
kind: TokenReview
spec:
  token: 

To submit this TokenReview and see the results, run:

kubectl create -f tokenreview.yaml

You will see a response like this:

status:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  authenticated: true
  user:
    extra:
      authentication.kubernetes.io/credential-id:
      - JTI=7ee52be0-9045-4653-aa5e-0da57b8dccdc
      authentication.kubernetes.io/node-name:
      - kind-control-plane
      authentication.kubernetes.io/node-uid:
      - 497e9d9a-47aa-4930-b0f6-9f2fb574c8c6
      authentication.kubernetes.io/pod-name:
      - test-pod
      authentication.kubernetes.io/pod-uid:
      - e87dbbd6-3d7e-45db-aafb-72b24627dff5

This output shows the claims embedded in the token, including node name, pod name, and UIDs. These enhancements make service account tokens more secure, allowing for better access control and token revocation.

4. Structured Authorization Configuration

Feature Group: SIG Auth | KEP: #3221

Kubernetes v1.32 introduces the ability to configure multiple authorizers for the API server, providing more granular and customizable access control. This feature allows administrators to define a chain of authorizers, each with its own rules and logic, including support for Common Expression Language (CEL) match conditions. This enables precise filtering of requests before they are processed by webhooks.

A new approach to configure the authorization chain is through a configuration file specified using the --authorization-config flag on the API server. The configuration file allows admins to define multiple authorizers with clear rules for request validation and failure handling. For example, requests that fail to meet specific match conditions can be explicitly denied or passed on to the next authorizer in the chain.

apiVersion: apiserver.config.k8s.io/v1
kind: AuthorizationConfiguration
authorizers:
  - type: Webhook
    name: custom-webhook
    webhook:
      authorizedTTL: 30s
      unauthorizedTTL: 30s
      timeout: 3s
      subjectAccessReviewVersion: v1
      failurePolicy: Deny
      connectionInfo:
        type: KubeConfigFile
        kubeConfigFile: /kube-system-authz-webhook.yaml
      matchConditions:
        - expression: request.resourceAttributes.namespace == 'kube-system'
        - expression: "!('system:serviceaccounts:kube-system' in request.groups)"

This configuration enables a webhook authorizer that intercepts requests only for the kube-system namespace, but excludes requests from system service accounts.

These improvements provide greater control over API server access and reduce unnecessary webhook overhead.

5. Auto-Remove PVCs Created by StatefulSet

Feature Group: SIG Apps | KEP: #1847

In previous Kubernetes versions, when a StatefulSet was deleted, its associated PersistentVolumeClaims (PVCs) remained, often leading to orphaned storage. With Kubernetes v1.32, a new persistentVolumeClaimRetentionPolicy field has been introduced to control how PVCs are managed during StatefulSet lifecycle events like deletion or scale-down.

This feature allows admins to specify two distinct policies:

• whenDeleted – Determines the behavior of PVCs when a StatefulSet is deleted.
• whenScaled – Specifies what happens to PVCs when StatefulSet replicas are scaled down.

For each of these policies, admins can choose between:

• Delete – Automatically deletes PVCs after Pods are terminated.
• Retain (default) – Keeps PVCs intact, which was the default behavior in previous versions.

apiVersion: apps/v1
kind: StatefulSet
spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Delete

In this configuration, PVCs will be retained if the StatefulSet is deleted but will be automatically deleted when scaling down the replicas. This change prevents unnecessary storage usage.

Kubernetes v1.32 Beta Features

6. Job API Managed-By Mechanism

Feature Group: SIG Apps | KEP: #4368

Kubernetes v1.32 introduces a new managedBy field for Jobs, allowing the delegation of job management to an external controller. This feature provides better control over job synchronization and lifecycle management, especially for third-party controllers like Kueue.

With the managedBy field, operators can disable the built-in Kubernetes Job controller for specific Jobs. To enable this feature, the JobManagedBy feature gate must be enabled, which is not enabled by default. The value of the managedBy field indicates the controller responsible for managing the Job. If the field is set to any value other than kubernetes.io/job-controller, Kubernetes assumes that a third-party controller will manage the Job.

7. Structured Parameter Support for DRA

Feature Group: SIGNode, SIG Scheduling and SIG Autoscaling | KEP: #4381

Dynamic Resource Allocation (DRA) is a Kubernetes API that helps you in sharing and allocation of specialized resources, such as GPUs, among Pods and containers. Kubernetes v1.32 introduces structured parameter support for DRA, enhancing its capability to handle complex resource requests.

In earlier Kubernetes releases (v1.26 to v1.31), DRA was implemented in alpha, but it lacked structured parameter support. The new enhancement allows third-party drivers to define structured resource parameters, enabling more efficient scheduling and better prediction of resource availability. These parameters also help specify custom initialization for unique resources, like GPUs, based on workload requirements.

To use DRA, Kubernetes v1.32 must be installed, the DRA feature gate must be enabled, and Third-party drivers must be installed to track and allocate specific resources (like GPUs).

This structured support provides better alignment with complex workloads, especially those requiring specialized hardware. It also enables finer control over how resources are requested, allocated, and initialized. The improved DRA system aligns with modern workload demands and provides a standardized way to manage specialized resource allocation at scale.

‍

8. Restricting Anonymous Access to Specific Endpoints

Feature Group: SIG Auth  | KEP:  #4633 

In Kubernetes v1.32, administrators can now specify which API server endpoints permit anonymous access. This enhancement allows anonymous requests to be limited to non-sensitive endpoints, such as /healthz, /livez, and /readyz, while ensuring that all other endpoints require proper authentication. This feature enhances cluster security by preventing unauthorized access to critical resources, even in cases of misconfigured Role-Based Access Control (RBAC) settings.

To configure this, administrators can use the AuthenticationConfiguration file instead of relying on the --anonymous-auth flag. Here’s an example configuration file:

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

With this setup, only the /livez, /readyz, and /healthz endpoints are accessible anonymously, while all other endpoints require proper authentication.

9. Enhancing Scheduler Efficiency with Per-Plugin QueueingHints

 Feature Group: SIG Scheduling  | KEP: #4247

Kubernetes v1.32 introduces QueueingHint, a feature that improves the efficiency of the kube-scheduler by allowing each scheduling plugin to provide specific callback functions. These functions help determine when a pod should be requeued for scheduling, based on relevant events or changes in the cluster. By utilizing these per-plugin callbacks, the scheduler can make more informed decisions about retrying pod scheduling, reducing unnecessary retries and enhancing overall scheduling throughput.

For example, if a pod cannot be scheduled due to node affinity constraints, the NodeAffinity plugin can use a QueueingHint to requeue the pod only when a node update occurs that makes scheduling feasible. This targeted approach minimizes scheduling delays and optimizes resource utilization.

Kubernetes v1.32 Alpha Features

10. Asynchronous Preemption in the Kubernetes Scheduler

Feature Group:  SIG API Machinery | KEP: #4832‍

‍
Kubernetes v1.32 introduces several enhancements to improve cluster efficiency and resource management. One notable feature is Asynchronous Preemption in the scheduler, which enhances scheduling throughput by handling preemption operations asynchronously. Previously, preemption tasks were performed synchronously during the PostFilter phase, resulting in delaying the scheduling cycle due to necessary API calls. With asynchronous preemption, these tasks are processed in parallel, allowing the scheduler to continue scheduling other pods without delays. 

To enable this feature, the SchedulerAsyncPreemption feature gate must be activated. Once enabled, the scheduler can perform preemption operations asynchronously, improving overall scheduling efficiency. This change is advantageous in environments with high pod churn or frequent scheduling failures, as it allows the scheduler to handle preemptions in parallel with other tasks.

‍

11. Mutating Admission Policies Using CEL Expressions

Feature Group: SIG API Machinery | KEP: #3962

With Kubernetes v1.32, the API server introduces Mutating Admission Policies powered by the Common Expression Language (CEL) providing a declarative and efficient alternative to mutating admission webhooks. It reduces operational complexity, eliminates webhook dependencies, and integrates with the kube-apiserver for fast, reliable in-process mutations.

CEL-based policies allow administrators to define mutation rules for Kubernetes resources through simple, expressive configurations. These policies support two mutation types:

• Apply Configuration: It uses Server-Side Apply (SSA) merge strategies for updates.
• JSON Patch: It applies precise modifications using JSON Patch operations.

For example, you can configure a policy to add a sidecar container to newly created pods that lack one.

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: "sidecar-policy.example.com"
spec:
  paramKind:
    kind: Sidecar
    apiVersion: mutations.example.com/v1
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE"]
      resources:   ["pods"]
  matchConditions:
    - name: does-not-already-have-sidecar
      expression: "!object.spec.initContainers.exists(ic, ic.name == \"mesh-proxy\")"
  failurePolicy: Fail
  reinvocationPolicy: IfNeeded
  mutations:
    - patchType: "ApplyConfiguration"
      applyConfiguration:
        expression: >
          Object{
            spec: Object.spec{
              initContainers: [
                Object.spec.initContainers{
                  name: "mesh-proxy",
                  image: "mesh/proxy:v1.0.0",
                  args: ["proxy", "sidecar"],
                  restartPolicy: "Always"
                }
              ]
            }
          }

12. Pod-Level Resource Specifications

Feature group: SIG Node | KEP: #2837

Kubernetes v1.32 introduces pod-level resource specifications, an improvement in resource management that allows administrators to define resource requests and limits at the Pod level. This enables all containers within a Pod to share a dynamic resource pool, making it useful for workloads with fluctuating or bursty resource requirements. By leveraging Linux cgroup settings, Kubernetes making sure that these resource limits are enforced while maintaining backward compatibility with existing container-level configurations. This approach minimizes over-provisioning, increases resource efficiency, and simplifies operations for tightly integrated applications, such as those utilizing sidecar containers.

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  resources:
    limits:
      cpu: "1"
      memory: "200Mi"
    requests:
      cpu: "1"
      memory: "100Mi"
  containers:
  - name: pod-resources-demo-ctr-1
    image: nginx
    resources:
      limits:
        cpu: "0.5"
        memory: "100Mi"
      requests:
        cpu: "0.5"
        memory: "50Mi"
  - name: pod-resources-demo-ctr-2
    image: fedora
    command:
    - sleep
    - inf

In this example, the Pod has overall CPU and memory limits and requests defined. The first container has specific resource settings, while the second container dynamically uses resources within the Pod's shared pool. 

Kubernetes 1.32 brings a total of 44 Kubernetes Enhancement Proposals (KEPs) implemented. These enhancements include Kubernetes functionalities, storage improvements, networking advancements, security measures, and more.

Beyond the major changes we've discussed, there are other features added by the k8s team. We encourage you to have a look at the Kubernetes v1.31 release notes and check this for more details.