Containers & orchestration

A container packages an application with everything it needs to run, but unlike a VM it shares the host's kernel instead of virtualizing hardware underneath its own — which is why it starts in milliseconds instead of tens of seconds. This page covers what that shared-kernel model actually buys you, how a Dockerfile turns source code into a layered image, where that image lives between build and run, and why running more than a handful of containers forces you toward an orchestrator like Kubernetes. By the end you'll be able to say precisely what a Pod, a Deployment, and a Service each do, and why none of the three is optional.

Containers vs. VMs: process isolation, not hardware virtualization

A virtual machine gets its isolation from a hypervisor (KVM, VMware ESXi, Hyper-V) that virtualizes hardware — CPU, memory, disk, network interfaces — and boots a complete guest operating system, kernel included, on top of that virtual hardware. That guest kernel takes real time to initialize (tens of seconds is typical) and consumes real memory and disk just to exist, before the application inside it does anything. Run ten VMs on one host and you're running ten kernels.

A container gets its isolation from the host kernel itself, using two Linux primitives: namespaces (separate views of process IDs, network interfaces, mounts, hostname, and inter-process communication, so a container can't see or touch what's outside it) and cgroups (hard limits on how much CPU and memory a group of processes can consume, so one container can't starve its neighbors). No second kernel boots — a container is just a process, or a small group of processes, launched by a container runtime (containerd, or the lower-level runc that implements the Open Container Initiative's runtime spec) with those namespaces and cgroups applied. Starting one is closer to a fork()+exec() than to booting a machine, which is why start times are measured in milliseconds, not seconds, and why a single host can run hundreds of containers instead of the dozen or so VMs the same hardware would support.

The isolation is real but it is weaker than a VM's: every container on a host shares that one kernel, so a kernel-level vulnerability or a kernel panic is a blast radius of "everything on this host," not "one VM." That's the actual trade a team is making by choosing containers over VMs for a given workload — density and startup speed against a thinner isolation boundary — not a claim that containers are simply VMs done better.

Image layers and a Dockerfile's anatomy

A container image is built as a stack of read-only layers, each one a filesystem diff from the layer below it, combined at run time by a union filesystem (typically OverlayFS) into what looks like one coherent filesystem. Layers are content-addressed and cached: if two images share an identical base layer, a Docker daemon or CI runner that already has that layer doesn't re-download or re-store it. A Dockerfile is the recipe that produces this stack, one instruction at a time:

• FROM — the base image this one builds on top of (an OS layer, a language runtime, or another team's image), and the first layer in the stack.
• COPY — adds files from the build context (your source tree) into the image as a new layer.
• RUN — executes a command during the build (installing packages, compiling code) and commits its filesystem changes as a new layer.
• CMD — not a build-time instruction but metadata: the default command the container runs when it starts, overridable at docker run time.

The snippet below shows a minimal Dockerfile for a small service, followed by the Kubernetes object — covered in full further down this page — that actually runs many copies of the image it produces.

# Dockerfile
FROM node:20-slim
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

# deployment.yaml — runs the image built above
apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
spec:
  replicas: 3
  selector:
    matchLabels: { app: checkout-api }
  template:
    metadata:
      labels: { app: checkout-api }
    spec:
      containers:
        - name: checkout-api
          image: registry.internal/checkout-api:1.4.2
          ports:
            - containerPort: 3000

Registries: where images live between build and run

A built image has to land somewhere a runtime can pull it from, and that somewhere is a container registry — Docker Hub, Amazon ECR, Google Artifact Registry, GitHub Container Registry (ghcr.io), or a self-hosted option like Harbor. A registry is artifact storage in the same sense covered in build and artifact management: the CI pipeline builds an image once, tags it, pushes it to the registry, and every later stage — staging, production, a rollback — pulls that exact same immutable artifact rather than rebuilding it.

An image reference has the shape registry/namespace/repository:tag, for example registry.internal/checkout-api:1.4.2 in the YAML above. A tag is a mutable pointer — someone can push a new image under the same tag tomorrow — while a digest (@sha256:...) pins to one specific, content-addressed image forever. Production manifests that reference a mutable tag like :latest can silently start running a different image than the one that was tested, which is why many teams pin production deployments to a digest, or at minimum a version tag that's never reused, and reserve :latest for local development only.

Why orchestration once you're past a handful of containers

Running one container on one host is a docker run command. Running fifty containers across a dozen hosts, staying up as traffic grows and hosts fail, is a different problem entirely, and it's the reason orchestrators exist. Four needs show up as soon as the container count outgrows what a person can track by hand:

• Scheduling — deciding which host runs which container, based on each host's available CPU and memory versus what the container asks for. Doing this by hand across a dozen-plus hosts means either overpacking some machines or wasting capacity on others.
• Self-healing — when a container crashes or its host dies, something has to notice and restart it elsewhere, without a human paging themselves at 3 a.m. to run docker run again.
• Horizontal scaling — adding or removing running copies of a container as load changes, ideally automatically, rather than someone manually starting more instances during a traffic spike.
• Service discovery — as containers get rescheduled onto different hosts and different IPs over time, other services need a stable way to find them that doesn't break every time a reschedule happens.

Kubernetes is the dominant answer to all four, but it's not the only one — Docker Swarm and HashiCorp Nomad solve the same problem with a smaller surface area. What all of them share is a control loop: a scheduler that places workloads, a controller that continuously compares desired state to actual state and corrects drift, the same reconciliation model covered for infrastructure generally in infrastructure as code.

Kubernetes' core objects, conceptually

Kubernetes exposes that control loop through a small set of objects. Three matter most for a conceptual grasp of how workloads actually run:

• Pod — the smallest deployable unit. Not a container itself, but a wrapper around one or more containers that share a network namespace (one IP address) and can share storage volumes. Most Pods run exactly one application container; a second container in the same Pod is the sidecar pattern — a helper process co-located and co-scheduled with the main container, commonly used for shipping logs to a collector or running a service-mesh proxy (Envoy, in an Istio or Linkerd mesh) that intercepts the main container's network traffic. Pods are disposable: Kubernetes expects to destroy and recreate them, not to keep any individual Pod alive forever.
• Deployment — manages a set of identical Pod replicas (the replicas: 3 field in the YAML above) and their rollouts. It's what actually implements self-healing (replacing a Pod that dies) and horizontal scaling (changing the replica count), and it drives rolling updates when the image tag changes — the mechanics of which are covered in deployment strategies.
• Service — a stable network identity for a set of Pods, selected by label rather than by tracking individual Pod IPs. Pods come and go and get new IPs on every reschedule; a Service gives every other component in the cluster one unchanging address and DNS name to talk to, solving the service-discovery need above regardless of which Pods are currently behind it.

Nothing about Kubernetes replaces the need to configure what runs inside a container image — it decides where and how many copies run, not what's installed on them. That's still the job of the image build itself, or of a configuration-management tool for anything Kubernetes doesn't own; see configuration management for where that line sits. The same pushed image a Deployment references is what a pipeline scanned and a registry stored upstream, and what gets watched once it's running, covered in monitoring and observability.