What Is the Kubelet in Kubernetes?
Every computer in a Kubernetes cluster runs a small, tireless helper called the kubelet. This guide explains, from zero, what it is, what it does, how it talks to containers, and why almost nothing in Kubernetes works without it.
Picture a large hotel chain. At head office, managers decide that room 204 in the Paris hotel needs fresh towels, and that the Tokyo hotel should open two extra rooms for a conference. But head office cannot walk into any hotel and change a single towel. In every hotel, a local floor supervisor receives the instructions, checks what is really happening on the floor, does the work, and reports back: “Towels delivered. Two rooms ready.”
Kubernetes works in almost the same way. The brain of the cluster sits in one place and makes plans, but the real work of starting and watching programs happens on each individual computer. The floor supervisor on every computer is called the kubelet. This article will walk you through it slowly, in plain words, with everyday pictures to help each idea stick.
1The Problem the Kubelet Solves
A plan is useless until someone on the ground carries it out.
Kubernetes is a system that runs your programs, packed inside containers, across a group of computers. You write down what you want, for example “run three copies of my shopping program”, and Kubernetes makes it happen. The part that makes the decisions is called the control plane. It knows the plan, but it does not sit inside each computer.
That creates a gap. Someone must be present on each computer to actually start the containers, keep an eye on them, restart them when they crash, and tell the control plane what is going on. Without that someone, plans would stay on paper, and the control plane would be guessing about a world it cannot see.
Think of a school principal who writes the timetable for a hundred classrooms. The principal cannot stand in every room. Each classroom needs a teacher who reads the timetable, teaches the lesson, notices when a child feels unwell, and reports to the office. The kubelet is that teacher, one in every classroom.
The kubelet is the answer to the question, “Who does the work on each machine?” Once you hold on to that single sentence, everything else in this guide is just detail.
2So, What Exactly Is the Kubelet?
The short version: the node agent that makes sure containers match the plan.
The kubelet is a small program that runs on every node in a Kubernetes cluster. A node is simply one computer in the cluster, either a physical machine or a virtual one. The kubelet is called a node agent, which is a fancy phrase for “the representative of the cluster living on this particular computer”.
Its central job can be stated in one sentence: it makes sure that the containers described in the Pods assigned to its node are running and healthy. A Pod, if you are new to the word, is the smallest unit Kubernetes manages, a wrapper around one or more containers that live and die together.
Imagine a restaurant chain where head office sends each kitchen a list of dishes to prepare. The head chef in each kitchen reads the list, checks whether the ingredients and stoves are available, cooks the dishes, and phones head office if the oven breaks. The kubelet is that head chef, and the Pods are the dishes on the list.
What the kubelet is not
Beginners often confuse the kubelet with other parts of the system, so it helps to draw clear borders. The kubelet is not the scheduler, because it does not choose which node a Pod goes to. It is not the container runtime, because it does not itself create containers; it asks the runtime to do so. It is not the network proxy, which is a different helper that handles service traffic. And it does not manage containers that were not created through Kubernetes.
The kubelet does not run inside a container like your applications. On most clusters it runs directly on the computer as an ordinary background service, because it must be alive before any containers exist.
3Where the Kubelet Sits in the Cluster
A Kubernetes cluster has a thinking half and a working half, and the kubelet lives in the working half.
Every Kubernetes cluster is divided into two groups of computers. The control plane is the thinking half. It contains the API server, which is the front door of the cluster; a state store that remembers everything; the scheduler, which picks a node for each new Pod; and the controllers, which keep comparing reality with your goals. The worker nodes are the working half, where your applications actually run.
On each worker node there are three main helpers. The kubelet is the manager. The container runtime is the engine that actually starts and stops containers. The network proxy handles traffic rules for services. The kubelet talks to the control plane on one side and the container runtime on the other, acting as the bridge between the two worlds.
flowchart TD
API["API server: the front door of the cluster"] --> SCH["Scheduler: picks a node for each Pod"]
API --> CTRL["Controllers: compare goals with reality"]
API --> STORE[("State store: the memory")]
API KL1["Kubelet on Node 1"]
API KL2["Kubelet on Node 2"]
KL1 --> RT1["Container runtime on Node 1"]
KL2 --> RT2["Container runtime on Node 2"]
RT1 --> C1["Containers of Pods"]
RT2 --> C2["Containers of Pods"]
Think of a shipping company. Head office plans routes. In each port, a harbour master receives the orders, directs the cranes that load and unload the ships, and reports progress back. Head office is the control plane, the cranes are the container runtime, and the harbour master is the kubelet.
Notice that the kubelet is the one that reaches out to the API server, not the other way around. Each kubelet keeps a connection open and watches for changes, which keeps the design simple and scalable.
4The Kubelet’s Main Responsibilities
Eight jobs that fill a kubelet’s day.
Although the kubelet feels like one program, it wears many hats. Here they are in simple language, each with a picture from daily life.
Register the node
Introduces its computer to the cluster, like a new employee signing in at reception on the first day.
Receive Pod instructions
Learns which Pods should run on its node, like reading the day’s task list pinned on the wall.
Start and stop containers
Asks the container runtime to create or remove containers, like a supervisor telling a crane operator which box to lift.
Check health
Runs regular checks on containers, like a nurse taking pulse and temperature on every round.
Manage resources
Makes sure containers get the memory and processing power promised to them and no more, like a landlord enforcing fair use of the electricity.
Prepare storage and settings
Mounts volumes and delivers settings and secrets to each Pod, like setting a table before guests arrive.
Protect the node
Evicts Pods and cleans up old files when the computer runs short of resources, like a lifeguard clearing an overcrowded pool.
Report back
Sends regular status and heartbeats to the control plane, like a soldier radioing headquarters every hour.
The following chapters open each of these jobs in turn. First, we need a handful of words that make the rest easy to read.
5Vocabulary You Need First
Ten simple terms that unlock every kubelet conversation.
Every technology has its own words. These ten come up again and again when people talk about the kubelet, so it is worth meeting them now.
Node
One computer in the cluster. Every node that runs applications has its own kubelet.
Pod
The smallest thing Kubernetes runs: one or more containers sharing a home, like flatmates who share one address.
PodSpec
The written description of a Pod: which containers, which settings, how much memory. It is the recipe the kubelet follows.
Container runtime
The engine that actually creates and runs containers on a node. Common examples are containerd and CRI-O.
CRI
The Container Runtime Interface: a standard language the kubelet uses to talk to any compatible runtime, like a universal plug socket.
Probe
A small health check the kubelet performs on a container to see whether it is alive or ready.
Static Pod
A Pod managed directly by the kubelet from a file on the node, without asking the control plane.
cgroup
A feature of the operating system that limits how much memory and processing power a group of programs may use.
Eviction
The kubelet removing a Pod from a node to protect the node when it is running out of resources.
Heartbeat
A regular “I am alive” message from the kubelet to the control plane, so the cluster knows the node is healthy.
If you remember only two words, keep PodSpec and container runtime. The kubelet reads the first and instructs the second. That is its whole story in a nutshell.
6How the Kubelet Learns What to Do
Instructions can arrive from more than one place.
The kubelet cannot act until it knows which Pods belong on its node. It gets this knowledge through what are called Pod sources. In practice there are three, although one of them is used far more than the others.
Source 1: the API server
This is the normal route. When you ask Kubernetes to run something, the scheduler picks a node and records that choice on the Pod. Each kubelet keeps a watch on the API server, asking only for Pods assigned to its own node. The moment a new one appears, the kubelet hears about it, without having to keep asking over and over.
Source 2: files on the node
The kubelet can also be told to watch a folder on its own computer. Any Pod description dropped into that folder is started by the kubelet directly, and removed when the file disappears. These are the static Pods we will meet later.
Source 3: a web address
Less common today, the kubelet can be pointed at a web address that serves Pod descriptions. It checks the address regularly for changes. Few clusters rely on this route, but it exists for special setups.
| Source | How it works | Typical use |
|---|---|---|
| API server | Kubelet watches for Pods assigned to its node | Almost all normal application Pods |
| Files on the node | Kubelet watches a local folder | Control plane components on some clusters |
| Web address | Kubelet checks a URL regularly | Rare special setups |
A waiter normally takes orders from the central kitchen screen. But some restaurants also keep a handwritten notice on the wall for permanent daily specials, and a few check a shared website for catering orders. All three end up in the same place: the waiter’s list of things to serve.
7The Kubelet’s Inner Loop
The same compare-and-correct idea that powers Kubernetes also powers the kubelet.
Inside the kubelet runs a loop that never ends. It looks at what the plan says should be running on this node, looks at what is actually running, and if the two differ, it takes action to close the gap. Then it looks again. This is often called the sync loop, and it is the beating heart of the kubelet.
A home thermostat works this way. You set twenty-two degrees. The thermostat measures the room, switches the heater on if it is cold, and switches it off if it is warm. It does not know why the room changed, and it does not need to. It only cares about the gap between wanted and actual.
Watching for changes in the real world
The kubelet needs to notice when something happens to a container, such as a crash. To do this efficiently, it uses a helper that keeps checking the runtime and produces simple events, like “container started” or “container died”. Those events wake up the sync loop for the affected Pod, so the kubelet reacts in moments instead of waiting for the next big round of checks.
sequenceDiagram
participant You
participant API as API server
participant KL as Kubelet
participant RT as Container runtime
You->>API: Run 1 copy of my app
API-->>KL: A new Pod is assigned to your node
KL->>RT: Prepare a sandbox and pull the image
KL->>RT: Start the containers
RT-->>KL: Containers are running
KL-->>API: Pod status: Running
Note over RT: A container crashes
RT-->>KL: Container exited
KL->>RT: Start it again
KL-->>API: Pod status updated
Because the loop only cares about the gap, one simple mechanism handles many different surprises: crashes, deleted containers, restarts of the computer, and changes to the plan.
8The Life of a Pod Through the Kubelet’s Eyes
Follow one Pod from arrival to departure.
Let us watch what the kubelet does when a brand-new Pod is assigned to its node. Seeing the full journey once turns many abstract words into a clear story.
The Pod is noticed
The kubelet hears from the API server that a new Pod has been assigned to its node and reads the PodSpec.
The kubelet checks that the Pod fits
It confirms that the node truly has enough resources and meets the Pod’s requirements. If not, the Pod is turned away with a clear reason.
The Pod’s environment is prepared
The kubelet creates the resource limits for the Pod, prepares its storage volumes, and gathers the settings and secrets it needs.
The runtime builds the sandbox
The kubelet asks the container runtime to create the Pod’s shared space, including its network identity, so all its containers can live together.
Images are pulled and containers start
Any missing container packages are downloaded, then the containers are created and started in the order the Pod requires, with any preparation containers going first.
Health checks take over
Once containers run, the kubelet starts its probes and reports the Pod’s status to the control plane as it changes.
Shutdown happens gracefully
When the Pod is deleted, the kubelet politely asks containers to stop, waits for a grace period, and only then forces them to end. It then cleans up storage and network leftovers.
The states a Pod can be in
As the Pod moves through this journey, its overall phase changes. It starts as Pending while images download and containers get ready. It becomes Running once at least one container is up. It ends as Succeeded if all containers finished their task cleanly, or Failed if they ended with an error. Occasionally the status becomes Unknown, usually because the node stopped reporting.
When a container keeps crashing, the kubelet waits longer between each restart attempt, up to a limit of a few minutes. You will see the label CrashLoopBackOff. It means the kubelet is being patient, not that it has given up.
9Talking to the Container Runtime, Network and Storage
The kubelet is a manager, so it depends on specialists.
The kubelet does not know how to build a container by itself, and it does not know how to configure every kind of network or disk. Instead, it speaks standard languages to specialists. This is a clever design, because you can swap any specialist without changing the kubelet.
CRI: Container Runtime Interface
The kubelet uses it to ask a runtime such as containerd or CRI-O to pull images, create sandboxes and start or stop containers.
CNI: Container Network Interface
A network plugin gives each Pod its address and connects it to the cluster network. In modern setups the runtime calls the plugin on the kubelet’s behalf.
CSI: Container Storage Interface
A storage plugin attaches and prepares disks from many vendors so the kubelet can mount them into Pods.
Device plugins
Special hardware, such as graphics cards, announces itself to the kubelet so Pods can request it like any other resource.
A building manager does not personally fix lifts, wire electricity or lay plumbing. Instead, the manager calls a lift company, an electrician and a plumber, each speaking the trade’s standard language. Change the electrician, and the manager’s job stays the same. That is how the kubelet treats runtimes, networks and storage.
Kubernetes used to include built-in support for one particular container engine inside the kubelet. That special support was removed in favour of the standard interface, so any runtime that speaks CRI can be used. This made the kubelet simpler and the ecosystem more open.
10Health Checks: The Kubelet as a Doctor
Running is not the same as working.
A container can be technically running yet completely stuck, like a person who is awake but frozen in confusion. To detect this, the kubelet performs probes. A probe is a small, regular question or test it directs at a container. The Pod’s description says what to ask, how often, and how many failures are acceptable.
The three kinds of probe
Liveness probe: “Are you alive?”
If this check keeps failing, the kubelet restarts the container. It rescues programs that are stuck in a state they cannot escape by themselves, such as a frozen loop.
Readiness probe: “Are you ready for visitors?”
If this check fails, the container is not restarted. Instead, the Pod is quietly removed from the list of targets receiving traffic until it recovers. It suits programs that are warming up or temporarily busy.
Startup probe: “Have you finished waking up?”
Slow programs get extra time to start. Until this check succeeds, the other two are paused, which stops the kubelet from killing an application that is simply still loading.
How a probe can ask
The kubelet can ask in several ways: by sending a web request and looking for a healthy reply, by trying to open a network connection to a port, by running a small command inside the container and checking its result, or by using a standard health-checking call for programs that support it.
A nurse on ward rounds asks three different questions. “Can you hear me?” is like liveness. “Are you well enough to see visitors?” is like readiness. And after an operation, “Give it time, you are still waking up” is like the startup check. Each question triggers a different action.
Making a liveness check depend on another service, such as a database, is dangerous. If the database slows down, every container fails its check, gets restarted, and a small problem becomes a large outage. Liveness should only look at the container itself.
11Managing Resources: Requests, Limits and Priorities
The kubelet is the fair-play referee on every computer.
A single node is shared by many Pods. Without rules, one greedy Pod could eat all the memory and starve its neighbours. Kubernetes uses two ideas to prevent this. A request is the amount of resource a container asks to be guaranteed, and it is what the scheduler uses for planning. A limit is the maximum the container is allowed to use, and it is enforced on the node.
The kubelet is the one that turns these numbers into real enforcement. It works with a feature of the operating system called cgroups, which put a fence around each container so that memory and processing use stay within bounds. If a container exceeds its memory limit, it is stopped. If it exceeds its processing limit, it is slowed down rather than stopped.
Consider a shared flat with one electricity meter. The agreement says each flatmate is guaranteed a basic amount of power and may borrow more when others are not using it, but never beyond a fixed ceiling. The landlord who enforces the rules is the kubelet.
Three quality classes
Depending on how requests and limits are set, the kubelet assigns each Pod a quality-of-service class. These classes decide who is protected and who is removed first when trouble comes.
| Class | How it is set | Treatment under pressure |
|---|---|---|
| Guaranteed | Requests equal limits for every container | Most protected; removed last |
| Burstable | Some request set, but lower than the limit or partly missing | Middle priority |
| BestEffort | No requests or limits at all | Least protected; removed first |
Not all of the computer is for Pods
The computer also needs memory and processing power for the operating system and for Kubernetes itself, including the kubelet. So the kubelet computes an allocatable amount: the total capacity minus what is set aside for the system and for eviction safety margins. Only the allocatable amount is offered to Pods, which prevents the node from being run into the ground.
12Node Pressure and Eviction
When a computer runs short, the kubelet acts before it collapses.
Nodes can run short of memory, disk space, or the number of processes they can hold. If nothing were done, the whole computer could freeze, taking every Pod with it. The kubelet watches these levels and compares them with thresholds. When a threshold is crossed, the node reports a pressure condition, and the kubelet begins to free resources.
What the kubelet does first
Before removing any Pods, the kubelet tries gentler steps, such as deleting unused container images and dead containers to reclaim disk space. Only if that is not enough does it start evicting Pods.
Who is evicted first
The kubelet ranks Pods using the quality class and how far each one is exceeding what it requested. Pods using far more than they asked for, and those in the least protected class, go first. The evicted Pod is stopped, and the control plane creates a replacement elsewhere, if the Pod belongs to a managed group.
Measure
The kubelet continuously reads memory, disk and process levels on the node.
Warn
When a threshold is crossed, the node advertises a pressure condition so the scheduler stops sending new Pods there.
Clean
Unused images and finished containers are deleted to win space back.
Evict
If pressure remains, the kubelet removes the least protected, most greedy Pods until the node is healthy again.
A lifeboat that is too full will sink. The captain first throws overboard the spare cargo, and only then, if the boat is still too heavy, asks the passengers with the least essential seats to move to another boat. The captain is not being cruel; the decision protects everyone else.
Pods with no resource settings are the first to be evicted, so leaving them blank is a hidden risk. Setting sensible requests protects your Pods and also helps the scheduler place them wisely.
13Registering the Node and Sending Heartbeats
The control plane only trusts what the kubelet reports.
When a kubelet starts for the first time, it introduces its computer to the cluster. This is called node registration. The kubelet tells the API server the node’s name, its capacity, its operating system, and labels describing it. From then on, the cluster knows this computer exists and may send Pods to it.
Two ways of saying “I am alive”
The kubelet sends two kinds of signals. The first is a status update, a detailed report covering things like available memory, disk, and the readiness of the node. It is sent when something changes and otherwise at slower regular intervals. The second is a lightweight lease: a tiny record that the kubelet renews every few seconds. Because it is so small, thousands of nodes can send it without overloading the control plane.
flowchart LR
KL["Kubelet on a node"] -- "small lease renewed every few seconds" --> API["API server"]
KL -- "detailed status when things change" --> API
API --> NC["Node controller"]
NC -- "no heartbeat for too long" --> UN["Node marked Unknown"]
UN --> REP["Pods are replaced on healthy nodes"]
What happens when heartbeats stop
If the node controller in the control plane stops hearing from a kubelet for longer than a grace period, it marks the node as Unknown or NotReady. After a further waiting time, Pods on that node are marked for removal, and their managers create replacements on healthy nodes. This is how Kubernetes recovers from a computer that has died or become unreachable.
Think of a mountain expedition that checks in with base camp every hour. A quick “all well” call is the lease. A full written report each evening is the status update. If the calls stop for too long, base camp assumes trouble and sends help by another route.
14Volumes, Secrets and Configuration
The kubelet sets the table before the meal begins.
Programs need more than a container package. They need storage, settings and sometimes passwords. The kubelet prepares all of these on the node before the containers start, so that everything is in place when the program wakes up.
Volumes
A volume is a folder made available to the containers of a Pod. It might be temporary space that disappears with the Pod, a folder shared between containers, or lasting storage from a network disk. The kubelet works with storage plugins to attach the disk to the node, prepare it, and mount it into the right place inside each container.
Settings and secrets
Ordinary settings and sensitive items such as passwords can be delivered to a Pod as files or as environment values. The kubelet fetches them from the control plane and places them where the containers expect. For secrets, the kubelet keeps the content in memory-backed storage on the node rather than writing it to the disk, which reduces the chance of leaks.
Before a school exam, a helper lays out pens, papers and a clock on every desk, and hands each student only their own envelope of confidential information. The helper is the kubelet, and the desks are the Pods.
| Item | What the kubelet does | Result for the container |
|---|---|---|
| Temporary volume | Creates a folder on the node | Scratch space that disappears with the Pod |
| Persistent volume | Works with the storage plugin to attach and mount a disk | Data survives Pod replacement |
| Configuration | Fetches and places settings | Program reads its settings at startup |
| Secret | Fetches and stores in memory-backed space | Program receives credentials safely |
If a volume cannot be attached or a required secret is missing, the kubelet cannot start the Pod. That is why a Pod can sit in a waiting state with a message about storage or settings even though its container package is perfectly fine.
15Static Pods and Bootstrapping the Cluster
Who starts the manager if the manager is itself a program?
Here is a classic puzzle. The control plane is made of programs, and Kubernetes is very good at running programs in containers. But Kubernetes cannot start until its control plane runs, and the control plane cannot run until Kubernetes starts them. Which comes first?
The kubelet solves this with static Pods. A static Pod is described in a file placed in a special folder on the node. The kubelet, which runs as an ordinary service, watches that folder and starts whatever it finds there, without needing the API server. Many clusters start their control plane components this way. The kubelet even tries to create a read-only mirror of the Pod in the API server so that you can see it, though the kubelet remains its real owner.
Imagine building a city. Before the city council exists, a caretaker with a list in their pocket opens the town hall doors, switches on the lights, and puts up the sign. Once the council arrives, it can run everything else. The kubelet is the caretaker, and the static Pod files are the list in the pocket.
Differences from ordinary Pods
Advantages
- Works even when the control plane is not available yet
- Simple: the file is the single source of truth
- Started and restarted automatically by the kubelet
- Ideal for control plane components on a self-run cluster
Disadvantages / Trade-offs
- Bound to one specific node
- Cannot be managed by the usual deployment tools
- Changes require editing files on the node itself
- No automatic scaling or rescheduling elsewhere
16Security Around the Kubelet
A helper with this much power must be carefully guarded.
The kubelet can start containers and read secrets on its node, and it offers a small web interface of its own for tasks such as fetching logs or running commands in a container. If an attacker reached that interface without proper checks, they could take control of the node. Securing the kubelet is therefore a basic part of securing a cluster.
Authentication
Every caller of the kubelet must prove who they are, by certificate or token. Anonymous access should be turned off.
Authorization
After identity is known, the kubelet asks the control plane whether the caller is allowed to do the requested action.
Encrypted connections
Traffic to and from the kubelet is protected with certificates, and these certificates can be renewed automatically.
Restricted network access
Firewalls should allow only the control plane and trusted tools to reach the kubelet’s port, never the open internet.
Limited node identity
A kubelet is only permitted to see and change objects related to its own node, so a compromised node cannot roam freely across the cluster.
Hardened Pods
Running containers with minimal privileges and sensible security settings reduces what can go wrong on the node itself.
Consider the floor supervisor’s master key in a hotel. It opens many doors, so it must be issued only to verified staff, must only work on that floor, and must be tracked. Nobody hands such keys to passers-by in the street.
Exposing the kubelet’s management port to the public internet, or allowing anonymous requests, has led to real cluster takeovers. Treat that port like the door to the vault.
17Monitoring, Logging and Metrics
The kubelet is both a source of truth and something to watch.
The kubelet sits closest to the containers, so it is a natural place to collect information about them. It has a built-in component that measures how much processor, memory, disk and network each container uses. Monitoring tools can gather these measurements from the kubelet to draw graphs and raise alerts.
Metrics
Numbers over time such as memory use and restarts. The kubelet exposes both node-level and Pod-level numbers.
Logs
The kubelet serves container logs from its node, and it also writes its own diary of decisions, which is priceless when debugging.
Events
Short messages about what happened to a Pod, such as image pulled, container started, probe failed or Pod evicted.
What to watch first
Beginners can start small: how many nodes are Ready, how often containers restart, how full the memory and disks are, and how long Pods take to start. If Pods take unusually long to start, or nodes flip between Ready and NotReady, a kubelet or its runtime is often the first suspect.
A ship’s log records what the crew did. The instrument panel shows live readings. The alarm bell rings when something is wrong. Together they help the captain understand the ship. Metrics, logs and events do the same for a node.
Kubernetes events are kept for a short time only. If you are investigating a problem, look early, or send events to a longer-term store so the clues are not lost.
18Reading the Signs: Common Problems and What They Mean
Most Pod troubles are the kubelet honestly reporting what it sees.
When something goes wrong, the status shown for a Pod is usually the kubelet’s report. Learning to read these words turns a confusing screen into a clear clue.
| What you see | Plain meaning | Common causes |
|---|---|---|
| ImagePullBackOff | The container package could not be downloaded, and the kubelet is retrying slowly | Wrong name, missing permission, registry unreachable |
| CrashLoopBackOff | The container starts, then keeps failing, and the kubelet waits longer between attempts | Bug in the program, missing settings, failing checks |
| OOMKilled | The container used more memory than its limit and was stopped | Limit set too low, memory leak |
| ContainerCreating for a long time | The kubelet cannot finish preparing the Pod | Storage cannot attach, network plugin trouble, missing secret |
| Evicted | The kubelet removed the Pod to protect the node | Memory or disk pressure |
| Node NotReady | The kubelet is not reporting healthy | Kubelet stopped, runtime broken, network split, resource exhaustion |
Think of a warning light on a car dashboard. The light is not the problem; it is the car reporting a problem. Reading the kubelet’s status words is like reading the dashboard: it tells you where to look next.
Start with the Pod’s events, then the container’s logs, then the node’s condition, and only then the kubelet’s own diary. Working from the outside inwards saves a lot of time.
19Advantages and Trade-offs of the Kubelet Design
A node agent is a smart design choice, with a few costs.
Placing a small agent on each node, rather than commanding nodes remotely from the centre, shapes how Kubernetes behaves. It brings strengths and some responsibilities.
Advantages
- Each node works independently, so a control plane outage does not immediately stop running containers
- The design scales to thousands of nodes because work is spread across many small agents
- Standard interfaces allow runtimes, networks and storage to be swapped freely
- Local decisions, such as eviction, happen quickly without waiting for the centre
- The same agent works on laptops, data centres and any cloud
Disadvantages / Trade-offs
- Another program to install, secure, configure and upgrade on every node
- A misconfigured kubelet can make an entire node unreliable
- Version differences between kubelet and control plane must stay within supported limits
- Debugging often requires access to the node itself
- Its power makes it an attractive target for attackers
Cloud providers’ managed Kubernetes services handle much of the kubelet’s installation, certificates and upgrades. That removes a good deal of the operational burden for beginners and small teams.
20Patterns to Follow and Anti-patterns to Avoid
Lessons other teams have already paid for.
Helpful patterns
Always give Pods realistic resource settings
Accurate requests and limits let the scheduler place Pods sensibly and let the kubelet protect them during pressure.
Use all three probes with intention
A startup probe for slow programs, a readiness probe for traffic control, and a simple liveness probe for true freezes give the kubelet the right signals.
Reserve capacity for the system
Setting aside memory and processing power for the operating system and Kubernetes components keeps the node stable when Pods get busy.
Upgrade nodes gradually
Drain a node so its Pods move elsewhere, upgrade it, bring it back, and move on to the next. The cluster stays available throughout.
Anti-patterns
Problem
Running important workloads with no resource requests or limits.
Why It’s Harmful
These Pods land in the least protected class, are the first to be evicted, and can starve their neighbours on a busy node.
Correct Approach
Set requests based on measured usage, and set limits thoughtfully so one Pod cannot harm the rest.
Problem
Fixing problems by logging into a node and changing containers or kubelet settings by hand.
Why It’s Harmful
The change is invisible to others, can be undone by the next restart, and makes nodes differ from one another in ways nobody remembers.
Correct Approach
Keep kubelet configuration in version-controlled files and roll changes out to all nodes in a controlled, repeatable way.
Problem
Leaving the kubelet’s network port reachable from wherever with anonymous requests allowed.
Why It’s Harmful
Anyone who finds the port could read information or run commands on the node, which can lead to a full cluster compromise.
Correct Approach
Require certificate or token authentication, enable authorization checks, and limit network access to trusted sources.
21Best Practices and Beginner Mistakes
Small habits that keep nodes calm and clusters predictable.
Match the cgroup settings
Make sure the kubelet and the container runtime agree on how they manage resource groups. A mismatch is a classic cause of strange instability.
Keep versions compatible
The kubelet should never be newer than the control plane, and it may only lag behind by a small, documented number of versions.
Enable certificate rotation
Automatic renewal of the kubelet’s certificates prevents nodes from suddenly losing access when a certificate expires.
Watch disk space
Container images and logs quietly fill disks. Configure cleanup thresholds and log rotation before they become emergencies.
Turn off swap unless intentionally supported
Historically the kubelet refused to start on nodes with swap memory enabled, because it makes resource limits unpredictable. Check your version’s rules before changing this.
Drain before maintenance
Move Pods away gracefully before rebooting or upgrading a node, so users never notice.
When Pods misbehave, teams often look only at the program. Sometimes the cause is the node: full disk, broken runtime or an unhealthy kubelet. Check both.
A limit that is tighter than the program’s real needs causes constant memory kills and slowdowns. Measure first, then set.
Checking too often with too little patience can restart healthy containers during a brief slowdown. Give probes sensible delays and tolerances.
22Real-World Examples
The kubelet quietly works behind services you use every day.
You rarely see a kubelet, yet on any Kubernetes-based service it is working non-stop. Here are some everyday pictures of what that looks like.
An online store during a sale
Traffic surges and the platform adds many new Pods. On each node, the kubelet pulls images, starts containers, runs readiness checks, and only lets Pods receive shoppers when they are truly ready.
A video streaming service
When a container serving a region crashes, the kubelet notices within moments and restarts it, often before viewers see any interruption.
A bank rolling out an update
New Pods are introduced gradually. The kubelet’s readiness checks decide when each new Pod may begin receiving customer requests, which keeps the rollout safe.
A machine learning team with special hardware
Nodes with graphics cards announce them through device plugins. The kubelet makes sure a training Pod is granted exactly the hardware it requested.
A cluster that must bootstrap itself
When a new cluster starts, the kubelet launches the control plane from static Pod files. The cluster literally pulls itself into existence with the kubelet’s help.
A node that runs out of memory
A memory-hungry Pod pushes a node towards trouble. The kubelet evicts the least protected Pods, the node survives, and the control plane restarts the evicted Pods elsewhere.
23Frequently Asked Questions
Quick answers to questions beginners ask most.
Often yes. In many clusters, the control plane components themselves run as Pods, and it is the kubelet on those computers that starts and watches them. Even the “brain” computers rely on this helper.
Usually not. It typically runs directly on the computer as a background service, because it needs to exist before any container can be started.
The kubelet is the manager that decides what should run and checks that it does. The container runtime is the engine that actually creates and runs containers when the kubelet asks. One directs, the other executes.
The kubelet looks after Pods on the node. The kube-proxy maintains the network rules that let traffic reach services. Both live on each node, but they have separate jobs.
Containers already started by the runtime usually keep running for a while, but nobody is watching them. They will not be restarted if they crash, no new Pods will start, and the node will eventually be marked NotReady by the control plane.
No. The kubelet only manages containers that belong to Pods it knows about. Containers created some other way are outside its concern.
The scheduler decides. The kubelet accepts the assignment, does a final check that the Pod fits, and then carries it out.
Yes. It reads a configuration file and accepts settings covering things such as resource reservations, eviction thresholds, security options and the runtime to talk to. Because these settings affect the whole node, they should be changed carefully and consistently across nodes.
Learn what a container and a Pod are, then understand how the control plane and worker nodes divide the work. After that, the kubelet’s role as the node’s manager and its compare-and-correct loop will feel natural.
24Summary and Key Takeaways
The kubelet is the local manager of every Kubernetes node. It receives descriptions of the Pods that belong on its computer, asks the container runtime to create them, prepares their storage and settings, checks their health, enforces their resource limits, protects the node when resources run short, and reports everything back to the control plane. It is simple in idea, a loop that compares what should be with what is, yet it carries out almost all the real work of the cluster. Understand the kubelet, and you understand how Kubernetes turns plans into running programs.
Key Takeaways
- The kubelet is the node agent — one runs on every worker node and makes sure the Pods assigned there are running and healthy.
- It manages, it does not build — the kubelet directs the container runtime through a standard interface rather than creating containers itself.
- It follows a compare-and-correct loop — it constantly matches the real state of the node with the desired state and closes any gap.
- Probes give it senses — liveness, readiness and startup checks tell it when to restart a container or hold back traffic.
- It enforces fairness and protects the node — requests, limits and quality classes decide who is guaranteed resources and who is evicted first.
- Heartbeats keep the cluster informed — leases and status updates let the control plane know a node is alive and react if it is not.
- It must be secured and watched — require authentication, restrict its port, keep certificates fresh, and monitor node health from the start.