PHASE 1: The Foundation: Infrastructure & Basics

Focus: Setting the stage before running a single container.

Chapter 1: Linux & Networking Prerequisites

1. Kernel Namespaces & Cgroups (The technology behind containers)
   • Namespaces (Isolation): Virtual “walls” that define what a process can see (Network, Files, PIDs).
   • Cgroups (Limits): A “meter” that defines how much a process can use (CPU, RAM, Disk I/O).
2. Linux Networking (Bridges, iptables, IPVS)
   • Linux Bridge: A virtual Layer 2 switch that connects container “pipes” (veth pairs) to each other and the host.
   • iptables: The kernel’s security guard/mailroom; it handles firewall filtering and NAT (port mapping) via sequential rules.
   • IPVS: A high-performance Layer 4 load balancer that uses hash tables to keep networking fast even with thousands of services.
   • veth pairs: The virtual ethernet cables that act as a “pipe” between a container’s namespace and the host’s bridge.
   • NAT (Masquerading): The process where iptables rewrites a container’s private IP to the host’s public IP for internet access.
   • O(n) vs. O(1): iptables gets slower as rules increase (linear); IPVS stays fast regardless of rule count (constant).
3. Systemd vs. Docker Init
   • PID 1 Rule: The “boss” process must clean up Zombies (dead processes) and pass Signals (like stop/restart).
   • Systemd: Heavyweight OS manager; overkill/insecure for containers.
   • Docker Init (Tini): Tiny bodyguard binary; handles signals and zombies so your app doesn’t have to.
   • Zombie Apocalypse: When dead processes clog the system because PID 1 isn’t “reaping” them.
   • Graceful Shutdown: Using an init (or exec) ensures your app stops safely instead of being “force-killed” by the kernel.

–

Chapter 2: Container Fundamentals (Docker & Beyond)

1. Docker vs. Containerd vs. CRI-O vs Podman
   • The OCI Standard: The “rulebook” ensuring any container image can run on any compliant runtime (Docker, Podman, etc.).
   • CRI (Container Runtime Interface): The standard “plug” that allows Kubernetes to talk to different container engines.
   • Docker: The “Luxury SUV”—a full feature-rich suite for developers, now separated from the Kubernetes production core.
   • Containerd: The “Industrial Engine”—the industry-standard, lightweight runtime used by AWS EKS, GKE, and AKS.
   • CRI-O: The “K8s Purist”—a minimal runtime built strictly for Kubernetes, default for Red Hat OpenShift.
   • Podman: The “Daemonless Rebel”—a rootless, secure Docker alternative that doesn’t require a background process.
   • Dockershim Deprecation: Kubernetes (v1.24+) no longer supports Docker directly; it now uses Containerd or CRI-O.
2. Writing Optimized Dockerfiles (Multi-stage builds)
   • Multi-Stage Builds: Using a “Builder” stage for heavy tools and a “Runner” stage for the app to shrink images from GBs to MBs.
   • Base Image Selection: Always prefer Alpine or Distroless versions (e.g., python:3.9-alpine) to minimize the attack surface and disk space.
   • The COPY --from Pattern: The secret to moving only compiled binaries or static assets into the final production image.
   • Layer Caching: Order commands from least frequent to most frequent changes (e.g., COPY package.json before COPY .) to speed up builds.
   • Security & Size: Smaller images pull faster across networks and contain fewer “bloat” binaries (like curl or git) for hackers to exploit.
3. Image Security (Distroless images, vulnerability scanning)
   • The Shell Threat: Standard images include tools like curl, wget, and sh, providing a ready-made “hacker toolkit” if your app is breached.
   • Distroless Images: The ultimate defense; these images contain only your app, removing the shell, package manager, and all OS utilities.
   • Vulnerability Scanning: The practice of using tools like Trivy or Clair to detect CVEs (vulnerabilities) in your OS layers and libraries before deployment.
   • Reduced Attack Surface: By using Distroless or Alpine, you decrease the number of installed packages, drastically lowering the chance of a “High” severity exploit.
   • Runtime Security: Without a shell (/bin/sh), attackers cannot easily execute scripts or lateral movement commands within your network.

Chapter 3: Kubernetes Architecture

1. Control Plane: API Server, Etcd, Controller Manager, Scheduler
2. Data Plane: Kubelet, Kube-proxy, Container Runtime
3. The “Pause” Container: The hidden container in every Pod

Chapter 4: Kubernetes Setting Up the Lab

1. Install kubectl
2. Local Setup on personal computer
3. Web Based Kubernetes Learning
   • Killercoda provides interactive Kubernetes scenarios and a playground environment
   • Play with Kubernetes gives you a temporary Kubernetes cluster in your browser
4. Cloud Setup Real World
   • Create an EKS Cluster

PHASE 2: Core Workloads: Running Applications

Focus: Mastering the basic objects.

Chapter 5: Pods & The Life of a Container

• Pod Lifecycle (Pending, Running, CrashLoopBackOff)
• Static Pods (Pods without an API server)
• Sidecar Pattern: Logging agents, Proxies
• InitContainers: Setting up the environment