Study notes17 min read

🐳☸️ Docker and Kubernetes - The Complete Guide

Wijayamuni Dewage Yashith8 Nov 2026 · Associate Software Engineer

From zero to hero, explained as if teaching a small child — with simple examples and diagrams. 18 lessons — Docker (1–8), Kubernetes (9–18).

📑 Table of Contents

Part 1 — Docker

What is Docker? + Image vs Container
Installing it and running your first container
Basic commands
Docker Hub — where to find images
Dockerfile — building your own image
Volumes — keeping your data safe
Ports & Networking
Docker Compose

Part 2 — Kubernetes 9. Why do we need Kubernetes? 10. Cluster, Nodes & Control Plane 11. Pods 12. Deployments 13. Services 14. ConfigMaps & Secrets 15. Namespaces 16. Volumes & Persistent Storage 17. Ingress 18. Everything together — a real app

📝 Commands Cheat Sheet (complete)
🧭 What's next?

🐳 Part 1 — Docker

Lesson 1

What is Docker? + Image vs Container

The problem

A programmer builds an app on their own computer. On their machine it works perfectly. But when it's put on a different computer, it doesn't work. There's a famous phrase for this:

"But it works on my machine!"

The reason: every computer has a different environment (libraries, settings, versions). It's like cooking a chicken curry — if one house has a different cooker and different ingredients than another, the curry won't turn out the same way.

The solution — Docker

Docker is a tool that lets you pack your app and everything it needs (code, libraries, settings, environment) into one box. That box is called a container. Take that box to any computer, and it works exactly the same everywhere.

flowchart TB
    subgraph without["❌ Without Docker"]
        A["Developer laptop<br/>App works"] -->|"move to server"| B["Different server<br/>App breaks 💥"]
        B -.-> C["'works on my machine!'"]
    end

    subgraph with["✅ With Docker"]
        D["Container<br/>App + everything packed"] --> E["Laptop ✅"]
        D --> F["Server ✅"]
        G["Friend's PC ✅"]
        D --> G
    end

The 2 most important words

	Image	Container
What is it?	The recipe / blueprint	The real, running app
State	Read-only	Alive, running
Example	The cake recipe card	The cake you baked
How many	1	You can make many from it

Golden rule: Image → (run) → Container

Lesson 2

Installing it and running your first container

Docker Engine

Docker Engine is the "engine" that creates, runs, and manages containers — like a chef who cooks for the containers. You need to install it on your computer.

Windows / Mac: download and install the Docker Desktop app (docker.com)
Linux: install Docker Engine with a few commands

Check that it installed:

docker --version

Your first container

docker run hello-world

Here's what happens behind the scenes with that one command:

flowchart TB
    A["You: docker run hello-world"] --> B["Docker Engine: do I already have the image?"]
    B -->|"if not"| C["Download from Docker Hub"]
    C --> D["Create a container from the image"]
    B -->|"if yes"| D
    D --> E["Container runs<br/>message is printed ✅"]

A real web server

docker run -d -p 8080:80 nginx

Browser → http://localhost:8080 → "Welcome to nginx!" 🎉

-d → detached mode (runs in the background, your terminal stays free)
-p 8080:80 → port mapping (Lesson 7)
nginx → the image to run

💡 You never installed nginx — Docker fetched it from Docker Hub, set it up, and ran it for you. That's the power of Docker.

Lesson 3

Basic commands

The life of a container (lifecycle)

flowchart LR
    A["Image<br/>the recipe"] -->|"docker run"| B["Running"]
    B -->|"docker stop"| C["Stopped"]
    C -->|"docker start"| B
    C -->|"docker rm"| D["Removed 🗑️"]

Everyday commands

What you want to do	Command
See running containers	`docker ps`
See all (even stopped)	`docker ps -a`
Stop one	`docker stop <name>`
Start it again	`docker start <name>`
Remove one	`docker rm <name>`
See your images	`docker images`
Remove an image	`docker rmi <image>`
See what's going on inside	`docker logs <name>`
Go inside a running container	`docker exec -it <name> bash`

💡 stop = a temporary pause. start = start again. rm = delete completely.

Lesson 4

Docker Hub — where to find images

Docker Hub is the big "app store" for Docker images (like the Play Store, but for images). People all over the world upload images, and anyone can download them for free.

