Kubernetes 1.31 - (Elli): What changes for production

Kubernetes 1.31, Elli, delivers 45 enhancements: 11 graduated to Stable, 22 entered Beta, and 12 reached Alpha, with particular emphasis on node security, storage lifecycle management, networking scalability, and hardware-aware workloads. The official release announcement describes Elli as a joyful dog with a sailor’s cap, celebrating Kubernetes’ diverse contributor community and the project’s first decade.

Key highlights and graduations

Architecture and workload controllers

Kubernetes 1.31 includes 11 Stable enhancements. The release blog lists the following cross-cutting and workload-management graduations:

Metric cardinality enforcement
PodHealthyPolicy for PodDisruptionBudget
Retriable and non-retriable Pod failures for Jobs
Elastic Indexed Jobs
StatefulSet control over starting replica ordinal numbers
Random Pod selection during ReplicaSet downscaling

These features are GA in 1.31. Operators should review the official Kubernetes 1.31 changelog for their complete API behavior and any feature-specific upgrade notes; the supplied release excerpt does not provide enough detail to document their configuration safely.

Scheduler QueueingHint behavior

When the SchedulerQueueingHints feature gate is enabled, the scheduler uses registered QueueingHint implementations for Pod/Updated events. Previously, an update to an unschedulable Pod always returned it to activeQ or backoffQ; under the new behavior, the Pod is requeued only when at least one hint returns Queue.

This requires action from custom scheduler plugin developers. If a plugin can reject a Pod for a condition that a subsequent update to that same Pod can resolve, the plugin must implement an appropriate QueueingHint for Pod/Update events. For example, a plugin that rejects Pods carrying schedulable=false should return Queue when that label is changed in a way that can make the Pod schedulable.

SIG Storage

Stable: PersistentVolume last phase transition time

PersistentVolume phase-transition timestamps are GA. Each PersistentVolume can expose:

.status.lastTransitionTime

The field records when the volume last transitioned between phases such as Pending, Bound, or Released. It is not populated immediately for every pre-existing volume after an upgrade; it is populated when a PersistentVolume is updated and first transitions to another phase after the cluster moves to 1.31.

For production environments, this creates a Kubernetes-native signal for measuring provisioning latency, such as the interval between Pending and Bound, and for building storage metrics and SLOs.

Beta: Always honor PersistentVolume reclaim policy

The enhancement that always honors a PersistentVolume reclaim policy is Beta in 1.31. It ensures that a Delete reclaim policy is enforced regardless of whether the PersistentVolume or PersistentVolumeClaim is deleted first.

This addresses cases where deletion order previously allowed the external storage resource to remain behind even though the PV reclaim policy was Delete. Storage operators should account for the fact that deletion now more reliably removes the underlying backend object.

Beta: VolumeAttributesClass and ModifyVolume

The VolumeAttributesClass API advances to Beta. It provides a Kubernetes-native mechanism for dynamically changing volume parameters, such as provisioned I/O, while a workload is online—provided that the storage provider supports the operation.

The practical benefit is vertical storage scaling without replacing the volume, allowing operators to adjust cost and performance characteristics as workload requirements change.

Alpha: OCI image volumes

Kubernetes 1.31 introduces an Alpha capability for mounting an OCI-compatible image or artifact as a Pod volume. It is controlled by the:

ImageVolume

feature gate.

This is intended to support use cases such as distributing AI/ML content through OCI registries and mounting that content into containers. Because it is Alpha, it should be evaluated in non-production environments unless the risks and lifecycle implications are explicitly accepted.

SIG Node

Stable: AppArmor support

AppArmor support is GA. Container profiles are configured through the container securityContext field:

appArmorProfile.type

Before Kubernetes 1.30, AppArmor configuration was annotation-based. Operators should migrate existing workloads away from the legacy annotations and use the structured appArmorProfile.type field.

Stable: CDI devices in the device plugin API

The release lists support for CDI devices in the device plugin API as Stable. The supplied excerpt does not provide configuration or migration details, so device plugin and hardware platform owners should validate their implementations against the full 1.31 changelog .

Alpha: Updated Dynamic Resource Allocation APIs

Kubernetes 1.31 updates the Dynamic Resource Allocation design, with a focus on structured parameters. Structured parameters make resource information and requests visible to Kubernetes and its clients, enabling use cases such as scheduler-based allocation and future cluster autoscaling integration.

The kubelet implementation was also updated to support version skew between kubelet and the control plane. With structured parameters, the scheduler allocates ResourceClaims while scheduling a Pod.

The earlier controller-based allocation model remains available as classic DRA. In 1.31, its control-plane controller has a separate gate:

DRAControlPlaneController

This gate must be enabled explicitly when a DRA driver requires controller-based allocation policies that are not supported through structured parameters.

Alpha: Device health in Pod status

An Alpha feature can expose assigned-device health through container status. When enabled, each applicable container status can include:

allocatedResourcesStatus

This reports health information for devices assigned to that container. The feature is disabled by default in 1.31; without it, operators must continue using the PodResources API to determine whether a Pod is associated with a failed device.

SIG Network

Stable: Improved ingress connectivity reliability in kube-proxy

