In the context of Certified Kubernetes Administrator (CKA) Workloads & Scheduling, Taints and Tolerations function as a filtering mechanism to restrict which pods can be scheduled on specific nodes. Unlike Node Affinity, which attracts pods to nodes, Taints allow a node to repel pods.
A **Taint** …In the context of Certified Kubernetes Administrator (CKA) Workloads & Scheduling, Taints and Tolerations function as a filtering mechanism to restrict which pods can be scheduled on specific nodes. Unlike Node Affinity, which attracts pods to nodes, Taints allow a node to repel pods.
A **Taint** is applied to a Node using a key, value, and an effect (e.g., `key=value:NoSchedule`). This marks the node as dedicated or restricted. By default, the Kubernetes scheduler will not place any pod on a tainted node.
A **Toleration** is applied to a Pod's specification. If a pod contains a toleration that matches a node's taint (matching key, value, and effect), the scheduler allows the pod to be placed on that node. It essentially serves as an 'immunity' card against the node's 'repellent'.
There are three taint effects you must know for the CKA:
1. **NoSchedule**: Strict. New pods will not be scheduled on the node unless they tolerate the taint. Existing pods remain running.
2. **PreferNoSchedule**: Soft. The system tries to avoid placing non-tolerant pods on the node, but will do so if no other resources are available.
3. **NoExecute**: Aggressive. New pods are blocked, and any existing pods on the node without the toleration are immediately evicted.
Common use cases include dedicating nodes for specific hardware (like GPUs) to ensure standard workloads do not waste resources, or isolating Control Plane nodes to prevent application interference with critical cluster components.
Mastering Taints and Tolerations for the CKA Exam
What are Taints and Tolerations? Taints and Tolerations are a primary mechanism in Kubernetes used to restrict what pods can be scheduled on specific nodes. While concepts like Node Affinity are used to attract pods to a set of nodes, Taints allow a node to repel a set of pods.
Why is it Important? This feature is critical for cluster stability and resource management. It allows administrators to: 1. Dedicate nodes for specific users or applications (e.g., ensuring only heavy-computation pods run on GPU nodes). 2. Protect the Control Plane (Master) nodes from running user workloads (Kubernetes does this by default). 3. Evict pods from nodes that are experiencing hardware or network issues.
How it Works: The relationship is lock-and-key: 1. Taints (The Lock): You apply a taint to a Node. A taint consists of a key, a value, and an effect. 2. Tolerations (The Key): You apply a toleration to a Pod specification. If the pod's toleration matches the node's taint (key, value, and effect), the scheduler allows the pod to run on that node.
The Three Taint Effects: When applying a taint (e.g., color=blue:Effect), you must choose one of these effects: - NoSchedule: New pods will not be placed on the node unless they tolerate the taint. Existing pods are unaffected. - PreferNoSchedule: A soft restriction. Kubernetes will try to avoid placing the pod on the node, but will do so if no other nodes are available. - NoExecute: Strongest effect. New pods are rejected, and existing pods running on the node without a matching toleration are immediately evicted (killed).
How to Answer Exam Questions: In the CKA exam, you are often asked to taint a specific node or schedule a pod on a tainted node. Follow these steps: 1. Applying a Taint: Use the imperative command syntax: kubectl taint nodes <node-name> key=value:taint-effect. Example: kubectl taint nodes node01 app=blue:NoSchedule 2. Adding a Toleration: You must edit the Pod YAML. Under the spec section, add a tolerations list that matches the taint exactly. 3. Removing a Taint: If asked to remove a restriction, append a minus sign (-) to the command. Example: kubectl taint nodes node01 app=blue:NoSchedule-
Exam Tips: Answering Questions on Taints and tolerations - Check for Default Taints: If a question asks why a pod is pending, check if the intended node is a Control Plane node. It likely has a taint like node-role.kubernetes.io/control-plane:NoSchedule. - Precision Matters: Ensure the key, value, and effect in your Pod toleration match the Node taint exactly. Double-check spelling (e.g., NoSchedule vs NoScheduled). - NoExecute Behavior: Be very careful with NoExecute questions. If the question asks to evict running pods, this is the effect you must use. - Verification: After applying changes, always run kubectl describe node <node-name> | grep Taint to confirm the taint is applied, and kubectl get pods -o wide to verify where the pod was scheduled.