Control Where Pods Run

You rarely want the scheduler to drop a Pod on any node. Some workloads need a particular OS or hardware, some must stay off nodes reserved for other teams, and replicas of the same app should spread out so one node failure can't take them all down. Kubernetes gives you a small set of levers for this:

• nodeSelector — the simplest filter: only schedule where the node carries these labels. (nodeAffinity is the richer version, with In/NotIn/Exists operators and soft preferred rules — same idea, more expressive.)
• Resource requests — what the Pod needs to fit on a node. The scheduler only places a Pod where the requested CPU and memory are available, so requests are a scheduling input, not just a limit.
• Taints and tolerations — a node with a taint repels Pods unless the Pod carries a matching toleration. This is how you keep general workloads off dedicated nodes (control-plane, GPU, a team's pool).
• topologySpreadConstraints — spread replicas evenly across a topology domain (nodes, zones) so they don't clump. maxSkew bounds how uneven the distribution may get; whenUnsatisfiable: ScheduleAnyway makes it a soft preference rather than a hard block.

In this lab you take a Deployment from "runs anywhere" to "runs where you say."

Useful aliases

k is aliased to kubectl and completion is configured. The jumpbox also has k9s, jq and yq. kubectl get nodes --show-labels shows what you can match.