The Worker Node and the Data Plane

Kubelet: the agent on every node

kubelet is a process running on the worker node.

Its main job is making sure the Pods assigned to that node actually run.

The kubelet watches cluster state through the API Server and checks whether objects assigned to its node have appeared.

You can simplify it to:

API Server
   |
   v
kubelet
   |
   v
container runtime

If the scheduler decides:

Pod X -> Node 2

the kubelet on Node 2 will see that information and start carrying out the task.

What the kubelet does

The kubelet is responsible, among other things, for:

• watching Pods assigned to the node,
• starting and stopping containers through the runtime,
• reporting node state,
• reporting Pod status,
• running some of the health checks,
• keeping the local state consistent with the declaration.

So the kubelet is a kind of local Kubernetes executor on every machine.

Container runtime

The kubelet doesn't start a container by itself.

For that you need a container runtime.

The most common options are:

• containerd,
• CRI-O.

The runtime handles the actual container lifecycle:

• create,
• start,
• stop,
• delete.

CRI: the layer between the kubelet and the runtime

Kubernetes doesn't want to be tied directly to one specific runtime.

That is why it uses CRI (Container Runtime Interface).

The scheme:

kubelet
  |
  v
 CRI
  |
  v
containerd / CRI-O

CRI is a contract.

The kubelet says what it needs, and the runtime implements the operations.

This lets Kubernetes work with different runtimes without rebuilding the whole system.

Kubernetes and Docker

This is where a common question comes up:

Does Kubernetes use Docker?

Historically Docker was very often used in Kubernetes environments.

Today the typical runtime is, for example, containerd.

That doesn't mean images built with Docker stopped working.

The image format is based on OCI standards, so an image built with Docker can be run by containerd.

It is worth separating:

Docker CLI
Docker Engine
container image
container runtime

These are not exactly the same things.

What happens after a Pod is assigned

Let's say the scheduler has picked a node.

Then:

1. the assignment is recorded in the API,
2. the kubelet on that node notices it,
3. the kubelet asks the runtime to prepare the containers,
4. networking gets configured,
5. the containers are started,
6. the kubelet reports the status.

In short:

scheduler
   |
   v
chosen node
   |
   v
kubelet
   |
   v
container runtime
   |
   v
container

Does a worker node have to be a VM?

No.

A worker node can be:

• a virtual machine,
• a physical server,
• an instance in the public cloud.

What matters to Kubernetes is that the node acts as an executing machine and has the right components.

What to remember

The simplest split looks like this:

scheduler
-> picks the node

kubelet
-> looks after the Pod on the node

container runtime
-> runs the containers

These three roles are often confused, but they are responsible for completely different stages of the process.