flowchart TB
    HUB["🏪 Docker Hub<br/>nginx | mysql | python | node ..."]
    HUB -->|"pull (download)"| PC["Your computer<br/>takes it and runs it"]
    MINE["The image you built"] -->|"push (upload)"| HUB

Pull = download an image from Docker Hub → docker pull mysql
Push = upload an image you built, to share it

Image name and tag

nginx:1.27
  │     │
  │     └── tag (the version)
  └──────── the image's name

A tag is like a version — python:3.12, mysql:8.0
If you don't give a tag → it automatically uses latest
⚠️ In real projects it's better to specify an exact version (latest changes over time)

Official images (nginx, mysql, python) = verified by Docker and trustworthy. Use these whenever you can.

Lesson 5

Dockerfile — building your own image ⭐

This is the heart of Docker. A Dockerfile is the sheet where you write the recipe for building an image — a list of steps.

Example project (3 files)

app.py (a small Python web app):

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello from my own Docker image! 🎉'

app.run(host='0.0.0.0', port=5000)

requirements.txt:

flask

Dockerfile ⭐:

FROM python:3.12
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]

Every line explained

Keyword	Meaning (simply)
`FROM python:3.12`	Which base image to start from (like a ready-made cake mix)
`WORKDIR /app`	The working folder inside the container (like clearing the kitchen counter)
`COPY . .`	Copy my files into the container (bringing in the ingredients)
`RUN pip install ...`	Commands to run while building the image (installing things)
`EXPOSE 5000`	Which port the app works on (a signboard)
`CMD ["python","app.py"]`	The main thing to start when the container runs

🧠 RUN = while building the image (happens once). CMD = every time the container runs.

Build and run

docker build -t myapp .
docker run -d -p 5000:5000 myapp

Browser → http://localhost:5000 → "Hello from my own Docker image!" 🏆

flowchart LR
    A["Dockerfile<br/>recipe (text)"] -->|"docker build"| B["Image<br/>myapp (read-only)"]
    B -->|"docker run"| C["Container<br/>app is running"]

Lesson 6

Volumes — keeping your data safe

The problem

A container is temporary (like a whiteboard). When you run docker rm, all the data inside is lost. For a database, that's a huge problem!

The solution — Volume

A volume is a place outside the container (on your computer) where data is saved — like an external hard disk. Even if the container is gone, the data in the volume stays exactly as it was.

flowchart TB
    subgraph nov["❌ Without a volume"]
        A["Container<br/>data inside"] -->|"docker rm"| B["data is gone 💥"]
    end

    subgraph wv["✅ With a volume"]
        C["Container"] -->|"connect"| D["Volume<br/>saved on the computer<br/>(like a hard disk)"]
        C -->|"docker rm → new container"| E["Old data is back! ✅"]
        D --> E
    end

Using it — the `-v` flag

docker run -d -v mydata:/var/lib/mysql mysql

-v  mydata : /var/lib/mysql
       │           │
       │           └── where data is saved inside the container
       └────────────── the volume's name (on your computer)

2 types of volumes

	Named Volume	Bind Mount
Left side is	A name (`mydata`)	A real folder path (`/home/...`)
Who manages it	Docker	You
Best used for	Databases, important data	While developing code

Volume commands

What you want to do	Command
List volumes	`docker volume ls`
Create one	`docker volume create mydata`
Remove one	`docker volume rm mydata`

🧠 Golden rule: Give every container that holds a database, user files, or other important data a volume.

How exactly does the folder connect?

-v SOURCE:TARGET — left = the real location, right = the location inside the container. This is not a copy — it's a live link. Both sides point to the very same files.

flowchart LR
    A["Folder on your computer<br/>/home/kamal/myshop/uploads<br/>(SOURCE = left)"] <-->|"the same files (live link)"| B["Folder inside the container<br/>/app/uploads<br/>(TARGET = right)"]

Named volume → managed by Docker (on Linux: /var/lib/docker/volumes/...). Best for databases.
Bind mount → a real folder of yours. Awesome while developing code:
```
# Linux/Mac
docker run -d -p 5000:5000 -v $(pwd):/app myapp
# Windows PowerShell
docker run -d -p 5000:5000 -v ${PWD}:/app myapp
```
$(pwd) = "the folder I'm in right now". If you edit the code, it's instantly updated inside the container too!

