Kubernetes SELinuxMount Upgrade Checklist

The official Kubernetes post on SELinux volume label changes in v1.36 is one of the more important upgrade notes for platform teams this spring. The short version is simple: Kubernetes is moving from slow recursive relabeling toward faster mount-time labeling, and some older shared-volume patterns will stop working when SELinuxMount becomes the default path.

What Changed in Kubernetes v1.36?

Today, many SELinux-enabled clusters rely on the container runtime to recursively relabel every file on a mounted volume. That works, but it can be slow, especially on large or remote-backed volumes.

Kubernetes v1.36 makes the newer mount-option approach ready for real preflight work. The stable seLinuxChangePolicy Pod field lets you control label behavior, while the optional selinux-warning-controller and new metrics help you find workloads that will conflict with the future default behavior.

The main risk is not performance regression. It is compatibility. Two patterns are especially important:

• two Pods with different SELinux labels sharing the same volume through different subPath values
• a privileged Pod and an unprivileged Pod sharing one volume

Those patterns can work with recursive relabeling but may block one Pod from starting when mount-based labeling is enforced.

Why SRE Teams Should Care

This is exactly the kind of change that bites during an otherwise routine upgrade. Nothing looks broken until the wrong pair of Pods lands on the same node and one gets stuck in ContainerCreating.

For SRE teams, that means hidden deployment risk, noisy rollouts, and confusing incident symptoms. The good news is that v1.36 gives you time to detect the problem before the default changes.

Audit Checklist

First, enable the warning controller on kube-controller-manager so the control plane starts surfacing volume-sharing conflicts:

kube-controller-manager \
  --controllers=*,selinux-warning-controller

Then watch for the new warning metric and related events:

kubectl get events -A | grep SELinuxLabel
kubectl -n kube-system port-forward deploy/kube-controller-manager 10257:10257
curl -ks https://127.0.0.1:10257/metrics | grep selinux_warning_controller_selinux_volume_conflict

If a workload must keep the old behavior for now, opt it out explicitly:

apiVersion: v1
kind: Pod
spec:
  securityContext:
    seLinuxChangePolicy: Recursive

That buys time, but it should not become the permanent answer. The better long-term fix is to remove conflicting shared-volume patterns where possible.

Operational Tips

Treat this as an upgrade rehearsal. Audit stateful workloads, backup jobs, security agents, and any privileged helper Pods first. Those are the places where shared volumes and mixed privilege levels tend to hide.

Also remember the scope: if SELinux is disabled on your nodes, this change does not affect you. If SELinux is enforced, though, v1.36 is the right moment to validate your workload design before v1.37 makes the faster path much harder to ignore.

Conclusion

Kubernetes v1.36 does not just improve SELinux volume performance. It gives platform teams a clean warning window before a future default can break legacy sharing patterns. Run the audit now, opt out only where needed, and fix the workload shapes that will cause startup conflicts later.

If you want to turn upgrade warnings into tracked operational work, Akmatori helps SRE teams automate infrastructure checks, incident response, and remediation flows. For the cloud and edge foundation behind modern platforms, Gcore provides the global infrastructure to run reliably at scale.