Until now the cluster had one node, and every Pod went there. This chapter adds two more. With a choice to make, a component from Chapter 2 finally has work to do: the scheduler.

Two steps

A new Pod has no spec.nodeName. The scheduler notices and runs two phases for it:

Filtering removes nodes that break a hard rule: not enough free CPU, a label the Pod demands, a taint it does not tolerate. Scoring ranks what is left: more free capacity is better, and a node that already runs a replica of the same Deployment scores lower, which is why replicas spread out.

The kubelet on the chosen node then pulls the images and starts the containers. The scheduler never touches a Pod again.

Seeing the choice

kubectl get nodes
kubectl get pods -o wide

NAME                   READY   STATUS    IP           NODE
market-web-7d9-k2m4x   1/1     Running   10.42.0.8    peaks-node-2
market-web-7d9-q8r1z   1/1     Running   10.42.0.9    shallows-node-1

kubectl describe pod records the decision as its first event: Successfully assigned peaks/market-web-… to peaks-node-2.

When no node passes

The Pod stays Pending and the scheduler says why, per node:

0/3 nodes are available: 1 Insufficient cpu, 2 node(s) didn't match Pod's node affinity/selector.

It keeps retrying. Change something, a label, a taint, a request, and the Pod schedules by itself. Every lesson in this chapter is one of those rules.

Skipping the scheduler

spec:
  nodeName: peaks-node-3

A Pod that names its node is never seen by the scheduler. The kubelet there runs it whether it fits or not. Useful for a quick experiment; wrong as a way to place real workloads.