If you are using a released version of Kubernetes, you should refer to the docs that go with that version.
The latest release of this document can be found [here](http://releases.k8s.io/release-1.2/docs/design/taint-toleration-dedicated.md).Documentation for other releases can be found at releases.k8s.io.
This document describes taints and tolerations, which constitute a generic mechanism for restricting the set of pods that can use a node. We also describe one concrete use case for the mechanism, namely to limit the set of users (or more generally, authorization domains) who can access a set of nodes (a feature we call dedicated nodes). There are many other uses--for example, a set of 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 being drained before shutdown, or a node could trigger evictions when it experiences hardware or software problems or abnormal node configurations; see #17190 and #3885 for more discussion.
A taint is a new type that is part of the NodeSpec; when present, it prevents pods
from scheduling onto the node unless the pod tolerates the taint (tolerations are listed
in the PodSpec). Note that there are actually multiple flavors of taints: taints that
prevent scheduling on a node, taints that cause the scheduler to try to avoid scheduling
on a node but do not prevent it, taints that prevent a pod from starting on Kubelet even
if the pod's NodeName was written directly (i.e. pod did not go through the scheduler),
and taints that evict already-running pods.
This comment
has more background on these different scenarios. We will focus on the first
kind of taint in this doc, since it is the kind required for the "dedicated nodes" use case.
Implementing dedicated nodes using taints and tolerations is straightforward: in essence, a node that
is dedicated to group A gets taint dedicated=A and the pods belonging to group A get
toleration dedicated=A. (The exact syntax and semantics of taints and tolerations are
described later in this doc.) This keeps all pods except those belonging to group A off of the nodes.
This approach easily generalizes to pods that are allowed to
schedule into multiple dedicated node groups, and nodes that are a member of multiple
dedicated node groups.
Note that because tolerations are at the granularity of pods, the mechanism is very flexible -- any policy can be used to determine which tolerations should be placed on a pod. So the "group A" mentioned above could be all pods from a particular namespace or set of namespaces, or all pods with some other arbitrary characteristic in common. We expect that any real-world usage of taints and tolerations will employ an admission controller to apply the tolerations. For example, to give all pods from namespace A access to dedicated node group A, an admission controller would add the corresponding toleration to all pods from namespace A. Or to give all pods that require GPUs access to GPU nodes, an admission controller would add the toleration for GPU taints to pods that request the GPU resource.
Everything that can be expressed using taints and tolerations can be expressed using
node affinity, e.g. in the example
in the previous paragraph, you could put a label dedicated=A on the set of dedicated nodes and
a node affinity dedicated NotIn A on all pods not belonging to group A. But it is
cumbersome to express exclusion policies using node affinity because every time you add
a new type of restricted node, all pods that aren't allowed to use those nodes need to start avoiding those
nodes using node affinity. This means the node affinity list can get quite long in clusters with lots of different
groups of special nodes (lots of dedicated node groups, lots of different kinds of special hardware, etc.).
Moreover, you need to also update any Pending pods when you add new types of special nodes.
In contrast, with taints and tolerations,
when you add a new type of special node, "regular" pods are unaffected, and you just need to add
the necessary toleration to the pods you subsequent create that need to use the new type of special nodes.
To put it another way, with taints and tolerations, only pods that use a set of special nodes
need to know about those special nodes; with the node affinity approach, pods that have
no interest in those special nodes need to know about all of the groups of special nodes.
One final comment: in practice, it is often desirable to not
only keep "regular" pods off of special nodes, but also to keep "special" pods off of
regular nodes. An example in the dedicated nodes case is to not only keep regular
users off of dedicated nodes, but also to keep dedicated users off of non-dedicated (shared)
nodes. In this case, the "non-dedicated" nodes can be modeled as their own dedicated node group
(for example, tainted as dedicated=shared), and pods that are not given access to any
dedicated nodes ("regular" pods) would be given a toleration for dedicated=shared. (As mentioned earlier,
we expect tolerations will be added by an admission controller.) In this case taints/tolerations
are still better than node affinity because with taints/tolerations each pod only needs one special "marking",
versus in the node affinity case where every time you add a dedicated node group (i.e. a new
dedicated= value), you need to add a new node affinity rule to all pods (including pending pods)
except the ones allowed to use that new dedicated node group.
// The node this Taint is attached to has the effect "effect" on
// any pod that that does not tolerate the Taint.
type Taint struct {
Key string `json:"key" patchStrategy:"merge" patchMergeKey:"key"`
Value string `json:"value,omitempty"`
Effect TaintEffect `json:"effect"`
}
type TaintEffect string
const (
// Do not allow new pods to schedule unless they tolerate the taint,
// but allow all pods submitted to Kubelet without going through the scheduler
// to start, and allow all already-running pods to continue running.
// Enforced by the scheduler.
TaintEffectNoSchedule TaintEffect = "NoSchedule"
// Like TaintEffectNoSchedule, but the scheduler tries not to schedule
// new pods onto the node, rather than prohibiting new pods from scheduling
// onto the node. Enforced by the scheduler.
TaintEffectPreferNoSchedule TaintEffect = "PreferNoSchedule"
// Do not allow new pods to schedule unless they tolerate the taint,
// do not allow pods to start on Kubelet unless they tolerate the taint,
// but allow all already-running pods to continue running.
// Enforced by the scheduler and Kubelet.
TaintEffectNoScheduleNoAdmit TaintEffect = "NoScheduleNoAdmit"
// Do not allow new pods to schedule unless they tolerate the taint,
// do not allow pods to start on Kubelet unless they tolerate the taint,
// and try to eventually evict any already-running pods that do not tolerate the taint.
// Enforced by the scheduler and Kubelet.
TaintEffectNoScheduleNoAdmitNoExecute = "NoScheduleNoAdmitNoExecute"
)
// The pod this Toleration is attached to tolerates any taint that matches
// the triple <key,value,effect> using the matching operator <operator>.
type Toleration struct {
Key string `json:"key" patchStrategy:"merge" patchMergeKey:"key"`
// operator represents a key's relationship to the value.
// Valid operators are Exists and Equal. Defaults to Equal.
// Exists is equivalent to wildcard for value, so that a pod can
// tolerate all taints of a particular category.
Operator TolerationOperator `json:"operator"`
Value string `json:"value,omitempty"`
Effect TaintEffect `json:"effect"`
// TODO: For forgiveness (#1574), we'd eventually add at least a grace period
// here, and possibly an occurrence threshold and period.
}
// A toleration operator is the set of operators that can be used in a toleration.
type TolerationOperator string
const (
TolerationOpExists TolerationOperator = "Exists"
TolerationOpEqual TolerationOperator = "Equal"
)(See this comment to understand the motivation for the various taint effects.)
We will add
// Multiple tolerations with the same key are allowed.
Tolerations []Toleration `json:"tolerations,omitempty"`to PodSpec. A pod must tolerate all of a node's taints (except taints
of type TaintEffectPreferNoSchedule) in order to be able
to schedule onto that node.
We will add
// Multiple taints with the same key are not allowed.
Taints []Taint `json:"taints,omitempty"`to both NodeSpec and NodeStatus. The value in NodeStatus is the union
of the taints specified by various sources. For now, the only source is
the NodeSpec itself, but in the future one could imagine a node inheriting
taints from pods (if we were to allow taints to be attached to pods), from
the node's startup coniguration, etc. The scheduler should look at the Taints
in NodeStatus, not in NodeSpec.
Taints and tolerations are not scoped to namespace.
Using taints and tolerations to implement dedicated nodes requires these steps:
- Add the API described above
- Add a scheduler predicate function that respects taints and tolerations (for TaintEffectNoSchedule) and a scheduler priority function that respects taints and tolerations (for TaintEffectPreferNoSchedule).
- Add to the Kubelet code to implement the "no admit" behavior of TaintEffectNoScheduleNoAdmit and TaintEffectNoScheduleNoAdmitNoExecute
- Implement code in Kubelet that evicts a pod that no longer satisfies TaintEffectNoScheduleNoAdmitNoExecute. In theory we could do this in the controllers instead, but since taints might be used to enforce security policies, it is better to do in kubelet because kubelet can respond quickly and can guarantee the rules will be applied to all pods. Eviction may need to happen under a variety of circumstances: when a taint is added, when an existing taint is updated, when a toleration is removed from a pod, or when a toleration is modified on a pod.
- Add a new
kubectlcommand that adds/removes taints to/from nodes, - (This is the one step is that is specific to dedicated nodes) Implement an admission controller that adds tolerations to pods that are supposed to be allowed to use dedicated nodes (for example, based on pod's namespace).
In the future one can imagine a generic policy configuration that configures an admission controller to apply the appropriate tolerations to the desired class of pods and taints to Nodes upon node creation. It could be used not just for policies about dedicated nodes, but also other uses of taints and tolerations, e.g. nodes that are restricted due to their hardware configuration.
The kubectl command to add and remove taints on nodes will be modeled after kubectl label.
Examples usages:
# Update node 'foo' with a taint with key 'dedicated' and value 'special-user' and effect 'NoScheduleNoAdmitNoExecute'.
# If a taint with that key already exists, its value and effect are replaced as specified.
$ kubectl taint nodes foo dedicated=special-user:NoScheduleNoAdmitNoExecute
# Remove from node 'foo' the taint with key 'dedicated' if one exists.
$ kubectl taint nodes foo dedicated-Let's say that the cluster administrator wants to make nodes foo, bar, and baz available
only to pods in a particular namespace banana. First the administrator does
$ kubectl taint nodes foo dedicated=banana:NoScheduleNoAdmitNoExecute
$ kubectl taint nodes bar dedicated=banana:NoScheduleNoAdmitNoExecute
$ kubectl taint nodes baz dedicated=banana:NoScheduleNoAdmitNoExecute
(assuming they want to evict pods that are already running on those nodes if those pods don't already tolerate the new taint)
Then they ensure that the PodSpec for all pods created in namespace banana specify
a toleration with key=dedicated, value=banana, and policy=NoScheduleNoAdmitNoExecute.
In the future, it would be nice to be able to specify the nodes via a NodeSelector rather than having
to enumerate them by name.
At present, the Kubernetes security model allows any user to add and remove any taints and tolerations.
Obviously this makes it impossible to securely enforce
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 any fields of NodeSpec)
and from mutating the Tolerations field of their pods. #17549 is relevant.
Another security vulnterability arises if nodes are added to the cluster before receiving their taint. Thus we need to ensure that a new node does not become "Ready" until it has been configured with its taints. One way to do this is to have an admission controller that adds the taint whenever a Node object is created.
A quota policy may want to treat nodes differently based on what taints, if any, they have. For example, if a particular namespace is only allowed to access dedicated nodes, then it may be convenient to give the namespace unlimited quota. (To use finite quota, you'd have to size the namespace's quota to the sum of the sizes of the machines in the dedicated node group, and update it when nodes are added/removed to/from the group.)
It's conceivable that taints and tolerations could be unified with pod anti-affinity. We have chosen not to do this for the reasons described in the "Future work" section of that doc.
Old scheduler versions will ignore taints and tolerations. New scheduler versions will respect them.
Users should not start using taints and tolerations until the full 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 master to a version that does not support them. Longer-term we will use a progamatic approach to enforcing this (#4855).
This proposal is based on the discussion in #17190. There are a number of other related issues, all of which are linked to from #17190.
The relationship between taints and node drains is discussed in #1574.
The concepts of taints and tolerations were originally developed as part of the Omega project at Google.