Afinidade / antiafinidade de pods
Regras que controlam onde os pods ficam em relação uns aos OUTROS. A afinidade aproxima pods no mesmo nó/zona (por exemplo, uma aplicação perto do seu cache, para baixa latência); a antiafinidade os mantém separados (por exemplo, espalhando réplicas por vários nós para que a queda de um nó não leve todas junto).
Como funciona: as regras casam com os rótulos de outros pods e com uma "topology key" (nó, zona, região) que define o que significa "perto" e "longe". Há duas intensidades: required (rígida — o pod nem é agendado se a regra não puder ser cumprida) e preferred (flexível — tenta, mas agenda mesmo assim se não der). Usos clássicos: antiafinidade para nunca rodar duas réplicas do mesmo serviço no mesmo nó (evita que a falha de um nó derrube o serviço inteiro); afinidade para colocar lado a lado serviços que conversam muito. Não confundir com a afinidade de nó (que escolhe pelas propriedades dos nós, não de outros pods) nem com o topology spread (mecanismo mais novo, que distribui de forma mais uniforme). Poderosa, mas regras rígidas demais podem tornar o agendamento impossível. Relacionada a afinidade de nó e topology spread constraint.