Kubernetes Node Runtime Overview

Kubernetes Node Runtime Overview is a summary orientation to how a single machine actually turns a scheduling decision into a running container: the node registers with the cluster, the kubelet watches for Pods assigned to it, and a container runtime, reached through a standardized interface, does the actual work of pulling images and starting isolated processes. This overview exists to connect the individually detailed topics, node identity, the kubelet, the container runtime, into one coherent picture of what happens on a machine once it joins a cluster.

What a Node Contributes

Capacity and Identity

A node contributes two things to a cluster: raw compute capacity, CPU, memory, storage, that the scheduler can allocate against, and a distinct, registered identity through which the control plane tracks its health and current workload assignment.

kubectl get nodes -o wide
kubectl describe node worker-node-3

Joining a Cluster

A node becomes usable the moment its kubelet successfully registers with the API server, at which point it begins reporting capacity and status, becoming eligible for the scheduler to place Pods onto it.

The Kubelet's Role at a Glance

Watching Only Its Own Assignment

The kubelet formally watches for Pods bound to its own node's name, ignoring every Pod scheduled elsewhere, and continuously reconciles the containers actually running against what those Pod specifications describe.

Reporting Back Upward

Beyond starting and stopping containers, the kubelet reports Pod and node status back to the API server, including probe results and resource pressure, the signal every higher-level controller and human operator relies on to know what is actually happening on that machine.

kubectl get pod codartium-api-abc123 -o jsonpath='{.status.containerStatuses}'

The Container Runtime's Role at a Glance

The Component That Actually Creates Containers

Beneath the kubelet, a container runtime, communicating through the Container Runtime Interface, is what actually pulls images, creates isolated namespaces and cgroups, and starts the processes that constitute a running container; the kubelet decides what should run, the runtime is what actually runs it.

crictl ps
crictl images

Runtime Interchangeability

Because this relationship is mediated entirely by the standardized CRI, the specific runtime installed, containerd, CRI-O, is interchangeable from the kubelet's perspective, and a node's choice of runtime has no bearing on how the rest of the cluster addresses or schedules onto it.

Networking and Storage as Node-Local Companions

CNI for Connectivity

Alongside the kubelet and runtime, a CNI plugin runs on every node to allocate Pod IP addresses and attach new Pod sandboxes to the cluster's network fabric, invoked by the kubelet at the moments a Pod is created and removed.

CSI for Storage

Where Pods require persistent storage, a node-local CSI driver component handles staging and mounting volumes into the paths a Pod's containers expect, coordinated by the kubelet as part of a Pod's startup sequence.

kubectl get volumeattachments

The Full Path From Assignment to Running Container

One Coherent Sequence

Put together, the sequence on any single node runs: the kubelet observes a newly bound Pod, requests the CNI plugin set up networking for its sandbox, requests any needed volumes be staged and mounted by the CSI driver, and requests the container runtime pull images and start containers, with probes then continuously assessing the result and status flowing back to the API server throughout.

kubectl get events --field-selector involvedObject.name=codartium-api-abc123 -n codartium-team

Why This Overview Matters

Holding this single sequence, node identity, kubelet observation, CNI, CSI, and CRI each contributing their own narrow piece, in mind is what makes the deeper detail of any individual node-side topic, kubelet internals, runtime architecture, node lifecycle, tractable: each of those subjects is really an elaboration on one step of this same overall path from a scheduling decision to a running, networked, storage-attached container.