Bidirectional mount propagation for hostroot #1290
Conversation
…root` volume in the `multus-daemonset-thick.yml` example/quickstart deployment file from `HostToContainer` to `Bidirectional`. This change enables the volume to be accessible in both directions, which is necessary for users who need to share a mount with another container/pod. This is motivated by the fact that in thin plugin mode, since all things were run on the host directly, CNI plugins wouldn't be limited by the mount propagation. One example that has come up recently is userspace CNI interaction with kubevirt, and sharing the usage of the socket as mounted by kubevirt. This does expose some level of risk (as noted in the mount propagation docs regarding changing of mounts), however, I don't believe it's significantly more than would've been the case in thin plugin mode. References - [Kubernetes Volume Mount Propagation Documentation](https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation)
dougbtv
changed the title
| @@ -190,7 +190,7 @@ spec: | |||
| readOnly: true | |||
| - name: hostroot | |||
| mountPath: /hostroot | |||
| mountPropagation: HostToContainer | |||
| mountPropagation: Bidirectional | |||
There was a problem hiding this comment.
don't we actually consider these yamls to be just examples ?
Why can't the downstreams that require it to be bi-directional use what they need ?
I'm trying to wrap my head around the fact this is not the recommended configuration, required only for specific use cases, but still, we're advocating / instructing everyone to use it.
There was a problem hiding this comment.
These are indeed examples, but, I think this more accurately represents a setup that's similar to what happens in a thin plugin mode on the host -- you'd see mounts in both directions. So, I think it's a valid setup and probably better for more cases at least.
There was a problem hiding this comment.
I disagree, but don't have more arguments other than this is not the recommended configuration, and is required only for specific use cases.
Do we even know if this will work on openshift ?
Modifies the
hostrootvolume in themultus-daemonset-thick.ymlexample/quickstart deployment file fromHostToContainertoBidirectional. This change enables the volume to be accessible in both directions, which is necessary for users who need to share a mount with another container/pod.This is motivated by the fact that in thin plugin mode, since all things were run on the host directly, CNI plugins wouldn't be limited by the mount propagation.
One example that has come up recently is userspace CNI interaction with kubevirt, and sharing the usage of the socket as mounted by kubevirt.
This does expose some level of risk (as noted in the mount propagation docs regarding changing of mounts), however, I don't believe it's significantly more than would've been the case in thin plugin mode.
References