💡 Every program has a place inside the container where it stores its data:

MySQL → /var/lib/mysql

PostgreSQL → /var/lib/postgresql/data

MongoDB → /data/db

Lesson 7

Ports & Networking

What is a port?

An apartment building has one address (IP), with a number of flats inside (ports). A port = a specific door.

Web → port 80 / 443
MySQL → 3306
Our Flask app → 5000

The `-p` flag

A container is closed off — to open a door to the outside, you need -p.

-p  8080 : 80
     │      │
     │      └── the port inside the container (where the app runs)
     └───────── the port on your computer (the door from outside)

flowchart LR
    A["Browser<br/>localhost:8080"] --> B["Computer's door<br/>port 8080<br/>(left)"]
    B -->|"-p 8080:80"| C["Inside the container<br/>port 80<br/>nginx"]

The left and right numbers don't have to match: -p 3000:80 → localhost:3000
If a door is already in use, pick another number: -p 9090:80

Two containers talking to each other — Docker Network

A Docker network is a private room just for a few containers. Containers inside it recognise each other by name (no IP needed).

docker network create shop-net
docker run -d --name shop-db --network shop-net mysql:8.0
docker run -d --name web-app --network shop-net myapp

flowchart LR
    subgraph net["Docker network: shop-net (private room)"]
        A["web-app<br/>Flask"] -->|"talks via the name 'shop-db'"| B["shop-db<br/>MySQL"]
    end

For web-app to talk to shop-db, it simply uses the name shop-db itself as the address.

`-p` vs `--network`

	`-p` (port mapping)	`--network`
What for?	Outside world → container	Container → container
Example	browser → web app	web app → database

Lesson 8

Docker Compose

The problem

Running a multi-container app with a pile of commands is long, hard, and error-prone.

The solution — Compose

Docker Compose = the conductor of an orchestra. You write all your containers in one file (docker-compose.yml) and run them with a single command.

`docker-compose.yml`

services:
  web-app:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - shop-db

  shop-db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: mypass123
      MYSQL_DATABASE: shopdb
    volumes:
      - shop-data:/var/lib/mysql

volumes:
  shop-data:

services: → the containers
build: . → build from the Dockerfile
image: → pull from Docker Hub
ports / environment / volumes → the same as -p, -e, -v in the commands, just written neatly
depends_on → what needs to start first

🧠 None of this is new — it's the very same things from the commands, written in an orderly way!

flowchart LR
    A["docker-compose.yml<br/>web-app + shop-db<br/>+ volume + network"] -->|"docker compose up"| B["Automatically: network + volume<br/>+ build + run<br/>the whole app ✅"]

Commands

What you want to do	Command
Run everything (in the background)	`docker compose up -d`
Stop and remove everything	`docker compose down`
View logs	`docker compose logs`
Running services	`docker compose ps`
Rebuild and run again	`docker compose up -d --build`

☸️ Part 2 — Kubernetes

Lesson 9

Why do we need Kubernetes?

Docker Compose is limited to a single computer. As your app grows, problems appear:

💥 One computer isn't enough — you need many servers
😴 If a container crashes, it doesn't come back automatically
📊 How do you add or remove containers depending on the number of customers?
🔥 What if an entire server dies?

The solution — Kubernetes (K8s)

Kubernetes = a "ship's captain" ⚓ that automatically manages lots of containers across lots of servers. (K + 8 letters + s = K8s)

🧭 Distributes — spreads containers properly across servers
❤️‍🩹 Self-healing — a dead one is automatically brought back
📈 Scaling — more or fewer, depending on customers
🔀 Load balancing — spreads traffic properly
🔄 Rolling updates — switch versions with no downtime

flowchart TB
    subgraph c["Docker Compose"]
        A["Just one computer<br/>if it crashes → rebuild by hand"]
    end
    subgraph k["Kubernetes (the Captain manages automatically)"]
        B["Server 1<br/>web, web"]
        C["Server 2<br/>web, database"]
        D["Server 3<br/>web"]
    end

⚠️ Kubernetes ≠ a replacement for Docker. Docker creates containers, Kubernetes manages them — they work together. For small projects Compose is enough; K8s is worth it for big, serious apps.

Lesson 10

Cluster, Nodes & Control Plane

