Why Node components (kubelet, kube-proxy, container runtime) in Kubernetes? - Purpose & Use Cases

The Big Idea

What if your apps could fix themselves and stay connected without you touching each server?

The Scenario

Imagine you have many computers (nodes) running your apps, and you try to manage each one by hand--starting apps, connecting them, and keeping them healthy.

You have to log into each machine, check if apps are running, fix network issues, and update software manually.

The Problem

This manual way is slow and tiring. You might forget to start an app or connect it properly.

Network settings can get mixed up, causing apps to fail silently.

It's easy to make mistakes that break your whole system.

The Solution

Kubernetes node components like kubelet, kube-proxy, and container runtime automate these tasks.

Kubelet makes sure your apps (containers) run correctly on each node.

Kube-proxy handles network connections so apps can talk to each other smoothly.

The container runtime runs the apps inside containers safely and efficiently.

Before vs After

✗ Before

ssh node1
sudo docker start myapp
sudo iptables add rules
ssh node2
sudo docker start myapp
sudo iptables add rules

✓ After

kubectl apply -f deployment.yaml
# kubelet and kube-proxy handle app start and networking automatically

What It Enables

This lets you run and manage many app containers across many machines reliably and automatically, without logging into each one.

Real Life Example

A company runs a website on 100 servers. Instead of managing each server manually, Kubernetes node components keep all servers running the website apps and connected, even if some servers fail.

Key Takeaways

Manual app and network management on many nodes is slow and error-prone.

Kubelet, kube-proxy, and container runtime automate app running and networking on each node.

This automation makes large-scale app management reliable and easy.

Practice

1. Which Kubernetes node component is responsible for making sure containers start and keep running on a node?

easy

A. kube-proxy

B. kubelet

C. container runtime

D. etcd

Solution

1. Step 1: Understand the role of kubelet

   kubelet runs on each node and ensures containers are started and stay running as requested by the control plane.

2. Step 2: Differentiate from other components

   kube-proxy manages network traffic, container runtime runs containers, and etcd stores cluster data.

3. Final Answer:

   kubelet -> Option B

4. Quick Check:

   Container management = kubelet [OK]

Hint: kubelet manages containers on nodes, not networking or storage [OK]

Common Mistakes:

• Confusing kubelet with kube-proxy
• Thinking container runtime manages container lifecycle
• Selecting etcd which is for cluster data storage

2. Which of the following is the correct command to check the status of the kubelet service on a Linux node?

easy

A. systemctl status kube-proxy

B. docker ps | grep kubelet

C. systemctl status kubelet

D. kubectl get pods kubelet

Solution

1. Step 1: Identify the service name for kubelet

   The kubelet runs as a system service named 'kubelet' on Linux nodes.

2. Step 2: Use systemctl to check service status

   The command 'systemctl status kubelet' shows the running status of the kubelet service.

3. Final Answer:

   systemctl status kubelet -> Option C

4. Quick Check:

   Check kubelet service = systemctl status kubelet [OK]

Hint: Use systemctl with 'kubelet' to check its status [OK]

Common Mistakes:

• Checking kube-proxy instead of kubelet
• Using kubectl which manages cluster, not node services
• Searching for kubelet in docker containers

3. Given the following command output snippet from a node, which component is responsible for managing network rules to allow pod communication?

NAME       STATUS   ROLES    AGE   VERSION
node-1     Ready    <none>   10d   v1.26.0

Active connections:
- kubelet running
- kube-proxy running
- container runtime running

medium

A. kube-proxy

B. container runtime

C. kubelet

D. etcd

Solution

1. Step 1: Identify the role of kube-proxy

   kube-proxy manages network rules and traffic routing inside the cluster to enable pod communication.

2. Step 2: Differentiate from other components

   kubelet manages containers, container runtime runs containers, and etcd stores cluster data.

3. Final Answer:

   kube-proxy -> Option A

4. Quick Check:

   Network management = kube-proxy [OK]

Hint: Network rules inside cluster are handled by kube-proxy [OK]

Common Mistakes:

• Confusing kubelet with network management
• Thinking container runtime manages networking
• Selecting etcd which is unrelated to node networking

4. You notice pods on a node are not receiving network traffic correctly. You check and find kube-proxy is not running. Which command would you use to restart kube-proxy on a systemd-based node?

medium

A. systemctl restart kube-proxy

B. kubectl restart kube-proxy

C. systemctl restart kubelet

D. docker restart kube-proxy

Solution

1. Step 1: Identify the correct service to restart

   Since kube-proxy manages network traffic and is not running, restarting kube-proxy service is needed.

2. Step 2: Use systemctl to restart kube-proxy

   On systemd-based systems, 'systemctl restart kube-proxy' restarts the kube-proxy service properly.

3. Final Answer:

   systemctl restart kube-proxy -> Option A

4. Quick Check:

   Restart kube-proxy with systemctl restart kube-proxy [OK]

Hint: Restart kube-proxy service with systemctl to fix network issues [OK]

Common Mistakes:

• Restarting kubelet instead of kube-proxy
• Using kubectl which cannot restart node services
• Trying to restart kube-proxy as a docker container

5. A Kubernetes node uses containerd as its container runtime. You want to verify that the container runtime is running correctly and can start containers. Which sequence of commands would you use to check containerd status and list running containers?

hard

A. docker ps && crictl status

B. systemctl status kubelet && docker ps

C. kubectl get pods && systemctl status containerd

D. systemctl status containerd && crictl ps

Solution

1. Step 1: Check containerd service status

   Use 'systemctl status containerd' to verify the container runtime service is active and running.

2. Step 2: List running containers with crictl

   Since containerd uses CRI, 'crictl ps' lists running containers managed by containerd.

3. Final Answer:

   systemctl status containerd && crictl ps -> Option D

4. Quick Check:

   Check containerd and containers with systemctl and crictl [OK]

Hint: Use systemctl for service and crictl for container runtime containers [OK]

Common Mistakes:

• Using docker commands when containerd is runtime
• Checking kubelet status instead of container runtime
• Mixing kubectl pod commands with container runtime checks