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. Core controllers coordinate Kubernetes object state through the API server; node runtime and data-plane communication use other paths.
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. It persists Kubernetes API object state, including Deployments, Secrets and node records. It does not contain application volume data or an indefinite history of deleted objects. Back up its state and application data through their respective recovery procedures. Core Kubernetes clients access object state through the API server.
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 API-driven changes and inspection fail; local processes, runtime tools and existing data paths can still operate.
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 kubelet watches assigned pod state through the API. The API server can also contact kubelets for operations such as logs and exec, so this is not a claim that all communication is one-way. That is why a node that loses contact with the API server keeps running the pods it already has.
Follow one replica from intent to execution
For a Deployment increasing from two replicas to three, the request first passes API authentication, authorization and admission. Controllers observe the new desired count and create a pod object. The scheduler chooses a feasible node and records the assignment; the kubelet on that node then asks the runtime to start the containers.
That sequence provides useful checkpoints. If no new pod object appears, inspect controller and admission evidence. If the pod exists without a node assignment, inspect scheduling events. If a node is assigned but the container has not started, inspect image pulls, volume setup and kubelet/runtime errors. A request accepted by the API has passed only the first checkpoint.
During an API outage, existing workloads may continue and local container restarts may still occur. New control-plane reconciliation is impaired, and applications that depend on the API can fail. Check the actual service request path before declaring the outage harmless. Cluster components describes the responsibilities; node/control-plane communication includes API-server connections to kubelets.
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. Node responsibilities depend on the managed service mode. Application configuration, identity and provider control-plane problems still need investigation.
"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.
Confusing a recorded scheduling assignment with a successfully started container.
Forgetting etcd, or describing it as a cache. It stores API state; application data needs separate protection.
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.