Treat SELinux mount labeling as a workload-level change

GA does not mean every volume takes the fast path

Recursive SELinux relabeling can turn volume setup into work proportional to the contents of a volume. Mount-time labeling changes that cost: instead of walking files to change their labels, Kubernetes can apply a label through a mount option. The Kubernetes 1.36 release announcement describes the improvement as generally available and says it can reduce Pod startup delays on SELinux-enforcing systems.

I would not read that announcement as a guarantee that upgrading to Kubernetes 1.36 makes every Pod start faster. The details matter. The Kubernetes SELinux volume-labeling guidance clarifies that the broader SELinuxMount feature gate is beta and disabled by default in 1.36. The ReadWriteOncePod path and the SELinuxChangePolicy field have different graduation status. Whether a volume uses mount-time labeling depends on the applicable feature gates and volume and Pod conditions.

That distinction changes the operational question. It is not simply, “Did I upgrade?” It is, “Which of my workloads now use mount-time labeling, on which nodes, and what changes for those workloads?” I would confirm the effective behavior in the cluster before attributing a startup change to the release. Otherwise, a before-and-after comparison can tell me little: the relevant path may not have changed at all.

The gain depends on the path through the system

A volume with many files is an obvious candidate for a measurable difference if it previously required recursive relabeling. But file count alone is not a useful workload profile. I would also look at the storage type and CSI driver, how the volume is mounted, whether Pods share it, and whether those Pods use compatible SELinux labels. These details determine both whether mount-time labeling applies and whether a single mount label fits the way the workload uses the data. The Kubernetes SELinux labeling change guidance describes conflicts when Pods with different SELinux labels share a volume.

This is why I would treat the change as an operational trade-off, not a free optimization. The shorter setup path is useful only if it preserves the sharing and access behavior the workload needs. A startup improvement that turns a previously valid shared-volume pattern into a Pod start failure is not an improvement for that workload. I would not loosen SELinux policy or assume a storage driver behaves like another one just to make a benchmark look good.

The node matters too. The feature is aimed at Linux systems that use SELinux; a cluster with mixed node configurations should not be assessed as if every Pod encounters the same mount path. I would group results by the node and storage combinations the scheduler can actually place the workload on. If a service moves between node pools, its observed startup time may reflect that difference as much as the feature itself.

Measure the part that changed

I would compare the same workload before and after enabling the relevant path, keeping the volume contents and placement conditions as consistent as I can. I would include the ordinary case and the cases most likely to expose trade-offs: large or file-dense volumes, the actual CSI driver, concurrent starts, and any shared-volume patterns in use. I would not use a tiny empty volume as evidence for a workload whose startup depends on a populated one.

For each run, I would track Pod creation through readiness, but I would also break that interval into observable stages. Scheduling, image pulls, volume attachment, mounting, container startup, and readiness checks can all contribute to the total. If only the overall time changes, I still do not know whether SELinux labeling was responsible. If the mount stage shrinks but the Pod reaches readiness at the same time, the feature may be working while another stage remains the actual bottleneck.

I would compare repeated runs and look at both the typical result and the slow tail. Cold and warm image-cache states should not be mixed without being recorded, and concurrent starts should be tested separately from isolated starts. Those are not claims that every cluster needs a formal benchmark suite; they are ways to avoid mistaking unrelated startup variation for a storage-labeling gain.

For a workload where I need to explicitly choose the policy, the Pod field gives me a visible control. For example, a workload that must retain recursive relabeling can state that intent:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  securityContext:
    seLinuxChangePolicy: Recursive
  containers:
    - name: app
      image: example-image

I would not copy that setting into every Pod as a precaution. It opts that workload out of the mount-option path; applying it indiscriminately could also hide the very behavior I am trying to evaluate. The Kubernetes SELinux volume-labeling guidance explains the policy field and the feature-gate conditions. I would use it where the workload needs recursive behavior, then document why that exception exists.

Upgrade for the capability, not an assumed speedup

A platform upgrade can make a better implementation available, but it cannot tell me whether my own bottleneck was recursive relabeling. I would first inventory the node operating systems, feature-gate state, CSI drivers, volume access patterns, and workloads that share storage. Then I would test representative cases and check both startup behavior and compatibility before changing the default posture.

If the measured mount work falls and the workload still starts correctly, I have evidence to expand adoption. If there is no meaningful change, I would investigate whether the volume took the mount-time path and whether another startup stage dominates. If a shared-volume workload fails or behaves differently, I would treat that as a compatibility issue to resolve, not as a reason to disable SELinux across the cluster.

That is the performance claim I would trust: not that Kubernetes 1.36 is faster in general, but that a specific workload, on a known node and storage path, starts better without changing the security or sharing behavior it depends on.