Study guide
3.8 Node Taints & Pod Tolerations
Certified Kubernetes Administrator CKA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CKA Exam Environment & Cluster Architecture
1.1 CKA Exam Mechanics, Scoring & Remote Terminal Environment 1.2 Kubernetes Control Plane & Worker Node Components 1.3 etcd Architecture, Clustering & Raft Consensus 1.4 Initializing Clusters with Kubeadm 1.5 Highly Available (HA) Control Plane Topologies 1.6 Cluster Lifecycle & Step-by-Step Upgrades 1.7 etcd Snapshot Backup and Restore Procedures
2 Chapter 2: Cluster Extensions, Packaging & RBAC
2.1 Kubernetes TLS Certificates & PKI Infrastructure 2.2 Managing Kubeconfig Files, Users, & Contexts 2.3 Installing Cluster Components with Helm & Kustomize 2.4 Role-Based Access Control (RBAC): Roles & RoleBindings 2.5 ClusterRoles & ClusterRoleBindings 2.6 Custom Resource Definitions (CRDs) & Operators 2.7 Pod Security Standards (PSS) & Admission Controllers
3 Chapter 3: Workloads, Lifecycle & Pod Scheduling
3.1 Pod Lifecycle, Multi-Container Patterns & Init Containers 3.2 Deployments: Rolling Updates, Rollouts & Rollbacks 3.3 DaemonSets & StatefulSets Architecture 3.4 Batch Workloads: Jobs & CronJobs 3.5 Managing ConfigMaps & Sensitive Data with Secrets 3.6 Resource Requests, Limits & Namespace ResourceQuotas 3.7 NodeSelectors, Node Affinity & Anti-Affinity 3.8 Node Taints & Pod Tolerations 3.9 Autoscaling: Horizontal Pod Autoscaler (HPA) & Custom Metrics
4 Chapter 4: Services, Networking & Ingress Architecture
4.1 Kubernetes IP-per-Pod Model & CNI Plugins (Flannel, Calico, Cilium) 4.2 Services Deep Dive: ClusterIP, NodePort, LoadBalancer & EndpointSlices 4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF 4.4 CoreDNS Configuration, Resolution & Custom Forwarding 4.5 NetworkPolicies: Ingress, Egress & Default-Deny Isolation 4.6 Ingress Architecture, Controllers & Path-Based Routing 4.7 Gateway API: GatewayClass, Gateway, HTTPRoute & Traffic Splitting 4.8 External Traffic Ingress: NodePort, Cloud LoadBalancers & MetalLB
5 Chapter 5: Storage Architecture & Persistent Volumes
5.1 Ephemeral Volumes, EmptyDir, HostPath & Config Volumes 5.2 PersistentVolumes (PV) & PersistentVolumeClaims (PVC) Lifecycle 5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes 5.4 Storage Access Modes, Reclaim Policies & Volume Expansion 5.5 Container Storage Interface (CSI) Architecture & Drivers 5.6 StatefulSet VolumeClaimTemplates & Persistent Storage Workflows
6 Chapter 6: Advanced Troubleshooting, Monitoring & Maintenance
6.1 Systematic Kubernetes Troubleshooting Methodology 6.2 Node Failure, Kubelet Diagnostics & Systemd Services 6.3 Control Plane Failures, Static Pods & Component Logs 6.4 etcd Troubleshooting, Quorum Loss & Database Defragmentation 6.5 Pod Startup Failures, CrashLoopBackOff & OOMKilled Diagnostics 6.6 Workload Scheduling Failures & Resource Constraint Resolution 6.7 Container & Node Logging Architecture, Journalctl & Fluentd 6.8 Metrics Server, Resource Utilization & Kubectl Top 6.9 Service, Endpoint & Ingress Connectivity Troubleshooting 6.10 Storage Failures: PVC Pending, Mount Failures & Multi-Attach Errors 6.11 NetworkPolicy Isolation & CoreDNS Resolution Diagnostics
3.8 Node Taints & Pod Tolerations
Key Takeaways Explain This Topic AI
Taints are applied to nodes to repel unauthorized Pods; Tolerations are applied to Pods to allow (but not force) scheduling on tainted nodes.
A Taint consists of key, value, and effect (Key=Value:Effect); supported effects are NoSchedule, PreferNoSchedule, and NoExecute.
NoExecute taints immediately evict running non-tolerating Pods, or delay eviction according to tolerationSeconds.
Toleration matching requires either operator: Equal (matching key, value, and effect) or operator: Exists (matching key and effect regardless of value).
Dedicated node pools (e.g., GPU hardware or PCI-DSS isolated compute) require combining Taints/Tolerations with Node Affinity for bidirectional isolation.
Last updated: August 2026
Node Taints & Pod Tolerations
While Node Affinity attracts Pods to specific nodes, Taints and Tolerations work in reverse: Taints allow a node to repel a set of Pods , ensuring that arbitrary workloads do not land on specialized, reserved, or unhealthy hardware. Tolerations are applied to Pod manifests, allowing (but not forcing) the Pod to schedule onto nodes with matching taints.
1. Taints and Tolerations Mechanics +-----------------------------------------------------------------------------------------+
- | TAINTS AND TOLERATIONS MECHANICS |
- | |
- | [Node 1: Tainted] (dedicated=gpu:NoSchedule) |
- | ^ |
- | | |
- | +------+---------------------------------------+ |
- | | | |
- | [Pod A: No Toleration] [Pod B: Toleration for dedicated=gpu] |
- | --> REPELLED (Cannot schedule on Node 1) --> ALLOWED (Can schedule on Node 1) |
- | |
- | * Critical Rule: Tolerations ALLOW scheduling; they do not FORCE scheduling. |
- | To guarantee Pod B ONLY lands on Node 1, combine with Node Affinity! |
- +-----------------------------------------------------------------------------------------+
- Applying and Removing Taints via kubectl # Syntax: kubectl taint nodes <node-name> key=value:effect
- kubectl taint nodes worker-gpu-01 dedicated=gpu:NoSchedule
- # Applying a taint without a value (key:effect)
- kubectl taint nodes worker-02 maintenance:NoExecute
- # Inspect taints applied to a node
- kubectl describe node worker-gpu-01 | grep -i taints
- # Output: Taints: dedicated=gpu:NoSchedule
- # Removing a taint (append a minus '-' sign to the effect)
- kubectl taint nodes worker-gpu-01 dedicated=gpu:NoSchedule-
- kubectl taint nodes worker-02 maintenance:NoExecute-
- 2. The Three Taint Effects Deep Dive
A taint's Effect determines the enforcement behavior applied by kube-scheduler and kubelet :
Taint Effect Impact on Pending (New) Pods Impact on Already Running Pods Primary Production Use Case
NoSchedule Pods without a matching toleration will not be scheduled on the node. Existing Pods already running on the node continue running unaffected . Dedicated node pools (e.g. GPU compute, high-memory datastores, control-plane nodes).
PreferNoSchedule Scheduler attempts to avoid placing the Pod on the node, but will place it there if no other compute is available. Existing Pods continue running unaffected . Non-critical preferences (e.g. edge nodes, spot/preemptible instances, bursting pools).
NoExecute Pods without a matching toleration will not be scheduled on the node. Existing Pods without matching toleration are immediately evicted from the node. Active node maintenance, draining, hardware failures, kernel upgrades.
3. Pod Toleration Syntax and Matching Rules
A Pod defines tolerations in spec.tolerations using either the Equal or Exists operator.
Example 1: Exact Match with operator: Equal
Requires exact matching of key , value , and effect : spec:
tolerations:
- key: "dedicated"
- operator: "Equal"
- value: "gpu"
- effect: "NoSchedule"
- Example 2: Key Matching with operator: Exists
Matches any taint with the specified key regardless of its value : spec:
tolerations:
- key: "node-role.kubernetes.io/control-plane"
- operator: "Exists"
- effect: "NoSchedule"
- Example 3: Universal Match (Match All Taints)
Leaving key empty with operator: Exists matches all keys, values, and effects (used by cluster-critical DaemonSets like CNI and logging agents): spec:
tolerations:
- operator: "Exists"
- 4. tolerationSeconds and Delayed Eviction under NoExecute
When a node is tainted with NoExecute , running Pods that tolerate the taint can specify tolerationSeconds to define a grace period before eviction: spec:
tolerations:
- key: "node.kubernetes.io/unreachable"
- operator: "Exists"
- effect: "NoExecute"
- tolerationSeconds: 300
- key: "node.kubernetes.io/not-ready"
- operator: "Exists"
- effect: "NoExecute"
- tolerationSeconds: 300
If the node enters NotReady or Unreachable state, kubelet delays eviction for 300 seconds (5 minutes), allowing transient network partitions to recover without triggering unnecessary Pod rescheduling.
5. Built-in System Taints Injected by Node Controller
The Kubernetes control plane automatically injects node taints when node conditions degrade:
node.kubernetes.io/not-ready : Node is unhealthy and not ready to receive Pods.
node.kubernetes.io/unreachable : Node controller has lost communication with kubelet.
node.kubernetes.io/memory-pressure : Node memory is exhausted.
node.kubernetes.io/disk-pressure : Node disk capacity is exhausted.
node.kubernetes.io/pid-pressure : Node process ID space is exhausted.
node.kubernetes.io/network-unavailable : Node network CNI is uninitialized.
node.kubernetes.io/unschedulable : Node is cordoned ( kubectl cordon <node> ).
6. Constructing Dedicated Node Pools: The Bidirectional Isolation Pattern
A frequent CKA exam requirement is dedicating nodes exclusively to a specific workload (e.g. GPU compute for machine learning) such that:
Standard workloads CANNOT run on the GPU nodes.
GPU workloads CANNOT run on standard CPU nodes.
The Complete 3-Step Implementation
Taint the specialized nodes to repel all standard workloads: kubectl taint nodes gpu-node-01 sku=gpu:NoSchedule
Label the specialized nodes for targeting: kubectl label nodes gpu-node-01 sku=gpu
Configure the ML Pods with both a Toleration (to pass the taint) AND Node Affinity / nodeSelector (to force placement on the labeled nodes): apiVersion: v1
kind: Pod
metadata:
name: gpu-training-pipeline
spec:
# 1. Force Pod onto GPU nodes
nodeSelector:
- sku: gpu
- # 2. Allow Pod to tolerate the GPU taint
tolerations:
- key: "sku"
- operator: "Equal"
- value: "gpu"
- effect: "NoSchedule"
containers:
- name: model-trainer
- image: tensorflow/tensorflow:latest-gpu