Kube-proxy connection draining for terminating Nodes is Stable. It applies to Services configured with:

type: LoadBalancer
externalTrafficPolicy: Cluster

The mechanism reduces traffic loss during Node termination by coordinating connection draining. It requires kube-proxy to be the cluster’s default service proxy and the external load balancer to support connection draining.

No specific configuration change is required for kube-proxy: the behavior has been enabled by default since Kubernetes 1.30 and graduates to Stable in 1.31.

Beta: nftables backend for kube-proxy

The nftables backend reaches Beta behind the following feature gate, which is enabled by default:

NFTablesProxyMode

The nftables API is intended as the successor to iptables. The kube-proxy nftables mode can process Service endpoint changes more efficiently and can improve in-kernel packet processing at very large scale.

Important constraints apply:

It is available only on Linux Nodes.
It requires Linux kernel 5.13 or later.
It might not be compatible with every network plugin.
Some behavior, particularly around NodePort Services, differs from iptables mode.

Enabling the feature gate does not itself establish that a cluster has switched proxy modes. Before migration, operators must manually verify CNI or network-plugin compatibility and review any required configuration overrides.

Beta: Multiple Service CIDRs

Support for multiple Service CIDRs is Beta and disabled by default. It allows cluster administrators to modify Service CIDR ranges dynamically without downtime, addressing IP exhaustion in long-lived or large clusters.

This is particularly significant because the Service IP range was historically fixed at cluster creation through a kube-apiserver flag. The new capability avoids unsupported and potentially disruptive manual range replacement procedures.

Beta: Service traffic distribution

The trafficDistribution field in the Service specification is Beta and enabled by default. It provides a routing preference that the underlying implementation can consider when making traffic-distribution decisions.

Operators should treat the field as guidance to the implementation rather than assume behavior not documented in the supplied release source.

SIG Auth and security

Beta: Node-bound service account tokens

The ServiceAccountTokenNodeBinding feature advances to Beta. It permits requesting a service account token bound to a Node rather than to a Pod.

The token contains Node information in its claims, and the Node’s existence is validated when the token is used. This provides a more specific identity model for Node-scoped use cases.

Alpha: Selector-aware authorization

Kubernetes 1.31 introduces finer-grained authorization for list and watch requests that include label or field selectors. Webhook authorizers—and potential future in-tree authorizers—can make decisions such as:

Allowing a user to list only Pods whose .spec.nodeName matches a particular Node.
Allowing a user to watch Secrets that are not labelled confidential: true.

Combined with CRD field selectors, which the release blog states are Beta in 1.31, this can support more narrowly scoped per-Node extensions.

Alpha: Restrictions on anonymous API access

The following feature gate enables endpoint-specific control over anonymous access through an authentication configuration file:

AnonymousAuthConfigurableEndpoints

This can reduce exposure caused by RBAC mistakes that unintentionally grant broad permissions to anonymous users. The supplied excerpt does not define the configuration schema or default gate state, so the exact implementation must be verified against the official documentation before use.

Deprecations, removals, and breaking changes

Cgroup v1 enters maintenance mode

Cgroup v1 support is now in maintenance mode. Kubernetes will not add new cgroup v1 features; critical security fixes will continue, while other bug fixes are best-effort.

Operators should begin moving to cgroup v2. The migration requires:

An operating system that supports cgroup v2.
A compatible container runtime.
Workload testing to confirm application behavior under cgroup v2.

Kubernetes 1.31 does not remove cgroup v1, but maintenance mode is a clear signal that new deployments should avoid increasing their dependency on it.

Node kube-proxy version field deprecated

The following Node status field is deprecated:

.status.nodeInfo.kubeProxyVersion

The field was unreliable because it was populated by the kubelet, which does not have authoritative information about the kube-proxy version or even whether kube-proxy is running.

In 1.31, the following feature gate defaults to true:

DisableNodeKubeProxyVersion

As a result, kubelet no longer attempts to populate the deprecated kube-proxy version field. Monitoring, inventory, and compliance systems must stop relying on this Node status value. The field is scheduled for removal in a later release, but the supplied sources do not identify that release.

All in-tree cloud-provider integrations removed

The final in-tree cloud-provider integrations have been removed from Kubernetes core. Clusters that integrate with cloud providers must use an external cloud-provider integration.

This is a breaking change for environments still dependent on the removed in-tree implementation. Before upgrading the control plane or Nodes, operators must confirm that the appropriate external integration is deployed and that their cluster lifecycle tooling is configured to use it.

In-tree provider feature gates removed

The following Alpha feature gates have been removed:

InTreePluginAWSUnregister
InTreePluginAzureDiskUnregister
InTreePluginAzureFileUnregister
InTreePluginGCEUnregister
InTreePluginOpenStackUnregister
InTreePluginvSphereUnregister

These gates had supported testing scenarios in which in-tree volume plugins were treated as unregistered. They became redundant after the associated plugins were deprecated.

The remaining CSI migration-related gate identified by the release blog is:

InTreePluginPortworxUnregister

It remains Alpha pending completion of Portworx CSI migration.

Kubelet flag removed

