Mastering Kubernetes Architecture: How Control Plane and Worker Nodes Work Together

Control Plane Components

Kubernetes runs on a machine designated as the control plane. It hosts daemons that communicate with the cluster when starting containers and pods. The main control‑plane components are:

etcd

etcd is a fast, distributed, consistent key‑value store that serves as the persistent storage for all Kubernetes objects (pods, replication controllers, secrets, services, etc.). It is the only place where the cluster state and metadata are stored. The API server is the sole component that talks directly to etcd; all other components read and write via the API server.

etcd also provides a watch mechanism that notifies interested components of key changes. The API server relies on this to receive updates and reconcile the desired state.

Why should the number of etcd instances be odd? In a high‑availability setup an odd number (3, 5, 7) ensures a majority can be reached for the Raft consensus algorithm. If only two instances run and one fails, the cluster cannot achieve quorum. With three instances, one can fail while a majority remains.

API Server

The API server is the only component that interacts directly with etcd. All other components, including kubectl, must go through the API server to work with cluster state. Its responsibilities include:

Providing a consistent way to store objects in etcd.

Validating objects to prevent malformed configurations.

Exposing a RESTful API for creating, updating, and deleting resources.

Implementing optimistic concurrency control.

Authenticating and authorizing client requests.

Enforcing admission control policies (e.g., image policies, default storage classes, resource quotas).

Providing a watch mechanism so other components can react to changes.

Controller Manager

Controllers are control loops that monitor the cluster state and attempt to move the current state toward the desired state. Each controller watches at least one resource type and acts on changes. Examples include replication controllers, replica sets, daemon sets, jobs, deployments, stateful sets, node controller, service controller, endpoint controller, namespace controller, and persistent‑volume controller.

The controller manager also performs lifecycle functions such as namespace creation, garbage collection of events, terminated pods, cascading deletions, and node cleanup.

Scheduler

The scheduler assigns pods to nodes. It watches for newly created pods without a node assignment, filters nodes that satisfy pod requirements, scores the feasible nodes, and selects the highest‑scoring node. The binding decision is then sent to the API server, which notifies the kubelet on the chosen node.

Scheduling decisions consider factors such as resource requests, node labels, host port availability, pod tolerations, affinity/anti‑affinity rules, and more.

Worker Node Components

Worker nodes run the kubelet agent, which ensures containers run inside pods.

kubelet

The kubelet runs on every node and is responsible for:

Registering the node with the API server.

Continuously monitoring pods scheduled to the node.

Launching containers via the configured container runtime.

Reporting container status, events, and resource usage to the API server.

Performing liveness probes and restarting failed containers.

Terminating containers when their pod is deleted.

Service Proxy (kube-proxy)

kube-proxy runs on each node and maintains network connectivity between pods, services, and nodes. It watches the API server for changes to services and endpoints and programs iptables (or IPVS) rules to load‑balance traffic to the backing pods.

Container Runtime

Two classes of container runtimes exist: low‑level runtimes that create containers and set namespaces/cgroups, and higher‑level runtimes (container engines) that manage images and provide APIs. The runtime is responsible for pulling images, unpacking layers, setting up mounts, applying security profiles, and launching the container process.

How They Work Together

All of these system components cooperate to ensure that every part of a Kubernetes cluster performs its intended function. Understanding their interactions helps you diagnose issues, keep the cluster healthy, and optimize workflows.

Source: Docker Chinese Community