Kubernetes Architecture: The City That Runs Itself 🏙️

Imagine a magical city where thousands of robots work together, and a smart brain at the center tells each robot exactly where to go and what to do. If one robot breaks, another takes its place instantly. Nobody panics. The city just keeps running.

That city is Kubernetes. And today, you’ll learn how to be the mayor!

What is Kubernetes?

Think of Kubernetes (we call it K8s for short—because there are 8 letters between ‘K’ and ‘s’) as a super-smart robot manager.

The Problem It Solves

Imagine you have 100 toy robots (your apps), and you need to:

• Make sure they’re all turned on
• Replace broken ones instantly
• Add more robots when lots of kids want to play
• Keep track of where each robot is

Doing this by hand? Exhausting! 😫

Kubernetes does all this automatically. You just say “I want 5 robots running” and K8s makes it happen—and keeps it that way!

Real-World Example

You: "Hey K8s, run 3 copies of my website"
K8s: "Done! Running on machines 1, 4, and 7"

[Machine 4 crashes]

K8s: "No worries! Started a new copy on machine 9"

You didn’t do anything. K8s handled it like a boss. 😎

K8s Architecture Overview

Let’s meet the two main parts of our magical city:

graph TD
    A[🧠 Control Plane<br/>The Brain] --> B[👷 Worker Nodes<br/>The Workers]
    B --> C[📦 Pods<br/>Your Apps]

The Two Teams

The Control Plane says “Run this app on Node 3” and the Worker Node does it. Simple!

Control Plane Overview

The Control Plane is the brain of Kubernetes. It has several parts, each with a special job:

graph TD
    A[📮 API Server<br/>Front Door] --> B[📝 etcd<br/>Memory Book]
    A --> C[🎯 Scheduler<br/>Assignment Manager]
    A --> D[🔄 Controller Manager<br/>Quality Checker]
    A --> E[☁️ Cloud Controller<br/>Cloud Connector]

Think of it like a school office:

• API Server = Reception desk (talks to everyone)
• etcd = Filing cabinet (stores all records)
• Scheduler = Teacher assigning seats
• Controller Manager = Principal checking everything’s okay
• Cloud Controller = Connection to school district

Let’s meet each one!

K8s API Request Flow

When you tell Kubernetes to do something, here’s the journey your request takes:

graph TD
    A[👤 You type kubectl] --> B[📮 API Server receives it]
    B --> C[🔐 Authentication<br/>Who are you?]
    C --> D[✅ Authorization<br/>Can you do this?]
    D --> E[📋 Admission Control<br/>Any rules to follow?]
    E --> F[💾 Save to etcd]
    F --> G[✨ Action happens!]

Step-by-Step Story

You: “Hey K8s, create a new app called ‘my-game’!”

1. API Server hears you 👂
2. Checks your ID badge (Authentication) - “Are you allowed here?”
3. Checks your permissions (Authorization) - “Can you create apps?”
4. Applies rules (Admission) - “Apps must have labels? Okay, added!”
5. Writes it down (etcd) - “Noted in the record book!”
6. Makes it happen - Your app starts running!

Example Command Flow

# You run this command
kubectl create deployment my-game --image=tetris

# Behind the scenes:
# 1. kubectl → API Server (HTTPS request)
# 2. API Server → "Is this user legit?" ✓
# 3. API Server → "Can they create deployments?" ✓
# 4. API Server → "Save to etcd" ✓
# 5. Scheduler → "Put it on Node 2"
# 6. Node 2 → "Running tetris!" 🎮

etcd Fundamentals

etcd (pronounced “et-see-dee”) is Kubernetes’ memory book. It remembers EVERYTHING.

What etcd Stores

Think of it as a giant notebook that stores:

• What apps should be running
• Where each app is running
• All the settings and secrets
• Who’s allowed to do what

graph TD
    A[📝 etcd Database] --> B[Desired State<br/>What you WANT]
    A --> C[Current State<br/>What IS happening]
    A --> D[Configuration<br/>All settings]
    A --> E[Secrets<br/>Passwords safely stored]

Why etcd is Special

Simple Example

Key: "apps/my-game/replicas"
Value: "3"

Translation: "my-game should have 3 copies running"

If etcd forgets, Kubernetes forgets. That’s why we always back it up! 💾

kube-apiserver

The kube-apiserver is the front door of Kubernetes. EVERYTHING goes through it.

What It Does

graph TD
    A[👤 Users] --> D[📮 API Server]
    B[🔧 kubectl] --> D
    C[🤖 Controllers] --> D
    D --> E[📝 etcd]
    D --> F[👷 Worker Nodes]

Think of it as a super-organized receptionist:

• Takes all requests
• Checks if you’re allowed in
• Sends you to the right place
• Keeps records of everything

Key Responsibilities

1. Authentication - “Show me your ID!”
2. Authorization - “Let me check what you can do…”
3. Admission Control - “Following the rules? Great!”
4. Request Handling - “I’ll process that for you!”

