A workload declares a storage request of 200 gigabytes with one writer, so what does the platform do before the container starts?
answer
- a request, not a device
- the platform resolves it
- matched or created on demand
- one request, one store
- no binding, no start
basics
~20 sThe 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.
solid answer
~50 sThe workload never names a disk. It declares what it needs — a size, how many copies may write at once, and optionally which kind of store — and the platform resolves that into something real. Resolution is called **binding**: the platform either matches the request against an already-provisioned store that satisfies every property, or calls a component that creates one on demand, and then marries request and store one-to-one. The store may be bigger than asked for; it is never smaller. Until the request is bound the workload is held before start rather than run without its storage, so an unbound request shows up as a workload that has produced no logs at all. Binding is exclusive and stable: no second request takes that store, and the request does not quietly move to a different one later.
code
yaml · 12 lines# what the workload declares
storageRequest:
requestedSize: 200GB
writers: single # one copy may write at a time
storeKind: fast-block # a kind the platform offers, not a device
growable: true
# what the platform reports back once it resolves the request
storageRequest:
state: bound
boundTo: store-7f3a # the store it matched or created
actualSize: 256GB # a floor was asked for, not an exact sizego deeper
Remember the shape: the workload asks for a size and a writer count, and the platform finds or creates something real to satisfy it. Nothing starts until that match exists.
Explain binding as a one-to-one marriage of a request to a backing store, name both routes to satisfying it — an already-provisioned store or one created on demand — and say the store may be larger than asked for.
Show that you read an unbound request as a start-time symptom: the workload produced no logs because no process ran, which already rules out an entire family of application-level causes before you touch anything.
Frame the request contract as an interface you offer teams. What the platform accepts, what it creates on demand and what it refuses outright decides how portable every team's spec is between environments.
## A request, not a disk A durable volume does not begin life as a device you look up by name. It begins as a **request** carried in the workload's spec: a size, a **writer count** (how many running copies may write to it at the same time), and usually a hint about which kind of store will do — a fast block device, or storage reachable by many clients at once. The workload says what it needs. It does not say what it gets. That indirection is the entire point: the same spec runs on a small platform whose only backing store is a local disk and on a fleet where storage is attached over the network, because the platform — not the author — resolves the request. ## Binding: what resolution actually is Resolution is called **binding**, and it has two halves. 1. **Find or make a backing store.** The platform looks for an existing store that satisfies *every* declared property: at least the requested size, the requested writer count, the requested kind. If none exists and the platform has a component that can create storage on demand, it calls it — **dynamic provisioning** — and the store is created for this request specifically. 2. **Marry the two, exclusively.** Once matched, request and store are bound one-to-one. No other request binds to that store, and this request does not silently move to a different store afterwards. Two consequences follow that people are routinely surprised by: - **The store may be larger than the request.** A request for 200 gigabytes can bind to a 256-gigabyte store, because the request is a floor, not an exact-match key. It is never satisfied by something smaller. - **Binding survives the container.** The bound store outlives the process, the container and the replacement of the container. That is the property the whole mechanism exists to provide. ## The two ways a request gets satisfied | | Pre-provisioned pool | Created on demand | |---|---|---| | Who makes the store | an operator, ahead of time | a platform component, at request time | | What must match | the request against stores already sitting there | the requested kind against something the platform can create | | Typical failure | no candidate in the pool fits | nothing is configured to create that kind | | Lifecycle | the store pre-dates and often outlives the request | the store is created for this request and is usually reclaimed with it | Most platforms support both, and a request written for one can sit unbound forever on a platform set up for the other. That is not an exotic failure — it is the ordinary reason a spec that worked in one place hangs in another. ## Why the workload waits instead of starting When the request is unbound, the workload is **not started at all**. It is not crash-looping, and it has produced no logs, because no process ever ran. Platforms hold the workload rather than starting it without its declared storage, and the reason is worth saying out loud: a process that started anyway would either fail confusingly on its first write, or — much worse — write successfully into a throwaway area, look completely healthy, and lose everything at the next replacement. So "no logs at all" is itself diagnostic. A workload that logs and then dies has a different problem from one whose storage request never bound. ## What the request deliberately does not say - **Not the device.** The request has no device name and no host path in it; naming a host path is a different mechanism with different portability properties. - **Not where the bytes physically live.** That is the backing store's business, and it is what makes the same spec portable. - **Not a guarantee of a copy.** A bound volume is storage, not a backup; keeping a second copy of that data is a separate subject with its own machinery. - **Not how many copies exist.** One request binds to one store; scaling the workload does not multiply it. ## Why interviewers ask it Because a request that never binds is one of the most common reasons a workload never starts, and because the request-and-bind model is the piece people skip. Candidates who learned one platform's storage objects can usually recite the object names and still cannot say what happens between "I asked for 200 gigabytes" and "a process is writing to something durable". The answer is: a match or a creation, then an exclusive binding, then — and only then — a start.
- Can a bound request later be re-pointed at a different backing store?Not as a normal operation. Binding is exclusive and stable — that is what lets the data outlive the container. Moving to a different store is a data migration: provision a new store through a new request, copy the contents, then switch the workload over. Platforms deliberately do not do that silently, because a request that drifted to an empty store would look healthy and have lost everything.
- Why does the bound store sometimes report more capacity than was requested?The requested size is a minimum, not an exact match. A pre-provisioned pool offers whatever sizes an operator created, and an on-demand component often rounds up to the granularity its backing technology allocates in. Anything at or above the request satisfies it; anything below it does not. Plan on the number you asked for, not the number you were given.
- What happens to the backing store when the workload is deleted?It depends on how the store came to exist. A store created on demand for a request is typically reclaimed with it, which is exactly the surprise people hit when they delete a workload to 'restart it cleanly'. A pre-provisioned store usually outlives the request and can be bound again. Because platforms differ here, treat it as a property to check deliberately, not to assume.
It is a room booking made by size and occupancy rather than by room number: the desk either finds a room that fits or opens one up, and from then on that reservation names exactly one room.
saying these in an interview costs you the question
- Thinks the request names a specific disk or host path
- Says the container starts and attaches the storage lazily
- Believes an unbound request makes the container crash-loop
- Assumes the bound store is exactly the requested size
- Treats a bound durable volume as a backup of the data