[
https://issues.apache.org/jira/browse/MESOS-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646230#comment-14646230
]
James DeFelice edited comment on MESOS-349 at 7/29/15 3:01 PM:
---------------------------------------------------------------
I have a specific use case that doesn't appear to be solved by the file system
isolator. The kubernetes-mesos framework schedules a single "kubelet-executor"
process that runs on a slave for all k8s-mesos tasks (currently uses mesos
containerizer). This kubelet proc creates mounts in $sandbox/pods/volumes
according to volumes delared in k8s pod specs. Many different types of
mount-types are supported by k8s volume plugins (e.g. nfs, iscsi, bind, tmpfs).
These mount points are passed to a 'docker run' invocation so that k8s pods can
see data in these mounted volume directories.
Running the kubelet in an isolated filesystem breaks this model because the
changes to the mount table of the kubelet-executor (running in an isolated
mount-ns) are not visible in the hosts's mount-ns (where docker is looking when
spinning up CT's).
There is no guaranteed way to clean up these mount points upon termination of
the kubelet-executor if the process terminates abnormally in some way. The
slave GC algorithm will remove the sandbox files but will not clean up the
mount points.
I'd like to re-open this issue for discussion but JIRA won't let me.
was (Author: jdef):
I have a specific use case that doesn't appear to be solved by the file system
translator. The kubernetes-mesos framework schedules a single
"kubelet-executor" process that runs on a slave for all k8s-mesos tasks
(currently uses mesos containerizer). This kubelet proc creates mounts in
$sandbox/pods/volumes according to volumes delared in k8s pod specs. Many
different types of mount-types are supported by k8s volume plugins (e.g. nfs,
iscsi, bind, tmpfs). These mount points are passed to a 'docker run' invocation
so that k8s pods can see data in these mounted volume directories.
Running the kubelet in an isolated filesystem breaks this model because the
changes to the mount table of the kubelet-executor (running in an isolated
mount-ns) are not visible in the hosts's mount-ns (where docker is looking when
spinning up CT's).
There is no guaranteed way to clean up these mount points upon termination of
the kubelet-executor if the process terminates abnormally in some way. The
slave GC algorithm will remove the sandbox files but will not clean up the
mount points.
I'd like to re-open this issue for discussion but JIRA won't let me.
> remove mounts when garbage collecting tasks
> -------------------------------------------
>
> Key: MESOS-349
> URL: https://issues.apache.org/jira/browse/MESOS-349
> Project: Mesos
> Issue Type: Improvement
> Components: slave
> Reporter: Jonathan Boulle
> Priority: Minor
>
> It would be extremely helpful if the GC process on a slave (which is
> currently effectively just an {{rm -rf}}) could also remove mounts within the
> executor sandbox.
> This would allow sandboxes to incorporate mounts from different filesystems,
> for example, or to utilise chroots (which require various mounts to function
> properly - e.g. {{/proc}} and {{/sys}} on Linux) - and still be cleaned up by
> the mesos slave without any external intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
