Mention that KCM cannot know default labels

Author: jsafrane

keps/sig-storage/1710-selinux-relabeling/README.md

@@ -606,7 +606,12 @@ Drawbacks:
 * The controller may report a conflict when two Pods are scheduled to the same node, but they will run serially there.
   For example, one pod is already being deleted and the other has just been scheduled there.
   Kubelet's `volume_manager_selinux_volume_context_mismatch_warnings_total` metric is more accurate in this case.
-  
+* The controller cannot read the SELinux default container labels from the operating system.
+  KCM often runs in a container and does not have access to `/etc/selinux` on the worker nodes.
+  As consequence, two labels that are equivalent from the SELinux point of view, may be reported as different, such as these two `seLinuxOptions` snippets: `{"type": "container_t", "level": "s0:c10,c0"}` and `{"level": "s0:c10,c1"}`.
+  `container_t` is the default type label for containers on Fedora, so kubelet is able to fill it in the `seLinuxOptions` when it is not set and see they're equivalent.
+  KCM does not know the default on nodes and treats these `seLinuxOptions` as different.
+
 ### Implementation phases
 
 Due to change of Kubernetes behavior, we will implement the feature only for cases where it can't break anything first.