📖 Read-only preview — lessons, diagrams, and quizzes only. The hands-on labs, live grading, and progress tracking require running the real course locally against a Kubernetes cluster.Run it locally →

Module 2 · Lesson 2.1

Pods and Namespaces

The Pod: Kubernetes's smallest deployable unit

A Pod is not a container — it's a thin wrapper around one or more containers that are always scheduled together, on the same node, sharing the same network namespace (one IP address) and optionally storage. Most of the time a Pod holds exactly one container; the multi-container case (sidecars, init containers) comes up later.

Why not just schedule containers directly? Because some things — a web server and a log-shipping sidecar, say — genuinely need to live or die as a unit, share localhost, and share a volume. The Pod is that unit.

You'll rarely create bare Pods in production (Deployments do that for you, starting next module), but understanding the Pod is the foundation for everything above it.

Linux aside: a container is, under the hood, just a regular Linux process with extra isolation — its own view of the filesystem, network, and process tree, enforced by kernel features (namespaces, cgroups), not a lightweight VM. That's why starting a container is fast: there's no boot, no hypervisor — just a new, isolated process.

Namespaces: a folder, not a wall

A namespace is a way to divide one cluster's objects into non-overlapping groups — by team, by environment, by application. Two things namespaces do: scope names (two web Deployments can coexist in team-a and team-b), and scope access control and resource quotas.

One thing namespaces don't do: they are not a network or scheduling boundary. A pod in team-a can, by default, reach a pod in team-b over the network just fine, and pods from every namespace share the same pool of nodes. (Network isolation is a deliberate, separate feature — NetworkPolicies, module 11 — not a side effect of namespaces.)

Pods scattered across nodes, grouped by namespace

🖥 node-1

web-7d9
ns: default
coredns-4f2
ns: kube-system
ledger-a1b
ns: team-payments

🖥 node-2

web-7e3
ns: default
kube-proxy-x9
ns: kube-system
ledger-c3d
ns: team-payments
default
kube-system
team-payments
Namespaces don't change where a pod runs — any node can host pods from any namespace. They're a logical folder for names, access control, and resource quotas, not a physical boundary.

Every cluster starts with a few built-in namespaces: default (where objects land if you don't specify one), kube-system (the control plane's own objects, which you met in Module 1), and kube-public.

The infrastructure analogy

Namespaces are closer to a folder structure or a tagging convention than to a VLAN or a VPC. If you want VPC-style network isolation between teams, that's a NetworkPolicy layered on top — namespaces alone just keep names and permissions tidy.

In the lab, you'll create a namespace and run pods both inside and outside it, entirely from the command line.

🧪 Lab: lab-03-pods-and-namespaces

Preview only

Goal

Get comfortable creating pods and namespaces directly from the command line — no YAML yet, just kubectl verbs. (Declarative YAML starts in the next lab.)

This lab is intentionally imperative — see manifests/README.md.

Tasks

  1. Create a namespace called shop: kubectl create namespace shop
  2. Run a pod named web in it, using nginx:1.27: kubectl run web --image=nginx:1.27 -n shop
  3. Run a second pod named scratch in the default namespace, using busybox:1.36, that actually stays running (a bare busybox container exits immediately — give it something to do): kubectl run scratch --image=busybox:1.36 -n default -- sleep 3600
  4. Confirm both are Running: kubectl get pods -A | grep -E "web|scratch"
  5. Try kubectl get pods with no flags — notice it only shows default, not shop. Namespaces genuinely scope what you see by default.

Check

Run the check once both pods show Running.

This lab runs against a real local Kubernetes cluster with an automated grader — clone the repo and run make start to do it for real.

📝 Quiz

1. What is a Pod, precisely?

2. Two containers in the same Pod can reach each other over the network via:

3. A pod in namespace `team-a` sends a request to a pod's IP in namespace `team-b`, with no NetworkPolicy installed anywhere in the cluster. What happens?scenario

4. If you run `kubectl get pods` with no flags right after creating a pod in namespace `shop`, what do you see?

5. Why does starting a container feel nearly instant compared to booting a VM?

Progress isn't saved in this preview — run the course locally to track completion and grade labs for real.