Seven components, each with one narrow job, deliver a Pod.

Press the right arrow to follow the request. This single story is the best summary of the whole architecture.

Nothing talks to anything else directly: every arrow goes to or from the API server, and every component only does its own narrow job.

Study notes

The full journey from kubectl apply to a running container

This is the sequence worth narrating fluently in an interview. Step 1: kubectl sends the Deployment manifest to the API server. Step 2: the API server authenticates, authorizes and admits it, then stores it in etcd. Step 3: the Deployment controller, which is watching Deployments, sees the new object and creates a ReplicaSet and then three Pod objects, none yet assigned to a node.

Step 4: the scheduler watches for Pods without a node, filters and scores the nodes, and writes the chosen node name into each Pod. Step 5: the kubelet on each chosen node, watching for Pods assigned to it, sees one, and instructs the container runtime to pull the image, create the namespaces and cgroups, and start the process. Step 6: the kubelet runs probes and reports the Pod's status back to the API server, which stores it in etcd.

Notice the pattern. Every arrow involves the API server. No controller calls the scheduler; no scheduler calls a kubelet. Each component watches the API for work meant for it and writes its result back. That is why the system is loosely coupled and why you can restart any component without losing the plan.

Use it for troubleshooting: ask which step stalled. No Pods created means the controller or admission. Pods Pending means the scheduler. Pods assigned but ContainerCreating or ImagePullBackOff means the kubelet or runtime. Deck 4 turns this into a systematic diagnostic tree.

Back Next