Comparison
Node affinityvsPod anti-affinity
Node affinity
you say the workload must land on nodes labelled with the fast disk, and the scheduler filters out everything else.
A workload's own rule about which nodes it wants, expressed against node labels and either required or merely preferred. It attracts, where a taint repels, and the two solve different halves of the same problem. Required rules are the ones that leave workloads permanently pending when the matching nodes are full, which is why preferred is the safer default for anything that would rather run somewhere imperfect than not at all.
Full entry →Pod anti-affinity
all three replicas were on one node and one reboot took the service down, which is exactly what this rule prevents.
A rule that keeps copies of the same workload apart — on different nodes, racks or zones — expressed relative to other workloads rather than to node labels. Without it a scheduler optimising for packing will cheerfully place every replica of a service on the same machine, and the redundancy you are paying for is imaginary. Required anti-affinity across zones also caps your replica count at the number of zones, which is a surprise the first time autoscaling hits it.
Full entry →