Understanding kubelet vs kubectl in Kubernetes

kubelet and kubectl are two completely different components in Kubernetes, even though their names are similar.

What is kubelet?

kubelet is the node agent in Kubernetes.

It runs as a system service on every Kubernetes node.

Think of kubelet as the manager of a single Kubernetes node.

Its primary responsibility is to ensure that the Pods assigned to its node are actually running and remain in the desired state.

Responsibilities of kubelet

When kubelet starts, it performs several important tasks.

• Registers the node with the Kubernetes cluster.
• Watches the Kubernetes API Server for Pods assigned to its node.
• Creates and deletes Pods.
• Communicates with the container runtime (containerd, CRI-O, etc.).
• Mounts storage volumes.
• Configures networking through the CNI plugin.
• Reports the status of the node and Pods back to the API Server.
• Performs health checks on Pods and containers.

How kubelet Works

             kube-apiserver
                    │
          Pod assigned to Node-2
                    │
                    ▼
              kubelet (Node-2)
                    │
         Uses CRI (Container Runtime Interface)
                    │
                    ▼
              containerd
                    │
                    ▼
                 runc
                    │
                    ▼
              Linux Container

Example: kubelet in Action

Suppose you create a Pod using the following command:

kubectl apply -f nginx.yaml

The Kubernetes Scheduler decides:

Run Pod on Worker-1

The kubelet running on Worker-1 notices that a new Pod has been assigned to it.

A new Pod is assigned to me.

The kubelet then performs the following steps:

1. Pulls the container image.

nginx:latest

2. Creates the Pod sandbox.
3. Configures Pod networking using the configured CNI plugin.
4. Starts the container through the container runtime.
5. Reports the Pod status back to the API Server.

Pod Running

kubelet Continuously Monitors Pods

Suppose someone manually removes the running container.

docker rm -f nginx

or by using containerd tools.

The kubelet detects the difference between the desired state and the actual state.

Expected: nginx exists

Actual: nginx missing

Since Kubernetes still expects the Pod to be running, the kubelet immediately recreates it.

This continuous comparison between the desired state and the actual state is known as reconciliation, one of Kubernetes’ core design principles.

What is kubectl?

kubectl is not a component of the Kubernetes cluster.

It is simply a command-line client that administrators and developers use to communicate with the Kubernetes API Server.

You
 │
 ▼
kubectl
 │
 ▼
API Server
 │
 ▼
Entire Kubernetes Cluster

Responsibilities of kubectl

Using kubectl, you can:

• Create Pods and Deployments.
• Delete Kubernetes resources.
• Scale Deployments.
• View Pod logs.
• Execute commands inside running containers.
• Retrieve cluster information.
• Apply YAML configuration files.
• Update existing resources.

Common kubectl Commands

Create Resources

kubectl apply -f deployment.yaml

List Pods

kubectl get pods

Describe a Pod

kubectl describe pod nginx

Delete a Pod

kubectl delete pod nginx

Open a Shell Inside a Pod

kubectl exec -it nginx -- bash

View Pod Logs

kubectl logs nginx

How kubectl Works

When you execute:

kubectl get pods

The request flows through the Kubernetes control plane as shown below.

You
 │
 ▼
kubectl
 │
 ▼
API Server
 │
 ▼
etcd
 │
 ▼
Returns Pod information
 │
 ▼
kubectl prints output

Notice that kubectl never communicates directly with:

• kubelet
• containerd
• Worker nodes
• etcd

It communicates only with the Kubernetes API Server.

kubelet vs kubectl

Where They Fit in the Kubernetes Architecture

                 You
                  │
            kubectl apply
                  │
                  ▼
          +-----------------+
          | kube-apiserver  |
          +-----------------+
                  │
          Stores Desired State
                  │
                  ▼
               etcd
                  │
                  ▼
         kube-scheduler selects a node
                  │
                  ▼
     Pod assigned to Worker-1
                  │
                  ▼
      +----------------------+
      | kubelet (Worker-1)   |
      +----------------------+
                  │
          Uses CRI to talk to
                  │
                  ▼
             containerd
                  │
                  ▼
                runc
                  │
                  ▼
             Linux Container

Simple Analogy

Imagine Kubernetes as a restaurant.

• You (Customer) place an order using kubectl.
• The API Server acts as the waiter, recording your order.
• The Scheduler decides which chef should prepare the meal.
• The kubelet is the chef at the assigned kitchen station who ensures the dish is prepared and remains available.
• containerd and runc are the cooking tools used by the chef.
• The running Pod is the finished dish served to the customer.

Key Takeaways

• ✔ kubectl is the command-line tool used by administrators and developers to interact with Kubernetes.
• ✔ kubelet is a background service running on every Kubernetes node.
• ✔ kubectl communicates only with the Kubernetes API Server.
• ✔ kubelet watches the API Server for Pods assigned to its node and ensures those Pods are running.
• ✔ kubelet communicates with the container runtime (such as containerd) through the Container Runtime Interface (CRI).
• ✔ Kubernetes relies on the kubelet’s continuous reconciliation loop to maintain the desired state of Pods.

In One Sentence

kubectl is the tool you use to tell Kubernetes what you want, while kubelet is the service running on each node that ensures what you requested is actually running.