diff --git a/modules/nodes-scheduler-taints-tolerations-about.adoc b/modules/nodes-scheduler-taints-tolerations-about.adoc index cc54215ce3..0fa3f36756 100644 --- a/modules/nodes-scheduler-taints-tolerations-about.adoc +++ b/modules/nodes-scheduler-taints-tolerations-about.adoc @@ -1,18 +1,50 @@ // Module included in the following assemblies: // // * nodes/scheduling/nodes-scheduler-taints-tolerations.adoc -// * nodes/nodes-scheduler-taints-tolerations.adoc // * post_installation_configuration/node-tasks.adoc [id="nodes-scheduler-taints-tolerations-about_{context}"] = Understanding taints and tolerations -A _taint_ allows a node to refuse pod to be scheduled unless that pod has a matching _toleration_. +A _taint_ allows a node to refuse a pod to be scheduled unless that pod has a matching _toleration_. -You apply taints to a node through the node specification (`NodeSpec`) and apply tolerations to a pod through the `Pod` specification (`PodSpec`). A taint on a node instructs the node to repel all pods that do not tolerate the taint. +You apply taints to a node through the `Node` specification (`NodeSpec`) and apply tolerations to a pod through the `Pod` specification (`PodSpec`). When you apply a taint a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint. -Taints and tolerations consist of a key, value, and effect. An operator allows you to leave one of these parameters empty. +.Example taint in a `Node` specification +[source,yaml] +---- +spec: +.... + template: +.... + spec: + taints: + - effect: NoExecute + key: key1 + value: value1 +.... +---- + +.Example toleration in a `Pod` specification +[source,yaml] +---- +spec: +.... + template: +.... + spec + tolerations: + - key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" + tolerationSeconds: 3600 +.... +---- + + +Taints and tolerations consist of a key, value, and effect. [id="taint-components-table_{context}"] .Taint and toleration components @@ -67,7 +99,7 @@ A toleration matches a taint: ** the `key` parameters are the same; ** the `effect` parameters are the same. -The following taints are built into kubernetes: +The following taints are built into {product-title}: * `node.kubernetes.io/not-ready`: The node is not ready. This corresponds to the node condition `Ready=False`. * `node.kubernetes.io/unreachable`: The node is unreachable from the node controller. This corresponds to the node condition `Ready=Unknown`. @@ -78,20 +110,26 @@ The following taints are built into kubernetes: * `node.kubernetes.io/unschedulable`: The node is unschedulable. * `node.cloudprovider.kubernetes.io/uninitialized`: When the node controller is started with an external cloud provider, this taint is set on a node to mark it as unusable. After a controller from the cloud-controller-manager initializes this node, the kubelet removes this taint. + [id="nodes-scheduler-taints-tolerations-about-seconds_{context}"] == Understanding how to use toleration seconds to delay pod evictions -You can specify how long a pod can remain bound to a node before being evicted by specifying the `tolerationSeconds` parameter in the `Pod` specification. If a taint with the `NoExecute` effect is added to a node, any pods that do not tolerate the taint are evicted immediately. Pods that do tolerate the taint are not evicted. However, if a pod that does tolerate the taint has the `tolerationSeconds` parameter, the pod is not evicted until that time period expires. +You can specify how long a pod can remain bound to a node before being evicted by specifying the `tolerationSeconds` parameter in the `Pod` specification or `MachineSet` object. If a taint with the `NoExecute` effect is added to a node, a pod that does tolerate the taint, which has the `tolerationSeconds` parameter, the pod is not evicted until that time period expires. .Example output [source,yaml] ---- -tolerations: -- key: "key1" - operator: "Equal" - value: "value1" - effect: "NoExecute" - tolerationSeconds: 3600 +spec: +.... + template: +.... + spec + tolerations: + - key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" + tolerationSeconds: 3600 ---- Here, if this pod is running but does not have a matching taint, the pod stays bound to the node for 3,600 seconds and then be evicted. If the taint is removed before that time, the pod is not evicted. @@ -106,11 +144,11 @@ You can put multiple taints on the same node and multiple tolerations on the sam + * If there is at least one unmatched taint with effect `NoSchedule`, {product-title} cannot schedule a pod onto that node. * If there is no unmatched taint with effect `NoSchedule` but there is at least one unmatched taint with effect `PreferNoSchedule`, {product-title} tries to not schedule the pod onto the node. -* If there is at least one unmatched taint with effect `NoExecute`, {product-title} evicts the pod from the node (if it is already running on the node), or the pod is not scheduled onto the node (if it is not yet running on the node). +* If there is at least one unmatched taint with effect `NoExecute`, {product-title} evicts the pod from the node if it is already running on the node, or the pod is not scheduled onto the node if it is not yet running on the node. + ** Pods that do not tolerate the taint are evicted immediately. + -** Pods that tolerate the taint without specifying `tolerationSeconds` in their toleration specification remain bound forever. +** Pods that tolerate the taint without specifying `tolerationSeconds` in their `Pod` specification remain bound forever. + ** Pods that tolerate the taint with a specified `tolerationSeconds` remain bound for the specified amount of time. @@ -137,37 +175,29 @@ $ oc adm taint nodes node1 key2=value2:NoSchedule + [source,yaml] ---- -tolerations: -- key: "key1" - operator: "Equal" - value: "value1" - effect: "NoSchedule" -- key: "key1" - operator: "Equal" - value: "value1" - effect: "NoExecute" +spec: +.... + template: +.... + spec + tolerations: + - key: "key1" + operator: "Equal" + value: "value1" + effect: "NoSchedule" + - key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" ---- In this case, the pod cannot be scheduled onto the node, because there is no toleration matching the third taint. The pod continues running if it is already running on the node when the taint is added, because the third taint is the only one of the three that is not tolerated by the pod. -[id="nodes-scheduler-taints-tolerations-about-prevent_{context}"] -== Preventing pod eviction for node problems - -The Taint-Based Evictions feature, enabled by default, adds a taint with the `NoExecute` effect to nodes that are not ready or are unreachable. This allows you to specify how long a pod should remain bound to a node that becomes unreachable or not ready, rather than using the default of five minutes. For example, you might want to allow a pod on an unreachable node if the workload is safe to remain running while a networking issue resolves. - -If a node enters a not ready state, the node controller adds the `node.kubernetes.io/not-ready:NoExecute` taint to the node. If a node enters an unreachable state, the node controller adds the `node.kubernetes.io/unreachable:NoExecute` taint to the node. - -The `NoExecute` taint affects pods that are already running on the node in the following ways: - -* Pods that do not tolerate the taint are evicted immediately. -* Pods that tolerate the taint without specifying `tolerationSeconds` in their toleration specification remain bound forever. -* Pods that tolerate the taint with a specified `tolerationSeconds` remain bound for the specified amount of time. - [id="nodes-scheduler-taints-tolerations-about-taintNodesByCondition_{context}"] == Understanding pod scheduling and node conditions (Taint Node by Condition) -{product-title} automatically taints nodes that report conditions such as memory pressure and disk pressure. If a node reports a condition, a taint is added until the condition clears. The taints have the `NoSchedule` effect, which means no pod can be scheduled on the node unless the pod has a matching toleration. This feature, *Taint Nodes By Condition*, is enabled by default. +*Taint Nodes By Condition*, which is enabled by default, automatically taints nodes that report conditions such as memory pressure and disk pressure. If a node reports a condition, a taint is added until the condition clears. The taints have the `NoSchedule` effect, which means no pod can be scheduled on the node unless the pod has a matching toleration. The scheduler checks for these taints on nodes before scheduling pods. If the taint is present, the pod is scheduled on a different node. Because the scheduler checks for taints and not the actual node conditions, you configure the scheduler to ignore some of these node conditions by adding appropriate pod tolerations. @@ -184,41 +214,66 @@ You can also add arbitrary tolerations to daemon sets. [id="nodes-scheduler-taints-tolerations-about-taintBasedEvictions_{context}"] == Understanding evicting pods by condition (Taint-Based Evictions) -The Taint-Based Evictions feature, enabled by default, evicts pods from a node that experiences specific conditions, such as `not-ready` and `unreachable`. +The *Taint-Based Evictions* feature, which is enabled by default, evicts pods from a node that experiences specific conditions, such as `not-ready` and `unreachable`. When a node experiences one of these conditions, {product-title} automatically adds taints to the node, and starts evicting and rescheduling the pods on different nodes. -Taint Based Evictions has a `NoExecute` effect, where any pod that does not tolerate the taint will be evicted immediately and any pod that does tolerate the taint will never be evicted. +Taint Based Evictions have a `NoExecute` effect, where any pod that does not tolerate the taint is evicted immediately and any pod that does tolerate the taint will never be evicted, unless the pod uses the `tolerationsSeconds` parameter. + +The `tolerationSeconds` parameter allows you to specify how long a pod stays bound to a node that has a node condition. If the condition still exists after the `tolerationSections` period, the taint remains on the node and the pods with a matching toleration are evicted. If the condition clears before the `tolerationSeconds` period, pods with matching tolerations are not removed. + +If you use the `tolerationSeconds` parameter with no value, pods are never evicted because of the not ready and unreachable node conditions. [NOTE] ==== {product-title} evicts pods in a rate-limited way to prevent massive pod evictions in scenarios such as the master becoming partitioned from the nodes. ==== -This feature, in combination with `tolerationSeconds`, allows you to specify how long a pod stays bound to a node that has a node condition. If the condition still exists after the `tolerationSections` period, the taint remains on the node and the pods are evicted in a rate-limited manner. If the condition clears before the `tolerationSeconds` period, pods are not removed. - {product-title} automatically adds a toleration for `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` with `tolerationSeconds=300`, unless the `Pod` configuration specifies either toleration. [source,yaml] ---- -spec - tolerations: - - key: node.kubernetes.io/not-ready - operator: Exists - effect: NoExecute - tolerationSeconds: 300 - - key: node.kubernetes.io/unreachable - operator: Exists - effect: NoExecute - tolerationSeconds: 300 +spec: +.... + template: +.... + spec + tolerations: + - key: node.kubernetes.io/not-ready + operator: Exists + effect: NoExecute + tolerationSeconds: 300 <1> + - key: node.kubernetes.io/unreachable + operator: Exists + effect: NoExecute + tolerationSeconds: 300 ---- -These tolerations ensure that the default pod behavior is to remain bound for five minutes after one of these node conditions problems is detected. +<1> These tolerations ensure that the default pod behavior is to remain bound for five minutes after one of these node conditions problems is detected. You can configure these tolerations as needed. For example, if you have an application with a lot of local state, you might want to keep the pods bound to node for a longer time in the event of network partition, allowing for the partition to recover and avoiding pod eviction. -Daemon set pods are created with NoExecute tolerations for the following taints with no tolerationSeconds: +Pods spawned by a daemon set are created with `NoExecute` tolerations for the following taints with no `tolerationSeconds`: * `node.kubernetes.io/unreachable` * `node.kubernetes.io/not-ready` -This ensures that daemon set pods are never evicted due to these node conditions, even if the `DefaultTolerationSeconds` admission controller is disabled. +As a result, daemon set pods are never evicted because of these node conditions. + +[id="nodes-scheduler-taints-tolerations-all_{context}"] +== Tolerating all taints + +You can configure a node to tolerate all taints by adding an `operator: "Exists"` toleration with no `key` and `value` parameters. +Pods with this toleration are not removed from a node that has taints. + +.Pod specification for tolerating all taints +[source,yaml] +---- +spec: +.... + template: +.... + spec + tolerations: + - operator: "Exists" +---- + diff --git a/modules/nodes-scheduler-taints-tolerations-adding-machineset.adoc b/modules/nodes-scheduler-taints-tolerations-adding-machineset.adoc new file mode 100644 index 0000000000..2d7dfd6fb2 --- /dev/null +++ b/modules/nodes-scheduler-taints-tolerations-adding-machineset.adoc @@ -0,0 +1,95 @@ +// Module included in the following assemblies: +// +// * nodes/nodes-scheduler-taints-tolerations.adoc +// * post_installation_configuration/node-tasks.adoc + +[id="nodes-scheduler-taints-tolerations-adding-machineset_{context}"] += Adding taints and tolerations using a machine set + +You can add taints to nodes using a machine set. All nodes associated with the `MachineSet` object are updated with the taint. Tolerations respond to taints added by a machine set in the same manner as taints added directly to the nodes. + +.Procedure + +. Add a toleration to a pod by editing the `Pod` specification to include a `tolerations` section: ++ +.Sample pod configuration file with `Equal` operator +[source,yaml] +---- +spec: +.... + template: +.... + spec: + tolerations: + - key: "key1" <1> + value: "value1" + operator: "Equal" + effect: "NoExecute" + tolerationSeconds: 3600 <2> +---- +<1> The toleration parameters, as described in the *Taint and toleration components* table. +<2> The `tolerationSeconds` parameter specifies how long a pod is bound to a node before being evicted. ++ +For example: ++ +.Sample pod configuration file with `Exists` operator +[source,yaml] +---- +spec: +.... + template: +.... + spec: + tolerations: + - key: "key1" + operator: "Exists" + effect: "NoExecute" + tolerationSeconds: 3600 +---- + +. Add the taint to the `MachineSet` object: + +.. Edit the `MachineSet` YAML for the nodes you want to taint or you can create a new `MachineSet` object: ++ +[source,terminal] +---- +$ oc edit machineset +---- + +.. Add the taint to the `spec.template.spec` section: ++ +.Example taint in a node specification +[source,yaml] +---- +spec: +.... + template: +.... + spec: + taints: + - effect: NoExecute + key: key1 + value: value1 +.... +---- ++ +This example places a taint that has the key `key1`, value `value1`, and taint effect `NoExecute` on the nodes. + +.. Scale down the machine set to 0: ++ +[source,terminal] +---- +$ oc scale --replicas=0 machineset -n openshift-machine-api +---- ++ +Wait for the machines to be removed. + +.. Scale up the machine set as needed: ++ +[source,terminal] +---- +$ oc scale --replicas=2 machineset -n openshift-machine-api +---- ++ +Wait for the machines to start. The taint is added to the nodes associated with the `MachineSet` object. + diff --git a/modules/nodes-scheduler-taints-tolerations-adding.adoc b/modules/nodes-scheduler-taints-tolerations-adding.adoc index 42f84fed7d..7f4b7eb0ab 100644 --- a/modules/nodes-scheduler-taints-tolerations-adding.adoc +++ b/modules/nodes-scheduler-taints-tolerations-adding.adoc @@ -6,15 +6,53 @@ [id="nodes-scheduler-taints-tolerations-adding_{context}"] = Adding taints and tolerations -You add taints to nodes and tolerations to pods allow the node to control which pods should (or should not) be scheduled on them. +You add tolerations to pods and taints to nodes to allow the node to control which pods should or should not be scheduled on them. For existing pods and nodes, you should add the toleration to the pod first, then add the taint to the node to avoid pods being removed from the node before you can add the toleration. .Procedure -. Use the following command using the parameters described in the taint and toleration components table: +. Add a toleration to a pod by editing the `Pod` specification to include a `tolerations` stanza: ++ +.Sample pod configuration file with an Equal operator +[source,yaml] +---- +spec: +.... + template: +.... + spec: + tolerations: + - key: "key1" <1> + value: "value1" + operator: "Equal" + effect: "NoExecute" + tolerationSeconds: 3600 <2> +---- +<1> The toleration parameters, as described in the *Taint and toleration components* table. +<2> The `tolerationSeconds` parameter specifies how long a pod can remain bound to a node before being evicted. ++ +For example: ++ +.Sample pod configuration file with an Exists operator +[source,yaml] +---- +spec: +.... + template: +.... + spec: + tolerations: + - key: "key1" + operator: "Exists" <1> + effect: "NoExecute" + tolerationSeconds: 3600 +---- +<1> The `Exists` operator does not take a `value`. + +. Add a taint to a node by using the following command with the parameters described in the *Taint and toleration components* table: + [source,terminal] ---- -$ oc adm taint nodes =: +$ oc adm taint nodes =: ---- + For example: @@ -24,33 +62,7 @@ For example: $ oc adm taint nodes node1 key1=value1:NoExecute ---- + -This example places a taint on `node1` that has key `key1`, value `value1`, and taint effect `NoExecute`. +This command places a taint on `node1` that has key `key1`, value `value1`, and effect `NoExecute`. + +The tolerations on the Pod match the taint on the node. A pod with either toleration can be scheduled onto `node1`. -. Add a toleration to a pod by editing the pod specification to include a `tolerations` section: -+ -.Sample pod configuration file with `Equal` operator -[source,yaml] ----- -tolerations: -- key: "key1" <1> - operator: "Equal" <1> - value: "value1" <1> - effect: "NoExecute" <1> - tolerationSeconds: 3600 <2> ----- -<1> The toleration parameters, as described in the taint and toleration components table. -<2> The `tolerationSeconds` parameter specifies how long a pod can remain bound to a node before being evicted. -+ -For example: -+ -.Sample pod configuration file with `Exists` operator -[source,yaml] ----- -tolerations: -- key: "key1" - operator: "Exists" - effect: "NoExecute" - tolerationSeconds: 3600 ----- -+ -Both of these tolerations match the taint created by the `oc adm taint` command above. A pod with either toleration would be able to schedule onto `node1`. diff --git a/modules/nodes-scheduler-taints-tolerations-binding.adoc b/modules/nodes-scheduler-taints-tolerations-binding.adoc index 11f71fe49a..200f4be1c8 100644 --- a/modules/nodes-scheduler-taints-tolerations-binding.adoc +++ b/modules/nodes-scheduler-taints-tolerations-binding.adoc @@ -6,13 +6,15 @@ [id="nodes-scheduler-taints-tolerations-bindings_{context}"] = Binding a user to a Node using taints and tolerations -You can configure a node so that particular users can use only the dedicated nodes. +If you want to dedicate a set of nodes for exclusive use by a particular set of users, add a toleration to their pods. Then, add a corresponding taint to those nodes. The pods with the tolerations are allowed to use the tainted nodes, or any other nodes in the cluster. + +If you want ensure the pods are scheduled to only those tainted nodes, also add a label to the same set of nodes and add a node affinity to the pods so that the pods can only be scheduled onto nodes with that label. .Procedure To configure a node so that users can use only that node: -. Add a taint to those nodes: +. Add a corresponding taint to those nodes: + For example: + @@ -21,8 +23,6 @@ For example: $ oc adm taint nodes node1 dedicated=groupName:NoSchedule ---- -. Add a corresponding toleration to the pods by writing a custom admission controller. -+ -The admission controller should add a node affinity to require that the pods can only schedule onto nodes labeled with the `key:value` label (`dedicated=groupName`). +. Add a toleration to the pods by writing a custom admission controller. + -. Add a label similar to the taint (such as the `key:value` label) to the dedicated nodes. diff --git a/modules/nodes-scheduler-taints-tolerations-dedicating.adoc b/modules/nodes-scheduler-taints-tolerations-dedicating.adoc deleted file mode 100644 index ec12f2a7ba..0000000000 --- a/modules/nodes-scheduler-taints-tolerations-dedicating.adoc +++ /dev/null @@ -1,26 +0,0 @@ -// Module included in the following assemblies: -// -// * nodes/nodes-scheduler-taints-tolerations.adoc -// * post_installation_configuration/node-tasks.adoc - -[id="nodes-scheduler-taints-tolerations_dedicating_{context}"] -= Dedicating a Node for a User using taints and tolerations - -You can specify a set of nodes for exclusive use by a particular set of users. - -.Procedure - -To specify dedicated nodes: - -. Add a taint to those nodes: -+ -For example: -+ -[source,terminal] ----- -$ oc adm taint nodes node1 dedicated=groupName:NoSchedule ----- - -. Add a corresponding toleration to the pods by writing a custom admission controller. -+ -Only the pods with the tolerations are allowed to use the dedicated nodes. diff --git a/modules/nodes-scheduler-taints-tolerations-removing.adoc b/modules/nodes-scheduler-taints-tolerations-removing.adoc index 0f7b5f2dc3..c0a831a9a8 100644 --- a/modules/nodes-scheduler-taints-tolerations-removing.adoc +++ b/modules/nodes-scheduler-taints-tolerations-removing.adoc @@ -6,7 +6,7 @@ [id="nodes-scheduler-taints-tolerations-removing_{context}"] = Removing taints and tolerations -You can remove taints from nodes and tolerations from pods as needed. +You can remove taints from nodes and tolerations from pods as needed. You should add the toleration to the pod first, then add the taint to the node to avoid pods being removed from the node before you can add the toleration. .Procedure @@ -32,13 +32,18 @@ $ oc adm taint nodes ip-10-0-132-248.ec2.internal key1- node/ip-10-0-132-248.ec2.internal untainted ---- -. To remove a toleration from a pod, edit the pod specification to remove the toleration: +. To remove a toleration from a pod, edit the `Pod` specification to remove the toleration: + [source,yaml] ---- -tolerations: -- key: "key2" - operator: "Exists" - effect: "NoExecute" - tolerationSeconds: 3600 +spec: +.... + template: +.... + spec: + tolerations: + - key: "key2" + operator: "Exists" + effect: "NoExecute" + tolerationSeconds: 3600 ---- diff --git a/modules/nodes-scheduler-taints-tolerations-special.adoc b/modules/nodes-scheduler-taints-tolerations-special.adoc index 58dfe1dafe..165cafb1c6 100644 --- a/modules/nodes-scheduler-taints-tolerations-special.adoc +++ b/modules/nodes-scheduler-taints-tolerations-special.adoc @@ -1,16 +1,37 @@ // Module included in the following assemblies: // -// * nodes/nodes-scheduler-taints-tolerations.adoc +// * nodes/scheduling/nodes-scheduler-taints-tolerations.adoc // * post_installation_configuration/node-tasks.adoc [id="nodes-scheduler-taints-tolerations-special_{context}"] = Controlling Nodes with special hardware using taints and tolerations -In a cluster where a small subset of nodes have specialized hardware (for example GPUs), you can use taints and tolerations to keep pods that do not need the specialized hardware off of those nodes, leaving the nodes for pods that do need the specialized hardware. You can also require pods that need specialized hardware to use specific nodes. +In a cluster where a small subset of nodes have specialized hardware, you can use taints and tolerations to keep pods that do not need the specialized hardware off of those nodes, leaving the nodes for pods that do need the specialized hardware. You can also require pods that need specialized hardware to use specific nodes. + +You can achieve this by adding a toleration to pods that need the special hardware and tainting the nodes that have the specialized hardware. .Procedure -To ensure pods are blocked from the specialized hardware: +To ensure nodes with specialized hardware are reserved for specific pods: + +. Add a toleration to pods that need the special hardware. ++ +For example: ++ +[source,yaml] +---- +spec: +.... + template: +.... + spec: + tolerations: + - key: "disktype" + value: "ssd" + operator: "Equal" + effect: "NoSchedule" + tolerationSeconds: 3600 +---- . Taint the nodes that have the specialized hardware using one of the following commands: + @@ -26,8 +47,4 @@ Or: $ oc adm taint nodes disktype=ssd:PreferNoSchedule ---- -. Adding a corresponding toleration to pods that use the special hardware using an admission controller. -For example, the admission controller could use some characteristic(s) of the pod to determine that the pod should be allowed to use the special nodes by adding a toleration. - -To ensure pods can only use the specialized hardware, you need some additional mechanism. For example, you could label the nodes that have the special hardware and use node affinity on the pods that need the hardware. diff --git a/nodes/scheduling/nodes-scheduler-taints-tolerations.adoc b/nodes/scheduling/nodes-scheduler-taints-tolerations.adoc index eb0a02b64a..7cba42cd34 100644 --- a/nodes/scheduling/nodes-scheduler-taints-tolerations.adoc +++ b/nodes/scheduling/nodes-scheduler-taints-tolerations.adoc @@ -7,7 +7,7 @@ toc::[] -Taints and tolerations allow the Node to control which Pods should (or should not) be scheduled on them. +Taints and tolerations allow the node to control which pods should (or should not) be scheduled on them. // The following include statements pull in the module files that comprise // the assembly. Include any combination of concept, procedure, or reference @@ -18,7 +18,7 @@ include::modules/nodes-scheduler-taints-tolerations-about.adoc[leveloffset=+1] include::modules/nodes-scheduler-taints-tolerations-adding.adoc[leveloffset=+1] -include::modules/nodes-scheduler-taints-tolerations-dedicating.adoc[leveloffset=+2] +include::modules/nodes-scheduler-taints-tolerations-adding-machineset.adoc[leveloffset=+2] include::modules/nodes-scheduler-taints-tolerations-binding.adoc[leveloffset=+2] diff --git a/post_installation_configuration/node-tasks.adoc b/post_installation_configuration/node-tasks.adoc index 9997405d24..93692249fc 100644 --- a/post_installation_configuration/node-tasks.adoc +++ b/post_installation_configuration/node-tasks.adoc @@ -55,7 +55,7 @@ Understand and work with taints and tolerations. include::modules/nodes-scheduler-taints-tolerations-about.adoc[leveloffset=+2] include::modules/nodes-scheduler-taints-tolerations-adding.adoc[leveloffset=+2] -include::modules/nodes-scheduler-taints-tolerations-dedicating.adoc[leveloffset=+2] +include::modules/nodes-scheduler-taints-tolerations-adding-machineset.adoc[leveloffset=+2] include::modules/nodes-scheduler-taints-tolerations-binding.adoc[leveloffset=+2] include::modules/nodes-scheduler-taints-tolerations-special.adoc[leveloffset=+2] include::modules/nodes-scheduler-taints-tolerations-removing.adoc[leveloffset=+2]