One-line feature description (can be used as a release note):
Kubernetes can run mount utilities in pods instead on the host.
Primary contact (assignee): @jsafrane
@jsafrane please, don't forget about the design proposal link.
The design proposal - https://github.com/kubernetes/community/pull/589
slipped from 1.7
There are two design proposals:
mount propagation
mount containers
this has been discussed and the feature approved during sig-storage calls and 1-off designs.
sig-storage strongly supports this feature. We really need this to get in for 1.8.
Slipped from 1.8
@jsafrane :wave: Please indicate in the 1.9 feature tracking board
whether this feature needs documentation. If yes, please open a PR and add a link to the tracking spreadsheet. Thanks in advance!
UPDATE: Thanks for the update: no docs required. 馃憤
Relevant PR that went into 1.9 is: https://github.com/kubernetes/kubernetes/pull/53440/
Also this feature is alpha in 1.9 NOT beta. Relabeling.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
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
/remove-lifecycle stale
@jsafrane @saad-ali
Any plans for this in 1.11?
If so, can you please ensure the feature is up-to-date with the appropriate:
stage/{alpha,beta,stable}
sig/*
kind/feature
cc @idvoretskyi
@justaugustus @idvoretskyi, I updated the feature description. This feature will never reach beta or stable, we plan to use it only in e2e tests. Perhaps we can close this issue as all the work for the feature has been done.
[Now we need to actually use the feature in e2e tests, but that's another story]
That's interesting - What's the reason for not targeting it for beta/GA?
@jsafrane Okay, I'm going to close this out, but if you need to reopen for any reason, feel free!
/close
What's the reason for not targeting it for beta/GA?
It's dangerous. We want to reduce the options how volume plugins are working. We already have enough problems with containerized kubelet.
Note that a Flex driver can be deployed in containers already, it's orthogonal to this feature. And CSI basically requires to deploy mount utilities in containers.
Might just want to clarify. Containerizing just the mount tools (so that stuff like the native ceph driver can work) is the thing not going forward. The ability to share mounts outside of a container, or have whole drivers (csi) is staying. So the end goal of having all the things in containers is still moving forward, just without this particular implementation?
Containerizing just the mount tools (so that stuff like the native ceph driver can work) is the thing not going forward
Yes.
The end goal is CSI - CSI drivers may (and often must) containerize their tools and Kubernetes does not need to be changed in any way.
Most helpful comment
Yes.
The end goal is CSI - CSI drivers may (and often must) containerize their tools and Kubernetes does not need to be changed in any way.