A Kubernetes cluster is composed of a control plane and a set of worker Nodes. A Node is a worker machine (physical or virtual) where Pods run, identified by metadata.name, addresses (InternalIP, ExternalIP, Hostname), nodeInfo (kubelet version, OS, architecture), and conditions such as Ready, MemoryPressure, DiskPressure, and PIDPressure. The Node controller monitors heartbeats from kubelets; if a node stops reporting within the node-monitor-grace-period (default 40s), its status is marked NotReady and Pods are eventually rescheduled elsewhere.
The control plane consists of several cooperating components. The kube-apiserver is the front end of the cluster, exposing the REST API and being the only component that talks directly to etcd, the consistent distributed key-value store that holds all cluster state and requires a quorum for safety. The kube-controller-manager runs core control loops such as the Node controller, Job controller, EndpointSlice controller, and ServiceAccount controller, continuously reconciling actual state toward desired state. The cloud-controller-manager embeds cloud-specific logic for node lifecycle, routes, and load balancer integration, separating vendor concerns from the core control plane.
On each Node, the kubelet registers the Node with the API server, watches for Pod specs assigned to it, and ensures that the described containers are running and healthy. kube-proxy maintains iptables, IPVS, or eBPF rules to implement Service virtual IPs. The Scheduler is the control plane component that watches for newly created Pods without an assigned node and selects one based on resources, affinity rules, taints, and other policies. Scheduling decisions can be influenced by taints, which are key-value-effect triplets applied to nodes that repel Pods lacking a matching toleration; the standard effects are NoSchedule, PreferNoSchedule, and NoExecute. Pods may declare tolerations to allow (but not require) scheduling onto tainted nodes. Node affinity attracts Pods to a set of nodes based on labels, expressed as either requiredDuringSchedulingIgnoredDuringExecution or preferredDuringSchedulingIgnoredDuringExecution, while pod anti-affinity prevents Pods from being scheduled on the same node, zone, or topology domain as other matching Pods to spread load or improve availability.