Kubelet acts as an agent on each physical node or virtual machine in a Kubernetes cluster. It is responsible for translating configuration declarations (PodSpecs) from the control plane into reality by interacting directly with container runtimes such as Docker or containerd.
Imagine you deploy a web application with 3 replicas. When the control plane decides that a pod needs to run on node A, the Kubelet here will receive commands via API Server, download the container image from the registry, launch the container, and continuously check its status.
The Kubelet workflow can be described in four main steps:
Get PodSpec: Kubelet gets pod information from API Server via watch mechanism.
Container initialization: Use CRI (Container Runtime Interface) to communicate with container runtime, pull image and run container.
Health monitoring: Perform periodic health checks via liveness/readiness probe. If the container crashes, Kubelet automatically restarts.
Status reporting: Continuously update pod status to API Server so that the control plane has an overview of the cluster.
The default Kubelet configuration file is usually located at /var/lib/kubelet/config.yaml . Some important parameters include:
apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration address: 0.0.0.0 port: 10250 clusterDNS: - 10.96.0.10
In which, clusterDNS specifies the cluster's internal DNS address, helping pods resolve service names.
While Kubelet manages the container lifecycle, Kube Proxy is responsible for routing network traffic between services. Every time you create a Kubernetes Service, Kube Proxy on each node updates iptables or IPVS rules to ensure traffic reaches the correct backend pod.
For example, when creating a Service type NodePort for a web application, Kube Proxy will open ports 30000-32767 on all nodes and set up forwarding rules to the corresponding pods.
Kube Proxy supports three main operating modes:
When creating a Service with clusterIP 10.96.0.10, Kube Proxy will generate similar rules:
-A KUBE-SERVICES -d 10.96.0.10/32 -p tcp -m comment --comment "default/web-service" -m tcp --dport 80 -j KUBE-SVC-ABCD1234
This rule ensures that all traffic to clusterIP:80 will be routed to the KUBE-SVC-ABCD1234 chain, which contains the list of pod endpoints.
Although they have different responsibilities, Kubelet and Kube Proxy work closely together to ensure that applications can both run reliably and communicate. When Kubelet creates a new pod, it updates the pod IP address metadata to Kube Proxy via the API Server. Kube Proxy uses this information to update its network rules.
In the scenario of scaling pod from 3 to 5 replicas, the process goes like this:
1. Control Plane adjusts the number of replicas.
2. Kubelet on nodes receives new pod and launches container.
3. Kube Proxy detects new endpoint via API Server and updates iptables/IPVS rules.
4. Traffic to the service is automatically distributed to new pods.
Understanding how Kubelet and Kube Proxy work is fundamental to running an effective Kubernetes cluster. While Kubelet ensures the health of individual containers, Kube Proxy builds a “transportation system” for network traffic. This combination allows Kubernetes to manage distributed applications at scale while ensuring high availability.
For beginners, mastering these two components helps debug common issues like pods failing to start or services failing to connect. For production systems, optimizing Kubelet and Kube Proxy configurations is key to achieving high performance and stability.