Affinity, taints and tolerations serve different purposes in Kubernetes pod scheduling:

Taints and Tolerations

• Taints are applied to nodes and act like repellents
• Tolerations are applied to pods and allow them to schedule on tainted nodes
• Think of it as: "Nodes repel pods unless the pods have matching tolerations"
• Use case: Reserve nodes for specific workloads (e.g., GPU nodes only for ML workloads)

Node Affinity

• Attracts pods to specific nodes based on node labels
• More expressive than nodeSelector (supports "preferred" vs "required" rules)
• Think of it as: "Pods are attracted to nodes with specific attributes"
• Use case: Schedule pods on nodes with SSDs or in specific availability zones

Pod Affinity/Anti-Affinity

• Controls pod placement relative to other pods
• Affinity: "Place me near pods with label X"
• Anti-affinity: "Don't place me near pods with label X"
• Use case: Co-locate related services for performance or spread replicas across nodes for high availability

Key differences:

• Taints/tolerations are node-centric and reject pods by default
• Affinity is pod-centric and attracts pods to specific nodes
• Tolerations don't guarantee placement on tainted nodes; they just permit it
• Node affinity can force or prefer placement on specific nodes
• Pod affinity deals with pod-to-pod relationships rather than pod-to-node

A common pattern combines both: use taints/tolerations to reserve nodes for certain workloads, and use affinity to attract the right pods to those nodes.