Kubernetes derives its core capabilities from control plane decisions, node-side execution, and declarative reconciliation. This article focuses on key modules such as kube-apiserver, etcd, scheduler, controller-manager, and kubelet, explaining how they work together to deliver scheduling, self-healing, and service discovery. Keywords: Kubernetes, etcd, scheduler.
Technical Specification Snapshot
| Parameter | Details |
|---|---|
| Technical Topic | Kubernetes Core Components |
| Primary Language | Go |
| Communication Protocols | HTTP/HTTPS, gRPC, watch mechanism |
| Data Store | etcd |
| Runtime Interface | CRI |
| Networking Implementation | iptables / IPVS / CNI |
| GitHub Stars | Not provided in the source content |
| Core Dependencies | etcd, containerd/CRI-O, CoreDNS, CNI |
AI Visual Insight: This diagram shows the Kubernetes architecture and typically presents the control plane and worker nodes in separate layers. It highlights the API Server as the unified entry point, etcd as the state store, the Scheduler as the Pod placement engine, the Controller Manager as the reconciliation engine, and kubelet, kube-proxy, and the container runtime as the node-side executors.
Kubernetes core components form a declarative control system
Kubernetes is not a platform that directly “executes commands.” Instead, it is a control system that continuously drives the cluster toward the desired state. After a user submits YAML, the control plane receives, stores, schedules, and reconciles the request, while node-side components run the actual containers.
The key architectural value here is decoupling. Components do not directly control one another. Instead, they collaborate around the API Server and cluster state, which gives Kubernetes stronger observability, extensibility, and high availability.
The control plane is responsible for global decisions
The control plane mainly includes kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and optionally cloud-controller-manager. Together, they handle request intake, state persistence, decision-making, and convergence.
kubectl apply -f app.yaml # Submit the desired state to the cluster
kubectl get pod -o wide # View scheduling results and node distributionThese commands reflect the basic Kubernetes interaction model: first declare the target state, then let the control plane complete the follow-up actions.
kube-apiserver is the cluster’s only trusted entry point
kube-apiserver is the unified entry point for all external requests and internal communication. Whether the client is kubectl, a controller, the scheduler, or kubelet, it ultimately accesses the Kubernetes API through the API Server.
It is also the only core component that directly reads from and writes to etcd. As a result, it owns authentication, authorization, admission control, auditing, and resource version management. Without the API Server, the cluster’s entire control path breaks down.
The API Server unifies access paths and security boundaries
By funneling all operations through a single entry point, Kubernetes avoids direct coupling between components. This design also makes auditing easier and simplifies extensibility through webhooks, the aggregated API, and multi-tenant access control.
apiVersion: v1
kind: Pod
metadata:
name: demo-pod
spec:
containers:
- name: nginx
image: nginx:stable # Declare the image versionThis YAML does not create a container directly. Instead, the API Server first receives it and stores it as desired state.
etcd provides Kubernetes with its most critical strongly consistent state store
etcd is a distributed key-value database that stores node information, Pod state, configuration objects, leases, and metadata. Its importance is not just that it can store data, but that it can consistently provide a correct and up-to-date view of cluster state.
Strong consistency means that after a write succeeds, any client reading from any node should see the latest committed data, without dirty reads, stale reads, or out-of-order visibility.
etcd uses Raft to guarantee majority-confirmed writes
etcd relies on the Raft algorithm to achieve linearizability. Only the Leader accepts write requests, and a write is committed only after the log has been replicated to a majority of nodes. That is why production deployments commonly use an odd number of nodes, such as 3 or 5.
3-node cluster: a write succeeds after at least 2 nodes confirm it
5-node cluster: a write succeeds after at least 3 nodes confirm itThis means etcd trades part of its performance for extremely high data reliability and consistency.
kube-scheduler determines which machine ultimately runs a Pod
The Scheduler does exactly one thing: it selects the most suitable Node for a Pod that has not yet been bound. It does not run containers and does not maintain replicas. It is responsible only for placement decisions.
Its scheduling workflow usually consists of four steps: watch, filter, score, and bind. It first eliminates nodes that do not satisfy hard constraints, then scores the remaining candidates according to policy, and finally completes the binding through the API Server.
Scheduling fundamentally filters first and then chooses the best option
During the filtering phase, the Scheduler checks constraints such as available resources, taints and tolerations, affinity rules, port conflicts, and node health. During scoring, it ranks candidate nodes based on factors such as image locality, resource balance, node load, and preference rules.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values: [ssd] # Allow scheduling only onto SSD nodesThese constraints determine whether a Pod can be scheduled onto a node, while scoring rules determine which node is the best fit.
kube-controller-manager continuously drives desired state toward actual state
Controller Manager is not a single controller. It is a collection of controller processes. Its core mechanism is the Reconcile Loop: continuously watch resource changes, compare actual state with desired state, and execute corrective actions.
This is also the root of Kubernetes self-healing. Automatic Pod rescheduling after node failures, automatic replica recovery when replicas are missing, and automatic Service endpoint updates after backend changes are all handled by different controllers.
Different controllers solve different automation problems
The Node Controller is responsible for node health and failure eviction. The ReplicaSet Controller converges replica counts. The Endpoint Controller maps Services to backend Pod IP addresses.
def reconcile(desired, current):
if current < desired:
return "create" # Create a Pod when replicas are insufficient
if current > desired:
return "delete" # Delete a Pod when there are too many replicas
return "keep" # Keep the current state when it already matchesThis pseudocode captures the core controller idea: compare continuously, then execute convergence actions.
Node components turn control plane decisions into actual runtime state
The key node-side components include kubelet, kube-proxy, and the container runtime. They run on every worker node and are responsible for starting containers, reporting state, and implementing service forwarding.
kubelet is the node agent. It continuously watches the PodSpec assigned to the local node through the API Server, calls the container runtime to create or destroy containers, and periodically reports node health and resource information.
kube-proxy and the container runtime complete the node execution loop
kube-proxy maintains network rules through iptables or IPVS and provides service discovery and load balancing for Services. The container runtime uses the CRI interface to pull images, start and stop containers, and manage container lifecycles.
crictl ps # View running containers
kubectl get svc -A # View Service resources
kubectl describe node xx # View node status and resourcesThese commands correspond to the main observation points for container execution, service abstraction, and node health.
Core add-ons fill in DNS, networking, metrics, and ingress capabilities
CoreDNS provides service name resolution, allowing applications to communicate through Service names instead of hard-coded IP addresses. CNI plugins provide Pod networking and cross-node communication, with common implementations including Calico and Flannel.
Metrics Server aggregates resource metrics and provides CPU and memory data for HPA. The Ingress Controller handles external HTTP/HTTPS traffic and routes requests to internal services based on hostnames or paths.
cloud-controller-manager integrates public cloud capabilities
When Kubernetes runs on AWS, Alibaba Cloud, or other public clouds, cloud-controller-manager takes over cloud resource interactions such as load balancers, cloud disks, and node metadata.
This allows the Kubernetes core to remain generic while cloud provider capabilities are integrated through independent controllers.
Understanding how components work together matters more than memorizing definitions
In interviews and production practice, the real value lies not in reciting component names, but in understanding the call chain: a user request enters the API Server, state is written to etcd, the Scheduler selects a node, Controllers keep the system converging, and kubelet ultimately executes the container lifecycle.
As long as you understand these five main threads—unified entry point, strongly consistent storage, declarative scheduling, controller-driven self-healing, and node-side execution—you can quickly understand most Kubernetes behavior.
FAQ
Why does Kubernetes not allow other components to operate on etcd directly?
Because the API Server must centrally handle authentication, authorization, admission, auditing, and resource version control. If components accessed etcd directly, they would break the security boundary and the consistent access model.
Why does a Pod remain in the Pending state?
Common causes include insufficient CPU or memory, missing tolerations for node taints, non-matching affinity rules, unhealthy candidate nodes, or image and architecture constraints that cannot be satisfied.
Which component mainly implements Kubernetes self-healing?
The core responsibility belongs to kube-controller-manager. Through multiple controllers, it continuously runs reconciliation loops and automatically restores the desired state in scenarios such as node disconnection, missing replicas, and endpoint changes.
Summary
This article systematically explained Kubernetes core components, focusing on the responsibilities, collaboration patterns, and typical workflows of kube-apiserver, etcd, scheduler, controller-manager, kubelet, and kube-proxy, while also covering the role of cloud controllers and core add-ons.