Comparison
Pod anti-affinityvsTopology spread
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 →Topology spread
instead of forbidding two replicas per zone you say the counts must stay within one of each other, and the scheduler balances them.
A softer, quantitative alternative to anti-affinity: specify the maximum imbalance allowed across a topology domain rather than an outright prohibition. It expresses what teams usually actually want — spread evenly across zones, but do not refuse to schedule if one zone is full. It is the standard fix for a service that became unschedulable because its strict anti-affinity rule could not be satisfied during a zone outage.
Full entry →