Docker & Kubernetes Essentials

Containers show up in three interview moments: the platform / SRE round that grills the mechanics (what is a layer, what does a Service actually do), the system design round where you deploy whatever you just drew, and the debugging scenario - "a pod is crash-looping, walk me through it" is a stock question. The framing that keeps answers crisp: Docker packages a process with its filesystem (an image is a stack of read-only layers; a container is that stack plus a writable layer and namespaces/cgroups around a process). Kubernetes is a reconciliation loop - you declare desired state in objects, controllers work to make reality match.

• ·Multi-stage builds: build in a fat image (deps, compilers), COPY --from=build only the artifacts into a slim runtime stage. Routinely cuts images from GBs to tens of MBs.
• ·Small, pinned base images: FROM node:22-slim or alpine, never FROM node:latest. latest makes builds non-reproducible and rebuild-roulette.
• ·Order instructions least- to most-frequently-changing: deps manifest before source. COPY package*.json + RUN npm ci first, COPY . . last - so editing source doesn't bust the dependency cache layer.
• ·Use .dockerignore: exclude .git, node_modules, build output, .env. Shrinks the build context (faster sends) and keeps secrets out of layers.
• ·Run as non-root: USER node (or create one). A container escape from root-in-container is a much worse day. Most interview answers forget this one.
• ·One process per container. Sidecars and process managers belong to the orchestrator, not the image.
• ·Combine related RUN steps and clean up in the same layer: RUN apt-get update && apt-get install -y X && rm -rf /var/lib/apt/lists/*. Deleting files in a later layer does not shrink the image - the bytes live on in the earlier layer.
• ·Prefer COPY over ADD. ADD's magic (URL fetch, auto-extract tarballs) is surprising; COPY does exactly one thing.
• ·Never bake secrets into layers (ENV or COPY .env). They're readable with docker history. Use build secrets (--mount=type=secret) or inject at runtime.
• ·Use exec-form CMD ["node", "server.js"] (not shell form) so PID 1 is your process and actually receives SIGTERM - the difference between graceful shutdown and a 10s SIGKILL.
• ·Add HEALTHCHECK (or rely on k8s probes) so the platform knows "running" from "working".

Each Dockerfile instruction produces a read-only layer - a filesystem diff stacked via overlayfs. Layers are content-addressed and shared: ten images FROM the same base store the base once, and a push only uploads layers the registry lacks. At build time, Docker walks instructions top-down and reuses the cached layer when the instruction and its inputs are unchanged (for COPY/ADD, that means file checksums). The first cache miss invalidates every later layer - which is the entire reason for the ordering rule: COPY package.json + install deps before COPY . ., so a one-line source edit rebuilds only the cheap final layers instead of re-running npm ci. Two follow-up traps worth pre-empting: RUN apt-get update in its own layer can serve a stale package index from cache forever (combine update+install), and deleting a file in a later layer hides it but doesn't reclaim the space - the bytes still ship in the earlier layer.

Pod

Smallest deployable unit: one or more containers sharing network namespace (localhost) and volumes. Mortal by design - you almost never create bare pods; a controller owns them.

Deployment

Desired state for stateless pods: image, replica count, update strategy. Manages ReplicaSets to do rolling updates and rollbacks. The default answer for "how do I run my API."

Service

Stable virtual IP + DNS name load-balancing across pods selected by label. Types: ClusterIP (in-cluster, default), NodePort (port on every node), LoadBalancer (cloud LB). Solves "pods die and change IPs."

Ingress

L7 HTTP routing into the cluster: host/path rules + TLS termination, fulfilled by an ingress controller (nginx, ALB, Traefik). One LB fanning out to many Services instead of one LB each.

ConfigMap

Non-secret config as env vars or mounted files, decoupled from the image. Pods don't see updates to env-injected values until restarted.

Secret

Same shape as ConfigMap for sensitive values - but only base64-encoded, not encrypted, by default. Real answer: encryption at rest + RBAC, or an external manager (Vault, AWS Secrets Manager) via CSI/operator. Saying "Secrets are encrypted" is the trap.

StatefulSet

Pods with stable identity: sticky names (db-0, db-1), stable DNS, per-pod PersistentVolumes, ordered rollout. For databases, Kafka, anything where replicas aren't interchangeable.

DaemonSet

Exactly one pod per (matching) node. Node-level agents: log shippers, monitoring, CNI plugins.

Job / CronJob

Run-to-completion workloads with retries (Job); on a schedule (CronJob). Batch processing, migrations, nightly reports.

Namespace

Virtual cluster partition for grouping, RBAC scoping, and ResourceQuotas. team-a/prod-vs-staging separation without separate clusters.

HPA (HorizontalPodAutoscaler)

Scales a Deployment's replicas on CPU/memory/custom metrics. Targets utilization relative to requests - which is why unset requests break autoscaling.

• ·kubectl get pods - confirm the state and restart count; -o wide tells you if it's node-specific.
• ·kubectl describe pod <name> - read Events bottom-up and grab Last State: exit code and reason (OOMKilled, Error). Also catches the lookalikes: ImagePullBackOff, failed mounts, unschedulable.
• ·Decode the exit code: 137 = OOMKilled (raise the memory limit or fix the leak); 1/2 = app error (go read logs); 126/127 = bad command/entrypoint (typo in CMD, missing binary).
• ·kubectl logs <pod> --previous - the dying container's last words. --previous is the key flag; the current container may be seconds old and empty.
• ·Crash is at startup? Check config: missing env var, bad ConfigMap/Secret key reference (describe shows CreateContainerConfigError), wrong DB hostname, migration failing.
• ·Suspect the probes: a too-aggressive liveness probe (short timeout, checks a dependency) kills healthy-but-slow containers in a loop. describe shows probe failures in Events.
• ·Reproduce without the orchestrator: docker run the same image locally, or kubectl debug to poke around (distroless images have no shell for exec).
• ·Still opaque? Override the entrypoint to keep the container alive - command: ["sleep", "3600"] - then exec in and run the real command by hand to watch it fail.
• ·Fix, kubectl apply, kubectl rollout status deploy/<name>, and confirm restart count stops climbing.