# Local Files And Paths Used By The Kubelet

Local Files And Paths Used By The KubeletThe kubelet is mostly a stateless process running on a Kubernetes node. This document outlines files that kubelet reads and writes.Note:This document is for informational purpose and not describing any guaranteed behaviors or APIs. It lists resources used by the kubelet, which is an implementation detail and a subject to change at any release.The kubelet typically uses the control plane as the source of truth on what needs to run on the Node, and the container runtime to retrieve the current state of containers. So long as you provide a kubeconfig (API client configuration) to the kubelet, the kubelet does connect to your control plane; otherwise the node operates in standalone mode.On Linux nodes, the kubelet also relies on reading cgroups and various system files to collect metrics.On Windows nodes, the kubelet collects metrics via a different mechanism that does not rely on paths.There are also a few other files that are used by the kubelet as well, as kubelet communicates using local Unix-domain sockets. Some are sockets that the kubelet listens on, and for other sockets the kubelet discovers them and then connects as a client.Note:This page lists paths as Linux paths, which map to the Windows paths by adding a root disk C:\ in place of / (unless specified otherwise). For example, /var/lib/kubelet/device-plugins maps to C:\var\lib\kubelet\device-plugins.ConfigurationKubelet configuration filesThe path to the kubelet configuration file can be configured using the command line argument --config. The kubelet also supports drop-in configuration files to enhance configuration.CertificatesCertificates and private keys are typically located at /var/lib/kubelet/pki, but can be configured using the --cert-dir kubelet command line argument. Names of certificate files are also configurable.ManifestsManifests for static pods are typically located in /etc/kubernetes/manifests. Location can be configured using the staticPodPath kubelet configuration option.Systemd unit settingsWhen kubelet is running as a systemd unit, some kubelet configuration may be declared in systemd unit settings file. Typically it includes:command line arguments to run kubeletenvironment variables, used by kubelet or configuring golang runtimeStateCheckpoint files for resource managersAll resource managers keep the mapping of Pods to allocated resources in state files. State files are located in the kubelet's base directory, also termed the root directory (but not the same as /, the node root directory). You can configure the base directory for the kubelet using the kubelet command line argument --root-dir.Names of files:memory_manager_state for the Memory Managercpu_manager_state for the CPU Managerdra_manager_state for DRACheckpoint file for device managerDevice manager creates checkpoints in the same directory with socket files: /var/lib/kubelet/device-plugins/. The name of a checkpoint file is kubelet_internal_checkpoint for Device ManagerPod resource checkpointsFEATURE STATE: Kubernetes v1.33 [beta] (enabled by default: true)If a node has enabled the InPlacePodVerticalScalingfeature gate, the kubelet stores a local record of allocated and actuated Pod resources. See Resize CPU and Memory Resources assigned to Containers for more details on how these records are used.Names of files:allocated_pods_state records the resources allocated to each pod running on the nodeactuated_pods_state records the resources that have been accepted by the runtime for each pod pod running on the nodeThe files are located within the kubelet base directory (/var/lib/kubelet by default on Linux; configurable using --root-dir).Container runtimeKubelet communicates with the container runtime using socket configured via the configuration parameters:containerRuntimeEndpoint for runtime operationsimageServiceEndpoint for image management operationsThe actual values of those endpoints depend on the container runtime being used.Device pluginsThe kubelet exposes a socket at the path /var/lib/kubelet/device-plugins/kubelet.sock for various Device Plugins to register.When a device plugin registers itself, it provides its socket path for the kubelet to connect.The device plugin socket should be in the directory device-plugins within the kubelet base directory. On a typical Linux node, this means /var/lib/kubelet/device-plugins.Pod resources APIPod Resources API will be exposed at the path /var/lib/kubelet/pod-resources.DRA, CSI, and Device pluginsThe kubelet looks for socket files created by device plugins managed via DRA, device manager, or storage plugins, and then attempts to connect to these sockets. The directory that the kubelet looks in is plugins_registry within the kubelet base directory, so on a typical Linux node this means /var/lib/kubelet/plugins_registry.Note, for the device plugins there are two alternative registration mechanisms Only one should be used for a given plugin.The types of plugins that can place socket files into that directory are:CSI pluginsDRA pluginsDevice Manager plugins(typically /var/lib/kubelet/plugins_registry).Graceful node shutdownFEATURE STATE: Kubernetes v1.21 [beta] (enabled by default: true)Graceful node shutdown stores state locally at /var/lib/kubelet/graceful_node_shutdown_state.Image Pull RecordsFEATURE STATE: Kubernetes v1.33 [alpha] (enabled by default: false)The kubelet stores records of attempted and successful image pulls, and uses it to verify that the image was previously successfully pulled with the same credentials.These records are cached as files in the image_registry directory within the kubelet base directory. On a typical Linux node, this means /var/lib/kubelet/image_manager. There are two subdirectories to image_manager:pulling - stores records about images the Kubelet is attempting to pull.pulled - stores records about images that were successfully pulled by the Kubelet, along with metadata about the credentials used for the pulls.See Ensure Image Pull Credential Verification for details.Security profiles & configurationSeccompSeccomp profile files referenced from Pods should be placed in /var/lib/kubelet/seccomp. See the seccomp reference for details.AppArmorThe kubelet does not load or refer to AppArmor profiles by a Kubernetes-specific path. AppArmor profiles are loaded via the node operating system rather then referenced by their path.LockingFEATURE STATE: Kubernetes v1.2 [alpha]A lock file for the kubelet; typically /var/run/kubelet.lock. The kubelet uses this to ensure that two different kubelets don't try to run in conflict with each other. You can configure the path to the lock file using the the --lock-file kubelet command line argument.If two kubelets on the same node use a different value for the lock file path, they will not be able to detect a conflict when both are running.What's nextLearn about the kubelet command line arguments.Review the Kubelet Configuration (v1beta1) reference