Kubernetes Architecture: The Operating System of the Cloud

[!IMPORTANT] First Principles: Kubernetes (K8s) is not just a container orchestrator; it is a distributed database (Etcd) with a set of controllers (Scheduler, Kubelet) that constantly drive the current state towards a desired state.

Before we dive into the components, let’s understand the problem Kubernetes solves. In the old days, we deployed applications on physical servers. Then came Virtual Machines (VMs). Then came Containers (Docker). But running containers at scale introduced a new problem: How do you manage thousands of containers across hundreds of servers?

You need a system that can:

  1. Schedule: Decide where to run a container.
  2. Heal: Restart a container if it crashes.
  3. Scale: Add more containers if traffic spikes.
  4. Connect: Allow containers to talk to each other.

This is Kubernetes.

1. The “Shipping Port” Analogy

Imagine a massive, automated shipping port. This port represents your Cluster.

  • The Containers: These are your Docker containers (shipping crates). They contain your goods (application code).
  • The Ships: These are your Worker Nodes (VMs or physical servers). They carry the containers.
  • The Control Tower: This is the Control Plane. It manages everything.
  • The Radio Operator (API Server): The only entry point. All instructions (“Load ship A”, “Move crate B”) must go through the radio operator.
  • The Ledger (Etcd): A giant whiteboard where the state of every ship and container is written down. If it’s not on the whiteboard, it doesn’t exist.
  • The Planner (Scheduler): A logistics expert who decides which ship has enough space/capacity for a new container.
  • The Foreman (Controller Manager): Checks the whiteboard. If a ship sinks (Node failure), the Foreman orders new containers to be loaded onto a different ship.
  • The Ship Captain (Kubelet): An agent on every ship. They listen to the Radio Operator and ensure their ship is carrying exactly what the whiteboard says it should.
  • The Traffic Controller (Kube-proxy): Manages the network rules so trucks (requests) can find the right container.

2. The Control Plane (The Brain)

The Control Plane makes global decisions about the cluster (e.g., scheduling) and detects/responds to cluster events (e.g., starting up a new pod).

A. API Server (kube-apiserver)

The Hub and Spoke model. The API Server is the only component that talks to Etcd.

  • Role: The Front Desk / Gateway.
  • Mechanism: Exposes a RESTful API (usually on port 6443).
  • Authentication/Authorization: Verifies who you are (User, ServiceAccount) and what you can do (RBAC).
  • Validation: Checks if your YAML request is valid.

B. Etcd

The Source of Truth.

  • Role: Distributed Key-Value Store.
  • Mechanism: Uses the Raft Consensus Algorithm to ensure data consistency across multiple nodes.
  • Why Key-Value?: It’s fast, simple, and perfect for storing configuration data.
  • Critical: If Etcd is lost, the cluster is lost. Always back up Etcd!

C. Scheduler (kube-scheduler)

The Matchmaker.

  • Role: Assigns new Pods to Nodes.
  • Logic:
    1. Filter: Which nodes can run this pod? (CPU/RAM checks, Taints/Tolerations).
    2. Score: Which node is the best fit? (Spread constraints, Affinity).
    3. Bind: Tell the API Server “Pod X belongs to Node Y”.

D. Controller Manager (kube-controller-manager)

The Reconciler.

  • Role: Runs controller processes.
  • Loop: Current State ≠ Desired State → Make Change.
  • Examples:
  • Node Controller: Notices if a node goes down.
  • Replication Controller: Ensures the correct number of pods are running.

3. The Worker Node (The Muscle)

Worker nodes do the heavy lifting. They run the applications.

A. Kubelet

The Agent.

  • Role: The primary “node agent” that runs on each node.
  • Function:
  • Registers the node with the API Server.
  • Watches for PodSpecs assigned to its node.
  • Talks to the Container Runtime (CRI) to start/stop containers.
  • Reports status back to the API Server.

B. Kube-proxy

The Networker.

  • Role: Maintains network rules on nodes.
  • Function: Implements the Kubernetes Service concept. It forwards traffic to the correct Pod IP.
  • Modes: iptables (default) or IPVS (high performance).

C. Container Runtime

The Engine.

  • Role: Software responsible for running containers.
  • Examples: containerd, CRI-O, Docker Engine (via cri-dockerd).

4. Interactive: Cluster Architecture Visualizer

Hover over the components to see the data flow. Observe how the API Server is the central hub.

Kubernetes Cluster Architecture

Control Plane (Master)

Etcd
The Database
API Server
The Hub
Scheduler
The Planner
CM
The Controller

Worker Node

Kubelet
The Agent
Proxy
Network
Runtime
Docker/CRI
Pod 1
Pod 2
Hover over a component to reveal its secrets.

5. Key Takeaways

  • API Server is King: It is the central hub. No component talks to another directly; they all go through the API Server.
  • Etcd is Critical: It holds the state. Back it up.
  • Worker Nodes are Disposable: If a node dies, the Control Plane (Controller Manager + Scheduler) will just schedule the work elsewhere.
  • Declarative Nature: You tell Kubernetes what you want (Manifest), and the Controllers ensure it happens.

In the next chapter, we will deep dive into the Control Plane Components and see exactly what happens when you run kubectl apply -f pod.yaml.