Kubernetes Node Definition

Kubernetes Node Definition is the precise characterization of a node as a worker machine, physical or virtual, that has registered with a cluster's control plane and runs the components necessary to host and execute Pods on the control plane's behalf. Formally, a node is defined jointly by two things: the underlying machine providing compute, memory, and storage capacity, and the Node API object through which the control plane tracks that machine's identity, capacity, and health, with the two kept in sync through continuous status reporting.

The Node as a Physical and Logical Entity

Dual Nature

A node exists simultaneously as a physical or virtual machine, running an operating system and a set of processes, and as a Node object recorded in the cluster's API, representing that machine's registered identity, capacity, and observed condition. Neither exists as a "node" in the Kubernetes sense without the other: an unregistered machine is not part of the cluster, and a Node object with no corresponding running kubelet quickly becomes stale and unreachable.

Required Components

By definition, a machine only qualifies as a Kubernetes node once it runs a kubelet capable of registering with the control plane, a container runtime satisfying the Container Runtime Interface, and, in the standard networking model, a Container Network Interface plugin providing Pod connectivity. A machine lacking any of these is not a functioning node, regardless of its physical presence in the same network as the cluster.

Node Identity

Registration

A node's identity is established the moment its kubelet successfully registers with the API server, at which point a corresponding Node object is created, recording the node's name, addresses, operating system, architecture, and initial capacity.

apiVersion: v1
kind: Node
metadata:
  name: worker-node-3
status:
  capacity:
    cpu: "8"
    memory: "32Gi"
    pods: "110"
  nodeInfo:
    kubeletVersion: v1.29.2
    containerRuntimeVersion: containerd://1.7.13

Capacity and Allocatable

A node's capacity field records its total resources; its allocatable field records the subset of capacity actually available for scheduling Pods, after subtracting resources reserved for the operating system and Kubernetes system daemons, a distinction that is part of the formal definition of what a node offers to the scheduler.

Node Conditions

Standard Conditions

A node reports a standard set of conditions describing its health: Ready, indicating it is healthy and prepared to accept Pods; MemoryPressure, DiskPressure, and PIDPressure, each indicating the corresponding resource is nearing exhaustion; and NetworkUnavailable, indicating its network is not yet correctly configured.

kubectl get node worker-node-3 -o jsonpath='{.status.conditions}'

Ready vs. NotReady vs. Unknown

A node's Ready condition status of True indicates it is fully healthy; False indicates it is unhealthy but still reachable; and Unknown indicates the control plane has not received a heartbeat within the expected interval, a state from which a node transitions to Pod eviction if it persists beyond a configured grace period.

Scope of Node Responsibility

What a Node Owns

By definition, a node is responsible only for the Pods explicitly scheduled onto it; it has no authority over Pods scheduled elsewhere, and its kubelet reconciles exclusively against the subset of the cluster's desired state that pertains to itself, obtained by watching the API server for Pods bound to its own name.

What a Node Does Not Own

A node does not participate in decisions about which node a Pod should be scheduled to, that responsibility belongs to the scheduler, and it does not persist any authoritative cluster state of its own; all durable state remains in etcd, accessed only through the API server.

Node Taxonomy

Control-Plane Nodes

A control-plane node is a node additionally running one or more control plane components, distinguished in the API through a standard label and often protected from ordinary workload scheduling through a taint, though it remains a node in the same formal sense as any worker.

Worker Nodes

A worker node runs no control plane components and exists solely to host application workloads, representing the majority of nodes in most production clusters and the primary lever by which a cluster's total compute capacity is scaled.

kubectl get nodes -o wide
kubectl label nodes worker-node-3 disktype=ssd
kubectl cordon worker-node-3

Node Lifecycle Boundaries

A node's existence, in the Kubernetes sense, begins at successful registration and ends when its Node object is deleted, whether through explicit removal, automatic garbage collection after prolonged unreachability, or deliberate decommissioning, at which point any Pods still bound to it are considered orphaned and are rescheduled elsewhere by the relevant controllers.