Mastering Kubernetes Pod Affinity: From Node Rules to Anti‑Affinity Strategies

Overview

Pod scheduling affinity in Kubernetes allows fine‑grained control over where Pods are placed by using node affinity and pod affinity/anti‑affinity rules.

Node Affinity

Node affinity is defined in the nodeAffinity field and supports required (hard) and preferred (soft) rules.

Hard rules

Pods are scheduled only to nodes that match all requiredDuringSchedulingIgnoredDuringExecution criteria; otherwise they remain Pending.

Soft rules

Scheduler assigns scores based on preferredDuringSchedulingIgnoredDuringExecution weights and chooses the highest‑scoring node.

Examples show labeling nodes (e.g., env=prod, disk-type=ssd) and creating a Deployment with hard or soft node‑affinity rules.

Pod Affinity

Pod affinity lets Pods be co‑located based on labels of other Pods, using requiredDuringSchedulingIgnoredDuringExecution (hard) or preferredDuringSchedulingIgnoredDuringExecution (soft) and a topologyKey such as kubernetes.io/hostname.

Hard example

Deployments that require Pods with label app=nginx to run on the same node.

Anti‑Affinity

Pod anti‑affinity spreads Pods across nodes or zones to improve availability and resource isolation. Hard anti‑affinity ensures only one matching Pod per topology domain.

Example demonstrates a Deployment where only one replica runs per node, leaving excess Pods in Pending state.

Pod Anti‑Affinity vs DaemonSet

Anti‑affinity is a scheduling constraint, while a DaemonSet is a controller that guarantees one Pod per node.

Feature

Pod Anti‑Affinity

DaemonSet

Definition

Scheduling rule controlling Pod placement

Controller ensuring a Pod on each node

Purpose

High availability, isolation, performance

Run cluster‑level agents (logging, monitoring)

Scheduling

Uses labelSelector and topologyKey Creates a Pod on every node automatically