← Back to all projects

LEARN KUBERNETES

Learn Kubernetes (K8s) by Building

Goal: Understand Kubernetes not as a “magic black box” that runs containers, but as a distributed operating system. You will learn how it schedules workloads, manages networking, persists data, and self-heals.

The Mindset: Kubernetes is fundamentally a Control Loop.

  1. You tell it what you want (Desired State: “Run 3 copies of Nginx”).
  2. It looks at what exists (Current State: “0 copies running”).
  3. It takes action to fix it (Action: “Start 3 containers”).

Every project below explores a different part of this loop.

Core Concept Analysis

To learn K8s, you must break it down:

  1. The Primitive: The Container (Docker).
  2. The Brain: The Control Plane (API Server, Scheduler, Etcd).
  3. The Muscle: The Worker Nodes (Kubelet, Kube-proxy).
  4. The Network: CNI, Services, Ingress.
  5. The State: Persistent Volumes (CSI).

Project List

Project 1: The “Poor Man’s” Orchestrator (Shell Script K8s)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: Bash (Shell Scripting)
  • Alternative Programming Languages: Python
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold” (Understanding the “Why”)
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Orchestration Logic / Monitoring
  • Software or Tool: Docker
  • Main Book: “Kubernetes: Up and Running” by Brendan Burns (Co-creator of K8s)

What you’ll build: A script that mimics the Kubernetes Controller Manager. It will read a simple configuration file (desired_state.txt), check if a Docker container is running, and if not (or if it crashes), it will automatically restart it.

Why it teaches Kubernetes: Before using K8s, you must understand why it exists. K8s effectively does what this script does, but for thousands of machines. This teaches you the concept of the Reconciliation Loop.

Core challenges you’ll face:

  • State Monitoring: How do you ask Docker “is this container running?” programmatically?
  • The Loop: Implementing an infinite loop that checks state without eating 100% CPU.
  • Configuration Parsing: Reading “I want 3 nginx containers” and translating that to logic.

Key Concepts:

  • Desired State vs. Current State: The fundamental theorem of K8s.
  • Self-Healing: Automatic recovery from failure.

Difficulty: Beginner/Intermediate Time estimate: Weekend Prerequisites: Docker basics.

Real world outcome:

  1. Run ./orchestrator.sh.
  2. It starts an Nginx container.
  3. You manually run docker stop nginx.
  4. Within 5 seconds, your script detects it and starts a new one automatically.

Implementation Hints: Create a file manifest.txt with image: nginx, count: 1. Write a loop:

  1. Parse file.
  2. Run docker ps.
  3. If container missing -> docker run.
  4. Sleep 5 seconds.

Project 2: The “Hard Way” Cluster (Local Setup)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: Bash / CLI
  • Alternative Programming Languages: N/A
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. Service & Support
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Cluster Architecture
  • Software or Tool: Vagrant / VirtualBox (or 2 cloud VMs)
  • Main Book: “Kubernetes the Hard Way” by Kelsey Hightower (Online Tutorial)

What you’ll build: A functional Kubernetes cluster without using easy tools like Minikube, Kind, or EKS. You will manually install the Container Runtime (containerd), the Kubelet, and initiate the cluster using kubeadm on virtual machines.

Why it teaches Kubernetes: Tools like Minikube hide the architecture. By installing it manually, you learn that K8s is just a set of binaries (kube-apiserver, kube-scheduler, kubelet) talking to each other.

Core challenges you’ll face:

  • Networking: Making the Worker Node talk to the Control Plane Node.
  • CNI (Container Network Interface): Installing a network plugin (like Calico or Flannel) so pods can talk to each other.
  • Certificates: Understanding that K8s relies heavily on TLS for internal communication.

Key Concepts:

  • Control Plane Components: API Server, Controller Manager, Scheduler.
  • Worker Components: Kubelet, Kube-proxy.
  • Etcd: The database where K8s stores its state.

Difficulty: Advanced Time estimate: 1 week Prerequisites: Linux CLI comfort.

Real world outcome: You run kubectl get nodes and see your two manual VMs listed as Ready. You feel like a wizard.

Implementation Hints: Use kubeadm. It is the standard tool for bootstrapping.

  1. VM1 (Master): Install kubeadm, kubelet, kubectl, containerd. Run kubeadm init.
  2. VM2 (Worker): Install containerd, kubelet. Run the kubeadm join command output by the Master.
  3. Install a CNI plugin (e.g., Calico) or the nodes will never become “Ready”.

Project 3: The “Resilient” Web App (Deployments & ReplicaSets)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: YAML (K8s Manifests)
  • Alternative Programming Languages: N/A
  • Coolness Level: Level 2: Practical
  • Business Potential: 2. Micro-SaaS
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Workload Management
  • Software or Tool: kubectl
  • Main Book: “Kubernetes in Action” by Marko Luksa

