Updated 2 November 2026 · Published by Zoorik
The kubelet is the primary node agent that runs on each Kubernetes node. It makes sure the containers in each pod spec, the YAML or JSON that describes a pod, are running and healthy.
It takes pod specs mainly from the API server. It doesn’t manage containers that Kubernetes didn’t create.
What the kubelet does on each node
- Registers its node with the API server. That’s the default, and the pattern most distributions use.
- Runs each container’s probes: startup, liveness and readiness. They decide when it has started, when to restart it and when it can take traffic.
- Sends its node’s heartbeats: status updates, and a Lease in the
kube-node-leasenamespace. If they stop, the control plane marks the node Unknown. By default, it starts evicting the node’s pods 5 minutes later. - Caps how many pods its node can run through its max pods setting, which defaults to 110.
- Serves the CPU and memory use of its node and its pods at
/metrics/resource. Metrics Server collects them from each kubelet.
How the kubelet reserves node capacity
By default, pods can use a node’s whole capacity. The kubelet’s Node Allocatable feature reserves CPU, memory and ephemeral storage for system daemons. Kube-reserved covers the kubelet and the container runtime, and system-reserved covers OS daemons.
Allocatable, what pods can use, is capacity minus those two reserves and, for memory and storage, the hard eviction threshold. The Kubernetes docs’ example node, with 16 CPUs and 32Gi of memory, leaves pods 14.5 CPUs and 28.5Gi.
AKS sets CPU and memory reserves on every node for you, so a node’s allocatable is less than its total.
How the kubelet evicts pods under node pressure
The kubelet watches memory, disk space, filesystem inodes and process IDs on its node. When one crosses a threshold, it first frees node resources, such as unused container images. Then it evicts pods, ignoring PodDisruptionBudgets and, on a hard threshold, any grace period.
- The default hard thresholds on Linux nodes are
memory.available<100Mi,nodefs.available<10%,imagefs.available<15%,nodefs.inodesFree<5%andimagefs.inodesFree<5%. - BestEffort and Burstable pods that use more than they request go first, by priority, then by how far over they are. Guaranteed pods, and Burstable pods under their requests, go last.
Why the kubelet matters for your cloud cost
The kubelet’s reserves come off every node you pay for. The scheduler fills only what’s left, by pod requests.
- A pod that uses more than it requests is first in line when the kubelet evicts. Requests far above use fill nodes on paper while their CPU and memory sit mostly idle.
- Coral rebalances CPU and memory requests on AKS and EKS to match real use, and drains spare nodes so your autoscaler can remove them.
- The free assessment works out your own figure.
Read next: Kubernetes allocatable vs capacity: what pods can use
Sources: Kubernetes, “kubelet” (opens in a new tab); Kubernetes, “Nodes” (opens in a new tab); Kubernetes, “Liveness, Readiness, and Startup Probes” (opens in a new tab); Kubernetes, “Resource metrics pipeline” (opens in a new tab); Kubernetes, “Reserve Compute Resources for System Daemons” (opens in a new tab); Kubernetes, “Node-pressure Eviction” (opens in a new tab); Kubernetes, “Resource Management for Pods and Containers” (opens in a new tab); Microsoft Learn, “Azure Kubernetes Service (AKS) Core Concepts” (opens in a new tab).