Cluster = the entire Kubernetes setup (the whole restaurant)
Node = a computer/server (a member of the cluster)
Control Plane = the brain / manager (makes decisions, doesn't do the work itself)
Worker Nodes = the chefs (they actually run the containers)

flowchart TB
    subgraph cluster["CLUSTER (the whole setup)"]
        CP["Control Plane (the Captain / the brain)<br/>makes decisions — doesn't run containers"]
        CP -->|"'do this'"| W1["Worker Node 1<br/>container, container"]
        CP --> W2["Worker Node 2<br/>container, database"]
        CP --> W3["Worker Node 3<br/>container"]
    end

`kubectl` — your walkie-talkie

The tool you use to give commands to the control plane (the captain). (Pronounced "cube-control".)

kubectl get nodes    # see the nodes in the cluster
kubectl get pods     # see the running pods

docker = for one computer. kubectl = for the entire cluster.

A cluster to learn on

On your own laptop: Minikube, kind, or Docker Desktop (enable Kubernetes).

💬 Who does `kubectl` talk to?

kubectl is only for you (from outside) → giving orders to the captain (Control Plane). The captain ↔ worker conversation isn't done with kubectl — that happens automatically inside the cluster, via components like kubelet.

flowchart LR
    U["You (laptop)"] -->|"kubectl"| CP["Control Plane (Captain)"]
    CP <-->|"automatic (not kubectl)"| W["Worker Nodes<br/>(kubelet)"]

Lesson 11

Pods

Kubernetes doesn't manage containers directly — it puts the container in a Pod and manages the Pod.

Pod = the smallest unit that K8s manages, wrapping one container (or several) — like a pea pod 🫛.

flowchart LR
    subgraph p1["Pod (usually)"]
        C1["container<br/>(web-app)"]
    end
    subgraph p2["Pod (sometimes)"]
        C2["app"]
        C3["helper"]
    end

Usually a pod has just one container (99% of the time)
Containers in the same pod → share network + storage (they talk over localhost)
⚠️ Pods are temporary — they die, new ones come, and the IP changes

Pod YAML (for learning/testing only)

apiVersion: v1
kind: Pod
metadata:
  name: my-web-pod
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - containerPort: 80

kubectl apply -f my-pod.yaml
kubectl get pods

⚠️ In real projects you don't create pods directly (if one crashes, it doesn't come back). You use a Deployment (next lesson).

Hierarchy — Russian dolls 🪆

flowchart TB
    CL["CLUSTER"] --> N["NODE (a computer)"]
    N --> P["POD (many on one node)"]
    P --> C["CONTAINER (usually one per pod)"]

Cluster ⊃ Nodes ⊃ Pods ⊃ Containers — like building ⊃ apartments ⊃ families. (One node can hold many pods!)

Lesson 12

Deployments ⭐

The most important, everyday-use thing in Kubernetes.

Deployment = the manager that looks after pods (like a thermostat 🌡️). You say "what I want" — it takes care of everything else.

Desired State

You say: "I always want 3 of this pod" (replicas: 3).

If one dies → Kubernetes automatically creates a new one (back to 3)
Just like a thermostat holding the temperature at 24°C

flowchart TB
    D["Deployment (manager)<br/>replicas: 3"] --> P1["Pod 1 ✅"]
    D --> P2["Pod 2 💥 crash"]
    D --> P3["Pod 3 ✅"]
    D -->|"'want 3, have 2' → auto"| P2b["Pod 2 (new!) ✅"]

Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 5000

replicas: 3 ⭐ = "I want 3 pods"
template: = the pods to be created should look like this
labels / selector = a "sticker" 🏷️ on the pods (this is how the Deployment finds its own pods)

Commands

kubectl apply -f deployment.yaml          # create/update
kubectl get deployments
kubectl get pods
kubectl scale deployment web-app --replicas=10   # scale! 📈
kubectl rollout undo deployment web-app          # rollback 🔄

Self-healing test: kubectl delete pod <name> → kubectl get pods → a new one has appeared! 🤯

🔄 Rolling Updates

Change the image in the YAML to myapp:2.0 and run kubectl apply → the old pods are gradually removed and replaced with new ones → switching versions with no downtime.

🧠 Golden rule: In Kubernetes you never create a pod directly — always use a Deployment.

Lesson 13

Services

2 problems

A pod's IP keeps changing — how do you talk to it?
There are 3 pods — which one gets the traffic?

