Pod Affinity: Grouping or Separating Your Pods

WHY IT EXISTS Kubernetes needs to know more than just resource requests (CPU/memory) to make smart scheduling decisions. For performance and high availability, the relative placement of related pods matters immensely. Affinity and anti-affinity rules provide this crucial context, moving beyond simple resource packing to relationship-aware placement.

THE MENTAL MODEL Think of pod affinity as social rules for your pods. Anti-affinity is like social distancing: "Keep these pods on different machines to ensure a hardware failure doesn't take out my whole service." Affinity is like a clique: "Keep this web server and its in-memory cache on the same machine to minimize network latency." These rules are hints or commands to the scheduler about pod relationships.

HOW IT WORKS You define podAffinity or podAntiAffinity in a pod's spec. The rule has three main parts. First, a labelSelector identifies the target pods you want to be near or away from. Second, a topologyKey defines the boundary for the rule, such as kubernetes.io/hostname (the same node) or topology.kubernetes.io/zone (the same availability zone). Third, a type: requiredDuringSchedulingIgnoredDuringExecution is a hard rule that must be met, while preferredDuringSchedulingIgnoredDuringExecution is a soft preference that the scheduler will try to honor but won't block scheduling if it can't.

WHEN TO USE IT Use pod affinity to co-locate pods that communicate frequently, like an application server and a local cache, to reduce latency and network hops. Use pod anti-affinity for high availability, spreading replicas of a stateful service like a database or message queue across different nodes, racks, or cloud provider zones to survive hardware or zone failures.

WHEN NOT TO USE IT Avoid using required rules unless absolutely necessary, as they can make your pods unschedulable if no nodes satisfy the condition. Be cautious in small clusters where strict anti-affinity rules might prevent pods from being scheduled at all. Also, remember this is not for pod-to-node constraints (like "needs a GPU"); use nodeAffinity for that.

ONE CANONICAL EXAMPLE To ensure high availability for a Redis cache, you can use podAntiAffinity. You would set a requiredDuringSchedulingIgnoredDuringExecution rule with a topologyKey of kubernetes.io/hostname. This tells the scheduler, "For any pod with the label app=redis, do not schedule it on a node that is already running a pod with the label app=redis." This guarantees that each Redis replica runs on a unique node, surviving a single-node failure.