Everything talks to one front door
Kubernetes exposes one REST API and the kube-apiserver process serves it. kubectl is just a convenient HTTP client; run any command with -v=8 to see the requests. Controllers, the scheduler and every kubelet are also clients: they list and watch objects through the same API rather than talking to each other or to the database.
The most important architectural fact is that the API server is the only component that reads or writes etcd. This is a deliberate choke point. Because every change must pass through it, authentication, authorization, validation, admission policy and audit logging are enforced uniformly, whether the caller is an administrator, a controller or a node.
Reveal the four steps with the right arrow: the API server, etcd behind it, the controllers and scheduler as clients, and finally the kubelets. Notice the direction of the packets: components send small updates to the API server and watch for changes; they never push to each other.
Production gotcha: because everything depends on this one endpoint, an overloaded API server slows the entire cluster. Excessive list calls from a badly written controller are a classic cause. Managed providers scale it for you, but you can still hit rate limits.