Containers & deployment

What a container actually is

A container is a normal Linux process that the kernel has fenced off. Two kernel features do the fencing. Namespaces decide what the process can see: its own process tree, network interfaces, filesystem mounts, hostname. Cgroups decide what it can use: a ceiling on CPU, memory, and IO. Nothing boots inside it. That is the whole difference from a virtual machine, which runs a full guest OS on a hypervisor and takes seconds to minutes to start. A container shares the host kernel and starts in milliseconds.

Wrong "A container is a lightweight VM." A VM virtualizes hardware and runs its own kernel. A container virtualizes nothing; it is your process with a restricted view of one shared kernel. Practical consequence: containers are cheap to start and pack densely, but because the boundary is the kernel, a kernel bug can cross it in a way a hypervisor boundary would not.

How Docker image layers and caching work

An image is a stack of read-only layers, one per build instruction, unioned into a single filesystem view (OverlayFS, copy-on-write). Each layer is cached by content. One rule governs every build: when a layer changes, every layer after it rebuilds, even if those later instructions are identical.

That rule explains the most common Dockerfile bug.

# WRONG: any code edit reinstalls every dependency
COPY . .
RUN npm ci

# RIGHT: deps stay cached until the lockfile changes
COPY package.json package-lock.json ./
RUN npm ci
COPY . .

Put the rarely-changing thing (dependencies) before the frequently-changing thing (source). Add a .dockerignore so node_modules and .git stay out of the build context.

Multi-stage builds handle image size: build in a fat image with the toolchain, then copy only the artifact into a slim runtime image.

FROM node:20 AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-slim
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

The runtime image never carries the compilers or dev dependencies, so it is smaller and exposes less.

Pods, deployments, and services

A Pod is the smallest unit Kubernetes schedules: one or more containers that share a network namespace and volumes, so they reach each other on localhost. A Deployment holds the desired state: run N replicas of this pod, and when the image changes, roll them out gradually. A Service gives that shifting set of pods one stable virtual IP and DNS name, load-balancing across whichever pods currently match its label selector.

The split matters because pods are disposable. They die, get rescheduled, and change IP. The Deployment keeps the replica count right; the Service keeps a stable address in front so callers never chase pod IPs.

Namespaces and cgroups, precisely

A container is one process (or process tree) wearing two orthogonal kinds of kernel restriction. Namespaces isolate what it can see, and naming them is a senior signal: pid (its own process numbering), net (its own interfaces and routing table), mnt (its own mounts), uts (hostname), ipc (shared memory), user (its own uid mapping, so root inside can map to an unprivileged uid outside). Cgroups are the other half: they cap and account for resources, cpu shares, memory limits, io bandwidth, a pids ceiling. Namespaces answer what exists for me, cgroups answer how much I get.

The security consequence separates this from trivia. Because every container shares one kernel, a kernel vulnerability is a shared blast radius, and the isolation is only as strong as that kernel. A hypervisor boundary is coarser but harder to cross. This is why hardened setups reach for user namespaces (rootless), dropped capabilities, and seccomp profiles, and why some workloads run in microVMs like Firecracker.

Choosing a deployment strategy

Three strategies, three cost profiles. Rolling update is the Kubernetes default: replace pods a few at a time, governed by maxSurge and maxUnavailable. No extra infrastructure, but two versions serve traffic during the roll, and rollback means rolling forward to the old image rather than an instant switch.

Blue-green runs two full environments and flips traffic in one cut. Rollback is instant, but you pay for double the capacity, and both colors usually share one database.

Canary sends a small slice of real traffic to the new version, watches error rate and latency, then widens. It catches problems the other two only surface after full exposure, at the cost of the most machinery: traffic splitting plus a metrics signal good enough to promote or abort on automatically.

Wrong "Blue-green makes database migrations safe." The traffic cut is instant; the schema is shared. A DROP COLUMN the old version still reads breaks the moment either color deploys. Expand-then-contract migrations are the real fix, and they are independent of deploy strategy.

Readiness, liveness, and graceful shutdown

Two probes, two jobs, and interviewers listen for whether you keep them straight. A failing liveness probe restarts the container. A failing readiness probe pulls the pod from the Service endpoints so it stops receiving traffic, with no restart. The classic mistake is pointing liveness at a dependency.

livenessProbe:      # WRONG: a DB blip restarts every replica at once
  httpGet: { path: /health/db }
readinessProbe:     # RIGHT: DB check gates traffic, no restart
  httpGet: { path: /health/db }

If the database blinks, a dependency check in liveness restart-loops every replica at once and turns a brief outage into an outage plus a restart storm. Put dependency checks in readiness. Reserve liveness for a wedged process (deadlock, stuck event loop), and add a startup probe for slow boots so liveness does not kill a process still warming.

Shutdown is the piece juniors miss. On rollout Kubernetes sends SIGTERM and waits terminationGracePeriodSeconds before SIGKILL. A well-behaved container fails readiness first to drain, finishes in-flight requests, then exits. Skip that and every deploy drops the requests in flight.