What you’ll build: A Deployment manifest that ensures 3 replicas of a web server are always running. You will then simulate a crash and watch K8s fix it.

Why it teaches Kubernetes: This introduces the Deployment object, which manages ReplicaSets, which manage Pods. This is the standard way to run stateless applications.

Core challenges you’ll face:

  • YAML Syntax: K8s YAML is indentation-sensitive and verbose.
  • Labels & Selectors: How the Deployment knows which Pods belong to it (Crucial concept).

Key Concepts:

  • Pod: The smallest unit of deployment (not the container!).
  • ReplicaSet: Ensures X copies exist.
  • Rolling Update: Updating the image without downtime.

Difficulty: Beginner Time estimate: Weekend Prerequisites: Working cluster (from Project 2 or Minikube).

Real world outcome:

  1. Apply the YAML.
  2. Run kubectl get pods. See 3 pods.
  3. Run kubectl delete pod <name-of-one-pod>.
  4. Immediately run kubectl get pods again. You will see the old one terminating and a NEW one already starting.

Project 4: The “Service Discovery” Lab (Networking)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: YAML
  • Alternative Programming Languages: Python (for the app code)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. Service & Support
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Internal Networking / DNS
  • Software or Tool: CoreDNS
  • Main Book: “Kubernetes in Action”

