TL;DR: A control plane of four pieces (API server, etcd, scheduler, controller manager) decides what should be running, and every node runs a kubelet and a network proxy that make it true. Everything communicates through the API server, and only the API server touches etcd.
How to approach it
Name the components, then say what each one would break if you switched it off. That second half is what separates someone who has run a cluster from someone who has read the docs page, and it takes about thirty extra seconds. Start with the control plane, finish on the node, and say the API server rule once, early.
A strong answer
etcd is the database. Every object you have ever created lives here as a record: Deployments, Secrets, the current state of every node. It is the only stateful thing in the cluster, which is why backing it up is the difference between a bad afternoon and starting over. Nothing but the API server connects to it.
The API server is the front door and the only door. kubectl, the kubelets, the controllers, your CI pipeline: all of them speak to the API server over HTTPS, and it authenticates them, checks whether they are allowed to do what they asked, runs the request past any admission webhooks, and writes the result to etcd. Switch it off and the cluster does not stop serving traffic, but nothing can change and nothing can be inspected.
The scheduler answers one question, repeatedly: this pod has no node, which node should it go on? It filters nodes that cannot take the pod (not enough memory, wrong architecture, a taint the pod does not tolerate) and scores the rest. Then it writes its choice back to the API server. It does not start anything.
The controller manager runs the reconciliation loops. A Deployment says three replicas and two exist, so the ReplicaSet controller creates one. A node stops reporting, so the node controller marks it and starts evicting. Each controller watches for a gap between what you asked for and what exists, then closes it.
On every node, two things:
The kubelet is the agent that actually runs containers. It watches the API server for pods assigned to its node, tells the container runtime (containerd, usually) to pull images and start containers, runs the health probes, and reports status back. It is the only component that talks to the runtime.
kube-proxy (or on newer clusters, an eBPF dataplane replacing it) programs the node's networking so that traffic sent to a Service's virtual IP reaches one of the pods behind it.
The sentence worth landing: the control plane never pushes anything to a node. The kubelet pulls its own work. That is why a node that loses contact with the API server keeps running the pods it already has.
What interviewers probe next
"What happens if etcd is unavailable?" Running workloads keep serving, because kubelets already know their pods. Nothing new can be scheduled, no deploy works, and kubectl fails. It degrades into a frozen cluster rather than a dead one.
"Where do managed clusters change this?" EKS, GKE and AKS run the control plane for you, so you never see the API server or etcd as machines. The nodes are still yours, which is why almost every problem you debug on a managed cluster is a kubelet, networking or capacity problem.
"What is the difference between the scheduler and the kubelet?" The scheduler chooses a node and writes it down. The kubelet reads that and makes it real. Two separate steps, which is why a pod can be assigned to a node and still not be running.
Common mistakes
Listing the components without saying what each does, which reads as memorisation and invites a harder follow-up immediately.
Saying the control plane sends pods to nodes. It does not push anything; the kubelet watches and pulls.
Forgetting etcd, or describing it as a cache. It is the only durable state in the cluster.
Putting the container runtime in the control plane. Containers only ever run on nodes, including control-plane nodes when they are running the control plane's own pods.