Containers

Before Kubernetes schedules anything, it is worth being precise about what is being scheduled. A container is not a small virtual machine. It is a process on the host, wearing a convincing disguise.

The disguise is made of two kernel features:

Namespaces limit what the process can see — its own process tree, network interfaces, hostname, mounts.
Control groups (cgroups) limit what it can use — CPU, memory, I/O.

There is no separate kernel and no emulation. That is why containers start in milliseconds and why a container that escapes its namespaces is simply a process on your node.

Reference

Terminology

Image — A read-only, layered filesystem plus the metadata needed to run it: the entrypoint, the default arguments, environment variables. Images are content-addressed and immutable; a tag such as nginx:1.27 is a movable pointer to a digest.
Container — A running instance of an image, with a thin writable layer on top. Delete the container and that writable layer goes with it. This is why data written to a container’s own filesystem does not survive.
Layer — Images are built as a stack of layers, and identical layers are shared between images and cached on the node. This is why pulling a second image based on the same base is fast, and why layer order matters for cache efficiency.
Registry — Where images live and are pulled from. docker.io, ghcr.io, and private registries all speak the same protocol.
Runtime — The thing that actually creates the container: containerd or cri-o, driven by Kubernetes through the CRI interface. Docker itself is no longer part of the chain.
PID 1 — The first process in a container. It has special responsibilities in Linux: it must reap orphaned child processes and it receives signals. An application that ignores SIGTERM will be killed hard after the termination grace period, which is a common cause of slow or unclean shutdowns.

Layers, in Practice

    ┌──────────────────────────┐  ← thin writable layer (lost with the container)
    ├──────────────────────────┤
    │   application + deps     │  ← image layers (shared, cached, read-only)
    ├──────────────────────────┤
    │   base distribution      │
    └──────────────────────────┘

Two consequences that matter all week:

Anything written inside a container is temporary. If it needs to survive, it has to be on a volume.
The image is the unit you version and scan. A running container is disposable; the image is the artefact you keep.

Images You Will Meet

Tag	What it means
`nginx:1.27`	A specific version. Predictable — use this
`nginx:latest`	Whatever was pushed most recently. Do not use it in anything you care about
`nginx@sha256:…`	An exact digest. The only truly immutable reference

A Deployment that references :latest will not roll out when you push a new image, because nothing in the manifest changed. That is not a Kubernetes bug; it is the reason tags should be immutable.

Exercises

Run something with a shell and look at it from the inside:
```
kubectl run shell --image=docker.io/library/busybox --restart=Never -- sleep 3600
kubectl exec -it shell -- sh
```
Inside, check hostname, ps aux, and ip addr. You are the only process, with your own hostname and IP — but you are running on the node, not in a virtual machine.

Prove the filesystem is disposable:

kubectl exec shell -- sh -c "echo hello > /tmp/note.txt"
kubectl exec shell -- cat /tmp/note.txt      # there
kubectl delete pod shell

The file is gone with the Pod. That is the whole motivation for the Persistence module on Day 2.

Watch a container handle a signal badly, and then well:
```
kubectl run term --image=docker.io/library/busybox --restart=Never -- sh -c 'sleep 3600'
time kubectl delete pod term
```
sh -c 'sleep 3600' does not forward SIGTERM to the sleep, so the container waits out the full termination grace period before being killed. This is the single most common reason a rolling update feels slow.

What to Take Away

A container is a process with restricted visibility and resource limits, not a lightweight VM.
Its own filesystem is temporary; only volumes persist.
The image is the durable artefact, and the tag you choose decides whether you can reproduce it later.
Process 1 and signal handling are your problem, not the platform’s.

Pods