New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Volumes require filesystem clients and utilities on host #8124

Closed
childsb opened this Issue May 12, 2015 · 4 comments

Comments

Projects
None yet
7 participants
@childsb
Copy link
Member

childsb commented May 12, 2015

The various filesystem plugins currently work by mounting a filesystem on the host then passing that mounted dir to the pod for access. This requires that the host system has the filesystems client & utils installed and configured.

I would like to containerize the filesystem client pieces and run it as a sidecar to the POD requesting the volume.

This is currently impossible as a PODs mount isn't in the hosts proper namespace. So a filesystem mounted within a POD isn't visible to other pods on the host.

@thockin

This comment has been minimized.

Copy link
Member

thockin commented May 12, 2015

Not sure what to do with this. You're correct that mounting from withing a container to be visible outside that container is tricky. Are you filing a bug so that we are aware (we are aware)? Or is this something you intend to pursue and are looking for guidance?

@pmorie did a lot of this same work

@eparis

This comment has been minimized.

Copy link
Member

eparis commented May 12, 2015

So I think this can be fixed in a couple of steps...

In docker 1.6 they defaulted to making volume mounts slave of the init mount namespace. We need a new flag where we can make volume mounts shared with the init mount namespace. aka, mounts that happen inside the container show up outside the container in the host namespace.

The second step would be to write a new kubernetes mounter (possibly one per mount type?) which instead of calling mount(8) on the host calls a container and that container does the mount. The container might be able to do the mount inside the container, but if the volume is shared with the init mount namespace the mount will show up in the host. Thus the next container would be able to use it!

This also would mean that all of the work that pmorie did hacking together an 'escape the kubelet' mounter could disappear. The kubelet wouldn't need to do mount at all. It would instead need to make sure that the container did that mount.

Step one is going to be changes to docker....

@childsb

This comment has been minimized.

Copy link
Member

childsb commented Oct 12, 2015

Crosslinking with Docker patch required: moby/moby#16773

@childsb childsb self-assigned this Jul 13, 2016

@fejta-bot

This comment has been minimized.

Copy link

fejta-bot commented Dec 16, 2017

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment