skip to content

Node Components

7 roadmaps5 questions

Each node runs a kubelet enforcing PodSpecs, a CRI runtime such as containerd, and kube-proxy programming service rules — the machinery that actually starts containers. Interviewers probe it to see where the control plane's job ends and the node's begins.

part ofKubernetesoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What is the kubelet responsible for on a Kubernetes worker node, and what does its pod sync loop actually do?

level: juniorimportance: must knowfreq 70%

answer

  1. node agent: PodSpec -> running containers
  2. 3 pod sources: apiserver watch, manifest dir, HTTP
  3. sync loop: admit, mount, pull, sandbox, init, probes
  4. reports pod status + node conditions + Lease
  5. no scheduling, no replicas, no etcd

basics

~20 s

The kubelet is the node agent. It watches the API server for Pods assigned to its node, tells the container runtime to create the containers described in each PodSpec, mounts volumes, runs probes, and reports Pod and node status back. It manages Pods only, not Deployments or ReplicaSets.

solid answer

~50 s

The kubelet is the per-node agent that makes reality match the PodSpecs assigned to that node. Its loop: it receives Pods from three sources — the API server (a watch filtered by `spec.nodeName`), static-pod manifest files on disk, and an HTTP endpoint — merges them into a desired set, and compares that against what is actually running via the Container Runtime Interface. For each difference it acts: pull images (respecting `imagePullPolicy` and pull secrets), set up volumes, ask the runtime to create the pod sandbox and containers, apply resource limits, run init containers in order, then run liveness/readiness/startup probes and restart containers per `restartPolicy`. It also **reports**: patching Pod status and, for the node, capacity, conditions and a renewed Lease object as a lightweight heartbeat. What it does *not* do: it never creates Pods on its own to satisfy a Deployment, never schedules, and never talks to etcd.

code

bash · 7 lines
bash
systemctl status kubelet
journalctl -u kubelet -f

# the kubelet's own view of running pods
curl -sk https://localhost:10250/pods --cert /var/lib/kubelet/pki/kubelet-client-current.pem

kubectl describe pod web-7d9f   # the Events section is written by the kubelet

go deeper

for a junior

Say clearly that kubelet is the node agent that runs and watches the containers of Pods assigned to its node and reports their status.

for a middle

Describe the sync loop concretely — pod sources, admission, volumes, image pull, sandbox, init containers, probes, status — and the kubelet/controller division of labour.

for a senior

Bring in node-level duties: registration, Lease heartbeats, node-pressure eviction, image and container GC, and how you debug through kubelet events and journal logs.

for a principal

Discuss the kubelet as the trust and blast-radius boundary of a node — what a node may assert about itself, NodeRestriction, port 10250 exposure, and how much autonomy nodes should have when the control plane is unreachable.

