A Kubernetes cluster is a set of cooperating processes. Knowing what each one does makes everything else, from scheduling to troubleshooting, easier to reason about. This guide names the components, then follows a single request all the way to a running container.

Control plane and worker nodes

The control plane makes decisions about the cluster. Worker nodes run your workloads. In a local cluster such as minikube, one node plays both roles. Production clusters usually have several control plane nodes for availability: if you lose the only one, you can no longer change anything in the cluster, although workloads that are already running typically keep running for a while. Control plane nodes are normally tainted so your application Pods aren’t scheduled onto them.

Control plane components

• kube-apiserver is the front door. Every client (kubectl, dashboards, scripts, and the other components) talks to it over an HTTP API. It authenticates and authorizes requests, validates objects, and is the only component that reads and writes etcd.
• etcd is a consistent key-value store holding all cluster state: which nodes exist, which Pods should run, their current status. Treat it like the cluster’s memory. Back it up, because losing it means losing track of everything.
• kube-scheduler picks a node for each Pod that doesn’t have one yet, based on resource requests, constraints, and available capacity.
• kube-controller-manager runs the controllers, the control loops that compare desired and actual state and act on the difference. The Deployment, ReplicaSet, and Node controllers all live here.
• cloud-controller-manager (only on cloud providers) integrates with the provider for things like load balancers and node lifecycle.

Node components

• kubelet is the agent on every node. It watches for Pods assigned to its node, makes sure their containers are running and healthy, and reports status back.
• Container runtime actually runs the containers. It is usually containerd or CRI-O, connected through the Container Runtime Interface. Kubernetes no longer talks to the Docker Engine directly (the dockershim was removed in 1.24), but images built with Docker still run, because images follow the open OCI standard.
• kube-proxy maintains the network rules on each node that make Service addresses reach the right Pods.
• A network plugin (CNI) gives Pods their IP addresses and connectivity across nodes.

Follow a request from kubectl apply to a running container

Suppose you apply a Deployment manifest. Here is what happens:

1. kubectl reads your kubeconfig and sends the manifest to the API server over HTTPS.
2. The API server authenticates and authorizes you, validates the object, stores it in etcd, and responds.
3. The Deployment controller notices the new Deployment and creates a ReplicaSet, and the ReplicaSet controller creates the Pod objects. At this point the Pods exist but aren’t assigned to a node.
4. The scheduler notices Pods without a node, chooses one for each, and records that decision through the API server.
5. The kubelet on the chosen node sees a Pod assigned to it and tells the container runtime to pull the image and start the containers.
6. The kubelet reports progress back to the API server, which stores it in etcd. That is what kubectl get pods reads.

Notice that the components never call each other directly. Each one watches the API server for the objects it cares about and reacts. That loose coupling is why you can restart most components without losing anything: the state they need is in etcd.

You can see the sequence in the events Kubernetes records:

kubectl create deployment demo --image=nginx:1.25
kubectl get events --sort-by=.metadata.creationTimestamp

Look for Scheduled, Pulling, Pulled, Created, and Started. Those are the scheduler and kubelet doing their parts.

Look at the components in your own cluster

kubectl get nodes -o wide
kubectl get pods -n kube-system

On minikube and kubeadm-built clusters you’ll see the control plane components running as Pods in the kube-system namespace, alongside kube-proxy and the network plugin. On managed services (EKS, GKE, AKS) the provider runs the control plane for you and you only see your worker nodes.

What this design means in practice

• The API server is the choke point. Everything passes through it, so securing and sizing it matters.
• etcd health is cluster health. Back it up and, in production, run it redundantly.
• Failures are expected. A dead node, a crashed component, or a deleted Pod is just a difference between desired and actual state that a controller will eventually fix.