Core Components: API Server, etcd, Scheduler, Controller Manager, Kubelet & Kube-Proxy
This chapter goes deeper into each of the six components. Interviewers frequently ask you to walk through what happens when you run kubectl apply -- this chapter gives you precision on each of the six
This chapter goes deeper into each of the six components. Interviewers frequently ask you to walk through what happens when you run kubectl apply -- this chapter gives you precision on each of the six: API Server, etcd, Scheduler, Controller Manager on the control plane, and kubelet and kube-proxy on the worker node.
-
API Server: stateless HTTP/REST server -- single entry point. Every request passes through authentication, authorization (RBAC), and admission control before being persisted to etcd.
-
etcd: distributed, strongly-consistent key-value store using Raft consensus. Kubernetes objects stored as protobuf under /registry/. Native watch support means components learn of changes without polling.
-
Scheduler: watches for Pods with empty spec.nodeName, runs filter (eliminate impossible nodes) then score (rank remaining), and writes a Binding. Never executes anything itself.
-
Controller Manager: one binary bundling many independent controllers (Deployment, ReplicaSet, Node, Job) into one process. Each runs its own watch-reconcile loop independently.
-
kubelet: the per-node agent and the only component talking to the container runtime via CRI. Runs probes locally and reports Pod and node status back to the API Server.
-
kube-proxy: implements the Service abstraction at the node level by programming packet-forwarding rules (iptables, IPVS, or eBPF) from EndpointSlice data.
-
Request arrives at API Server over HTTPS.
-
Authentication, authorization (RBAC), and admission controllers validate and mutate.
-
Validated object written to etcd -- the only component etcd ever talks to.
-
Controllers watch for object changes and reconcile actual toward desired state.
-
Scheduler binds unscheduled Pods to nodes via a Binding object.
-
kubelet instructs the runtime via CRI to pull image and start containers.
-
kube-proxy programs node-local forwarding rules from EndpointSlice data.
-
SREs checking Scheduler events first when diagnosing Pending Pods.
-
Platform teams writing admission webhooks for mandatory resource limit enforcement.
-
Security reviews focused on API Server RBAC configuration.
-
Debugging Service routing by inspecting kube-proxy's actual programmed rules.
-
Check kubectl describe pod events first for scheduling problems -- Scheduler writes specific failure reasons.
-
Treat failurePolicy: Fail admission webhooks as critical-path infrastructure needing their own HA.
-
Monitor etcd object count and database size, not just latency.
-
Prefer IPVS or eBPF kube-proxy modes at larger Service/endpoint counts.
-
Assuming Pending Pod is a kubelet problem -- Scheduler events are far more informative.
-
A failurePolicy: Fail webhook with no HA becomes a single point of failure for all matching creation.
-
Confusing Controller Manager (one process, many controllers) with a single controller.
-
The Scheduler only decides placement and writes a Binding -- it never starts containers.
-
Use server-side apply and reduce broad watches from custom controllers.
-
Regularly compact and defragment etcd; alert on database size approaching quota.
-
Back up etcd regularly and verify restore procedures.
-
Keep kubelet, kube-proxy, and control plane versions within documented skew range.
-
Run kubectl get events --field-selector involvedObject.kind=Pod after creating a Pod with an unsatisfiable resource request and read the exact Scheduler failure reason.
-
List active admission webhooks and identify failurePolicy: Fail ones that are potential SPOFs.
-
Without looking it up, list all six core components and write one sentence each.
-
API Server processes every request through authentication, authorization, then admission -- in that strict order.
-
etcd is a Raft-consistent KV store; only the API Server talks to it directly.
-
The Scheduler only decides and records placement (filter, score, bind) -- it never starts containers.
-
kube-controller-manager bundles many independent reconcile loops into one process.
-
kubelet is the only component talking to the container runtime via CRI.
-
kube-proxy implements Service load balancing via node-local forwarding rules from EndpointSlice data.
Want a visual for this concept?
Generate a diagram tailored to “Core Components: API Server, etcd, Scheduler, Controller Manager, Kubelet & Kube-Proxy” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →