Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Part 1
A Kubernetes cluster has two cooperating parts. The Control Plane contains the API Server, Controllers, and Scheduler, which coordinate work. On a Worker Node, the Kubelet directs the Runtime to start containers. The control plane decides what should run; workers execute it.
The request becomes desired state
The developer submits a Deployment for one web-app replica to the API server. When the server accepts it, Kubernetes records the desired state; controllers watch that Deployment and work from it, but they don't start a container themselves.
Controllers create; scheduler assigns
The Deployment controller creates a ReplicaSet through the API server, and the ReplicaSet controller creates the Pod there. Then the scheduler finds that pending Pod and records its assignment to an available worker node through the same server. Assignment isn’t startup.
Assigned is not running.
The control plane assigns the Pod; the worker node's kubelet directs its runtime to start the container.
The scheduler assigns the web Pod to a worker node. What starts its container?
Let's think this through. The scheduler assigns the web Pod to a worker node. What starts its container? A: The API server starts it directly. B: The node's kubelet directs its runtime. C: The scheduler starts it on the node. Choose an answer, or just think it through. I'll explain in a moment.
- The API server starts it directly
- The node's kubelet directs its runtime
- The scheduler starts it on the node
The scheduler assigns the web Pod to a worker node. What starts its container?
The answer is B: The node's kubelet directs its runtime. The scheduler records where the Pod should run, but it does not launch containers. The kubelet on the assigned node sees the Pod and asks its container runtime to start it.
- The API server starts it directly
- The node's kubelet directs its runtime
- The scheduler starts it on the node
The assigned node starts the container
On the assigned node, kubelet watches the API server for its Pod. When it sees the assignment, it asks the container runtime to start the container. The runtime reports back to kubelet, which then sends the Pod’s observed status to the API server.
One requested web app, one running Pod
The API Server’s assignment reaches Kubelet on the Worker Node. Kubelet directs Runtime to start the container, and the Web Pod is now running; Kubelet reports its status through the API Server. That confirms startup, but running alone doesn’t mean the app is ready to serve traffic.
Controllers keep checking
Controllers continuously compare the Desired Pod with the Observed Pod. If the Pod disappears, they work to restore the requested state by creating a replacement. It still needs an available worker node before its container can start.
Decide, assign, start
Control plane records desired state; worker nodes run assigned Pods. The API server records the Deployment; controllers create a ReplicaSet and Pod, scheduler assigns it, and kubelet directs the runtime to start its container.