skip to content

Container Storage & Data

12 roadmaps18 questions

Where a write from inside a container actually lands - a throwaway layer, a mounted host path, or a volume the platform provisions - and how long it survives. Most data-loss stories start here.

on this pageshow

explore

questions

18

Your batch job's data directory is a host path mounted into the container — how does that differ from a platform-provisioned volume?

level: juniorimportance: must knowfreq 70%

answer

  1. two sources for one path
  2. one names a machine, one asks
  3. who makes it exist if missing
  4. the machine keeps it, the workload leaves
  5. the platform tracks a volume, not your directory

basics

~20 s

A host path hands the container a directory that already exists on whichever machine it runs on. A platform-provisioned volume is storage the platform creates, tracks as its own object, and re-attaches wherever the workload lands.

solid answer

~40 s

Both put non-image data at a path inside the container, but they point at different things. A **host path mount** names a directory on the machine the container happens to run on: nothing is provisioned, the host's ownership and permission bits come through unchanged, and if the directory is missing platforms differ — some refuse to start the container, some quietly create an empty one. A **volume** is storage the platform provisions and tracks with a lifecycle of its own, independent of any container, so a replacement container gets the same data and the platform can attach it wherever the workload is placed, size it and snapshot it. The short version: a host path says *this machine*, a volume says *this workload*. Anything a replacement container must still find belongs in a volume.

code

yaml · 11 lines
yaml
mounts:
  - insidePath: /work/input
    backing: host-directory
    hostDirectory: /srv/drop
    writable: false

  - insidePath: /work/output
    backing: managed-volume
    volumeName: settlement-output
    sizeRequest: 20Gi
    writable: true

go deeper

for a junior

Be able to say the one sentence that matters: a host path points at a directory on the machine you happen to be running on, while a volume is storage the platform makes and keeps for the workload.

for a middle

Explain the consequences rather than the definitions: which one the platform knows about, what happens when the directory does not exist, and why the same spec behaves differently on a laptop and on a machine you did not choose.

for a senior

Show that you design for replacement. Say what a container that is replaced elsewhere will find, what is in the backup inventory and what is not, and be honest about the host-path cases that are still correct.

for a principal

The angle here is what you make the default for other teams. Pointing at a machine's directory is the cheapest thing to write and the most expensive thing to operate, and the cost lands on whoever is on call, not on whoever wrote the spec.

