Brain and muscle: control plane and worker nodes
Press the right arrow three times. Step one shows the control plane: the API server (the only front door), etcd (the source of truth), the scheduler (decides where pods go), the controller manager (runs the reconciliation loops) and, on cloud clusters, the cloud controller manager that talks to the provider for load balancers and nodes.
Step two shows the worker nodes. Each runs a kubelet (the node agent that makes assigned pods real), kube-proxy (programs Service networking rules) and a container runtime such as containerd. Pods, which hold your containers, live here. Your workloads are the only part that runs on nodes; the control plane never executes application code.
Step three animates traffic: kubelets and controllers talk to the API server, and everything flows through that one component. This single-front-door design is what lets authentication, authorization and policy be enforced uniformly.
On GKE, EKS and AKS the provider runs the control plane for you across several zones and you only see the API endpoint. With kubeadm, Rancher or k3s you run or manage those components yourself, which is why on-prem teams must understand etcd backups and certificate rotation.