Kubernetes architecture: control plane, nodes, kubelet and etcd

A Kubernetes cluster has two halves. The control plane keeps a record of what should be running and makes decisions about it. The nodes (worker machines, physical or virtual) actually run your containers. You talk only to the control plane; it tells the nodes what to do.

The key idea is desired state. You describe what you want (“three copies of this web server”) as an object, the control plane stores it, and a set of control loops keeps working until reality matches the description. If a node dies, the loops notice the difference and recreate the missing containers elsewhere.

Control plane components

• kube-apiserver: the front door. Every tool, including kubectl, the other control plane components and the kubelets on the nodes, reads and writes cluster state through this HTTP API.
• etcd: a consistent, highly available key-value store that holds all cluster data. Only the API server talks to it directly. If you lose etcd without a backup, you lose the cluster’s configuration.
• kube-scheduler: watches for new Pods that have no node assigned yet and picks a node for each one, based on resource requests, constraints, affinity rules and taints.
• kube-controller-manager: runs the built-in controllers (Deployments, ReplicaSets, Nodes, Jobs and others). Each controller is logically separate but they are compiled into one binary and run in one process.
• cloud-controller-manager (optional): links the cluster to a cloud provider’s API, for example to create cloud load balancers for Services. Clusters on your own hardware usually do not run it.

Node components

• kubelet: an agent on every node. It receives Pod specs from the API server, asks the container runtime to start the containers, runs health probes and reports status back.
• Container runtime: the software that actually runs containers, such as containerd or CRI-O. The kubelet talks to it through the Container Runtime Interface (CRI).
• kube-proxy (optional): maintains network rules on each node so that Service IPs reach the right Pods. Some network plugins implement this themselves, in which case kube-proxy is not needed.

Most clusters also run add-ons as ordinary Pods: cluster DNS (usually CoreDNS) so that Services get DNS names, a network plugin (CNI) that gives every Pod an IP address, and often a metrics server for kubectl top.

What happens when you create a Deployment

1. kubectl apply -f deploy.yaml sends the object to the API server, which validates it and stores it in etcd.
2. The Deployment controller sees the new Deployment and creates a ReplicaSet; the ReplicaSet controller creates the Pod objects.
3. The scheduler sees Pods with no node and assigns each one to a node.
4. The kubelet on that node sees a Pod assigned to it, pulls the image through the container runtime and starts the containers.
5. The kubelet reports status back to the API server, and kubectl get pods shows the Pod as Running.

Notice that no component calls another directly to say “do this now”. Each one watches the API server for objects it cares about and reacts. That is why Kubernetes heals itself: the same loops that created your Pods will recreate them after a failure.

Looking at your own cluster

kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -n kube-system
kubectl describe node worker1.example.com

On clusters built with kubeadm, the control plane components themselves run as Pods in the kube-system namespace, so you will see the API server, scheduler, controller manager and etcd listed there. Managed cloud services usually hide the control plane, and you only see your worker nodes.

High availability

A production control plane runs on several machines (commonly three) so that losing one does not stop the cluster. etcd needs a majority of its members to agree before it accepts writes, which is why odd member counts are used. Worker nodes can come and go freely; the scheduler simply stops placing Pods on nodes that are not Ready.

Official documentation

• Cluster Architecture
• Kubernetes Components