Kubernetes From Zero to Hero – Part 2:

Why Architecture Matters

Understanding Kubernetes architecture is like understanding how a car works before you drive it. If you know what each part does, you’ll be able to troubleshoot, optimise, and scale more effectively.

Let’s break it down into two key layers:

1. Control Plane – The “brain” of Kubernetes

2. Worker Nodes – The “muscle” where your apps actually run

---

1. Kubernetes Architecture Overview

Let’s look at the big picture:

                 [ kubectl / Dashboard / API Client ]
                                 |
                            [ API Server ]
                                 |
      -----------------------------------------------------
      |                   |                       |
 [ Controller Manager ] [ Scheduler ]         [ etcd (DB) ]
                                 |
      -----------------------------------------------------
      |                  |                   |
  [ Worker Node 1 ]  [ Worker Node 2 ]   [ Worker Node 3 ]
       |                  |                   |
    [ Pod A ]           [ Pod B ]           [ Pod C ]

Now, let’s walk through each component and what it does.

---

2. The Control Plane – The Brain of the Cluster

These are the components that make decisions, store cluster state, and manage the scheduling and scaling of your applications.

a) API Server

• The front door to your cluster.

• Accepts commands via kubectl, REST calls, Helm, etc.

• All components talk through the API server.

• Think of it like Kubernetes’ receptionist and traffic cop.

• Example: When you run kubectl apply -f nginx.yaml, the API server receives and processes that request.

b) etcd

• A distributed key-value store.

• Stores the entire state of the cluster (e.g., pods, nodes, secrets, config).

• Highly available and consistent (backed by the Raft algorithm).

• Analogy: It’s Kubernetes’ memory – everything it knows is stored here.

c) Controller Manager

• Watches the cluster state and reacts to changes.

• Has sub-controllers like:

  • Node Controller (detects node failures)

  • Replication Controller (keeps pod counts correct)

  • Job Controller, etc.

  • Example: If a pod crashes, the replication controller spins up a new one.

d) Scheduler

• Assigns pods to nodes based on available resources, affinity rules, and policies.

• Ensures optimal placement of workloads.

• Analogy: Like a hotel receptionist assigning rooms to guests (pods).

---

3. The Worker Nodes – The Body of the Cluster

This is where your actual applications run.

a) Kubelet

• An agent running on each node.

• Talks to the API server.

• Ensures the containers described in PodSpecs are running.

• Think of it as the node’s manager.

b) Kube-proxy

• Handles network routing and traffic rules for services.

• Manages access between pods and services across nodes.

• Acts like a traffic controller for service discovery.

c) Container Runtime

• The software that runs the containers.

• Examples: containerd, CRI-O, Docker (deprecated in K8s v1.24+).

• Think of it as the engine that actually runs your containers.

---

4. The Pod – Smallest Deployable Unit

A pod is a wrapper around one or more containers.

• All containers in a pod share the same network IP and storage volume.

• Usually, one container per pod (but not always).

• Example use case: A pod with a web server + sidecar logging agent.

---

How Everything Connects – Flow Example

1. You run kubectl apply to create a pod.

2. API server accepts and saves the request in etcd.

3. Scheduler finds a suitable node.

4. Controller ensures the pod spec is maintained.

5. Kubelet on that node pulls the image, starts the pod.

6. Kube-proxy routes traffic to the new pod as needed.

---

Real-World Analogy

---

Summary

• Kubernetes is split into a Control Plane (brain) and Worker Nodes (body).

• The control plane manages state, scheduling, and monitoring.

• The worker nodes run your actual applications in containers (via pods).

• Understanding these basics is critical before deploying real workloads.

---

Coming Up Next

In the next post, we’ll look at:
👉 Setting up a Kubernetes cluster locally using Minikube
👉 Hands-on: Running your first Pod
👉 Understanding the lifecycle of a Pod with YAML examples