Scheduling

Affinity is placement matching: prefer a label or force it, and use anti-affinity to keep replicas spread apart for resilience. Hardware is never uniform for long — a GPU pool here, fast local NVMe there, an isolated zone for regulated data — and workloads quietly depend on landing in the right place. Without explicit rules, the scheduler spreads pods by free capacity alone, and the pod that needs a GPU lands on the node that has none, failing at runtime instead of at schedule time. ...

The cluster schedules on requests but enforces limits, so a container that sets only one side leaves a half-open contract. Requests-only pods schedule honestly but burst without bound, free to starve neighbors when they spike. Limits-only pods are capped at runtime yet scheduled as if they cost nothing, so the scheduler packs them densely until the node saturates. Either half-contract fails under pressure; the two numbers only work as a pair. ...

Anti-affinity is the scheduler rule that keeps replicas apart. Where affinity says “run me next to these pods”, anti-affinity says “keep me away from them”, and the reason is almost always failure domains: if all three replicas land on one node, one node failure is a full outage. ...

Taint is the ’no admission’ sign and toleration is the permit, so you can pin paying platforms, GPUs, or spot nodes to exactly the pods that fit. A sign for specialists A taint marks a node as off-limits to ordinary pods, and it is fundamentally a sign, not a command: applying a taint does not move anything that is already running. New pods avoid the node unless they carry a matching toleration, which is the ‘permit.’ That is how you reserve a subset of the cluster, GPU machines, spot nodes, nodes with special hardware, for exactly the workloads that fit, while everything else schedules as if those nodes did not exist. Because it is scoped by opt-in, the same physical fleet can host both the general pool and the specialist pool without label soup. ...