The Central Hub
The kube-apiserver is the only component in the entire cluster that reads from and writes to etcd directly. Every other component — whether it's the scheduler, a controller, a worker node's kubelet, or your own kubectl command — communicates with the cluster exclusively by talking to the API Server.
This design is intentional. By funneling all communication through a single, well-defined interface, Kubernetes can enforce consistent security, validation, and auditing on every operation. No component ever reaches into etcd directly or calls another component directly.
Here is what that looks like in practice:
- When you run
kubectl apply -f deployment.yaml, your terminal sends an HTTP POST request to the API Server. - When a worker node's kubelet wants to report that a Pod has started, it sends an HTTP PATCH to the API Server.
- When the scheduler decides where to place a Pod, it sends a "Bind" request to the API Server.
- When the controller manager wants to know the current state of all Deployments, it issues a LIST/WATCH request to the API Server.
The API Server is stateless — it doesn't store anything itself. It processes requests, validates them, enforces security policies, and then reads from or writes to etcd. This means you can run multiple API Server replicas behind a load balancer for high availability without any coordination between them.
Interviewers often ask: "What happens if the API Server goes down?" The correct answer is nuanced. Already-running Pods continue running because the kubelet on each worker node operates independently once it has its instructions. However, no new scheduling decisions can be made, no controllers can reconcile state, and no kubectl commands will work. The cluster is frozen in its current state until the API Server recovers.