Kubelet & Container Runtime Interface (CRI): syncLoop mechanics, Static Pods, and cgroup drivers.

Architecture & Runtime Interface

The kubelet is the primary node agent running as a systemd service on every worker node. It does not manage containers directly; instead, it communicates with the container runtime (e.g. containerd) over a local UNIX domain socket using gRPC via the Container Runtime Interface (CRI).

+-------------------------------------------------------+
| Kubelet                                               |
|   +-----------------------------------------------+   |
|   | syncLoop (Listens to API Server, File, HTTP)  |   |
|   +-----------------------------------------------+   |
|                         |                             |
|                         v gRPC (/run/containerd.sock) |
|   +-----------------------------------------------+   |
|   | CRI: RuntimeService & ImageService            |   |
|   +-----------------------------------------------+   |
+-------------------------|-----------------------------+
                          |
                          v
+-------------------------------------------------------+
| Container Runtime (containerd)                        |
|   -> Pulls images via containerd ImageService         |
|   -> Calls OCI Runtime (runc / crun) to launch Pod    |
+-------------------------------------------------------+

1. The syncLoop Mechanics

The heart of Kubelet is an event loop (syncLoop) that monitors three configuration sources:

1. API Server: Pods assigned to this node.
2. File (Static Pods): Manifests in /etc/kubernetes/manifests/ (used to bootstrap self-hosted control plane components: etcd, api-server, scheduler).
3. HTTP endpoint: Legacy remote manifest polling. When a change occurs, syncLoop computes the difference between the desired state and the observed state and calls CRI methods (RunPodSandbox, CreateContainer, StartContainer).

2. The cgroup Driver Mismatch Bug

A frequent production issue occurs when the host operating system uses systemd as its init system, but Docker/containerd is configured with the cgroupfs driver. Having two cgroup managers leads to split resource accounting and node instability. Standard Fix: Always configure containerd to use the systemd cgroup driver:

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true