How Linux Runs Kubelet for Container Management

The Linux operating system manages the Kubernetes kubelet as a native host daemon that acts as the primary bridge between the cluster control plane and the node's underlying kernel. Operating typically under the control of an init system like systemd, the kubelet receives pod specifications, delegates container lifecycles to an OCI-compliant runtime via the Container Runtime Interface (CRI), and enforces resource limits by configuring Linux control groups (cgroups) and namespaces. This architecture ensures that workloads execute efficiently, maintain process isolation, and remain within assigned compute and memory boundaries on the host.

Service Initialization via systemd

In modern Linux distributions, the kubelet runs outside of containers directly on the host OS as a native binary managed by systemd. A dedicated unit file (usually located at /etc/systemd/system/kubelet.service or /usr/lib/systemd/system/kubelet.service) defines the execution environment, startup dependencies, and lifecycle policies.

Key interactions managed by systemd include:

• Process Supervision: systemd ensures high availability by automatically restarting the kubelet daemon if it crashes or is terminated.
• Startup Ordering: The service definition enforces that essential networking components, storage mount targets, and the container runtime (such as containerd or CRI-O) are fully initialized before the kubelet begins execution.
• Logging: Kubelet streams standard output and standard error directly to the Linux logging infrastructure, which systemd-journald captures for inspection via journalctl.

Communication with the Container Runtime (CRI)

The kubelet does not directly spawn Linux containers. Instead, it relies on the Container Runtime Interface (CRI) to communicate with a low-level runtime.

The interaction follows a structured path:

1. gRPC over UNIX Domain Sockets: The kubelet connects to runtimes like containerd or CRI-O using a local UNIX domain socket (for example, /run/containerd/containerd.sock).
2. OCI Delegation: The high-level runtime translates the kubelet's CRI instructions into Open Container Initiative (OCI) specifications and invokes a low-level runtime (such as runc or crun).
3. Kernel Primitives: The low-level runtime makes the necessary Linux system calls (clone, unshare, setns, pivot_root) to instantiate the container processes.

Kernel Isolation: Namespaces and cgroups

The primary mechanism by which the host Linux kernel enforces pod boundaries under kubelet guidance is through namespaces and control groups.

• Linux Namespaces: The runtime creates dedicated namespaces per pod or container to provide virtualization of system resources. This includes pid for process isolation, net for independent network stacks and loopback interfaces, mnt for isolated file system mount points, and ipc/uts for shared memory and hostname isolation.
• Control Groups (cgroups): Kubelet manages CPU, memory, and I/O resource allocations using either cgroupfs or the systemd cgroup driver. On modern installations, the systemd driver with cgroups v2 is preferred, providing a unified hierarchy that prevents split-brain resource contention between system services and Kubernetes pods. Kubelet configures distinct hierarchy slices (such as kubepods.slice, burstable.slice, and besteffort.slice) to prioritize resource distribution.

Resource Monitoring and Node-Pressure Eviction

The kubelet constantly inspects host and container resource utilization to protect the Linux host from instability:

• Kernel Filesystem Inspection: By polling /sys/fs/cgroup, /proc/meminfo, and local filesystem mount points, the kubelet tracks memory consumption, CPU saturation, disk usage, and process counts (PIDs).
• Out-of-Memory (OOM) Protection: The kubelet configures the Linux kernel’s oom_score_adj values. Critical host daemons and Kubernetes infrastructure components are given lower scores to protect them from the kernel OOM killer, while BestEffort user containers receive higher scores, making them the first targets for termination when the host runs out of memory.
• Eviction Thresholds: If available host memory or storage falls below predetermined thresholds, the kubelet bypasses standard scheduling and actively evicts pods to prevent node degradation.

Storage and Network Orchestration at the OS Level

To prepare an environment for container execution, the kubelet interacts directly with Linux storage and networking subsystems:

• Network Plumbing: For each pod, the kubelet instructs the runtime to invoke Container Network Interface (CNI) plugins. The plugin constructs virtual ethernet pairs (veth), assigns one end to the host's network namespace, moves the other end into the pod's net namespace, and configures node routing rules via iptables or nftables.
• Filesystem Mounting: The kubelet orchestrates volume attachment by mounting block devices, network shares, or host paths (hostPath) into designated host directories (under /var/lib/kubelet/pods/<pod-id>/volumes/). When the container starts, the runtime bind-mounts these paths into the container's isolated mount namespace.