The Split Brain

Look, if you've ever dealt with this in production, you know exactly what the problem is. Before writing any YAML files, you must understand how a Kubernetes cluster is physically constructed. A cluster is divided into two distinct components: The Control Plane (the brain) and the Worker Nodes (the muscle). The Control Plane makes all global decisions about the cluster (scheduling, scaling, and maintaining state). The Worker Nodes actually execute the application containers. You never run your application code on the Control Plane; it is reserved exclusively for Kubernetes management processes. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. The heart of the Control Plane is the 'kube-apiserver'. It is the only component in the entire cluster that communicates with the outside world. When you type a kubectl command on your laptop, you are making an HTTP POST request to the API Server. The API Server validates your request, checks your authentication, and serves as the central communication hub. Worker Nodes never talk to each other directly; everything goes through the API Server. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. If the API Server is the brain, 'etcd' is the memory. etcd is a highly-available, distributed key-value database that lives on the Control Plane. It stores the exact 'Desired State' of the entire cluster. When you submit a YAML file to the API Server requesting 3 copies of your app, the API Server saves that request into etcd. etcd is the absolute source of truth. If the cluster crashes, Kubernetes uses etcd to rebuild everything exactly as it was. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. The final pieces of the Control Plane are the Scheduler and the Controller Manager. The Scheduler continuously watches the API Server for newly created, unassigned containers. It calculates CPU/Memory requirements and assigns the container to the best available Worker Node. The Controller Manager runs the infinite 'Control Loops'. It constantly compares the Desired State (in etcd) with the Current State. If they don't match, it acts to fix the discrepancy. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. Moving away from the Control Plane, let's look at the Worker Nodes. Every Worker Node runs an agent called the 'kubelet'. The kubelet is the node's captain. It constantly listens to the API Server for instructions. If the API Server says, 'Start this container', the kubelet takes that instruction and tells the local Docker engine (or containerd) to physically pull the image and run it. The kubelet also reports the health of its node back to the API Server. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. The final critical component on the Worker Node is the 'kube-proxy'. While the kubelet manages the physical containers, the kube-proxy manages the network. Kubernetes relies heavily on internal networking to allow containers to talk to each other across different servers. The kube-proxy modifies the underlying OS networking rules (like iptables) to ensure that traffic routed to 'my-database' actually finds the correct container, regardless of which physical node it lives on. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

Look, if you've ever dealt with this in production, you know exactly what the problem is. You now understand the internal anatomy of a Kubernetes cluster. The Control Plane acts as the global brain: the API Server handles REST requests, etcd stores the memory, the Scheduler assigns work, and the Controller Manager enforces state. The Worker Nodes act as the muscle: the kubelet runs the containers, and the kube-proxy routes the network. Now that we know how it works internally, let's learn how to communicate with it using the kubectl CLI. This isn't just academic theory—understanding the *why* behind this is what separates junior devs from senior engineers. When you deploy to a cluster, this is the mechanic that prevents catastrophic failure.

The Split Brain. Before writing any YAML files, you must understand how a Kubernetes cluster is physically constructed. A cluster is divided into two distinct components: The Control Plane (the brain) and the Worker Nodes (the muscle). The Control Plane makes all global decisions about the cluster (scheduling, scaling, and maintaining state). The Worker Nodes actually execute the application containers. You never run your application code on the Control Plane; it is reserved exclusively for Kubernetes management processes.

The API Server. The heart of the Control Plane is the 'kube-apiserver'. It is the only component in the entire cluster that communicates with the outside world. When you type a kubectl command on your laptop, you are making an HTTP POST request to the API Server. The API Server validates your request, checks your authentication, and serves as the central communication hub. Worker Nodes never talk to each other directly; everything goes through the API Server.

In the Kubernetes Control Plane, which component serves as the central communication hub and the only entry point for external commands?

• →kube-apiserver
• →kubelet

etcd: The Memory of the Cluster. If the API Server is the brain, 'etcd' is the memory. etcd is a highly-available, distributed key-value database that lives on the Control Plane. It stores the exact 'Desired State' of the entire cluster. When you submit a YAML file to the API Server requesting 3 copies of your app, the API Server saves that request into etcd. etcd is the absolute source of truth. If the cluster crashes, Kubernetes uses etcd to rebuild everything exactly as it was.

Scheduler and Controller Manager. The final pieces of the Control Plane are the Scheduler and the Controller Manager. The Scheduler continuously watches the API Server for newly created, unassigned containers. It calculates CPU/Memory requirements and assigns the container to the best available Worker Node. The Controller Manager runs the infinite 'Control Loops'. It constantly compares the Desired State (in etcd) with the Current State. If they don't match, it acts to fix the discrepancy.

Which Control Plane component is specifically responsible for continuously comparing the current state of the cluster against the desired state stored in etcd?

• →kube-controller-manager
• →kube-scheduler

Worker Nodes: The Kubelet. Moving away from the Control Plane, let's look at the Worker Nodes. Every Worker Node runs an agent called the 'kubelet'. The kubelet is the node's captain. It constantly listens to the API Server for instructions. If the API Server says, 'Start this container', the kubelet takes that instruction and tells the local Docker engine (or containerd) to physically pull the image and run it. The kubelet also reports the health of its node back to the API Server.

Worker Nodes: kube-proxy. The final critical component on the Worker Node is the 'kube-proxy'. While the kubelet manages the physical containers, the kube-proxy manages the network. Kubernetes relies heavily on internal networking to allow containers to talk to each other across different servers. The kube-proxy modifies the underlying OS networking rules (like iptables) to ensure that traffic routed to 'my-database' actually finds the correct container, regardless of which physical node it lives on.

Which component running on the Worker Node is responsible for managing internal network rules and ensuring traffic reaches the correct containers?

• →kube-proxy
• →kube-apiserver

Conclusion of Architecture. You now understand the internal anatomy of a Kubernetes cluster. The Control Plane acts as the global brain: the API Server handles REST requests, etcd stores the memory, the Scheduler assigns work, and the Controller Manager enforces state. The Worker Nodes act as the muscle: the kubelet runs the containers, and the kube-proxy routes the network. Now that we know how it works internally, let's learn how to communicate with it using the kubectl CLI.