A workload needs a kernel version or module your hosts do not provide — why can a container not supply it?
answer
- the image ships user space only
- one kernel, chosen by the host
- files travel, kernel behaviour does not
- escape hatch removes limits, adds nothing
- a kernel requirement is a host requirement
basics
~20 sA container image holds user-space files only; the kernel serving its system calls is the host's. A feature the host kernel does not have is not in the image's power to add, which is the clearest honest signal that this workload wants a machine boundary.
solid answer
~50 sThe image contains no kernel. Every process inside a container issues its system calls to the host's already-running kernel, so the kernel version, its configuration and its loaded modules are properties of the **host**, not of the image. You can package the user-space tools that talk to a feature, and they will start and then fail, because the thing they talk to is absent. That leaves three honest responses: change the fleet so the hosts provide it — which changes the kernel every other workload on those hosts shares; constrain placement to the subset of hosts that do provide it, and carry the fragmentation that creates; or give the workload a **machine boundary with its own guest kernel**, chosen per workload. A workload with its own kernel requirements is telling you it wants its own kernel.
go deeper
Remember the one fact this rests on: the container's system calls are served by the host's kernel, and the image contains no kernel at all. Everything about versions and modules follows from that.
Explain why packaging the user-space half of a feature fails at the first call, and why the privileged escape hatch removes restrictions rather than adding capabilities.
Compare the three responses with their real costs — a fleet-wide kernel change, a pinned host pool with fragmented capacity, or a machine boundary — and say which you would pick for a named workload and why.
Decide the standing rule: whether your platform will ever carry a special host pool for one workload's kernel needs, or whether such workloads are routed to a machine boundary by policy, and what that policy costs.
## Why the image has no kernel to offer A container is a process on the host. When it opens a file, sends a packet or allocates memory, the code that services that request is the **host's running kernel** — the same one serving every other container and every host process. The image supplies the executable, its libraries and its data files. It supplies no kernel, and there is no point at which a runtime loads one from it. So the following are all properties of the host, never of the image: - the kernel version and what it was built with; - which modules are loaded, and which are even available to load; - host-wide behaviour switches, which are set once for the machine; - which system calls exist and what they do. This is the flip side of the fast start-up: you skipped the boot, so you did not get to choose what booted. ## What "just put it in the image" actually gets you Packaging the user-space half of a feature is easy and misleading. The tools install, the process starts, and the first call that needs the kernel half fails — often with a message about a missing device or an unsupported operation, which reads like a permissions problem and is not one. A useful habit is to ask, for any dependency: *is this a file, or is it behaviour inside the kernel?* Files travel in the image. Behaviour does not. The blanket privileged escape hatch is not the fix either, and reaching for it is the classic wrong turn. It removes restrictions that the platform applied to a container; it cannot conjure a capability that the kernel does not implement. And where it *does* allow loading a module, the module goes into the one kernel the whole host shares — so a per-workload requirement has just become a change to every tenant of that machine. That is a fleet change wearing a container's clothes. ## The three honest responses 1. **Change the fleet.** Upgrade the kernel, or arrange for the module to be present, on every host where this workload might be placed. This is a real option and sometimes the right one, but price it correctly: you are changing the kernel that every other workload on those hosts runs on, and you now own that change's blast radius and its rollback. 2. **Constrain placement.** Keep a subset of hosts that provide the feature and pin the workload to them. Cheaper to start, and it fragments your capacity: you now have two pools, two patch streams and a scheduler that can fail to place work while the other pool sits idle. Fine as a transition, expensive as a steady state. 3. **Give it a machine boundary.** A guest kernel is chosen per workload, so its version, configuration and modules are that workload's business and nobody else's. You pay the boundary's start-up, density and I/O costs, and you get a workload whose kernel requirements stop being anyone else's problem. ## Why this is such a clean signal Most "container or machine boundary" arguments turn on judgment about trust and risk, where honest engineers disagree. This one does not. Either the host kernel offers the feature or it does not, and no amount of image building changes that. So a workload that requires a specific kernel version, a module the fleet does not carry, or host-wide behaviour set differently from everyone else's is the least controversial case for a machine boundary there is. | response | what it costs | when it fits | |---|---|---| | change the fleet | every workload on those hosts moves with you | the feature is broadly wanted | | constrain placement | fragmented capacity, two things to operate | a transition, or a small fixed set | | machine boundary | start-up, density, I/O, a second kernel to patch | the requirement is genuinely this workload's alone | ## Two related traps - **Reading a version from inside the container.** What you see is the host's kernel, because there is only one. It does not tell you anything about the image, and it will change under you when the workload is placed on a differently patched host. - **"It works on my machine."** The build host's kernel offered something the production hosts' kernel does not. The image is identical and the behaviour is not, because the part that differed was never in the image. The sentence to leave the interviewer with: *the image ships user space, the host ships the kernel — so a kernel requirement is a host requirement, and a per-workload host requirement is what a machine boundary is for.*
- A teammate proposes granting the container privileged mode so it can load the module itself. What do you say?That it does not supply a missing capability, only removes restrictions — and where it does allow a load, the module enters the one kernel the whole host shares, so a single workload's requirement silently becomes every co-tenant's. It also hands that workload a very wide surface on the host. If the requirement is real, change the fleet deliberately or give the workload its own guest kernel.
- The service worked on the build host and fails in production with the same image. How does this explain it?The image is identical, so the difference is outside it: the build host's kernel offered something the production hosts' kernel does not — a version, a module, or a host-wide setting. Confirm by comparing kernel version and loaded modules across hosts, not by rebuilding the image.
saying these in an interview costs you the question
- Suggests installing a kernel or module into the image to fix it.
- Believes privileged mode can supply a capability the host kernel lacks.
- Reads a kernel version from inside a container and calls it the image's.
- Assumes each container can be given its own kernel settings.
- Treats a fleet-wide kernel change as a per-workload decision.