Two workloads on one host want different values for a host-wide kernel tunable — what can the container boundary do about that?

## Two classes of setting A container gets separate views of several resources — its own filesystem, process table, network, ids and hostname — and an accounting group that caps what it consumes. Kernel tunables interact with that split in exactly one way: **a tunable can differ between two containers only if the kernel scopes it to a view the containers already have separately.** That gives two classes: | Class | Typical examples | Can two tenants differ? | Where the value belongs | |---|---|---|---| | Scoped to the container's own view of a resource | listen backlog ceiling, ephemeral port range | yes, per workload | the workload's declaration, where the platform permits it | | One value for the whole machine | memory overcommit policy, ceiling on filesystem watch registrations | no | the host's provisioning | The crucial point is that **membership of those classes is the kernel's decision, not the platform's**. No amount of boundary work promotes a machine-wide value into a per-container one, and a platform that lets you write such a setting into a workload's declaration is either applying it to the host or refusing it, never giving each tenant a private copy. Check the scope of the specific setting before designing around it; the two classes are not distinguishable by intuition, which is why platforms usually gate which settings a workload may touch at all. ## Why the machine-wide class is awkward A machine-wide value has three uncomfortable properties: - **It outlives the workload that wanted it.** If it were carried by whichever container happened to ask, the host's behaviour would drift as workloads came and went, and a replacement host would come up different. - **It applies to the neighbours.** Raising a ceiling for one tenant raises it for every other tenant on that machine, including the ones whose capacity planning assumed the old number. - **It is invisible from inside.** A workload's own declaration says nothing about it, so the same workload can behave differently on two machines for reasons its owners cannot see in their own configuration. There is a fourth, subtler one: a shared ceiling is also **exhaustible**. A global allowance — registrations, ports, table entries — is drawn down by all the workloads on the machine together, so one greedy tenant can consume most of it and leave a quiet neighbour failing against a limit nobody changed. The symptom then appears in the wrong place entirely, and the only thing the failures have in common is the host. ## Resolving the conflict 1. **Confirm the scope** of the exact setting being argued about. Half of these disputes evaporate here, because the setting turns out to follow the container's own view and both tenants can simply have their own value. 2. **If it is machine-wide, look for one tolerable value.** Test the other workloads against the proposed number rather than assuming indifference; the tenant who did not ask for the change is the one who discovers it. 3. **If no shared value exists, separate the workloads.** The demanding one moves to a host population where the value is part of how those hosts are built, and the requirement becomes a placement constraint that somebody maintains. 4. **Record it where hosts are built**, so a rebuilt or replaced machine comes up with the same value. A tunable applied by hand once is a machine that silently regresses on its next restart. 5. **Re-review it like a host change**, because that is what it is — not a workload setting that happens to live somewhere unusual. ## What this tells you about the boundary The container boundary is a set of partitioned views plus an accounting group. It is not a machine, and it does not virtualise the kernel's own configuration. Everything the kernel holds as one value for itself — its version, its loaded modules, its machine-wide tunables — is shared, whatever the workload declarations look like. Density and multi-tenancy arguments that ignore this class of setting tend to fail late, when a tenant's tuning request turns out to be a request to retune everyone. The practical discipline is simply to treat these values as **host properties with tenants attached**: scope verified, value reviewed, change announced, and placement used as the tool of last resort when two tenants genuinely cannot share one number.