Day 1: Welcome to Kubernetes

What You'll Learn Today

What Kubernetes is and why you need it
The natural progression from Docker to Kubernetes
Kubernetes architecture and key components
The declarative model and desired state

From Docker to Kubernetes

In "Learn Docker in 10 Days," you mastered container fundamentals. Docker lets you package applications as containers and run them consistently anywhere. Docker Compose enabled multi-container orchestration on a single host.

But running containers at scale in production introduces new challenges.

flowchart TB
    subgraph Docker["Docker Alone"]
        D1["Container crashes?"]
        D2["One server isn't enough?"]
        D3["Zero-downtime updates?"]
        D4["Auto-scale with load?"]
    end
    subgraph K8s["Kubernetes Solves It"]
        K1["Self-healing"]
        K2["Multi-node cluster management"]
        K3["Rolling updates"]
        K4["Autoscaling"]
    end
    D1 --> K1
    D2 --> K2
    D3 --> K3
    D4 --> K4
    style Docker fill:#f59e0b,color:#fff
    style K8s fill:#3b82f6,color:#fff

Docker Compose vs. Kubernetes

Feature	Docker Compose	Kubernetes
Scope	Single host	Multi-node cluster
Self-healing	None	Automatic pod restart
Scaling	Manual	Autoscaling support
Load balancing	Manual setup	Built-in via Services
Rolling updates	None	Native support
Health checks	Basic	Detailed probe configuration
Secret management	.env files	Secret objects

What is Kubernetes?

Kubernetes (K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.

Originally developed by Google based on over a decade of experience running containers at scale with their internal system "Borg," Kubernetes was open-sourced in 2014. It is now maintained by the Cloud Native Computing Foundation (CNCF).

Origin of the Name

"Kubernetes" comes from Greek, meaning "helmsman" or "pilot." The abbreviation K8s refers to the 8 characters between "K" and "s."

Kubernetes Architecture

A Kubernetes cluster consists of two main layers: the Control Plane and Worker Nodes.

flowchart TB
    subgraph CP["Control Plane"]
        API["API Server"]
        ETCD["etcd"]
        SCHED["Scheduler"]
        CM["Controller Manager"]
    end
    subgraph W1["Worker Node 1"]
        KL1["kubelet"]
        KP1["kube-proxy"]
        P1["Pod A"]
        P2["Pod B"]
    end
    subgraph W2["Worker Node 2"]
        KL2["kubelet"]
        KP2["kube-proxy"]
        P3["Pod C"]
        P4["Pod D"]
    end
    API --> KL1
    API --> KL2
    API --> ETCD
    SCHED --> API
    CM --> API
    style CP fill:#8b5cf6,color:#fff
    style W1 fill:#3b82f6,color:#fff
    style W2 fill:#3b82f6,color:#fff

Control Plane Components

Component	Role
API Server	Front door for all cluster requests. kubectl commands are sent here
etcd	Distributed key-value store holding all cluster state
Scheduler	Decides which node should run new Pods
Controller Manager	Runs controllers that maintain desired state

Worker Node Components

Component	Role
kubelet	Agent managing Pod execution on each node
kube-proxy	Manages network rules and routes traffic to Pods
Container Runtime	Actually runs containers (containerd, etc.)

The Declarative Model: The Heart of Kubernetes

The most important concept in Kubernetes is the declarative model.

With Docker, you issued imperative commands: "run this container," "stop this container."

With Kubernetes, you declare the desired state: "I want 3 replicas of this application running."

flowchart LR
    subgraph Imperative["Imperative (Docker)"]
        I1["docker run app"]
        I2["docker stop app"]
        I3["docker run app"]
    end
    subgraph Declarative["Declarative (Kubernetes)"]
        D1["Desired state:\nreplicas: 3"]
        D2["Kubernetes\nmaintains it"]
    end
    style Imperative fill:#f59e0b,color:#fff
    style Declarative fill:#22c55e,color:#fff

How the Declarative Model Works

Define desired state → Write a YAML manifest specifying "3 replicas"
Submit to API Server → Apply with kubectl
Controllers watch → Continuously compare current state vs. desired state
Auto-correct differences → If a Pod dies, a new one is automatically created

This "observe → compare → correct" loop is called the Reconciliation Loop.

Key Kubernetes Objects

Kubernetes has many objects (resources). Here are the key ones covered in this book.

flowchart TB
    subgraph Workload["Workloads"]
        POD["Pod"]
        RS["ReplicaSet"]
        DEP["Deployment"]
    end
    subgraph Network["Networking"]
        SVC["Service"]
        ING["Ingress"]
    end
    subgraph Config["Configuration & Storage"]
        CM["ConfigMap"]
        SEC["Secret"]
        PV["PersistentVolume"]
    end
    DEP --> RS
    RS --> POD
    SVC --> POD
    ING --> SVC
    CM --> POD
    SEC --> POD
    PV --> POD
    style Workload fill:#3b82f6,color:#fff
    style Network fill:#22c55e,color:#fff
    style Config fill:#8b5cf6,color:#fff

Object	Description	Docker Equivalent
Pod	Smallest deployable unit	Container
ReplicaSet	Maintains a set number of Pod replicas	-
Deployment	Manages ReplicaSets with update control	-
Service	Stable network access to Pods	Network
Ingress	HTTP routing from external traffic	Port mapping
ConfigMap	Configuration data management	Environment variables
Secret	Sensitive data management	.env file
PersistentVolume	Data persistence	Volume

Benefits of Kubernetes

1. Self-healing

Automatically reschedules containers when they fail or nodes go down.

2. Horizontal Scaling

Automatically adjusts Pod count based on load (Horizontal Pod Autoscaler).

3. Rolling Updates

Updates applications gradually with zero downtime. Rollback is available if issues arise.

4. Service Discovery and Load Balancing

Assigns DNS names to Pods and automatically distributes traffic.

5. Storage Orchestration

Automatically mounts various storage systems — local, cloud provider, and more.

6. Declarative Configuration and Version Control

Everything defined in YAML files enables Git-based infrastructure management (Infrastructure as Code).

Summary

Concept	Description
Kubernetes	Container orchestration platform
Control Plane	Cluster brain (API Server, etcd, Scheduler, Controller Manager)
Worker Node	Machines where containers run (kubelet, kube-proxy)
Declarative Model	Define "desired state" and Kubernetes maintains it automatically
Reconciliation Loop	Auto-corrects differences between current and desired state

Key Takeaways

Kubernetes is the next step after Docker — it automates container operations and management
The declarative model lets you describe "what you want," and Kubernetes handles "how to do it"
The cluster has a two-layer structure: Control Plane and Worker Nodes

Practice Exercises

Exercise 1: Basics

List three key differences between Docker Compose and Kubernetes.

Exercise 2: Architecture

Name and describe the four Control Plane components.

Challenge

Explain the difference between declarative and imperative models using a real-life analogy (e.g., ordering at a restaurant, giving directions to a taxi driver).

References

Next up: In Day 2, you'll learn about "Setting Up Your Cluster and kubectl." We'll prepare a Kubernetes environment and run our first commands.