Scheduling assigns a pod to a worker node. Kubernetes then runs that pod on the assigned node; it does not move the same pod instance if it fails. section 3.3.1
A deployment leads to a running container through this sequence:
- kubectl sends the deployment request to the Kubernetes API server. section 3.3.1
- Kubernetes creates a pod and schedules it onto one worker node. section 3.3.1
- The node's Kubelet notices the assignment, directs Docker to pull the image, creates the container, and starts it. section 3.3.1
- If the pod fails, Kubernetes may create a replacement pod, which can be scheduled separately. section 3.3.1
Observe scheduling
Create a deployment with `kubectl create deployment kiada --image=luksa/kiada:0.1`, then inspect its pod with `kubectl get pods`. A pod initially shown as `Pending` becomes running after the scheduler assigns it to a worker node; pod events report the assignment and subsequent image and container operations. section 3.3.1
$ kubectl create deployment kiada --image=luksa/kiada:0.1 deployment.apps/kiada created
Use the deployment command to trigger the scheduling lifecycle and compare its output with pod status and events. section 3.3.1
