Kubernetes 1.32 dropped in December 2024 and, like most Kubernetes releases, came with a long changelog. Most of it is gradual maturation of features you may already be using. But several changes are significant enough to plan around — either because they’re graduating to stable (and you should start using them) or because they introduce patterns that will shape how Kubernetes works going forward.
Here’s the practical breakdown.
What Graduated to Stable
Stable features are the ones to actually adopt now. They’ve gone through Alpha and Beta, have clear APIs, and won’t change under you.
Persistent Volume Last Phase Transition Time (Stable)
PersistentVolumes now track when they last transitioned phases (Pending → Bound → Released, etc.). This sounds minor but is genuinely useful for debugging storage issues:
kubectl get pv my-volume -o jsonpath='{.status.lastPhaseTransitionTime}'
# 2026-01-15T08:23:45Z
Previously you had to infer from events when a volume got stuck. Now you have a direct timestamp.
Node Log Query (Stable)
You can now query node-level logs through the Kubernetes API, without SSHing into nodes:
# Get systemd service logs from a node
kubectl get --raw "/api/v1/nodes/worker-01/proxy/logs/?query=kubelet&sinceTime=2026-02-24T00:00:00Z"
For homelab and production environments where you want to maintain an audit trail of node-level activity through the API rather than direct SSH, this is a clean addition.
Recursive Read-Only Mounts (Stable)
Previously, marking a volume mount as readOnly: true didn’t prevent subdirectories within that mount from being writeable if they were mounted separately. With recursive read-only mounts, you can enforce that:
volumeMounts:
- name: config
mountPath: /etc/app/config
readOnly: true
# New: prevents any nested mounts from being writable
recursiveReadOnly: Enabled
This matters for security hardening — if you’re following CIS benchmarks, this closes a gap in the volume immutability model.
Notable Beta Features Worth Testing
Beta features have stable APIs (in most cases) and are suitable for non-production and advanced users willing to work through rough edges.
Dynamic Resource Allocation (Beta)
DRA is the future of how Kubernetes handles specialized hardware (GPUs, FPGAs, network accelerators). The current device plugin model was designed when the primary use case was “I have N GPUs on a node, schedule pods to use them.” DRA handles more complex scenarios:
- Multiple devices with different capabilities on the same node
- Resources that need to be prepared before the pod starts
- Shared resources across pods
- Resources with topology constraints
For AI/ML workloads, this is important:
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
name: gpu-claim
spec:
devices:
requests:
- name: gpu
deviceClassName: nvidia.com/gpu
count: 1
selectors:
- cel:
expression: "device.attributes['memory'].isGreaterThan(quantity('24Gi'))"
DRA allows you to express “I need a GPU with at least 24GB of VRAM” rather than just “I need 1 GPU.” For homelab users running AI workloads, this will eventually replace the current nvidia.com/gpu: 1 resource model.
In-Place Pod Resource Resize (Beta)
This is the one I’m most excited about. Previously, changing a pod’s CPU or memory requests/limits required restarting the pod. With in-place resize, you can update resources without a restart:
# Update container resources without pod restart
kubectl patch pod my-app -p '{"spec":{"containers":[{"name":"app","resources":{"requests":{"memory":"512Mi"},"limits":{"memory":"1Gi"}}}]}}'
# VPA with in-place updates (when both are enabled)
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: my-app-vpa
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
updatePolicy:
updateMode: InPlace # No restarts!
For databases, caches, and any stateful workload, avoiding restarts for resource adjustments is a significant operational improvement. This pairs well with Vertical Pod Autoscaler for true rightsizing without disruption.
Topology-Aware Routing (Enhanced)
Kubernetes’ topology-aware routing (previously “topology hints”) has been improved to be more reliable. This controls whether a Service routes traffic to endpoints in the same zone first:
apiVersion: v1
kind: Service
metadata:
name: my-service
annotations:
service.kubernetes.io/topology-mode: Auto
spec:
selector:
app: my-app
For multi-zone clusters, this reduces cross-zone data transfer costs and latency. The improvements in 1.32 address cases where the previous implementation would fall back to random routing more than expected.
Deprecations and Removals to Know
cgroup v1 is Now in Maintenance Mode
Not removed, but cgroup v1 is now explicitly in maintenance mode. Kubernetes recommends cgroup v2 for all new deployments. Most modern Linux distributions (Rocky Linux 9, Ubuntu 22.04+) default to cgroup v2 already.
If you’re still running cgroup v1:
# Check which cgroup version your nodes use
stat -fc %T /sys/fs/cgroup/
# cgroup2fs = v2
# tmpfs = v1
RKE2 on Rocky Linux 9 should be using cgroup v2 by default. Verify, and plan migration if not.
Legacy ServiceAccount Token Auto-Mounting
Automatic mounting of ServiceAccount tokens in pods is being further constrained. The best practice — explicitly setting automountServiceAccountToken: false and mounting tokens only where needed — has been the recommendation for years, but 1.32 tightens defaults:
# Security best practice (explicitly opt out of auto-mount)
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-app-sa
namespace: production
automountServiceAccountToken: false
---
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
serviceAccountName: my-app-sa
automountServiceAccountToken: false # Belt and suspenders
The Scheduling Improvements
Pod Scheduling Readiness (Stable)
Pods can now signal when they’re ready to be scheduled using a “scheduling gate.” This is useful for controllers that need to do work before a pod can be placed:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
schedulingGates:
- name: example.com/foo # Pod won't be scheduled until this gate is removed
containers:
- name: app
image: myapp:latest
A controller removes the gate when prerequisites are met. This avoids the pattern of creating pods that immediately fail because they depend on resources that don’t exist yet.
Upgrading to 1.32
The standard upgrade path for RKE2:
# Check current version
kubectl version --short
# On control plane nodes (one at a time):
# Update the RKE2 channel or pin to 1.32.x
curl -sfL https://get.rke2.io | INSTALL_RKE2_VERSION=v1.32.1+rke2r1 sh -
systemctl restart rke2-server
# Verify health before next node
kubectl get nodes
kubectl get pods -A --field-selector=status.phase!=Running
Always test in a non-production cluster first. Review the full changelog at kubernetes.io/docs/setup/release/notes for API changes that might affect your workloads.
Conclusion
Kubernetes 1.32’s most impactful additions for production operators are in-place pod resource resize (stop restarting databases for VPA adjustments), recursive read-only mounts (security hardening), and the continued maturation of Dynamic Resource Allocation for GPU workloads. The cgroup v2 push is also worth planning for if you haven’t migrated.
None of this is a reason to rush an upgrade in isolation — but if you’re on an upgrade cadence, these features make 1.32 worth moving toward.
