A taint marks a node so Pods without a matching toleration are not scheduled there by default. This is useful for reserving Arm, GPU, or Spot nodes for workloads that explicitly support them. section 8.1.3
A taint combines a key, value, and effect. For example, spot=true:NoSchedule rejects Pods that do not tolerate that taint. Prefer NoSchedule is softer; NoSchedule is recommended when avoiding a node class is the primary goal. section 8.1.3
Use taints with related scheduling settings to control placement:
- Add a matching toleration to a Pod so it may run on the tainted node. section 8.1.3
- Combine a toleration with a node label and nodeSelector to reserve a dedicated node group for one workload. section 8.1.4
Allowing a workload onto Spot nodes
A Deployment can tolerate the spot=true taint with effect NoSchedule. Its Pods may then be scheduled on Spot nodes, while ordinary workloads remain on untainted nodes.
$ minikube start --nodes 3 Done! kubectl is now configured to use "minikube" cluster $ kubectl get nodes NAME STATUS ROLES AGE VERSION minikube Ready control-plane 77s v1.24.3 minikube-m02 Ready <none> 55s v1.24.3 minikube-m03 NotReady <none> 19s v1.24.3 $ NODE_NAME=minikube-m02 $ kubectl taint nodes $NODE_NAME spot=true:NoSchedule node/minikube-m02 tainted
Experiment with a three-node Minikube cluster by applying spot=true:NoSchedule to one node. section 8.1.3
A taint can also explain a Pending Pod. Inspect the Pod with kubectl describe and check FailedScheduling events; either add the required toleration or provide an untainted node. section 8.3.2
