Code change:
} } } <del> // Check that the mounts are/are not propagated to the host. // Host can see mount from master cmd = fmt.Sprintf("test `cat %q/master/file` = master", hostDir) err = hostExec.IssueCommand(cmd, node) framework.ExpectNoError(err, "host should see mount from master") // Host can't see mount from slave cmd = fmt.Sprintf("test ! -e %q/slave/file", hostDir) err = hostExec.IssueCommand(cmd, node) framework.ExpectNoError(err, "host shouldn't see mount from slave") </del> <ins> // Find the kubelet PID to ensure we're working with the kubelet's mount namespace cmd = "pidof kubelet" kubeletPid, err := hostExec.IssueCommandWithResult(cmd, node) framework.ExpectNoError(err, "Checking kubelet pid") kubeletPid = strings.TrimSuffix(kubeletPid, "n") framework.ExpectEqual(strings.Count(kubeletPid, " "), 0, "kubelet should only have a single PID in the system (pidof returned %q)", kubeletPid) enterKubeletMountNS := fmt.Sprintf("nsenter -t %s -m", kubeletPid) // Check that the master and host mounts are propagated to the container runtime's mount namespace for _, mountName := range []string{"host", master.Name} { cmd := fmt.Sprintf("%s cat "%s/%s/file"", enterKubeletMountNS, hostDir, mountName) output, err := hostExec.IssueCommandWithResult(cmd, node) framework.ExpectNoError(err, "host container namespace should see mount from %s: %s", mountName, output) output = strings.TrimSuffix(output, "n") framework.ExpectEqual(output, mountName, "host container namespace should see mount contents from %s", mountName) } // Check that the slave, private, and default mounts are not propagated to the container runtime's mount namespace for _, podName := range []string{slave.Name, private.Name, defaultPropagation.Name} { cmd := fmt.Sprintf("%s test ! -e "%s/%s/file"", enterKubeletMountNS, hostDir, podName) output, err := hostExec.IssueCommandWithResult(cmd, node) framework.ExpectNoError(err, "host container namespace shouldn't see mount from %s: %s", podName, output) } </ins> }) })

Related discussion:
text: Today systemd's CPU usage is adversely affected by a large number of mountpoints, especially versions released prior to December 2020. This feature of systemd, which scans all /proc/1/mount to invoke udev events for every change suffers from two issues. The first was an inefficiency in systemd’s processing logic. This was fixed in December 2020, and this fix reportedly reduced the systemd mount-scanning-related overhead by 30-50%. The second is a lack of granularity in the events the kernel sends to systemd about mountpoint changes, which necessitates a full rescan of all mountpoints even on a minor change or single mountpoint addition. The kernel change to remedy this seems unlikely to move forward in the near term. (See for more details) For example, a fairly small OpenShift deployment today (which does not yet have the systemd December 2020 fix) has upwards of 400 mountpoints on every node owned by Kubelet, the Container Runtime, and infrastructure containers like OVN or CSI operators. Hiding the container mountpoints reduces the steady-state systemd CPU utilization from ~10% to ~0% on every worker node. On a more heavily loaded system, with 1000’s of container mountpoints, systemd’s usage will cap out at 100% of a single CPU core. Even with the 30-50% reduction in systemd usage expected from the December 2020 fix, having systemd take up as much as 50-70% of a single CPU in the worst-case scenario is a lot of unnecessary overhead. Administrators of other OSes with other host OS services that monitor or process mountpoints indiscriminately would be able to hide these container-specific mountpoints from the OS at large, at their option. With this requirement relaxed, it would be possible to run multiple instances of Kubernetes on a single host without the various mountpoints interfering with one another. There may be other inter-instance difficulties besides the mount namespace, but this does move in that direction without resorting to more complicated solutions like trying to run Kubernetes inside of containers.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available .