kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #193 from lvlv/master 

add discussion about pod isolation in propagation design
This commit is contained in:
Vish Kannan 2017-03-24 12:00:18 -07:00 committed by GitHub
parent 7e7fbb7803 9a631fff44
commit 24d72f74c2
1 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
contributors/design-proposals/propagation.md
View File

@ -150,6 +150,38 @@ non-privileged', an environment check and an WARNING log will be emitted about
whether propagation mode is supported. whether propagation mode is supported.
## Extra Concerns
@lucab and @euank has some extra concerns about pod isolation when propagation
modes are changed, listed below:
1. how to clean such pod resources (as mounts are now crossing pod boundaries,
thus they can be kept busy indefinitely by processes outside of the pod)
1. side-effects on restarts (possibly piling up layers of full-propagation mounts)
1. how does this interacts with other mount features (nested volumeMounts may or
may not propagate back to the host, depending of ordering of mount operations)
1. limitations this imposes on runtimes (RO-remounting may now affects the host,
is it on purpose or a dangerous side-effect?)
1. A shared mount target imposes some costraints on its parent subtree (generally,
it has to be shared as well), which in turn prevents some mount operations when
preparing a pod (eg. MS_MOVE).
1. The "on-by-default" nature means existing hostpath mounts, which used to be
harmless, could begin consuming kernel resources and cause a node to crash. Even
if a pod does not create any new mountpoints under its hostpath bindmount, it's
not hard to reach multiplicative explosions with shared bindmounts and so the
change in default + no cleanup could result in existing workloads knocking the
node over.
These concerns are valid and we decide to limit the propagation mode to HostPath
volume only, in HostPath, we expect any runtime should NOT perform any additional
actions (such as clean up). This behavior is also consistent with current HostPath
logic: kube does not take care of the content in HostPath either.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/propagation.md?pixel)]() [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/propagation.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS --> <!-- END MUNGE: GENERATED_ANALYTICS -->