## What a mount is at all Every path a containerised process sees comes from somewhere. Most of them come from the **image**: read-only layers stacked into a single filesystem view. On top of that sits a thin writable area belonging to this one instance, which is discarded when the instance is replaced. A **mount** is an override for one path: it declares that this directory inside the container is not image content — it comes from outside the container, and writes through it go outside too. So the real question is what *outside* means. There are two answers, and they behave nothing alike once a scheduler is involved. ## A host path A **host path mount** (also called a **bind mount**) names a directory on the machine the container happens to be running on and makes it appear at a chosen path inside the container. Nothing is provisioned and nothing is recorded anywhere: at start-up the platform resolves that path on that machine, and from then on the process reads and writes the host's filesystem directly, through the boundary. The properties you should be able to state on demand: - **The storage belongs to the machine, not to the workload.** It existed before the container and remains after it — on *that* machine. - **Ownership and permission bits pass through unchanged.** Whatever numeric owner and mode the host filesystem records is what the process inside must satisfy in order to write. - **The path is the entire contract.** Whether the directory holds the data you meant is not something the platform can check for you. - **If the directory is missing, platforms differ.** Some refuse to start the container; some create an empty directory at that path. Neither outcome is the one you wanted. - **The platform does not know this is state.** It will not size it, snapshot it, list it in an inventory, move it, or stop a second workload writing the same files. ## A managed volume A **volume** is storage the platform provisions and tracks as an object of its own, with a lifecycle separate from any container. The workload spec names a volume and the path to mount it at; making it exist, attaching it to whichever machine the workload is placed on, and keeping it after the container is gone are all the platform's responsibility. - The volume belongs to the **workload**, so a replacement container finds the same bytes. - Because the platform knows the volume exists, it can re-attach it after a restart, decline a placement where it cannot attach it, and offer capacity, expansion and snapshot operations on it. - The spec is portable, because it **asks for storage** rather than pointing at somebody's directory. The same spec run in another environment gets storage there too. (How a workload asks for a particular size and writer count is a subject of its own.) - Many platforms can set the ownership of a volume's contents at attach time, which is one practical reason a volume is the easier answer for a process that does not run as root. ## Side by side | | Host path mount | Platform-provisioned volume | |---|---|---| | What you name | a directory on whichever machine runs the container | a volume the platform creates and tracks | | Belongs to | the machine | the workload | | If it does not exist | platforms differ: refuse to start, or create it empty | the platform provisions it | | After replacement on another machine | the data stays behind; the container sees the new machine's copy of the path | the same volume is attached where the workload lands | | Ownership of contents | whatever the host filesystem already records | the platform can set it at attach time | | Visible to capacity, snapshot and backup tooling | no | yes | ## Why it keeps working on a laptop On a development machine the two look identical, because every assumption a host path makes happens to be true: one machine, a directory you created yourself, a process running as an id that can write it, and nothing moving the workload anywhere. Run the same spec against a node you did not choose and each assumption becomes a question, and the failures are quiet: 1. The workload is replaced on another machine, and the new container finds whatever *that* machine has at the path — usually nothing, occasionally another workload's leftovers. 2. Two copies of the workload land on two machines, each with its own version of "the" directory, so behaviour now depends on placement. 3. The directory exists but is owned by an id the process is not, and the first write is refused. 4. Nothing backs it up, because nothing in the platform knows it is data. ## When a host path is still right It is right when you genuinely mean **this machine**. An agent that has to read its own host's files, node-local scratch or cache you are content to lose, and the developer loop where you edit a tree on your laptop and want the change live inside the container without rebuilding an image are all cases where the data is a property of the machine — which is exactly what a host path expresses. Everything else, and specifically anything a replacement container must still find, wants a volume the platform provisions, tracks and re-attaches.

  • Two containers mount the same host directory and both write to it — what stops them colliding?
    Nothing does. A host path is just a directory; the platform is not tracking it as storage, so it does not know two workloads share it and will not serialise them. Whatever you want — a single writer, a lock file, a distinct subdirectory per instance — the application has to arrange for itself.
  • Does mounting over a path that the image already populated delete that content?
    No. The mount overrides the path for the life of the container: the image's files underneath are hidden, not removed, and they reappear if the mount is taken away. This is why mounting onto a directory the image filled in often looks like the image lost files.
  • When is a host path mount genuinely the right choice?
    When you mean *this machine*. An agent that must read its own host's files, node-local scratch or cache you are happy to lose, and the developer loop where an edit on your laptop should be live inside the container without a rebuild are all cases where the data is a property of the machine, and a host path says exactly that.

A host path is the drawer in one particular desk: what is in it depends on which desk you were given today. A managed volume is a locker the building assigns to you and wheels to whichever room you are moved to.

saying these in an interview costs you the question

  • Says a host path mount is just a volume under a different name.
  • Thinks the platform copies a host directory to whichever machine the workload lands on.
  • Assumes data written through a host path follows the workload to another machine.
  • Cannot say who is responsible for the directory existing on that machine.
  • Treats a host path as production-ready because it worked on a laptop.
  • Believes mounting over a directory deletes the image content underneath it.
open as a page

Why does a file a container writes inside itself vanish when that instance is replaced by a new one?

level: juniorimportance: must knowfreq 84%

basics

~20 s

The write landed in that instance's own thin writable layer, a private area created empty on top of the read-only image. Replacing the instance discards the layer, and nothing written only there is kept or recoverable.

open as a page

A container process runs under a non-root numeric user id and gets permission denied writing to its mounted host directory — why?

level: middleimportance: must knowfreq 58%

basics

~20 s

Mounted storage keeps the ownership and mode bits it has outside the container, and the check compares numeric ids: if the process is neither the owner nor in the owning group, only the others bits apply — which rarely include write.

open as a page

A workload declares a storage request of 200 gigabytes with one writer, so what does the platform do before the container starts?

level: middleimportance: must knowfreq 62%

basics

~20 s

The platform treats the declaration as a request: it looks for an existing backing store that satisfies the size and writer count, or creates one on demand, then binds the request to that one store. The workload starts only after binding.

open as a page

Why must each copy of a data-owning workload keep a stable identity and its own storage across replacement?

level: middleimportance: must knowfreq 66%

basics

~20 s

A data-owning copy holds data no other copy has, so the replacement is useful only if it comes back as that same copy. A durable per-copy name plus storage bound to that name, not to the instance, is what makes that possible.

open as a page

A search indexer with one copy and a bound 200-gigabyte single-writer volume is scaled to three copies, so why do two never start?