## The kubelet's job Every Kubernetes node runs a kubelet. It is the component that turns declarative Pod objects into running containers on that specific machine. It is deliberately narrow: it understands Pods and nothing above them. Deployments, ReplicaSets, StatefulSets and Jobs are controller-manager concerns; by the time the kubelet sees anything, the scheduler has already set `spec.nodeName` and the object is just "a Pod that belongs to me". ## Where Pods come from The kubelet merges three pod sources into one desired state: 1. **The API server** — a watch for Pods whose `spec.nodeName` equals this node. The normal path. 2. **A manifest directory on disk** (commonly `/etc/kubernetes/manifests`) — static pods, run without any control-plane involvement. 3. **An HTTP endpoint** — rarely used. ## The sync loop The kubelet runs a reconciliation loop driven by pod-source updates, periodic resyncs and runtime events. For each pod it computes what is needed to make the node match the PodSpec: - **Admit the pod**: does the node have the resources, do node selectors and taints still hold, are required devices present? A rejected pod ends in phase Failed with a reason such as `OutOfmemory`. - **Set up volumes**: attach and mount via the volume manager and CSI drivers; fetch ConfigMap and Secret contents and project them into files. - **Pull images**: honoring `imagePullPolicy` (`IfNotPresent`, `Always`, `Never`) and image pull secrets. Failures surface as `ErrImagePull` and `ImagePullBackOff`. - **Create the pod sandbox**: the shared network and IPC context for the pod, which is when the CNI plugin is invoked to give the pod its IP. - **Run init containers** sequentially to completion, then start the main containers with their commands, environment, resource requests and limits, and security context. - **Enforce lifecycle**: run startup, liveness and readiness probes; restart failed containers per `restartPolicy` with exponential backoff (the familiar `CrashLoopBackOff`); run preStop hooks and honor `terminationGracePeriodSeconds` on deletion. - **Report status**: update the Pod's `status` (phase, container statuses, conditions, pod IP) through the API server so controllers and Services react. An important consequence: **the kubelet enforces the PodSpec, it does not negotiate with it.** A Pod is effectively immutable in the fields that matter, so "updating" a workload means a controller creates a new Pod and deletes the old one. The kubelet just enforces whatever spec it holds. ## Node-level duties Beyond pods, the kubelet: - **Registers the node** on startup, creating the Node object with capacity, labels and runtime version. - **Heartbeats** by renewing a Lease object in the `kube-node-lease` namespace every few seconds, and updates Node conditions (Ready, MemoryPressure, DiskPressure, PIDPressure) less often. - **Evicts pods under node pressure** when memory or disk cross configured thresholds, choosing victims by QoS class and usage relative to requests. - **Garbage-collects** dead containers and unused images to keep disk usage bounded. - **Serves its own API** on port 10250 for `kubectl logs`, `exec`, `attach` and `port-forward`, and exposes container metrics. ## What it is not Worth stating explicitly in an interview: - The kubelet does **not** schedule. It does not choose which node a pod runs on; it runs what is assigned. - It does **not** manage replicas. Delete a container by hand and the kubelet restarts it because the PodSpec says so; delete the whole Pod and recreating it is the ReplicaSet controller's job. - It does **not** talk to etcd, and it does **not** program Service routing — that is kube-proxy or a CNI dataplane on the same node. - It is normally **not itself a container**: kubelet runs as a host process (usually a systemd unit), which is exactly what lets it bootstrap the rest of the control plane as static pods. ## Diagnosing through the kubelet When a Pod is stuck, the kubelet is where the truth lives: `kubectl describe pod` shows kubelet-written events (image pull failures, mount failures, failed probes, admission rejections), and `journalctl -u kubelet` on the node shows the rest. A node that is NotReady while its Pods still serve traffic usually means the kubelet stopped heartbeating, not that the workloads died.

  • If you stop the kubelet on a node, what happens to the Pods already running there?
    They keep running — the container runtime is a separate process and nothing tells it to stop. What breaks is management: no probes, no restarts, no status updates, and no Lease renewal, so the node goes NotReady after the grace period and the node controller begins evicting its Pods in the API. The containers linger until the kubelet returns and reconciles, or someone cleans them up on the host.
  • A container in a Pod is killed manually on the node with `crictl stop`. Who restarts it, and what if the whole Pod object is deleted instead?
    The kubelet restarts the container, because the PodSpec it holds still says that container should run, subject to restartPolicy and backoff. If the Pod object itself is deleted, the kubelet tears everything down and does not recreate it — creating a replacement replica is the ReplicaSet or other workload controller's job in the control plane.

The kubelet is the site foreman: head office decides which building goes on which lot; the foreman only makes that lot match the blueprint and phones in progress.

saying these in an interview costs you the question

  • Saying the kubelet schedules Pods onto nodes
  • Claiming the kubelet recreates a deleted Pod (that is the workload controller)
  • Saying the kubelet talks to etcd directly
  • Confusing kubelet with kube-proxy and giving it Service routing duties
  • Believing the kubelet manages Deployments or ReplicaSets

context

resolving links…

open as a page

How does a Kubernetes node register itself with the cluster and prove it is still alive, and what would you check when a node shows status NotReady while its workloads are still serving traffic?

level: seniorimportance: must knowfreq 48%

basics

~20 s

On startup the kubelet authenticates (usually a bootstrap token plus a CSR) and creates the Node object with its capacity and labels. It then renews a Lease in the kube-node-lease namespace every ~10s as a heartbeat and updates node conditions less often. NotReady means the kubelet stopped reporting or reported a problem — not that containers died.

open as a page

What is the Container Runtime Interface (CRI) in Kubernetes, and how does the kubelet use it to run containers with containerd?

level: middleimportance: should knowfreq 50%

basics

~20 s

CRI is the gRPC API the kubelet uses to talk to a container runtime over a local socket. The kubelet calls it to pull images and to create pod sandboxes and containers; containerd implements CRI natively and delegates actual container creation to a low-level OCI runtime such as runc.

open as a page

What is kube-proxy's job on a Kubernetes node, and what still works if kube-proxy stops running there?

level: middleimportance: should knowfreq 50%

basics

~20 s

kube-proxy runs on every node (usually as a DaemonSet) and programs the node's kernel so traffic to a Service's virtual IP is redirected to a healthy backend Pod. It is a control agent writing rules, not a data-path proxy: if it stops, existing rules keep working but new Services and endpoint changes stop being applied.

open as a page

What is a static pod in Kubernetes, how does it differ from a Pod created through the API server, and where are static pods actually used?

level: middleimportance: should knowfreq 45%

basics

~20 s

A static pod is defined by a manifest file in a directory the kubelet watches (typically /etc/kubernetes/manifests). The kubelet runs it directly, with no scheduler or controller involved. It creates a read-only mirror Pod in the API so you can see it, but deleting that mirror does not stop it — you must remove the file.

open as a page