The Kubernetes API server is the front door to a cluster. Requests from users and services enter through it, including kubectl commands, Kubernetes Dashboard operations, and direct JSON API calls. It encapsulates etcd and acts as an event-driven hub: other components communicate through the API server, while controllers watch for relevant change events. section 3.2.2
A request commonly crosses these responsibilities:
- Accept a request to create a Pod and coordinate with the Kubernetes scheduler. section 3.2.2
- Expose cluster state through clients such as kubectl, the Kubernetes Dashboard, and direct JSON API calls. section 3.2.2
- Provide the communication path used by worker-node components; after scheduling, the kubelet retrieves Pod specifications from the API server. section 3.2.3
- Support operational diagnosis by making component interactions and request paths central to tracing cluster problems and root causes. section 3.2
Creating a Pod
A client submits a Pod-creation request to the API server. The API server communicates with the scheduler, which selects a worker node. The kubelet on that node then retrieves the Pod specification from the API server and creates the Pod. section 3.2.2 section 3.2.3
Use the cluster component communication diagram to trace how the API server connects control-plane and worker-node responsibilities. section 3.2.3



