Mastering Kubernetes Control Plane: etcd, API Server, Scheduler, and Nodes

Control Plane Components

etcd

etcd is a fast, distributed, consistent key‑value store used as the persistent storage for Kubernetes objects such as pods, replication controllers, secrets, services, etc. It is the sole place where Kubernetes stores cluster state and metadata, and the only component that talks directly to etcd is the API Server.

etcd also provides a watch mechanism, offering an event‑driven interface for asynchronous monitoring of key changes. Observers receive notifications when keys change, which the API Server heavily relies on to move the current state toward the desired state.

Should the number of etcd instances be odd?

In HA setups you typically run 3, 5, or 7 etcd instances. etcd uses the Raft consensus algorithm, which requires a majority of the cluster to agree on state transitions. With an even number of nodes, a failure could prevent the cluster from achieving a majority, whereas an odd number tolerates one failure.

API Server

The API Server is the only component that interacts directly with etcd. All other Kubernetes components and clients (kubectl) must go through the API Server to read or write cluster state. It provides:

Consistent storage of objects in etcd.

Validation of objects before they are persisted.

RESTful API for creating, updating, and deleting resources.

Optimistic concurrency control.

Authentication and authorization of client requests.

Admission control (e.g., AlwaysPullImages, DefaultStorageClass, ResourceQuota).

Watch mechanisms for clients to observe changes.

Controller Manager

Controllers monitor cluster state and drive it toward the desired state. Each controller watches at least one resource type and acts on changes. Examples include ReplicationController, ReplicaSet, DaemonSet, Job, Deployment, StatefulSet, Node, Service, Endpoints, Namespace, and PersistentVolume controllers.

Controllers use watches to receive change notifications, periodically relist resources to avoid missing events, and perform lifecycle functions such as namespace creation, garbage collection of pods, cascading deletion, 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 for binding via the API Server.

Factors considered include resource requests, node labels, taints and tolerations, node affinity/anti‑affinity, and port conflicts.

Worker Node Components

Kubelet

Kubelet runs on each node as an agent responsible for ensuring containers run inside pods. Its main functions are to register the node with the API Server, monitor scheduled pods, launch containers via the configured container runtime, report status, perform liveness probes, and terminate pods when removed.

kube-proxy

kube-proxy runs on each node to enable communication between pods, nodes, and services. It watches the API Server for Service and endpoint changes and implements load‑balancing using iptables or IPVS rules.

Container Runtime

The container runtime handles pulling images, unpacking layers, preparing mount points, setting up namespaces and cgroups, applying security profiles, and launching containers via syscalls.