The long-deprecated kubelet flag below has been removed:

--keep-terminated-pod-volumes

Any kubelet service definition, systemd unit, Node bootstrap template, machine image, or configuration-management policy that still passes this flag must be updated before starting a 1.31 kubelet.

CephFS in-tree volume plugin removed

The in-tree CephFS volume plugin has been removed, making the following volume type non-functional:

cephfs

The migration path is the third-party CephFS CSI driver. Applications using the in-tree plugin must be redeployed to use the CSI driver before upgrading to 1.31. The plugin had been formally deprecated in Kubernetes 1.28.

Ceph RBD in-tree volume plugin removed

The Ceph RBD volume plugin and its CSI migration support have been removed, making the following in-tree volume type non-functional:

rbd

Clusters must use an RBD CSI driver instead. Existing applications using the in-tree RBD plugin must be redeployed with the CSI driver before the upgrade. The in-tree plugin had been formally deprecated in Kubernetes 1.28.

Non-CSI scheduler volume-limit plugins deprecated

Kubernetes 1.31 deprecates non-CSI volume-limit scheduler plugins and removes the following already-deprecated plugins from the default plugin set:

AzureDiskLimits
CinderLimits
EBSLimits
GCEPDLimits

Use the following scheduler plugin instead:

NodeVolumeLimits

If any of the deprecated plugins are explicitly present in a scheduler configuration, replace them with NodeVolumeLimits. The four plugin implementations are planned for removal in a future release; they are not described as completely removed from Kubernetes 1.31.

SHA-1 certificate compatibility

Go’s crypto/x509 library rejects SHA-1-signed certificates by default. This can affect user-provided certificates used by aggregated API servers or webhooks.

At the time of the 1.31 release, compatibility could be explicitly restored through:

GODEBUG=x509sha1=1

However, the release announcement warns that the x509sha1 override and SHA-1 certificate support would be removed with Go 1.24. Operators should therefore treat the environment variable only as a temporary compatibility measure and replace SHA-1-signed certificates.

Because later 1.31 patch releases can update the Go toolchain, verify SHA-1 behavior against the exact patch release in the official changelog .

Upgrade impact and operational notes

Before upgrading the control plane

Review the following areas:

Cloud-provider integration: Confirm that no control-plane component depends on an in-tree cloud provider.
Scheduler configuration: Replace explicit AzureDiskLimits, CinderLimits, EBSLimits, or GCEPDLimits entries with NodeVolumeLimits.
Custom scheduler plugins: Implement QueueingHint behavior for relevant Pod/Update events if SchedulerQueueingHints will be enabled.
Certificates: Identify SHA-1-signed certificates used by aggregated API servers or admission webhooks and plan their replacement.
Anonymous access: If evaluating AnonymousAuthConfigurableEndpoints, verify the authentication configuration format in the official documentation.
DRA controllers: If relying on classic DRA, account for the separate DRAControlPlaneController gate.
Service networking: Do not enable multiple Service CIDRs or migrate kube-proxy to nftables without validating the complete configuration and network-plugin behavior.

Before upgrading worker Nodes

Review each Node image and kubelet configuration for:

The removed --keep-terminated-pod-volumes flag.
AppArmor annotations that should be migrated to securityContext.appArmorProfile.type.
Dependencies on .status.nodeInfo.kubeProxyVersion.
Operating system and container runtime readiness for cgroup v2.
Linux kernel 5.13 or later if nftables kube-proxy mode will be used.
Network-plugin compatibility with the nftables backend.
Device plugin compatibility if using CDI or the updated DRA APIs.

The supplied sources do not define a new cluster-wide minimum kernel, container runtime, or etcd version for Kubernetes 1.31. Kernel 5.13 is specifically required only for the nftables kube-proxy backend described above; all other dependency requirements should be verified for the exact deployment method and patch release.

Storage migration gate

Do not proceed with the upgrade while active manifests still depend on the removed in-tree cephfs or rbd volume types. Those applications must be redeployed to use their corresponding CSI drivers.

Also review automation that deletes PVCs and PVs. With the Beta reclaim-policy enhancement, a Delete policy is honored regardless of PV/PVC deletion order, making backend deletion more consistent.

Patch-release security consideration

The supplied changelog documents CVE-2025-5187, a NodeRestriction vulnerability affecting kube-apiserver versions v1.31.0 through v1.31.11. The fixed 1.31 version identified by the changelog is v1.31.12.

Accordingly, the original v1.31.0 tag is useful as the historical release baseline, but operators planning a real deployment should review the complete 1.31 patch history and select an appropriate patched build rather than assuming that the initial release contains later security fixes.

Conclusion

Kubernetes 1.31 Elli combines mature production capabilities—such as GA AppArmor support, PersistentVolume transition timestamps, and improved LoadBalancer connection draining—with Beta networking and storage improvements and forward-looking Alpha work for accelerators, OCI artifacts, device health, and more granular authorization. The primary upgrade risks are concentrated around removed in-tree integrations, legacy Ceph volume types, obsolete kubelet flags, custom scheduler behavior, and infrastructure that still relies on cgroup v1 or SHA-1 certificates.