Kubernetes Architecture
Worker Nodes — kubelet, kube-proxy, Container Runtime
Workload executors and networking routing.
Interview: Be ready to explain how worker nodes execute instructions. Understand the difference between the Container Runtime Interface (CRI) and Container Network Interface (CNI), how the kubelet reports health status back to the control plane, and how kube-proxy maintains IP tables or IPVS rules for packet routing.
Introduction
Worker Nodes are the machines that run your containerized workloads. Unlike the control plane, which manages scheduling and state, worker nodes execute the actual application code and route network traffic.
Why It Matters
Your application performance depends directly on the stability of the worker node agents. If kubelet crashes, the node stops executing pod commands. If kube-proxy stops, client connections will fail to route to correct instances.
Real-World Analogy
Think of a worker node like a franchise restaurant branch:
• The kubelet is the restaurant manager who receives recipe instructions (PodSpecs) from corporate headquarters, hires staff (CRI), and supervises food preparation.
• The Container Runtime is the chef in the kitchen who actually cooks the meals.
• kube-proxy is the greeter and queue coordinator at the front door who redirects incoming diners to open tables.
How It Works
When a Pod is scheduled to a worker node:
- kubelet detects the assignment via watch endpoints on the API Server.
- kubelet issues gRPC calls to the local Container Runtime using the CRI schema.
- The Container Runtime pulls the image and runs the container.
- The CNI plugin allocates an IP and connects the container network card.
- kube-proxy writes new forwarding rules to iptables, enabling packet routing.
Internal Architecture
Kubernetes decouples node agents using interfaces:
• CRI (Container Runtime Interface): Allows kubelet to talk to different runtimes (containerd, CRI-O) without rebuilding.
• CNI (Container Network Interface): Configures network cards, bridge devices, and IPs.
Visual Explanation
Practical Example
Here is how to check node statuses and details using the command line:
Common Mistakes
1. Disabling Swap incorrectly: Kubelet is designed to run with Linux Swap memory disabled. If swap is enabled, and your system exhausts physical memory, kubelet will write to disk swap, causing performance to drop. Kubelet will fail to start by default if swap is active.
2. Firewalling Kubelet Ports: Blocking port 10250 on worker nodes. The API Server needs this port to connect to kubelet for reading logs and executing commands.
Quick Quiz
Q1: Which agent is responsible for pulling container images and starting container processes on worker nodes?
A) kube-proxy
B) Container Runtime (via CRI)
C) kubelet daemon directly
Answer: B — kubelet instructs the Container Runtime (e.g. containerd) to perform the low-level process allocation.
Scenario-Based Challenge
Scenario:
Your API container is running and healthy. You create a new service, but when clients connect to the Service NodePort IP, the connection times out. How do you check if the worker node network proxy is active?
View SolutionSince NodePort depends on iptables/IPVS rules, check the health of kube-proxy. Query the status of the kube-proxy Pods:
Debugging Exercise
Failure Case:
A worker node displays a status of NotReady in kubectl get nodes.
How do you troubleshoot this node?
View Solution2. Check if the kubelet service is active using system control:
Interview Questions
1. What is the difference between CRI and CNI inside Kubernetes?
CRI (Container Runtime Interface) controls container lifecycles (starting, stopping, compiling runtimes). CNI (Container Network Interface) controls card setup, IP allocation, and routing.
2. How does kube-proxy route network packets?
By monitoring Services and Endpoint objects via the API Server, and writing iptables or IPVS routing rules on the host node, directing traffic to target pods.
Production Considerations
Enable kubelet node eviction thresholds. Configure kubelet to gracefully drain and evict Pods if local disk space drops below 10%, protecting node stability.