The solution — Service

Service = a front desk 📞 that sits in front of the pods, has a fixed address, and distributes traffic (like an office receptionist).

Even if the pods' IPs change, the Service's address stays fixed ✅
Traffic is spread properly across the pods (load balancing) ✅
It finds the pods using a label (sticker)

flowchart LR
    U["Users"] --> S["Service<br/>fixed address<br/>(front desk)"]
    S -->|"distributes"| P1["Pod 1"]
    S --> P2["Pod 2"]
    S --> P3["Pod 3"]

3 types of Service

Type	What it's for	When
ClusterIP (default)	Internal only 🔒	web-app → database
NodePort	Opened to the outside (simply) 🚪	while testing
LoadBalancer	The real internet 🌍	a production website

Service YAML

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: ClusterIP
  selector:
    app: web          # to the pods that have the 'app: web' sticker
  ports:
    - port: 80
      targetPort: 5000

kubectl apply -f service.yaml
kubectl get services

🏗️ Deployment + Service = the basic set for any Kubernetes app.

Lesson 14

ConfigMaps & Secrets

Hard-coding settings/passwords into your code is bad 😬. So we keep them separate:

ConfigMap 📋 = settings that aren't secret (db name, mode, URL)
Secret 🔐 = secret things (passwords, API keys)

flowchart LR
    CM["ConfigMap 📋<br/>db name, mode, URL"] -->|"inject"| POD["Pod (app)<br/>gets settings from them<br/>(not hard-coded in the code)"]
    SEC["Secret 🔐<br/>password, API key"] -->|"inject"| POD

YAML

ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_NAME: shopdb
  APP_MODE: production

Secret:

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
stringData:
  DB_PASSWORD: mypass123

⚠️ Important: By default a Secret is only "hidden" using base64 — that is not real encryption. Anyone can decode it. In production, enable encryption / use tools like Vault.

Injecting into a Pod (environment variables)

containers:
  - name: web
    image: myapp:1.0
    env:
      - name: DB_NAME
        valueFrom:
          configMapKeyRef:
            name: app-config
            key: DB_NAME
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: app-secret
            key: DB_PASSWORD

kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl get configmaps
kubectl get secrets

Lesson 15

Namespaces

Namespace = a separate "room" 🗂️ inside the cluster — to keep things separated and tidy (like rooms in an office building).

Names only need to be unique within the same namespace (the same name is fine in different namespaces)
Most common use: separating dev / test / production

flowchart TB
    subgraph CL["CLUSTER"]
        subgraph dev["Namespace: dev"]
            D1["web-app"]
            D2["database"]
        end
        subgraph test["Namespace: test"]
            T1["web-app"]
            T2["database"]
        end
        subgraph prod["Namespace: production"]
            P1["web-app"]
            P2["database"]
        end
    end

(All 3 namespaces have a "web-app" — no conflict!)

Ones that already exist

default → where things go if you don't specify a namespace
kube-system → Kubernetes' own stuff (⚠️ don't touch)
kube-public → public stuff

Commands — the `-n` flag matters!

kubectl get namespaces
kubectl create namespace dev
kubectl get pods -n dev           # pods in the dev namespace
kubectl get pods -n production    # pods in production

⚠️ If you don't add -n, it always looks at default. If you can't see the pods in dev, add -n dev!

In YAML: metadata.namespace: dev

Lesson 16

Volumes & Persistent Storage

Since pods are temporary, you need storage to keep data safe (like Docker volumes). Kubernetes separates this into the request and the actual storage:

PersistentVolume (PV) 🗄️ = the actual storage (the books 📚)
PersistentVolumeClaim (PVC) 📝 = the "I need storage" request (the application form)
StorageClass ⚡ = automatically creates PVs for you (in the cloud)

flowchart LR
    POD["Pod (app)<br/>needs to save data"] -->|"use"| PVC["PVC (request)<br/>'I need 5GB' 📝"]
    PVC -->|"K8s matches"| PV["PV (actual storage)<br/>hard disk / cloud 🗄️"]

YAML

PVC (the request):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Using it in a Pod/Deployment:

spec:
  containers:
    - name: db
      image: mysql:8.0
      volumeMounts:
        - name: data
          mountPath: /var/lib/mysql      # where MySQL keeps its data inside the container
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: my-storage