What you’ll build: Two separate applications: a Frontend (Web) and a Backend (API). The Frontend will call the Backend using its name (e.g., http://my-backend), not an IP address.

Why it teaches Kubernetes: In K8s, Pod IPs change all the time. You cannot hardcode IPs. You must use Services (ClusterIP) and DNS. This project proves how K8s handles internal routing.

Core challenges you’ll face:

  • ClusterIP: Creating a stable IP for a set of dynamic pods.
  • DNS Resolution: Debugging why curl http://backend works or fails.
  • Environment Variables: How K8s injects service info into pods.

Key Concepts:

  • Service (ClusterIP): Internal load balancer.
  • CoreDNS: The internal DNS server of K8s.
  • Endpoints: The list of actual Pod IPs the Service points to.

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Docker, Basic Python/Node app building.

Real world outcome: You exec into the Frontend pod. You run curl http://my-backend-service. It returns a JSON response from the Backend pod. You delete the Backend pod, K8s creates a new one, and curl still works with the same name.

Implementation Hints: Write a simple Python Flask app for the backend that returns {"message": "Hello"}. Write a Service YAML for the backend named backend-svc. In the frontend, code the request to http://backend-svc.

Project 5: The “Public Gatekeeper” (Ingress Controller)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: YAML
  • Alternative Programming Languages: N/A
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. Micro-SaaS
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: External Networking / HTTP Routing
  • Software or Tool: Nginx Ingress Controller / Traefik
  • Main Book: “Kubernetes Up and Running”

What you’ll build: A single Load Balancer that routes traffic to different services based on the URL path.

  • myapp.com/blue -> goes to a Blue Website.
  • myapp.com/green -> goes to a Green Website.

Why it teaches Kubernetes: Exposing every service with a public IP is expensive and insecure. Ingress allows you to have one entry point for multiple apps.

Core challenges you’ll face:

  • Ingress Controllers: K8s doesn’t come with Ingress logic; you must install a controller (like Nginx) first.
  • Path Rewriting: Forwarding /blue to the app, but making sure the app understands it.
  • Host file modification: Faking myapp.com on your local machine to test.

Key Concepts:

  • Ingress Resource: The rules (YAML).
  • Ingress Controller: The software that enforces the rules (Nginx/Traefik).
  • Layer 7 Load Balancing: Routing based on URL/Host.

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Project 4.

Real world outcome: You open your browser to localhost/blue and see a blue page. You change to localhost/green and see a green page. Both are running in the same cluster, hidden behind one proxy.

Project 6: The “Persistent” Database (StatefulSets & PVs)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: YAML
  • Alternative Programming Languages: SQL
  • Coolness Level: Level 2: Practical
  • Business Potential: 4. Open Core Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Storage / CSI
  • Software or Tool: PostgreSQL / MySQL
  • Main Book: “Managing Kubernetes” by Burns and Beda

What you’ll build: A PostgreSQL database deployment. You will add data to it (create a table, insert rows). Then you will delete the entire pod. When K8s recreates the pod, the data must still be there.

Why it teaches Kubernetes: Docker containers are ephemeral; files are lost when they die. K8s uses Persistent Volumes (PV) and Persistent Volume Claims (PVC) to attach storage that survives the pod’s lifecycle.

Core challenges you’ll face:

  • StorageClasses: How K8s asks the underlying cloud/OS for disk space.
  • Access Modes: ReadWriteOnce vs ReadWriteMany.
  • StatefulSets: Why we use StatefulSet for DBs instead of Deployment (stable network IDs).

Key Concepts:

  • PV vs PVC: The “Hardware” vs the “Request”.
  • CSI (Container Storage Interface).
  • Volume Mounting: Mapping the disk to /var/lib/postgresql/data.

Difficulty: Advanced Time estimate: 1 week Prerequisites: SQL basics.

Real world outcome:

  1. Deploy Postgres.
  2. kubectl exec into it and run CREATE TABLE important_data....
  3. kubectl delete pod postgres-0.
  4. Wait for postgres-0 to restart.
  5. kubectl exec and run SELECT * FROM important_data. The data returns.

Project 7: The “Configuration Manager” (ConfigMaps & Secrets)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: Python (App) + YAML
  • Alternative Programming Languages: Go
  • Coolness Level: Level 2: Practical
  • Business Potential: 2. Pro Tool
  • Difficulty: Level 1: Beginner
  • Knowledge Area: App Configuration
  • Software or Tool: kubectl
  • Main Book: “Kubernetes in Action”

What you’ll build: An application that displays a “Message of the Day” and connects to a “Database” (simulated). You will change the message and the DB password in Kubernetes without changing the application code or rebuilding the Docker image.

Why it teaches Kubernetes: The 12-Factor App principle states config should be separated from code. ConfigMaps (plain text) and Secrets (encrypted/obfuscated) allow you to inject configuration at runtime.

Core challenges you’ll face:

  • Mounting vs. Env Vars: Injecting config as a file on disk vs an environment variable.
  • Hot Reloading: Updating a ConfigMap and having the app notice the change (advanced).

Key Concepts:

  • ConfigMap: Non-sensitive data.
  • Secret: Sensitive data (base64 encoded).
  • Volume Mounts: Mapping config files to paths.

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic coding.

Real world outcome: You edit the ConfigMap: kubectl edit configmap my-config. You change COLOR=blue to COLOR=red. You refresh your app, and the background turns red.

Project 8: The “Secure” Multi-Tenant Cluster (RBAC)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: YAML
  • Alternative Programming Languages: OpenSSL (for certs)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. Service & Support
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Security / Governance
  • Software or Tool: RBAC
  • Main Book: “Container Security” by Liz Rice

What you’ll build: You will create a new “User” (e.g., “Developer-Dave”) who has permission to view pods in the “dev” namespace but cannot delete them, and cannot see anything in the “prod” namespace.

Why it teaches Kubernetes: By default, the admin sees everything. In the real world, you need RBAC (Role-Based Access Control) to restrict users and service accounts.

Core challenges you’ll face:

  • Authentication vs Authorization: K8s assumes you are who you say you are (AuthN); RBAC handles what you can do (AuthZ).
  • Generating User Certs: Creating a .kubeconfig file for Dave using OpenSSL.
  • RoleBindings: Binding a “Role” to a “User”.

Key Concepts:

  • Role vs ClusterRole: Namespace-scoped vs Cluster-wide permissions.
  • ServiceAccount: Identity for processes (pods), not humans.
  • Namespace: Logical isolation.

Difficulty: Advanced Time estimate: 1 week Prerequisites: Project 2 (easiest with access to API server keys).

Real world outcome: You switch context: kubectl config use-context dave. You run kubectl get pods -n dev -> Success. You run kubectl delete pod x -n dev -> “Error: Forbidden”. You run kubectl get pods -n prod -> “Error: Forbidden”.

Project 9: The “Auto-Pilot” (Custom Controller / Operator)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: Python (Kopf framework)
  • Alternative Programming Languages: Go (Kubebuilder)
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. Industry Disruptor (SaaS)
  • Difficulty: Level 4: Expert
  • Knowledge Area: Extending Kubernetes
  • Software or Tool: Python / Kopf
  • Main Book: “Programming Kubernetes” by Michael Hausenblas

What you’ll build: You will extend K8s with a Custom Resource Definition (CRD) called Website. When you apply a manifest saying kind: Website, your Python script will automatically generate the Deployment, Service, and Ingress for you.

Why it teaches Kubernetes: This is how advanced tools (like Prometheus Operator or database operators) work. You are writing software that talks to the K8s API to automate complex tasks.

Core challenges you’ll face:

  • The Operator Pattern: Watching for events (Create/Update/Delete) and reacting.
  • CRDs: Teaching the API server about a new object type.
  • Client Libraries: Using the Python K8s client to manipulate cluster resources.

Key Concepts:

  • CRD (Custom Resource Definition).
  • Controller Pattern: The infinite loop of reconciliation.
  • K8s API: Interacting with K8s programmatically.

Difficulty: Expert Time estimate: 2 weeks Prerequisites: Python, all previous projects.

Real world outcome: You create a file my-site.yaml:

kind: Website
metadata:
  name: blog
spec:
  image: ghost:latest

You run kubectl apply -f my-site.yaml. Suddenly, a Deployment, Service, and Ingress appear automatically. You delete the Deployment, and your Operator recreates it instantly.

Implementation Hints: Use Kopf (Kubernetes Operator Pythonic Framework). It makes writing operators as easy as writing a standard Python function with a decorator: @kopf.on.create('websites') def create_fn(spec, ...):

Project 10: The “GitOps” Pipeline (ArgoCD)

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: YAML
  • Alternative Programming Languages: N/A
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. Open Core Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Automation / CI/CD
  • Software or Tool: ArgoCD
  • Main Book: “GitOps and Kubernetes” by Billy Yuen

What you’ll build: You will stop using kubectl apply. You will install ArgoCD. You will point ArgoCD to a GitHub repository containing your YAML files. When you commit a change to GitHub, ArgoCD will automatically sync the cluster to match the git repo.

Why it teaches Kubernetes: This is the “Gold Standard” for production. It solves the “Drift” problem (where someone manually changes the cluster and it no longer matches the code).

Core challenges you’ll face:

  • Installing ArgoCD: Running a complex operator in your cluster.
  • Sync Policies: Auto-sync vs Manual sync.
  • Self-Healing: If you manually delete a deployment, ArgoCD should detect the drift and put it back.

Key Concepts:

  • GitOps: Git as the single source of truth.
  • Drift Detection: Alerting when Cluster != Git.

Difficulty: Advanced Time estimate: 1 week Prerequisites: GitHub account, running cluster.

Real world outcome:

  1. You change the replica count from 3 to 5 in your GitHub repo.
  2. You commit and push.
  3. You watch the ArgoCD dashboard. It detects the “Out of Sync” state.
  4. It syncs, and your cluster scales up to 5 pods automatically.

Project Comparison Table

Project Difficulty Time Depth Fun Factor
1. Shell Orchestrator Intermed. Weekend ⭐⭐⭐ ⭐⭐⭐
2. K8s The Hard Way Advanced 1 Week ⭐⭐⭐⭐⭐ ⭐⭐⭐
3. Resilient Web App Beginner Weekend ⭐⭐⭐ ⭐⭐
4. Service Discovery Intermed. Weekend ⭐⭐⭐ ⭐⭐⭐
5. Ingress Controller Intermed. 1 Week ⭐⭐⭐ ⭐⭐⭐⭐
6. Stateful DB Advanced 1 Week ⭐⭐⭐⭐ ⭐⭐
7. Config Manager Beginner Weekend ⭐⭐ ⭐⭐
8. RBAC / Security Advanced 1 Week ⭐⭐⭐⭐ ⭐
9. Custom Operator Expert 2 Weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
10. GitOps (ArgoCD) Advanced 1 Week ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐

Phase 1: The Basics (Mandatory)

Project 1 -> Project 2 -> Project 3. Why: You must understand the “Loop” (Project 1) and the “Architecture” (Project 2) before the “Usage” (Project 3) makes sense. Do not skip the hard way.

Phase 2: Operations

Project 4 -> Project 5 -> Project 6. Why: This covers the three pillars of apps: Networking (Internal), Networking (External), and Storage.

Phase 3: Mastery

Project 9 (Operator) -> Project 10 (GitOps). Why: Writing an operator moves you from a “User” of K8s to a “Developer” of K8s. GitOps moves you to modern production standards.

Final Overall Project: The “Microservices Platform” Capstone

  • File: LEARN_KUBERNETES.md
  • Main Programming Language: Multiple (Python/Go/YAML)
  • Difficulty: Level 5: Master

What you’ll build: A complete microservices e-commerce platform hosted on your custom cluster.

  1. Frontend: React app served via Nginx.
  2. Backend: Python Flask API.
  3. Database: Stateful Redis or Postgres.
  4. Ingress: Exposing it via a domain (fake local domain).
  5. GitOps: All managed via ArgoCD.
  6. Observability: Prometheus and Grafana installed to monitor Pod CPU usage and HTTP error rates.

Why it teaches Kubernetes: This combines every single concept. Networking, Storage, Config, Scaling, and Monitoring. If you can build this and keep it running while randomly deleting pods, you have mastered Kubernetes.

Summary

Project Key Concept
1. Shell Orchestrator The Control Loop
2. K8s The Hard Way Architecture
3. Resilient Web App Deployments & Scaling
4. Service Discovery Services & DNS
5. Ingress Controller Layer 7 Routing
6. Stateful DB PVC & Storage
7. Config Manager ConfigMaps & Secrets
8. RBAC / Security Authorization
9. Custom Operator CRDs & API Extension
10. GitOps CD & Automation
11. Capstone Full Stack Integration