The Kubernetes scheduler decides which worker node should run each new Pod. It belongs to the control plane, which directs the cluster; applications run on worker nodes instead. Here, scheduling means assigning a Pod to a node, not arranging for it to run later. section 1.2.3 section 3.3.1
When you submit an application manifest, the API server stores its objects. A controller creates an object for each application instance, and the scheduler assigns each instance a node. The Kubelet on that node then starts it through the container runtime. The scheduler chooses where it runs; the Kubelet does the running. section 1.2.4
From Deployment to running container
Running `kubectl create deployment kiada --image=luksa/kiada:0.1` creates a Deployment. Kubernetes creates a Pod and assigns it to a worker node. The node’s Kubelet then pulls the image, creates the container, and starts it. Once assigned, that Pod instance stays on its node; if it fails, a new Pod instance may replace it rather than move it. section 3.3.1
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25s default-scheduler Successfully assigned
default/kiada-9d785b578-p449x
to kind-worker2
Normal Pulling 23s kubelet, kind-worker2 Pulling image "luksa/kiada:0.1"
Normal Pulled 21s kubelet, kind-worker2 Successfully pulled image
Normal Created 21s kubelet, kind-worker2 Created container kiada
Normal Started 21s kubelet, kind-worker2 Started container kiada
The event listing makes the handoff visible: `Scheduled` names the chosen node, followed by Kubelet events for pulling the image, creating the container, and starting it. section 3.3.1
