Anatomy of a Kubernetes Cluster: Nodes and Architecture

Previously in this course, we discussed the evolution from Docker to orchestration and identified why manual container management fails at scale. In this lesson, we move from the "why" to the "what" by dissecting the physical and logical components that form a functional Kubernetes cluster.

The Two-Tier Architecture

At its core, a Kubernetes cluster is a distributed system designed to manage containers across multiple machines. To achieve this, the cluster is divided into two primary types of entities:

1. The Control Plane (Master Nodes): The "brains" of the operation. It makes global decisions about the cluster, detects and responds to events, and maintains the desired state.
2. Worker Nodes: The "muscle." These machines host the actual applications (containers) that you deploy.

Think of the Control Plane as the manager in an office, and the Worker nodes as the employees. The manager doesn't do the actual data entry (the compute work), but they ensure the employees are assigned tasks, have the right resources, and are replaced if they stop showing up for work.

The Worker Node Components

When you deploy a containerized application, it lands on a Worker node. However, Kubernetes doesn't just "drop" a container there and walk away. Two critical agents live on every Worker node to ensure the application stays healthy:

The Kubelet

The Kubelet is the primary "node agent." It runs on every worker node and ensures that containers are running in a Pod as described in the cluster configuration. If the Control Plane tells the Kubelet, "You should have three copies of this web server running," the Kubelet watches the local container runtime (like containerd) to make sure those three containers are actually alive. If one crashes, the Kubelet restarts it.

The Kube-proxy

While the Kubelet handles the lifecycle of the container, the Kube-proxy handles the network. It maintains network rules on the nodes. These rules allow network communication to your Pods from sessions inside or outside of your cluster. Without the Kube-proxy, your application might be running, but it would be completely isolated from the network.

Visualizing the Cluster

The following diagram illustrates how the Control Plane interacts with the Worker nodes to maintain order:

Flow diagram: API Server; Kubelet; Kube-proxy; C Container; API -- "Instructs" → Kubelet; Kubelet -- "Manages" → Container; Proxy -- "Manages Networking" → Container

Hands-on Exercise: Identifying Components

In a real environment, you can see these components in action. While we will set up our local environment in a later lesson, you can run the following command on any existing cluster to see your nodes:

Bash
kubectl get nodes

This will list your Worker nodes. To see the "system" pods that run the Kubelet or other critical agents, you can inspect the kube-system namespace:

Bash
kubectl get pods -n kube-system

Practice: If you have access to a cluster, run the commands above. Can you identify which nodes are labeled as masters (often labeled node-role.kubernetes.io/control-plane) versus those that are workers?

Common Pitfalls

• Assuming the Kubelet is a container: The Kubelet is a binary that runs as a process on the host OS (the Worker node), not as a container inside Kubernetes. If the Kubelet dies, the node is effectively disconnected from the cluster.
• Confusing the Control Plane with the Application: Beginners often try to deploy their applications directly onto the Master node. In production, keep your Master nodes dedicated to management; don't let user workloads hog the resources needed to keep the cluster "brain" responsive.
• Ignoring Kube-proxy logs: When you can't reach your app, it’s rarely a "broken" container. It’s usually a networking issue. Always check if the Kube-proxy is running correctly on the host node.

FAQ

Q: Can a cluster have only one node? A: Yes, in development environments like Minikube or Kind, the Master and Worker roles are often collapsed onto a single machine. However, for production, you should always have at least three Master nodes for high availability.

Q: Does every node need a Kube-proxy? A: Yes. Every node requires a Kube-proxy to ensure that traffic directed to a service can find its way to the specific Pod, regardless of which node that Pod is living on.

Recap

We’ve established that a Kubernetes cluster is a harmony between the Control Plane (management) and Worker nodes (execution). The Kubelet acts as the local foreman, ensuring containers match your desired state, while the Kube-proxy acts as the network traffic controller. These components work together to provide the resilience and scalability that define modern cloud infrastructure.

Up next: The Control Plane and the State Store