Keep replicas apart and their caches close with Pod affinity
Intermediate · Kubernetes · about 12 minsearch uses required Pod anti-affinity on kubernetes.io/hostname, so no two replicas share a node. Each node should also run one cache Pod next to the search replica, which saves a network hop on every lookup.
About this scenario
search uses required Pod anti-affinity on kubernetes.io/hostname, so no two replicas share a node. Each node should also run one cache Pod next to the search replica, which saves a network hop on every lookup.
The cache Deployment says so with Pod affinity and anti-affinity, but none of its Pods start. Find out why, fix it, then grow both to four replicas.
Objectives
- Read why the cache Pods are Pending
- Each cache Pod runs beside a search Pod, one per node
- Scale both to 4, still one of each per node
- search still requires one replica per node
What you'll practice
- Pod affinity places a Pod in the same topology domain as Pods matching a label selector; anti-affinity keeps it out of one.
kubernetes.io/hostnamemeans the same node,topology.kubernetes.io/zonethe same zone. - A selector that matches nothing doesn't fail loudly: the Pods just stay Pending with
didn't match pod affinity rules. Check it againstkubectl get pods --show-labels. - Required anti-affinity per node caps the replicas at the number of nodes. Use
preferredDuringSchedulingIgnoredDuringExecution, or a topology spread constraint, when you'd rather pack than wait.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.