Node affinity matches workload requirements to node labels. It can require NVMe storage or prefer a newer instance family, but it does not replace the scheduler’s other checks. Even without affinity, scheduling filters resource requests, taints and volume constraints before scoring feasible nodes. It is not simply a comparison of idle capacity. ...
Requests guide placement and resource sharing; limits constrain runtime consumption. They are related inputs, not a universal floor-and-ceiling guarantee for application performance. Choose them from workload behavior, contention risk and recovery requirements. Inspect the admitted Pod because defaults and policy can change the resource values submitted in a manifest. ...
Pod anti-affinity expresses where a Pod should avoid selected peers. A hostname topology can reduce shared-node exposure; a zone topology can address a broader failure domain. The rule does not create extra capacity or prove application availability. It shapes placement, while replication, readiness, storage, and failure recovery remain separate responsibilities. ...
A taint repels Pods that do not tolerate its effect. A toleration removes that obstacle; it does not force placement onto specialized hardware. Dedicated-node designs usually combine a taint with a label and required node affinity, then check capacity and admission policy separately. ...