The Kubernetes scheduler assigns new pods to nodes. It checks available node resources and placement rules before choosing where a pod can run. The scheduler is a control-plane component; application pods run on worker nodes. section 1.5 section 2.1.2
For a node-placement task, work from the node label to the pod specification, then verify the result:
- Inspect existing labels with `kubectl get no --show-labels`, then label the intended node: `kubectl label no kind-worker disktype=ssd`. section 4.1
- Create a pod manifest with `kubectl run ssd-pod --image=nginx --dry-run=client -o yaml > ssd-pod.yaml`. Under `spec`, set `nodeSelector: {disktype: ssd}` so the pod selects a matching node. section 4.1
- After creating the pod, run `kubectl get po -o wide`. Check both its status and the `NODE` column; the example pod is `Running` on `kind-worker`. section 4.1
root@kind-control-plane:/# kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ssd-pod 1/1 Running 0 25s 10.244.1.2 kind-worker <none> <none>
The wide pod listing makes the placement check concrete: `ssd-pod` is running, and its `NODE` value is `kind-worker`. section 4.1
Do not confuse the scheduler with the controller manager. A controller works to match a Deployment’s current replica count to its desired count; the scheduler assigns the resulting pods to nodes. Nor does the scheduler place its own static control-plane pod: static pods come from manifests in `/etc/kubernetes/manifests`. section 1.5 section 8.2
When new replicas stay Pending
Suppose a Deployment scales from one replica to three, but the two new pods remain `Pending`. Check whether they were assigned a node, then investigate the scheduler pod in `kube-system` with `kubectl describe` and `kubectl logs`. In the failure exercise, the scheduler log reports `unknown flag: --kkubeconfig`; a bad scheduler command, rather than the application container, is the clue. Inspect the static-pod manifest at `/etc/kubernetes/manifests/kube-scheduler.yaml`, correct the error, and recheck the pods. section 8.2
If several control-plane components fail, restore API-server access before relying on `kubectl` to investigate scheduling. An exited scheduler container can also be found with `crictl ps -a`; its logs may identify a missing kubeconfig path in the scheduler manifest. section 8.2.5