kubectl apply -f pvc.yaml
kubectl get pvc
kubectl get pv
kubectl get storageclass

	Docker	Kubernetes
Keeping data safe	Volume	PV
How you ask for it	`-v name:/path`	PVC
Auto-creates it	—	StorageClass

Lesson 17

Ingress

The problems

💸 One LoadBalancer per app → very expensive
You can't split traffic by URL (/products, /blog)

The solution — Ingress

Ingress 🚦 = the smart traffic policeman standing at the entrance to the cluster. It takes in traffic through a single door, looks at the URL, and directs it to the right Service.

flowchart LR
    I["Internet<br/>users"] --> ING["Ingress 🚦<br/>looks at the URL<br/>(one door)"]
    ING -->|"/products"| S1["products Service"]
    ING -->|"/blog"| S2["blog Service"]
    ING -->|"/api"| S3["api Service"]

⚠️ Ingress = just the rules. You need to install an Ingress Controller to actually carry them out (the most popular: nginx-ingress).

Ingress = the rulebook 📖

Ingress Controller = the actual policeman 👮

Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
spec:
  rules:
    - host: shop.com
      http:
        paths:
          - path: /products
            pathType: Prefix
            backend:
              service:
                name: products-service
                port:
                  number: 80
          - path: /blog
            pathType: Prefix
            backend:
              service:
                name: blog-service
                port:
                  number: 80

kubectl apply -f ingress.yaml
kubectl get ingress

🔒 HTTPS (SSL/TLS) can also be managed in the Ingress, all in one place.

Lesson 18

Everything together — a real app 🎓

An online shop — every concept we've learned, working together:

flowchart TB
    U["Users (internet) 🌍"] --> ING["Ingress 🚦 (shop.com)"]
    ING --> WS["web Service 🚪"]
    WS --> WD

    subgraph WD["web Deployment (replicas: 3) ❤️‍🩹"]
        W1["web pod"]
        W2["web pod"]
        W3["web pod"]
    end

    CFG["ConfigMap 📋<br/>Secret 🔐"] -->|"settings"| WD
    WD -->|"via the name 'db-service'"| DS["db Service 🚪 (ClusterIP)"]
    DS --> DB["db pod (MySQL) 🗄️"]
    DB --> PVC["PVC → PV 💾<br/>(data is safe)"]

The journey of a request 🚶

🌍 A customer comes to shop.com
🚦 Ingress → looks at the URL and sends it to the web Service
🚪 web Service → picks one of the 3 pods (load balancing)
📦 web pod processes it (settings/password from the ConfigMap + Secret)
🗄️ If it needs the db → goes to the db Service using the name db-service
💾 db pod → data is kept safe on the PVC → PV
↩️ The answer goes back to the customer — the website appears! 🎉

Deployment order

File	What it's for	Lesson
`configmap.yaml`	settings	14
`secret.yaml`	password	14
`pvc.yaml`	database storage	16
`db-deployment.yaml` + `db-service.yaml`	database	12, 13
`web-deployment.yaml` + `web-service.yaml`	web app	12, 13
`ingress.yaml`	internet access	17

kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl apply -f pvc.yaml
kubectl apply -f db-deployment.yaml
kubectl apply -f db-service.yaml
kubectl apply -f web-deployment.yaml
kubectl apply -f web-service.yaml
kubectl apply -f ingress.yaml

💡 Put everything in one folder and run kubectl apply -f . to do it all at once!

Commands Cheat Sheet

🐳 Docker

# Images & containers
docker --version
docker run hello-world
docker run -d -p 8080:80 nginx       # detached + port mapping
docker ps                             # running containers
docker ps -a                          # all of them
docker stop <name>                    # stop
docker start <name>                   # start again
docker rm <name>                      # remove
docker logs <name>                    # view logs
docker exec -it <name> bash           # go inside

# Images
docker images                         # list images
docker pull mysql                     # download
docker rmi <image>                    # remove an image
docker build -t myapp .               # Dockerfile → image

# Volumes
docker volume ls
docker volume create mydata
docker run -d -v mydata:/var/lib/mysql mysql
docker run -d -v $(pwd):/app myapp    # bind mount

# Network
docker network create shop-net
docker run -d --name web --network shop-net myapp

# Compose
docker compose up -d
docker compose down
docker compose logs
docker compose ps
docker compose up -d --build

