[kind] mount host /sys into kind node #1365
Conversation
| - role: control-plane | ||
| extraMounts: | ||
| - hostPath: /proc | ||
| containerPath: /host/proc |
There was a problem hiding this comment.
I will put again my comment from #774 (comment)
With Kind we're not testing with real host proc or host sys as we are not interested in the PIDs and containers not managed by Kind, we never had any issue so far, so I am not sure the use case is valid.
There was a problem hiding this comment.
I'm not quite sure what you mean by
we are not interested in the PIDs and containers not managed by Kind
Maybe I'm wrong but I think CWS needs these extra mounts because of nested namespace issues, i.e. the Kind node is a container running other containers.
In the case of CWS, the data we get from the kernel is from the perspective of the root PID namespace so we need to mount the real host proc path to have the correct PID mapping, otherwise we will look at the PIDs of the namespace of the Kind node and the PIDs mapping will be wrong.
This is the same issue for the host sys path because the cgroup membership in /proc is relative to the cgroup namespace, so we need access to /host/sys/fs/cgroup/[cgroup]/cgroup.procs to validate the cgroup mapping for a given PID.
Let me know if you think there's another way to solve these namespace mapping issues.
There was a problem hiding this comment.
I see, I'm not 100% sure if container monitoring will be impacted or not. If not that's fine and can be merged, although it should be explained around the extra mounts.
What does this PR do?
Similarly to #774, the system-probe container needs access to the host /sys filesystem to retrieve cgroup data of processes. This PR hence updates the kind node configuration to mount the host /sys directory into the control-plane container so that it can be propagated to the system-probe container.
Which scenarios this will impact?
Motivation
Additional Notes