4 Kubernetes Nodes and Runtime

Kubernetes Nodes and Runtime is the layer of a Kubernetes cluster responsible for actually executing containerized workloads, encompassing the worker machines themselves and the software stack that pulls container images, starts and stops containers, and enforces the resource boundaries assigned to them.

What a Node Is

Physical or Virtual Machines

A node is any machine, physical or virtual, that has been registered with the cluster and has the necessary agents installed to receive and run workloads. Nodes contribute their CPU, memory, and storage capacity to the cluster's shared resource pool.

Node Types

Clusters commonly distinguish between control-plane nodes, which run control plane components, and worker nodes, which run application workloads exclusively. Some smaller or development clusters combine both roles on the same machines.

The kubelet Agent

Responsibilities

The kubelet runs on every node and is the primary point of contact between the control plane and that node. It reads the Pod specifications assigned to its node, ensures the described containers are created and kept running, and reports the node's and Pods' status back to the API server.

Health Reporting

The kubelet periodically sends heartbeats and status updates to the control plane. If these updates stop arriving within a configured threshold, the control plane marks the node as unhealthy and may begin rescheduling its workloads elsewhere.

Container Runtime Interface

Why an Interface Exists

Kubernetes does not implement container execution itself. Instead, it defines the Container Runtime Interface (CRI), a standardized API that any compliant container runtime can implement, allowing Kubernetes to remain agnostic to the specific technology used to run containers.

Common Runtimes

containerd and CRI-O are widely used CRI-compliant runtimes. Each is responsible for pulling container images from registries, unpacking image layers, creating the isolated execution environment for a container using operating system primitives such as namespaces and cgroups, and managing the container's lifecycle.

Resource Isolation Mechanisms

Namespaces and cgroups

At the operating system level, container isolation on Linux nodes relies on kernel namespaces, which isolate what a process can see, and control groups (cgroups), which limit and account for the resources a process can consume.

Requests and Limits

Kubernetes allows Pod specifications to declare resource requests, the amount reserved for scheduling purposes, and resource limits, the maximum a container is allowed to consume before being throttled or terminated.

Networking on the Node

Pod Network Namespace

Each Pod on a node is assigned its own network namespace and IP address, shared by all containers within that Pod. The Container Network Interface (CNI) plugin installed on the node is responsible for wiring this namespace into the broader cluster network.

kube-proxy

kube-proxy runs on every node and maintains the network rules that implement Service abstractions, translating a stable virtual IP into the current set of healthy Pod IPs behind it.

Node Lifecycle Diagram

Node Maintenance and Draining

Operators can mark a node as unschedulable and drain its running Pods before performing maintenance, such as upgrading the runtime or kernel. Draining evicts Pods gracefully, allowing controllers to reschedule them onto other available nodes, which minimizes disruption to running applications during planned maintenance windows.