DOCKER CONTAINERS KUBERNETES LEARNING PROJECTS

Deep Understanding: Docker, Containers & Kubernetes

To truly understand containers and orchestration, you need to go beyond docker run and YAML files. You need to understand what a container actually is at the Linux kernel level, how images work as layered filesystems, and why Kubernetes exists to solve distributed systems problems.

Core Concept Analysis

Containers (the foundation)

Linux namespaces - Process isolation (PID, network, mount, user, etc.)
cgroups - Resource limits (CPU, memory, I/O)
Union filesystems - Layered, copy-on-write storage
Container images - Tarballs of filesystem layers + metadata

Docker (the tooling)

Image building - Dockerfile instructions → filesystem layers
Container runtime - Spawning isolated processes
Networking - Bridge networks, port mapping, DNS
Storage - Volumes, bind mounts, storage drivers

Kubernetes (the orchestration)

Scheduling - Placing workloads on nodes
Service discovery - How pods find each other
Desired state reconciliation - Controllers watching and acting
Networking model - Every pod gets an IP, flat network

Project 1: Build Your Own Container from Scratch

File: DOCKER_CONTAINERS_KUBERNETES_LEARNING_PROJECTS.md
Programming Language: C or Go
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 1. The “Resume Gold”
Difficulty: Level 3: Advanced
Knowledge Area: OS Virtualization / Systems Programming
Software or Tool: Linux Namespaces / Cgroups
Main Book: “The Linux Programming Interface” by Michael Kerrisk

What you’ll build: A mini-container runtime in C or Go that uses Linux namespaces and cgroups to isolate a process—basically docker run without Docker.

Why it teaches containers: Docker isn’t magic. Containers are just Linux processes with isolation. By calling clone() with namespace flags and setting up cgroups yourself, you’ll see that a “container” is just a fancy way to run a process.

Core challenges you’ll face:

Setting up PID namespace (your container’s process thinks it’s PID 1)
Creating a mount namespace and pivot_root to a new filesystem
Configuring network namespace with a veth pair
Limiting CPU/memory with cgroups v2
Making the isolated process actually usable (mounting /proc, setting hostname)

Resources for key challenges:

“Containers from Scratch” by Liz Rice (talk + code) - The definitive walkthrough of building containers in Go
“The Linux Programming Interface” by Michael Kerrisk (Ch. 28-29) - Authoritative reference on namespaces

Key Concepts:

Linux Namespaces: “The Linux Programming Interface” Ch. 28 - Michael Kerrisk
Cgroups v2: “How Linux Works, 3rd Edition” Ch. 8 - Brian Ward
Mount/pivot_root: “Linux System Programming” Ch. 1 - Robert Love
Process Isolation: “Operating Systems: Three Easy Pieces” - Remzi Arpaci-Dusseau (Virtualization section)

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: C or Go, basic Linux syscalls, comfort with the terminal

Real world outcome: You’ll have a working binary that can run: ./mycontainer run /bin/sh and drop you into an isolated shell where ps aux only shows your shell, the filesystem is isolated, and you can’t see the host’s network interfaces. You can even limit it to 50MB RAM and watch it get OOM-killed if you exceed it.

Learning milestones:

First namespace isolation working - You understand that containers are just processes
Filesystem isolation with pivot_root - You understand why container images are just directory trees
Network namespace with veth - You understand how Docker networking actually works
Cgroups resource limits - You understand why containers can be limited to specific resources

Project 2: Build a Container Image Format & Registry

File: DOCKER_CONTAINERS_KUBERNETES_LEARNING_PROJECTS.md
Programming Language: Go
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Distributed Systems / Standards
Software or Tool: OCI Spec / Docker Registry API
Main Book: “Docker Deep Dive” by Nigel Poulton

What you’ll build: A tool that can create OCI-compliant container images (without Docker) and push/pull them to a registry.

