Cloud Fundamentals
Intermediate 15 min read Cloud Fundamentals

Virtualization & Containers

Virtualization splits one physical machine into many isolated guests; containers split one kernel into many isolated processes. Learn hypervisors, how VMs and containers differ, and how orchestration sits on top of both.

hypervisorvirtual machinecontainerkernelcgroupsnamespacesOCIorchestration
Prerequisites: Cloud Computing Fundamentals
Introduction

What is this?

Virtualization lets one physical server run many operating systems. A hypervisor (KVM, ESXi, Hyper-V) multiplexes hardware across virtual machines, each with its own kernel. Containers go one level higher: they share the host kernel but isolate processes with namespaces and cgroups, packaging an app and its dependencies into a portable unit. Orchestrators like Kubernetes manage fleets of both at scale.

Motivation

Why do you need it?

  • Every cloud instance you rent is a virtual machine running on a shared physical host.
  • Containers changed how applications are built, shipped and scaled — you will live in them daily.
  • Understanding the isolation boundary decides what breaks when a neighbor on the host misbehaves.
  • Capacity planning, security and cost all trace back to whether you run VMs, containers or bare metal.
  • Kubernetes, the orchestration layer, exists because running containers by hand does not scale.
Think about it

Mental model

Imagine

Apartments in a building

Think of

Virtual machines and containers

A physical server is the building. A VM is a fully separate apartment with its own walls, plumbing and electricity — heavy, but totally isolated. Containers are roommates in one apartment sharing the kitchen (kernel) but with their own locked rooms. Roommates are cheaper and start instantly, but the kitchen is a shared, contended resource.

Mechanics

How it works

  • The hypervisor sits between hardware and guests, virtualizing CPU, memory, storage and interrupts so each VM believes it owns the machine.
  • Each VM runs a full operating system with its own kernel, system libraries and boot lifecycle — which is why VMs take minutes to start.
  • A container reuses the host kernel but requests an isolated view of it through namespaces (PID, network, mount, user) and resource limits through cgroups.
  • The container image is a filesystem snapshot plus metadata, built from layers and described by the OCI runtime spec; the runtime (containerd, runc) unpacks and starts it.
  • Orchestration (Docker Swarm, Kubernetes) schedules containers across hosts, restarts failures, does rolling updates and handles service discovery.

VMs and containers side by side on the same host.

Physical host
Hypervisor
Virtual machines
Host kernel
Containers
Orchestrator
Reference

Key commands

docker ps

List running containers with their image, status and published ports.

docker run -d --name web -p 8080:80 nginx:1.25

Start an nginx container detached, mapping host port 8080 to container port 80.

docker images

List locally cached container images.

docker logs web

Print stdout/stderr from a container — the primary debugging channel.

free -m

See host memory; containers share this pool and do not show their own separate RAM.

Hands-on

Examples

Run an nginx container

Run an nginx container
$ docker run -d --name web -p 8080:80 nginx:1.25
7a9f3c1b5d2e4f6a8b0c2d4e
 
$ docker ps
CONTAINER ID   IMAGE         COMMAND                  CREATED         STATUS        PORTS                  NAMES
7a9f3c1b5d2e   nginx:1.25    "/docker-entrypoint..."   5 seconds ago   Up 4 seconds  0.0.0.0:8080->80/tcp   web
 
$ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080
200

docker run pulls the image, creates a container with its own PID, network and mount namespaces, and maps host port 8080 to the container's port 80. The curl confirms the web server answers. The container started in under a second because no kernel was booted — it reuses the host's.

Real world

In production

  • Autoscaling in the cloud is largely VM orchestration: launch instances, join them to a load balancer, and terminate them on scale-in.
  • Containers give you the same artifact in dev, CI and production — the image is immutable.
  • Kubernetes runs container fleets with declarative desired state, self-healing and rolling deployments.
  • Serverless platforms and managed databases are themselves built on VMs and containers under the hood.
Guidelines

Best practices

  • Keep images small and layered — order stable base layers first so rebuilds hit the cache.
  • Run one concern per container, but remember that one process per container is a guideline, not a law.
  • Pin image tags to digests or explicit versions; floating latest breaks reproducibility.
  • Set memory and CPU limits at every layer (cgroups, Kubernetes resources) so one tenant cannot starve the host.
Watch out

Common mistakes

  • Treating containers as lightweight VMs — containers share the kernel and cannot run a different OS.
  • Storing state inside a container's writable layer, which dies with the container.
  • Running a process manager inside a container instead of letting the orchestrator manage restarts.
  • Assuming VM-level isolation is enough for hostile multi-tenancy — containers give weaker isolation between neighbors.
Root cause analysis

Common issues

Error
docker: command not found
Root cause

The Docker CLI is not installed or not on PATH.

Fix

Install the engine or verify PATH with which docker; the daemon must be running too (docker info).

Error
Error response from daemon: port is already allocated
Root cause

Host port 8080 is already bound by another container or process.

Fix

Pick a free port or find the holder with docker ps and free it.

Error
Container exits immediately with code 137
Root cause

The process was killed — almost always by the OOM killer exceeding a memory limit.

Fix

Raise the memory limit or fix the memory leak; verify with docker inspect and dmesg.

When things break

Debugging tips

  • docker logs and docker inspect are the first stop for any container failure.
  • Compare free -m on the host against container limits to find cgroup memory throttling.
  • Use docker ps -a to see exited containers — many failures hide in the stopped list.
  • Check resource limits before blaming the app: OOM-killed processes exit 137.
Interviews

Interview checkpoint

Practice

Hands-on lab

Run a Container and Observe Resource Isolation
25 min · intermediate
In progress
Objectives
  • Confirm the host OS and kernel details
  • Run an nginx container with a port mapping
  • Verify the container's published port
  • Read host resource state alongside the container

Run a Container and Observe Resource Isolation

25 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which component shares the host kernel with other workloads?

2

Which technology virtualizes the hardware so multiple operating systems run on one machine?

3

Containers provide the same level of OS isolation as virtual machines.

Quick reference

Cheat sheet

VM vs container
VMFull guest OS + kernel, minutes to boot, strong isolation
ContainerShares host kernel, milliseconds to start, portable image
HypervisorKVM, ESXi, Hyper-V — virtualizes hardware
Runtimecontainerd + runc — unpacks and starts OCI images
OrchestratorKubernetes — schedules, heals, scales containers
Everyday container commands
docker ps -aAll containers, including exited ones
docker run -d -p 8080:80 nginxDetached run with port mapping
docker logs <name>See stdout/stderr
docker inspect <name>JSON details: mounts, limits, state
docker rm -f <name>Force remove a container
Go deeper

Official documentation

Kubernetes: What Are Containers?
docs
Docker: Get Started
docs
OCI: Runtime Specification
spec
KVM: Kernel-based Virtual Machine
docs