servers → containers → kubernetes

Application → Monolith → Microservice

Monolithic vs Microservices Architecture

• Monolithic: Single codebase, everything bundled; easy to start but hard to maintain and scale.
• Microservices: Application split into separate services; easier maintainability, scaling, and deployment, with the trade-off of slightly increased latency.

Traditional Deployment

• Server-based: Deploying entire applications directly on servers; led to resource wastage and poor utilization.
• Virtual Machines (VMs): Allowed multiple OS instances on the same hardware using hypervisors (e.g., KVM, VMware). Each VM needs its own OS, leading to high resource overhead.

Containers and Their Fundamentals

• Problems with VMs: “Works on my machine” syndrome due to inconsistent dependencies.
• Containers bridge this gap by packing code with its dependencies & runtime, ensuring consistency across environments.
• Introduction to the concept: A container is nothing but a Linux process isolated using Linux namespaces and cgroups
  • Namespaces provide isolation (PID, NET, IPC, UTS, MNT, USER, etc.).
  • cgroups restrict and manage resource consumption (CPU, memory, etc.).
• Layering: Images are layered; containers get their own writable layers, ensuring changes in one don’t reflect in others.
• Security: Not automatic—must be implemented at all layers.

Container Lifecycle & Internals

• Runtime: Explains docker, containerd, runc, and the role of high-level (e.g., Docker) and low-level (e.g., runc) runtimes.
• Shows how, under the hood, containers are just Linux processes with isolated resources.
• Demos: Running containers, inspecting their processes and namespaces, and observing cgroups memory/CPU limits.
• Hands-on: Encourages learners to use provided playgrounds to reinforce these concepts live.

Why Use Kubernetes?