☸️ Kubernetes (`kubectl`)

# View
kubectl get nodes
kubectl get pods
kubectl get deployments
kubectl get services
kubectl get ingress
kubectl get configmaps
kubectl get secrets
kubectl get pvc
kubectl get pv
kubectl get namespaces

# Create / update
kubectl apply -f file.yaml
kubectl apply -f .                    # everything in the folder

# Deployment
kubectl scale deployment web-app --replicas=10
kubectl rollout undo deployment web-app

# Namespace
kubectl create namespace dev
kubectl get pods -n dev               # -n = which namespace

# Debug
kubectl logs <pod>
kubectl describe pod <pod>
kubectl delete pod <pod>              # (the Deployment will recreate it)

What's next?

Going deeper into Kubernetes:

🩺 Probes (liveness/readiness) — checking whether a pod is healthy
📊 HPA (Horizontal Pod Autoscaler) — automatically increasing/decreasing the number of pods
📦 Helm — the "package manager" for Kubernetes
🔐 RBAC — who is allowed to do what (security)

Real-world work:

🔄 CI/CD — push code → automatically build & deploy
📈 Monitoring — Prometheus + Grafana
☁️ Managed Kubernetes — AWS (EKS), Google (GKE), Azure (AKS)

The most important thing — hands-on experience! 🛠️ Install Docker Desktop or Minikube on your laptop and build this shop app by hand. You learn far more by doing than by reading — it's what really sticks in the mind.

🎓 Summary of the core ideas

Concept	In one sentence
Image	The app's recipe/blueprint (read-only)
Container	The real, running app made from that recipe
Dockerfile	The recipe sheet that builds the image
Volume	External storage to keep data safe
Docker Compose	Multi-container → one file, one command
Kubernetes	The captain that auto-manages lots of containers
Cluster	The entire K8s setup
Node	A computer/server
Pod	The smallest unit wrapping containers
Deployment	The manager that looks after pods (self-heal, scale)
Service	A fixed address for pods + load balancing
ConfigMap / Secret	Settings / secrets (kept separate from the code)
Namespace	A separate room inside the cluster
PV / PVC	The actual storage / the request for storage
Ingress	The policeman that routes traffic by URL

🎉 Congratulations! You've learned Docker and Kubernetes from start to finish. Now go get some hands-on experience! 💪

📑 Table of Contents

🐳 Part 1 — Docker

Lesson 1

What is Docker? + Image vs Container

The problem

The solution — Docker

The 2 most important words

Lesson 2

Installing it and running your first container

Docker Engine

Your first container

A real web server

Lesson 3

Basic commands

The life of a container (lifecycle)

Everyday commands

Lesson 4

Docker Hub — where to find images

Image name and tag

Lesson 5

Dockerfile — building your own image ⭐

Example project (3 files)

Every line explained

Build and run

Lesson 6

Volumes — keeping your data safe

The problem

The solution — Volume

Using it — the -v flag

2 types of volumes

Volume commands

How exactly does the folder connect?

Lesson 7

Ports & Networking

What is a port?

The -p flag

Two containers talking to each other — Docker Network

-p vs --network

Lesson 8

Docker Compose

The problem

The solution — Compose

docker-compose.yml

Commands

☸️ Part 2 — Kubernetes

Lesson 9

Why do we need Kubernetes?

The solution — Kubernetes (K8s)

Lesson 10

Cluster, Nodes & Control Plane

kubectl — your walkie-talkie

A cluster to learn on

💬 Who does kubectl talk to?

Lesson 11

Pods

Pod YAML (for learning/testing only)

Hierarchy — Russian dolls 🪆

Lesson 12

Deployments ⭐

Desired State

Deployment YAML

Commands

🔄 Rolling Updates

Lesson 13

Services

2 problems

The solution — Service

3 types of Service

Service YAML

Lesson 14

ConfigMaps & Secrets

YAML

Injecting into a Pod (environment variables)

Lesson 15

Namespaces

Ones that already exist

Commands — the -n flag matters!

Lesson 16

Volumes & Persistent Storage

YAML

Using it — the `-v` flag

The `-p` flag

`-p` vs `--network`

`docker-compose.yml`

`kubectl` — your walkie-talkie

💬 Who does `kubectl` talk to?

Commands — the `-n` flag matters!

☸️ Kubernetes (`kubectl`)