Pod Anti-Affinity for HA

Spread pods across nodes/zones. The pattern.

Idea

Pod anti-affinity discipline is the practice of distributing pods of the same service across different nodes (or zones, or other topology). Without it, multiple replicas can land on the same node; node failure takes them all down; the workload's redundancy is theoretical.

What the idea looks like:

• Pods of the same service should not co-locate.: Multiple replicas of a service should run on different nodes. The replication is for redundancy; co-location defeats the redundancy.
• One node down does not equal all pods down.: When a node fails (kernel panic, hardware failure, network issue), pods on it go down. Anti-affinity ensures these are not all the workload's replicas; survivors keep serving.
• Multi-replica workloads.: Anti-affinity matters most for multi-replica workloads. Single-replica workloads do not benefit; multi-replica workloads use anti-affinity to preserve redundancy.
• Topology-aware.: Anti-affinity can be at the zone or region level. Multi-zone deployments distribute across zones; the failure domain is bounded.
• Default for stateless services.: Most production multi-replica services have anti-affinity. The discipline is consistent; the default produces resilience.

The idea is foundational. Without anti-affinity, the redundancy benefit is partially undone.

Setup

The pod spec includes podAntiAffinity rules. The rule specifies the topology key (where to spread) and whether the requirement is hard or soft.

• podAntiAffinity with hostname.: The hostname topology key spreads across nodes. Pods of the same workload do not land on the same node; node failures do not take down all replicas.
• Or zone topology key.: The zone topology key spreads across availability zones. Pods of the same workload do not land in the same zone; zone failures are bounded.
• Hard requirement.: requiredDuringSchedulingIgnoredDuringExecution makes the rule strict. Pods cannot schedule together; if topology is exhausted, pods stay pending.
• Soft requirement.: preferredDuringSchedulingIgnoredDuringExecution makes the rule a preference. The scheduler tries to spread; if it cannot, pods schedule together.
• Documented in pod spec.: The team's pod spec template includes anti-affinity. New pods inherit the discipline; the consistency is built in.

Setup is per-pod-template. The discipline is consistent across multi-replica workloads.

Limits

Hard anti-affinity can prevent scheduling. The team's discipline includes recognizing when soft is the right choice.

• Hard anti-affinity can prevent scheduling.: If the cluster has fewer nodes than replicas, hard anti-affinity prevents some pods from scheduling. The workload's full replica count cannot be achieved; the discipline becomes a barrier.
• Soft is more flexible.: Soft anti-affinity allows scheduling to proceed when the preference cannot be honored. The replicas may co-locate occasionally; the discipline is preferential rather than strict.
• Usually correct.: For most workloads, soft anti-affinity is the right choice. The benefit (spread when possible) is preserved; the cost (occasional co-location) is bounded.
• Hard for high-availability.: When the workload's availability cannot tolerate co-location, hard anti-affinity is justified. The team accepts that some replicas may not schedule; the survivors are guaranteed to be on different topology.
• Test the choice.: The team tests anti-affinity behavior. Drain a node; verify pods reschedule correctly; verify the workload's availability holds. The configuration matches the intent.

Pod anti-affinity discipline is one of those Kubernetes scheduling disciplines that pays off in real availability. Nova AI Ops integrates with cluster pod placement telemetry, surfaces patterns, and supports the team's distribution discipline.