Talking to the API Server

# Using kubectl (the easy way)
kubectl get pods

# Direct API call (behind the scenes)
GET https://your-cluster:6443/api/v1/pods

The API Server speaks REST—just like websites! It understands:

• GET = “Show me something”
• POST = “Create something new”
• PUT = “Update this thing”
• DELETE = “Remove this thing”

kube-scheduler

The kube-scheduler is like a smart seating chart maker for your apps.

The Scheduler’s Job

When a new app needs to run, the scheduler asks:

graph TD
    A[New Pod needs a home!] --> B{Which node?}
    B --> C[Node 1<br/>💻 8GB RAM free]
    B --> D[Node 2<br/>💻 2GB RAM free]
    B --> E[Node 3<br/>💻 16GB RAM free]
    C --> F[✅ Good choice!]
    E --> F
    D --> G[❌ Not enough space]

How It Decides

The scheduler looks at:

Example Decision

# Your app needs:
resources:
  requests:
    memory: "512Mi"
    cpu: "250m"

# Scheduler thinks:
# Node 1: Has 2GB free RAM ✓ Has 500m CPU ✓ → SELECTED!
# Node 2: Has 256Mi RAM ✗ → Won't fit
# Node 3: Has 4GB RAM ✓ But too far from database → Skip

kube-controller-manager

The kube-controller-manager runs control loops—like obsessive checkers that constantly ask “Is everything okay?”

What Controllers Do

graph TD
    A[🔄 Controller Manager] --> B[Deployment Controller<br/>Right number of pods?]
    A --> C[Node Controller<br/>All nodes healthy?]
    A --> D[Job Controller<br/>Jobs completed?]
    A --> E[Service Controller<br/>Connections working?]

The Magic Loop

Every controller follows this pattern:

FOREVER:
  1. Look at what SHOULD be (desired state)
  2. Look at what IS (current state)
  3. Make changes to match them
  4. Wait a bit
  5. Repeat!

Real Example: Deployment Controller

# You said: "I want 3 copies of my-app"
spec:
  replicas: 3

# Controller checks every few seconds:
# "How many pods exist?" → 2
# "How many should exist?" → 3
# "2 ≠ 3... Creating 1 more pod!"

# Next check:
# "How many pods exist?" → 3
# "How many should exist?" → 3
# "3 = 3 Perfect! Nothing to do."

Types of Controllers

cloud-controller-manager

The cloud-controller-manager is the translator between Kubernetes and your cloud provider (AWS, Google Cloud, Azure, etc.).

Why It Exists

graph TD
    A[☁️ Cloud Controller Manager] --> B[🌐 Load Balancers<br/>AWS/GCP/Azure]
    A --> C[💿 Storage<br/>Cloud Disks]
    A --> D[🖥️ Nodes<br/>Cloud VMs]
    A --> E[🔀 Routes<br/>Network Paths]

Kubernetes doesn’t know how to talk to AWS directly. The cloud-controller-manager handles that conversation!

What It Manages

Example: Creating a Load Balancer

# You create this service:
apiVersion: v1
kind: Service
metadata:
  name: my-website
spec:
  type: LoadBalancer  # ← Magic word!
  ports:
  - port: 80

# Cloud Controller sees "LoadBalancer" and:
# 1. Calls AWS API
# 2. Creates an ELB
# 3. Configures health checks
# 4. Updates service with external IP

Result: Your website gets a public IP automatically! 🎉

Putting It All Together

Here’s how all the pieces work as a team:

graph TD
    U[👤 You] -->|kubectl| API[📮 API Server]
    API -->|read/write| ETCD[📝 etcd]
    API -->|watch| SCH[🎯 Scheduler]
    API -->|watch| CM[🔄 Controller Manager]
    API -->|watch| CCM[☁️ Cloud Controller]
    SCH -->|assign pods| API
    CM -->|update resources| API
    CCM -->|manage cloud| CLOUD[☁️ Cloud Provider]
    API -->|instructions| NODES[👷 Worker Nodes]

The Story of Creating an App

1. You run kubectl create deployment game --image=tetris
2. API Server checks you’re allowed and saves to etcd
3. Deployment Controller sees “new deployment!” and creates a Pod spec
4. Scheduler picks the best node for the Pod
5. Worker Node downloads the image and starts your game
6. Cloud Controller (if needed) creates load balancers

Total time: Usually under 30 seconds! ⚡

Key Takeaways

You Did It! 🎉

You now understand how Kubernetes works under the hood. The control plane is like a well-organized office where:

• The API Server handles all communication
• etcd remembers everything
• The Scheduler finds homes for your apps
• Controllers make sure everything stays perfect
• The Cloud Controller talks to your cloud provider

Next time you run kubectl, you’ll know exactly what happens behind the scenes!

Remember: Kubernetes isn’t magic—it’s just a really well-organized team of components working together. And now you understand each team member! 🚀