github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-27 13:37:30 +00:00
Code Issues Projects Releases Wiki Activity

Add issue links to taint-toleration-dedicated.md

Browse Source
This commit is contained in:
xiangpengzhao 2016-07-01 21:45:30 -04:00
parent 7074169a63
commit 6604bd20e8
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/design/taint-toleration-dedicated.md
View File

@ -45,7 +45,8 @@ nodes with a particular piece of hardware could be reserved for pods that
require that hardware, or a node could be marked as unschedulable when it is require that hardware, or a node could be marked as unschedulable when it is
being drained before shutdown, or a node could trigger evictions when it being drained before shutdown, or a node could trigger evictions when it
experiences hardware or software problems or abnormal node configurations; see experiences hardware or software problems or abnormal node configurations; see
issues #17190 and #3885 for more discussion. issues [#17190](https://github.com/kubernetes/kubernetes/issues/17190) and
[#3885](https://github.com/kubernetes/kubernetes/issues/3885) for more discussion.
## Taints, tolerations, and dedicated nodes ## Taints, tolerations, and dedicated nodes
@ -274,7 +275,8 @@ taints and tolerations. Obviously this makes it impossible to securely enforce
rules like dedicated nodes. We need some mechanism that prevents regular users rules like dedicated nodes. We need some mechanism that prevents regular users
from mutating the `Taints` field of `NodeSpec` (probably we want to prevent them from mutating the `Taints` field of `NodeSpec` (probably we want to prevent them
from mutating any fields of `NodeSpec`) and from mutating the `Tolerations` from mutating any fields of `NodeSpec`) and from mutating the `Tolerations`
field of their pods. #17549 is relevant. field of their pods. [#17549](https://github.com/kubernetes/kubernetes/issues/17549)
is relevant.
Another security vulnerability arises if nodes are added to the cluster before Another security vulnerability arises if nodes are added to the cluster before
receiving their taint. Thus we need to ensure that a new node does not become receiving their taint. Thus we need to ensure that a new node does not become
@ -303,14 +305,15 @@ Users should not start using taints and tolerations until the full
implementation has been in Kubelet and the master for enough binary versions implementation has been in Kubelet and the master for enough binary versions
that we feel comfortable that we will not need to roll back either Kubelet or that we feel comfortable that we will not need to roll back either Kubelet or
master to a version that does not support them. Longer-term we will use a master to a version that does not support them. Longer-term we will use a
progamatic approach to enforcing this (#4855). progamatic approach to enforcing this ([#4855](https://github.com/kubernetes/kubernetes/issues/4855)).
## Related issues ## Related issues
This proposal is based on the discussion in #17190. There are a number of other This proposal is based on the discussion in [#17190](https://github.com/kubernetes/kubernetes/issues/17190).
related issues, all of which are linked to from #17190. There are a number of other related issues, all of which are linked to from
[#17190](https://github.com/kubernetes/kubernetes/issues/17190).
The relationship between taints and node drains is discussed in #1574. The relationship between taints and node drains is discussed in [#1574](https://github.com/kubernetes/kubernetes/issues/1574).
The concepts of taints and tolerations were originally developed as part of the The concepts of taints and tolerations were originally developed as part of the
Omega project at Google. Omega project at Google.