learninfra · Linux · Networking · Kubernetes · System Design · AI Infrastructure · Exam blueprints · Drills

Multi-container Pods (CKAD)

Init containers, sidecars and the volumes they share: what containers in one pod have in common, and what they do not.

An interactive Kubernetes lesson: 19 steps, about 30 minutes, on a live simulation in your browser.

The shop's frontend runs as one pod, web, with one container. shopper stands in for customers and requests pages through the Service in front of it.

web writes an access log to a file, /var/log/web/access.log. The operations team wants those lines in central logging. The file lives inside the container, where nothing else can read it.

What you will learn

  1. Two containers, one pod

    • A log file nobody can read: One container, one process, one job. A helper that must sit right beside the app gets its own container in the same pod.
    • Add a second container: Containers in a pod do not share a filesystem. Each sees its own image, plus whatever volumes it mounts.
    • localhost inside a pod: Containers in a pod share one network namespace: one IP, one localhost, one set of ports. Two of them cannot listen on the same port.
    • Break it: the helper crashes: READY n/m counts containers, and a pod gets traffic only at m/m. A failing helper takes the whole pod out of service.
  2. Sharing files with volumes

    • emptyDir: a directory both can see: A volume belongs to the pod. Each container opts in with a volumeMount, and may mount it at a different path.
    • What survives a container restart: An emptyDir lives exactly as long as its pod: it survives container restarts and is erased when the pod is removed.
    • Ephemeral volume types: Ephemeral volumes die with the pod: emptyDir is scratch space, configMap and secret deliver files, projected merges sources. Data that must outlive the pod needs a PersistentVolumeClaim.
  3. Init containers

    • Init containers run first, in order: Init containers run one at a time, in order, each to completion. The app containers start only after the last one exits 0.
    • Break it: an init container waits forever: Init:N/M means N of M init containers have finished. A pod stuck there is waiting on the next one: read that container's logs.
    • Break it: an init container fails: A status that starts with Init: is a problem in an init container. The app containers have not been started at all.
  4. Native sidecars

    • A sidecar is an init container that stays: A native sidecar is an init container with restartPolicy: Always. It starts before the app, runs alongside it, and stops after it.
    • A helper in a pod that must finish: A pod finishes when its regular containers finish. A sidecar never holds it open; an ordinary container always does.
  5. Adapter and ambassador

    • Adapter: translate what comes out: An adapter sits on the way out: it converts the app's own output into the standard format others expect.
    • Ambassador: proxy what goes out: An ambassador is a local proxy: the app talks to localhost, and the ambassador decides where the connection really goes.
  6. At exam speed

    • Build it fast, address it precisely
    • Drill: logs of one container
    • Drill: run a command in one container
  7. Recap & playground

    • Cheat sheet
    • Playground