Why it teaches Docker internals: Docker images aren’t magic either. They’re just tarballs of filesystem layers with a JSON manifest. By building your own image creator and implementing the registry API, you’ll understand exactly what docker build and docker push do.

Core challenges you’ll face:

Understanding OCI image spec (manifests, config, layers)
Creating filesystem layers as tar archives with proper metadata
Implementing content-addressable storage (SHA256 digests)
Speaking the Docker Registry HTTP API v2
Handling layer deduplication and caching

Resources for key challenges:

OCI Image Spec (opencontainers/image-spec) - The actual specification
“Dive” tool source code - See how image layers are analyzed

Key Concepts:

OCI Image Specification: opencontainers/image-spec GitHub documentation
Content-Addressable Storage: “Designing Data-Intensive Applications” Ch. 3 - Martin Kleppmann
Union Filesystems: “How Linux Works, 3rd Edition” Ch. 4 - Brian Ward
HTTP APIs: “Design and Build Great Web APIs” - Mike Amundsen

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: HTTP, JSON, tar format basics, any programming language

Real world outcome: You’ll have a CLI tool where you can run ./myimage build ./myapp to create an OCI image, then ./myimage push localhost:5000/myapp:v1 to push it to a registry, and finally run it with your container runtime from Project 1 or with docker run.

Learning milestones:

Create a valid image manifest - You understand the image format
Push to a real registry - You understand the registry protocol
Pull and unpack an existing image - You can work with any container image
Layer caching working - You understand why Docker builds can be fast

Project 3: Implement a Mini Kubernetes Scheduler

File: DOCKER_CONTAINERS_KUBERNETES_LEARNING_PROJECTS.md
Programming Language: Go
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Distributed Systems / Orchestration
Software or Tool: Kubernetes API
Main Book: “Programming Kubernetes” by Hausenblas & Schimanski

What you’ll build: A custom Kubernetes scheduler that makes placement decisions based on your own logic—resource requests, node labels, affinity rules.

Why it teaches Kubernetes: Kubernetes is fundamentally a control loop: watch for unscheduled pods, find a suitable node, bind the pod. By writing your own scheduler, you understand the core reconciliation pattern that powers all of Kubernetes.

Core challenges you’ll face:

Connecting to the Kubernetes API server (client-go or REST)
Watching for pods with spec.schedulerName matching yours
Implementing filtering (does this node have enough resources?)
Implementing scoring (which node is best?)
Binding pods to nodes atomically

Resources for key challenges:

“Programming Kubernetes” by Hausenblas & Schimanski - Deep dive on controllers and operators
Kubernetes scheduler source code (pkg/scheduler) - See the real implementation

Key Concepts:

Kubernetes API & Controllers: “Programming Kubernetes” Ch. 1-4 - Hausenblas & Schimanski
Watch/List Pattern: Kubernetes client-go documentation
Resource Management: “Kubernetes in Action” Ch. 14 - Marko Lukša
Distributed Consensus: “Designing Data-Intensive Applications” Ch. 8-9 - Martin Kleppmann

Difficulty: Intermediate-Advanced Time estimate: 1-2 weeks Prerequisites: Go (preferred) or Python, basic Kubernetes usage, understanding of REST APIs

Real world outcome: You deploy your scheduler to a Kubernetes cluster. When you create a pod with schedulerName: my-scheduler, your code decides where it runs. You can implement strategies like “always prefer nodes with GPUs” or “spread across availability zones” and watch pods land on the nodes you expect.

Learning milestones:

Successfully watch and list pods - You understand the Kubernetes API model
Bind your first pod - You understand the scheduling contract
Implement resource-aware filtering - You understand how Kubernetes does capacity planning
Add custom scoring logic - You can extend Kubernetes for your needs

Project 4: Build a Service Mesh Data Plane (Mini Envoy)

File: DOCKER_CONTAINERS_KUBERNETES_LEARNING_PROJECTS.md
Programming Language: C or Rust
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Networking / Distributed Systems
Software or Tool: Envoy / iptables
Main Book: “TCP/IP Illustrated, Volume 1” by W. Richard Stevens

