diff options
| author | Vish Kannan <vishh@users.noreply.github.com> | 2017-03-24 12:00:18 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-03-24 12:00:18 -0700 |
| commit | 24d72f74c2e36f7b72ee3e543baa7e53c72d980a (patch) | |
| tree | dccce216cbb2a73e8ef5987d8584544d4c9bf2c4 | |
| parent | 7e7fbb7803b0cea8b0021d3e0430a73d623ec705 (diff) | |
| parent | 9a631fff444a968dd2dbf30fc8c976aa35d994b8 (diff) | |
Merge pull request #193 from lvlv/master
add discussion about pod isolation in propagation design
| -rw-r--r-- | contributors/design-proposals/propagation.md | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/contributors/design-proposals/propagation.md b/contributors/design-proposals/propagation.md index 7a92d7cc..03d4124c 100644 --- a/contributors/design-proposals/propagation.md +++ b/contributors/design-proposals/propagation.md @@ -150,6 +150,38 @@ non-privileged', an environment check and an WARNING log will be emitted about 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 --> []() <!-- END MUNGE: GENERATED_ANALYTICS --> |