Kubernetes Architecture Explained

# CHAPTER 3

Kubernetes Architecture Explained #

1. Introduction #

2. Learning Objectives #

• Identify the 4 core components of the Control Plane (Master Node).

• Understand the critical role of the kube-apiserver.

• Understand how etcd acts as the cluster's absolute source of truth.

• Identify the 3 core components of a Worker Node (kubelet, kube-proxy, Container Runtime).

• Trace the lifecycle of a kubectl command from terminal to execution.

3. Beginner-Friendly Explanation #

• You (The User): You are outside. You use your phone (kubectl) to send an order: "I want 3 pizzas."

• The Manager (API Server): Receives your order. They are the only person allowed to talk to the outside world.

• The Ledger Book (etcd): The Manager writes down in a permanent, locked book: "Customer A requires 3 pizzas."

• The Floor Supervisor (Controller Manager): Constantly looks at the Ledger Book. They notice the book says "3 pizzas required," but there are currently 0 pizzas. They raise an alarm: "We need 3 pizzas!"

• The Dispatcher (Scheduler): Hears the alarm. They look at the kitchen. "Oven 1 is full. Oven 2 is empty. Send the pizza orders to Oven 2!"

• The Chefs (Worker Nodes / Kubelet): The chefs at Oven 2 receive the order from the Dispatcher. They cook the pizzas (Run the Pods) and report back to the Manager: "3 pizzas are ready."

4. The Control Plane (Master Node) Components #

1. 1. kube-apiserver: The front door. Every single command you type, and every internal communication between nodes, MUST pass through the API server.

1. 2. etcd: The database. It is a highly-available, key-value store. It holds the "Desired State" of your entire cluster. If a Pod is running, it is recorded in etcd. If etcd is deleted, your cluster essentially suffers total amnesia and dies.

1. 3. kube-scheduler: The matchmaker. When a new Pod needs to be created, the scheduler looks at the CPU and RAM of all Worker Nodes and decides which Node is the best fit to host the Pod.

1. 4. kube-controller-manager: The enforcer. It runs continuous loops comparing the "Current State" to the "Desired State." If the Desired State is 5 Pods, and the Current State drops to 4 (because a node crashed), the Controller Manager orders the creation of a new Pod.

5. The Worker Node Components #

1. 1. Container Runtime: The engine that actually runs the containers (e.g., containerd, Docker, CRI-O).

1. 2. kubelet: The captain of the ship. It is an agent running on the node that listens to the kube-apiserver. When the API Server says "Run this Pod," the kubelet tells the Container Runtime to start it. It also constantly reports the health of the Node back to the Master.

1. 3. kube-proxy: The network routing cop. It maintains network rules on the node, ensuring that if a user requests a web page, the network traffic is successfully routed to the correct Pod on that specific node.

6. Tracing a Command #

1. 1. kubectl authenticates with the API Server.

1. 2. The API Server writes the request into etcd.

1. 3. The Controller Manager notices a new deployment in etcd and creates a "ReplicaSet" requiring 1 Pod.

1. 4. The Scheduler sees an unassigned Pod. It analyzes the cluster and assigns the Pod to "Worker Node 2".

1. 5. The API server updates etcd with the assignment.

1. 6. The kubelet on Worker Node 2 sees its name in the API Server.

1. 7. The kubelet orders the Container Runtime to pull the Nginx image and start the container.

1. 8. The kube-proxy updates network rules so the Pod can be reached.

7. Mini Project: Explore Cluster Components #

Step-by-Step Tutorial:

1. 1. Ensure your Minikube cluster is running.

1. 2. By default, Kubernetes hides its own internal brain components in a special "Namespace" called kube-system. Let's look inside it:

kubectl get pods -n kube-system

1. 3. *The Proof:* You will see a list of Pods running the cluster itself! You will clearly see kube-apiserver-minikube, etcd-minikube, kube-scheduler-minikube, and kube-proxy. You are looking at the bare metal of the Control Plane!

8. Real-World Scenarios #

9. Best Practices #

• Protect etcd: In self-hosted, bare-metal Kubernetes clusters, taking regular, encrypted backups of the etcd database is the most critical operational task. Without an etcd backup, a catastrophic failure means rebuilding your entire infrastructure from memory.

10. Common Mistakes #

• Connecting Directly to Nodes: Beginners often try to SSH directly into a Worker Node to see what containers are running or to restart a crashed Docker container manually. Never do this. Kubernetes is the orchestrator. If you manually kill a container on a node, the Controller Manager will instantly notice the discrepancy and spawn a new one to replace it, fighting your manual actions!

11. Exercises #

1. 1. If a Worker Node experiences a total hardware failure and loses power, which component on the Master Node notices, and which component decides where the replacement Pods will be launched?

1. 2. Why is the kube-apiserver considered the single point of entry for the entire cluster?

12. FAQs #

13. Interview Questions #

• Q: Describe the step-by-step internal architectural process that occurs within a Kubernetes cluster when a deployment YAML file is applied via kubectl.

• Q: Explain the role of etcd in a Kubernetes cluster. Why must an enterprise etcd deployment be configured in a highly-available, odd-numbered quorum?

14. Summary #

15. Next Chapter Recommendation #