What you’ll build: A Layer 7 proxy that can intercept traffic, do load balancing, add retries/timeouts, and report metrics—the core of what Envoy/Linkerd do.

Why it teaches Kubernetes networking: Service meshes are how modern Kubernetes clusters handle traffic. By building the data plane yourself, you understand how sidecars intercept traffic, how load balancing works, and why observability comes “for free.”

Core challenges you’ll face:

Intercepting traffic with iptables rules (REDIRECT/TPROXY)
Parsing HTTP/1.1 and HTTP/2 protocols
Implementing load balancing algorithms (round-robin, least-connections)
Adding retry logic with exponential backoff
Emitting metrics in Prometheus format

Resources for key challenges:

“Envoy Proxy” source code and documentation - See how the real thing works
“TCP/IP Illustrated, Volume 1” by Stevens - Networking fundamentals

Key Concepts:

L4/L7 Proxying: “TCP/IP Illustrated, Volume 1” - W. Richard Stevens
iptables/netfilter: “Linux iptables Pocket Reference” - Gregor N. Purdy
HTTP Protocol: RFC 7230-7235 (HTTP/1.1 specification)
Load Balancing Algorithms: “Designing Data-Intensive Applications” Ch. 6 - Martin Kleppmann

Difficulty: Advanced Time estimate: 2-4 weeks Prerequisites: Network programming (sockets), HTTP protocol, Linux networking basics

Real world outcome: You deploy your proxy as a sidecar in Kubernetes. All traffic to your application goes through your proxy first. You can see metrics in Grafana showing request latency, success rates, and which backends are serving traffic. When a backend fails, your proxy automatically retries to another.

Learning milestones:

Basic TCP proxy working - You understand connection handling
HTTP parsing and routing - You understand L7 proxying
Load balancing implemented - You understand traffic distribution
Metrics emitting - You understand observability in distributed systems

Project 5: Create a Kubernetes Operator for a Stateful Application

File: DOCKER_CONTAINERS_KUBERNETES_LEARNING_PROJECTS.md
Programming Language: Go
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Orchestration / Automation
Software or Tool: Kubernetes CRDs / Operator SDK
Main Book: “Programming Kubernetes” by Hausenblas & Schimanski

What you’ll build: A Kubernetes operator that manages a stateful application (like a database cluster)—handling provisioning, scaling, backups, and failover automatically.

Why it teaches Kubernetes patterns: Operators are the “Kubernetes way” to manage complex applications. By building one, you understand Custom Resource Definitions, controllers, and the declarative model that makes Kubernetes powerful.

Core challenges you’ll face:

Defining a Custom Resource Definition (CRD) for your application
Writing a controller that watches your CRD and acts on changes
Managing stateful workloads (StatefulSets, PersistentVolumeClaims)
Implementing health checks and automatic failover
Handling upgrades without downtime

Resources for key challenges:

“Programming Kubernetes” by Hausenblas & Schimanski - The definitive operator guide
Operator SDK documentation - Tooling to scaffold operators

Key Concepts:

Operators & CRDs: “Programming Kubernetes” Ch. 4-6 - Hausenblas & Schimanski
StatefulSets: “Kubernetes in Action” Ch. 10 - Marko Lukša
Controller Pattern: “Kubernetes Patterns” - Ibryam & Huß
Distributed Systems Coordination: “Designing Data-Intensive Applications” Ch. 8 - Martin Kleppmann

Difficulty: Advanced Time estimate: 2-4 weeks Prerequisites: Go, Kubernetes fundamentals, understanding of stateful applications

Real world outcome: You apply a YAML like kind: MyDatabase, spec: replicas: 3 and your operator automatically creates a 3-node database cluster with proper networking, persistent storage, and automatic leader election. When you change replicas to 5, it scales up. When a node dies, it replaces it.

