A vendor library needs kernel features newer than the host's shared kernel — can the container image supply them?
answer
- what is actually inside an image
- who provides the system calls
- userspace ships; the kernel does not
- one kernel per host, shared by all
- new program, old kernel: the breaking direction
basics
~20 sNo. An image carries only userspace: binaries, libraries and files. Every container on a machine executes against the one kernel that machine booted, so a newer kernel version, or a feature from an unloaded module, has to come from the host.
solid answer
~50 sAn image is a userspace filesystem. It can carry an entirely different set of system libraries from the host's, which is why one image runs on machines that look nothing alike — but it carries no kernel, and the processes inside it make their calls into the single kernel the host booted. So a library that needs a newer kernel interface fails on an older host whatever base image you pick, and a feature delivered by a loadable kernel module is unavailable until someone loads that module on the host itself. The direction matters: kernels generally keep working for programs built against older interfaces, so an older image on a newer kernel is usually fine, while newer userspace on an older kernel is the case that breaks. The remedies are all host-side — raise the kernel, or place the workload on hosts that already satisfy it.
go deeper
Remember what an image actually holds: files, libraries and binaries, never a kernel. Every container on a machine runs against the kernel that machine booted.
Explain why a different userspace still works while a kernel requirement does not, and name the breaking direction: a new program against an old kernel.
Show the host-side remedies you would really run — raise the kernel, or keep a host population that satisfies the requirement — and turn the requirement into an explicit placement constraint instead of a surprise.
Weigh what accepting a vendor's kernel requirement costs the estate: another host population to certify and patch, fragmented capacity, and a dependency you now own indefinitely.
## What an image contains, and what it does not An image is a stack of read-only layers that together make a root filesystem: executables, shared libraries, configuration files, certificates — whatever the program expects to find on disk. When a container starts, a runtime unpacks that filesystem, hands the process separate views of the machine (filesystem, process table, network, ids, hostname), applies the accounting and limiting group that caps its consumption, and runs the entry program. **Nothing in that sequence boots a kernel.** That is both the trick of the format and its hard edge. The image can carry a completely different userspace from the host's, because a program needs only its own libraries on disk plus a kernel that accepts the calls it makes. It cannot carry a kernel, because what it starts is an ordinary process on the host, scheduled by the host's kernel and served by it. So on one machine: - every container is served by **one kernel**, the one the machine booted; - that kernel's version is a property of the **host**, never of an image; - the set of loaded kernel modules is likewise **one set**, shared by every workload; - a process that asks what kernel it is running on gets the host's answer, even though almost every other system fact it can see comes from its image. ## Why a kernel requirement is a host problem A vendor library that wants a newer kernel is asking for an interface the host either implements or does not. If it is missing, the call fails — sometimes loudly at start-up, sometimes as a silent fallback to a slower or weaker path that only shows up under load or in an audit. Either way the failure is unaffected by anything you change in the image. | What is required | Where it is satisfied | What changing the image does | |---|---|---| | A newer library, tool or certificate | inside the image | fixes it | | A newer kernel interface | on the host | nothing | | A feature from a loadable module | on the host, loaded with host privilege | nothing | | A host-wide tunable at a particular value | on the host | nothing | The module row is worth dwelling on. Loading a module is a host operation that needs host-level privilege; an ordinary container cannot do it for itself, and should not be given what it would take. Once loaded, the module is part of that host's kernel **for every workload on it** — one tenant's requirement widens the code surface all the others are exposed to, and the host's owners now have one more thing to patch and to re-load after a restart. ## The direction that breaks The two mismatches are not symmetric. Kernels are generally built so that programs compiled against older interfaces keep working, which is why hosts are upgraded under unchanged images far more often than the reverse. That guarantee is not absolute — behaviour can be tightened, and a changed default can surprise a program that leaned on the old one — but it is the direction that normally survives. The breaking direction is the other one: **new userspace on an old kernel**. The interface simply is not there, and no base image, no rebuild and no extra privilege adds it. Privilege decides what a process is *allowed* to ask for; it has nothing to say about what the kernel *implements*. ## What you actually do 1. **Pin down the real requirement.** A kernel version, a module, or a host-wide setting are three different asks with three different costs. Establish which, and whether the program fails loudly or quietly degrades. 2. **Raise the kernel on the hosts**, if the fleet can carry that version — the simplest answer whenever it is available. 3. **Otherwise place the workload where the requirement already holds**, and make that an explicit placement constraint rather than an accident of which machine had capacity. 4. **Record the requirement alongside the workload**, so that a replacement host or a move to different capacity does not quietly break it months later. 5. **Ask whether it is permanent.** A standing kernel requirement is a standing cost to the estate, not a one-off change. ## What this is not It is not a permissions problem, and it is not fixed by pinning the image by digest — digest pinning fixes *which bytes run*, and says nothing about what the kernel underneath supports. It is also not evidence that the container boundary is broken: the boundary was never a machine boundary, and supplying a workload with its own kernel is a different kind of boundary with its own trade-offs, a deliberate decision rather than a workaround for a missing interface.
- A teammate reads the kernel version from inside the container and sees the host's, not the image's. Why?Because only one kernel is involved. The separate views a container is given cover the filesystem, process table, network, ids and hostname — not the running kernel, which is the host's single instance. Anything the kernel reports about itself is therefore a host fact, and tooling that treats it as an image property is reading the wrong layer.
- The missing feature comes from a loadable kernel module. Who loads it, and what does loading it change for everyone else?Loading is a host operation carried out with host privilege, not something an ordinary container does for itself. Once loaded, the module is part of that host's kernel for every workload on it, so one tenant's requirement widens the surface every other tenant is exposed to, and the host owners now own patching it and keeping it loaded across restarts.
- Why does an old image usually run fine on a much newer kernel?Because kernels are generally built to keep working for programs compiled against older interfaces, so existing calls keep their meaning. The guarantee is not absolute — behaviour can be tightened and a changed default can surprise a program — but it is the direction that normally survives, which is why hosts get upgraded under unchanged images far more often than the reverse.
Your flat is yours to furnish — different fittings, different floors, nothing like the neighbours'. The building's water main is not yours: if a new appliance needs higher pressure, no amount of redecorating supplies it.
saying these in an interview costs you the question
- Thinks choosing a newer base image upgrades the kernel.
- Believes each container boots a kernel of its own.
- Assumes a kernel module can be loaded from inside an ordinary container.
- Says the kernel version seen inside a container comes from the image.
- Assumes kernel compatibility breaks equally in both directions.