+- - - - - - - - - - - - - - - - - - + ' Master ' ' ' ' +-----------------------+ ' ' | ConfigMap | ' ' +-----------------------+ ' ' ' +- - - - - - - - - - - - - - - - - - + ^ | 1. get REST API path | +- - - - - - - - - - - - - - - - - - + ' Kubelet ' ' ' ' +-----------------------+ ' ' | Mounter | ' <+ ' +-----------------------+ ' | ' ' | +- - - - - - - - - - - - - - - - - - + | | | | 2. mount REST call | 5. mount REST success v | + - - - - - - - - - - - - - - - - - - - - - - - - - - + | ' DaemonSet ' | ' ' | ' +-----------------------+ ' | ' +---------------------> | Daemon | ' -+ ' | +-----------------------+ ' ' | | ' ' | 4. success | 3. exec ' ' | v ' ' | +-----------------------+ ' ' +---------------------- | /sbin/mount.glusterfs | ' ' +-----------------------+ ' ' ' + - - - - - - - - - - - - - - - - - - - - - - - - - - +
Needs mount namespace propagation from Docker >= 1.10
-
One monolithic daemonset with all mount binaries or one daemon set that orchestrates multiple imagaes, each of which support certain types of filesystem.
- Rolling upgrade of daemonset doesn't exist.
- If new volume mount is absent in the daemonset, how to load it on the hosts without bringing down the existing mounts.
-
(pmorie) in-kernel vs in-user space mounters don't have the same resource usage profile. Long running mounts like FUSE need to be subject to quota control.
-
(saad) What is in the ConfigMap? REST API path for individual filesystems.
-
Is pod-running-inside-kubelet approach more resource efficient?
- (sami) running a pod to mount by
kubelet
- (sami) daemonset needs a REST API redirection on all hosts, seemingly inefficient.
- (hchen) running-pod-inside-kubelet needs to manage pod lifecycle, and ensure pod executes the mount (meaning watching apiserver)
- (sami) running a pod to mount by
-
(sami and pmorie) How to ensure mount namespace propagation to be set in a Pod (not Docker API)
-
(nelluri) How to ensure daemonset reacheable only by kubelet? Do other user containers able to access the daemonset to execute mount?