Learning milestones:

CRD installed and recognized - You understand Kubernetes extensibility
Controller reconciling - You understand the core Kubernetes pattern
Stateful workload managed - You understand the complexity of stateful apps
Failover working - You understand why operators exist

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
Container from Scratch	Intermediate	1-2 weeks	⭐⭐⭐⭐⭐ (Foundations)	⭐⭐⭐⭐
Image Format & Registry	Intermediate	1-2 weeks	⭐⭐⭐⭐ (Docker internals)	⭐⭐⭐
Mini K8s Scheduler	Intermediate-Advanced	1-2 weeks	⭐⭐⭐⭐⭐ (K8s core)	⭐⭐⭐⭐
Service Mesh Data Plane	Advanced	2-4 weeks	⭐⭐⭐⭐ (Networking)	⭐⭐⭐⭐⭐
Kubernetes Operator	Advanced	2-4 weeks	⭐⭐⭐⭐⭐ (K8s patterns)	⭐⭐⭐⭐

Recommendation

Start with Project 1: Build Your Own Container from Scratch.

Here’s why:

It destroys the magic: After building a container yourself, Docker becomes obvious. You’ll never wonder “what is a container” again.
It’s the foundation for everything else: Kubernetes orchestrates containers. If you don’t know what a container actually is, K8s will feel like magic boxes moving around.
It’s achievable in a weekend: You can get basic namespace isolation working in a few hours, then iterate.
The “aha moment” is incredible: When you run a process that thinks it’s PID 1 and can’t see your host filesystem, you suddenly understand what Docker has been doing all along.

Then proceed to Project 3 (Mini K8s Scheduler) to understand the Kubernetes reconciliation model, which is the heart of the entire system.

Final Capstone Project: Build a Mini Container Orchestrator

What you’ll build: A simplified container orchestrator that combines everything—your container runtime, scheduler, service discovery, and controller pattern—into a working system that can deploy and manage containerized applications across multiple nodes.

Why this is the ultimate test: This forces you to understand how all the pieces fit together. You can’t build this without understanding containers (Project 1), image distribution (Project 2), scheduling (Project 3), networking (Project 4), and controller patterns (Project 5).

Core challenges you’ll face:

Designing an API server that stores desired state (etcd or simpler)
Implementing node agents that report status and run containers
Building a scheduler that places workloads across nodes
Creating a service abstraction with load balancing
Handling node failures and rescheduling

Resources for key challenges:

“Kubernetes: Up and Running” by Hightower et al. - Understand what you’re replicating
“Designing Distributed Systems” by Brendan Burns - Patterns you’ll need
k3s source code - A minimal Kubernetes to study

Key Concepts:

Distributed Consensus: “Designing Data-Intensive Applications” Ch. 8-9 - Martin Kleppmann
API Design: “Kubernetes API Conventions” - Kubernetes documentation
Service Discovery: “Building Microservices” Ch. 4 - Sam Newman
Cluster Networking: “Kubernetes Networking” - James Strong & Vallery Lancey
Control Loops: “Programming Kubernetes” Ch. 1 - Hausenblas & Schimanski

Difficulty: Advanced Time estimate: 1-2 months Prerequisites: All previous projects, distributed systems basics

Real world outcome: You have a working cluster with 3+ nodes. You submit a job via your API: ./myorch run --replicas=3 --image=nginx. Your scheduler places containers across nodes. You can curl any node and reach your service via load balancing. When you kill a node, your system detects the failure and reschedules the containers elsewhere.

Learning milestones:

API server accepting requests - You understand the control plane
Agents running containers - You understand the data plane
Scheduler placing workloads - You understand distributed scheduling
Service discovery working - You understand the networking model
Failure recovery working - You understand why Kubernetes is valuable

After completing these projects, you won’t just use Docker and Kubernetes—you’ll understand them at a level that lets you debug any issue, optimize any deployment, and explain exactly what’s happening under the hood.