level: seniorimportance: must knowfreq 55%

basics

~20 s

One request bound one store, and that store honours a single writer at a time. The first copy attaches it; the other two are refused at attach and wait, never started. Scaling the workload did not multiply the request.

open as a page

For a data-owning workload you run yourself, what must a backup cover that redeploying the image never restores?

level: seniorimportance: must knowfreq 58%

basics

~20 s

Everything written after the image was built. An image restores the process and none of its data, so a data-owning workload needs a separate copy of the data, held outside its failure domain, mapped back to the member that owned it, and proven by an actual timed restore.

open as a page

What does the writer count in a storage request promise, and at what moment does the platform enforce it?

level: middleimportance: should knowfreq 46%

basics

~20 s

It promises how many running copies may hold the volume for writing at once — one, or many — and it constrains which backing stores can satisfy the request. The platform enforces it when it binds and again when a copy attaches, never inside the file.

open as a page

After a full outage, why do the copies of a data-owning workload come back one at a time in a fixed order?

level: middleimportance: should knowfreq 44%

basics

~20 s

Ordered bring-up gives the group a first member. Each copy starts only after the previous one reports ready, so later copies join something that already exists instead of several copies each initialising their own empty data set. Shutdown runs in reverse.

open as a page

A worker unpacks each upload into a temporary directory inside the container — why declare a scratch area for that instead?

level: middleimportance: should knowfreq 55%

basics

~20 s

A declared scratch area gives the intermediate files a named path, an explicit size ceiling and a chosen backing — memory or disk — that the platform can account for. The writable layer gives none of that: it is unbounded and drawn silently from shared host storage.

open as a page

A nightly reconciliation job that worked against a laptop directory now reads an empty input tree on a scheduler-chosen machine — why?

level: seniorimportance: should knowfreq 46%

basics

~20 s

A host path resolves on whichever machine the container lands on, so the path is not the data. On an unprepared machine the directory is missing or empty, and platforms differ on which of those you get.

open as a page

A workload will not start because its 200-gigabyte storage request is still unbound, so how do you work out which cause it is?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Read the request's own status rather than the workload's, because no process ever ran. Three causes account for nearly all of it: no store large enough, nothing configured to create one on demand, or a declared writer count no candidate can honour. Each leaves a different trace.

open as a page

Why does storage attached in one zone pin a data-owning copy to that failure domain, and what does losing it cost?

level: seniorimportance: should knowfreq 47%

basics

~20 s

Placement follows the data: a copy can only run where its backing store can be attached, so the candidate hosts shrink to one zone. If that zone is lost the copy has nowhere to go, and recovery is bounded by moving or rebuilding the data, not by starting the process.

open as a page

A long-running worker's writable layer has grown to tens of gigabytes of temporary and rotated files — what actually clears it?

level: seniorimportance: should knowfreq 46%

basics

~20 s

Two things clear it: the process deleting files it wrote, which releases those bytes immediately, and replacing the instance, which discards the layer whole. Restarting the same container in place keeps it, and nothing inside prunes it on a schedule.

open as a page

Should the team run the payments ledger itself on the container platform or buy a managed data service, and what decides it?

level: principalimportance: should knowfreq 50%

basics

~20 s

Capability is not the question - the platform can run it. The decision turns on who owns durability, restores, version upgrades and the pager, weighed against the control and the money a managed service costs, and against what an hour down and an hour of lost writes are worth.

open as a page

A job mounts its input tree read-only and its output volume writable — what does the read-only mount actually prevent?

level: middleimportance: nice to knowfreq 32%

basics

~20 s

Only this container's writes through that one path. The write is refused at the moment it is attempted. It does not freeze the underlying storage, does not stop other writers, and does not cover any other path the container can reach.

open as a page

A team backs a worker's scratch directory with memory instead of disk — what does that speed cost them?

level: middleimportance: nice to knowfreq 30%

basics

~20 s

Every byte written into a memory-backed scratch area is charged against the workload's own memory budget, as if the process had allocated it. The area's ceiling must therefore fit inside that budget, on top of what the code actually needs.

open as a page

How should a platform team set the default storage request it offers — size, writer count, room to grow — when those choices resist reversal?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

Default to a single writer, a deliberately modest size, and expansion enabled, because growth is usually possible and shrinking and changing writer count are not. Then make used-versus-requested capacity a watched signal, since a full volume hurts more than unused capacity costs.

open as a page