EKS 1.31 leaves extended support on November 26, 2026. After that date AWS upgrades the control plane to 1.32 for you, with no notice beforehand. So if you still have a 1.31 cluster, you're about to do the 1.31 to 1.32 hop whether you planned it or not.
Most people prepare for a hop by scanning for removed APIs. That scan comes back clean for this one. It still misses a change I think is worth ten minutes.
The 1.32 changelog has this line:
Apply fsGroup policy for ReadWriteOncePod volumes.
That's the whole entry. Here is what it means. If a pod sets securityContext.fsGroup and mounts a ReadWriteOncePod volume, the files on that volume get re-owned to the fsGroup the first time the pod mounts it after the upgrade. ReadWriteOnce volumes already worked this way. ReadWriteOncePod ones didn't.
For most apps that's harmless. It matters in two cases. One is an app that depends on the ownership its files had before. The other is a large volume, because the ownership change is a recursive chown.
Here's the read-only check. It lists every claim that uses the ReadWriteOncePod access mode:
kubectl get pvc -A -o json | jq -r '.items[] | select(.spec.accessModes | index("ReadWriteOncePod")) | .metadata.namespace + "/" + .metadata.name' I ran it against a sample with three claims, two of them ReadWriteOncePod, and got:
payments/ledger-data search/index-0 No output means you have nothing to check. If you get names back, look at the pods that mount those claims. A pod that sets fsGroup is affected. If you'd rather avoid the full recursive pass, set fsGroupChangePolicy: OnRootMismatch in the pod's securityContext, which limits the chown.
One more thing about the forced upgrade. AWS only moves the control plane. Your node groups stay on 1.31 until you upgrade them yourself, so run this check before you roll the nodes.
Are you running ReadWriteOncePod volumes in production yet, or is everything still ReadWriteOnce?
