Container Isolation Model

Passing the CPU ceiling only slows a process: it is throttled, waits for the next period's quota, and stays alive. Passing the memory ceiling ends it — there is no memory throttle, so the kernel kills a process inside the boundary.

Root inside a container is an id read in that container's own view, and the runtime already trimmed its privilege set, so host-wide powers like setting the clock are missing. Many setups also map that id onto an unprivileged host id.

A container shares the host's already-running kernel; a virtual machine boots a guest kernel and a whole system of its own from a disk image. Sharing removes the boot, so a container starts a process in milliseconds instead of booting a machine.

The fences hide other workloads; they do not rewrite the interfaces that report machine capacity. Those numbers come from the shared kernel's host-wide view, while the container's ceiling lives in an accounting group nobody told the process about.

It bets that the workloads will not peak at the same time. Placement only subtracts reservations from capacity, so ceilings may sum far past what the host owns. Density is the payoff; coincident peaks are the unpaid bill.

A reservation is a placement input: the scheduler subtracts it from a node's free capacity when deciding where a workload fits. A ceiling is enforced on the running process by the kernel's accounting mechanism. Different actors, different moments, different failures.

Two components split the work. A container manager pulls and unpacks an image into a root filesystem and writes a configuration document beside it; a low-level runtime then applies the fences named in that document and executes the declared command as the first process inside the boundary.

They stop too. A ceiling bounds how much of a resource a workload consumes; it does not bound the kernel running on that workload's behalf, and one kernel serves every container on the machine, so a panic takes all of them down together.

No. 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.

Everything the guest model duplicates per instance goes away: a resident kernel, a first process and system services, the memory set aside for the guest up front, and a full disk image. What remains per container is roughly the workload's own working set.

Everything the ceilings do not divide: one pool of cached file pages, one storage device and its queue, one network link, and the shared path to memory. Ceilings partition two axes and certify nothing about the rest.

Two agreements carry it: an image specification fixing what an image is — content-addressed layers plus a recorded configuration of command, environment and architecture — and a runtime specification fixing what a runtime is handed and what it must do with it.

Root's authority is a set of separately grantable privileges, and a runtime hands a workload a small default subset. Privileges whose effect reaches the shared host are withheld; privileges whose effect ends inside the container's own view are kept.

Under id remapping the container's ids sit on a range of unprivileged host ids, so a file created inside as id 0 lands on the host owned by the first id of that range - a number no host account claims, which is why tools print it raw.

A 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.

The separate process table view: each container sees only its own processes, so the agent finds nothing to watch. Either start it sharing the target's process view, collect from the host instead, or have the application publish what the agent needs.

Processor time can be shared more thinly, so a shortage slows everything and ends nothing. Memory is occupied space that cannot be split further, so the only way out of a shortage is taking it from someone.

Set them equal when the replica's performance must not depend on what else lands beside it: the capacity it is placed against becomes the capacity it may use. You pay for the peak continuously, which is worth it for latency commitments and not for elastic background work.

Most services demand more memory while initialising than while serving: configuration and data are loaded, caches are warmed, pools are opened, often concurrently. A ceiling sized from steady-state observation is below that transient peak, so the wall is hit before serving ever begins.

A CPU ceiling is a quota per short repeating period, not a long-run average. A burst exhausts one period's quota and the process waits out the rest of that period, so requests stall in slices while the averaged number stays low.

Privileged mode restores the full privilege set at once and typically disables the confinement profiles and exposes host devices, leaving little but the separate views. The disciplined alternative is to read the denied operation and request that single privilege.

The manager is not the workload's parent. The low-level runtime that created each container exited at start-up, and a small per-container supervising process sits between: it parents the first process, owns its output pipes and holds its exit status until the manager returns and re-attaches.

Nothing, for a value the kernel keeps per machine. Some settings follow a container's own view of a resource and can differ per workload; a single machine-wide value is one number for everyone, so the conflict is settled by placement, not by configuration.

There is no single ratio. Set the gap per class of workload, priced by what that class's failure costs, with separate rules for processor time and memory. The guardrail is the victim class's latency, not utilisation.

Decide two things: how much version fragmentation the estate will carry, and how fast the whole fleet can be turned over. One version is cheapest to certify and patch; each extra host population buys one workload's requirement at a permanent cost.

Runs whose code the customer controls, on hosts that also hold other tenants' data or platform credentials, justify a machine boundary. The deciding questions are whose code it is and what else is reachable through one shared kernel — not how risky the feature feels.

Each container gets its own host-identity fence, and the runtime sets that name per instance, so a replacement carries a different one. Identity meant to outlive an instance must be supplied as configuration, not read back from the hostname.

One host keeps one pool of cached file pages. A single pass over a large file fills it with pages nobody will read again, pushing the service's hot pages out, so its reads now reach the storage device.

Everything above the seam stays: the same image, the same configuration document, the same manager and the same lifecycle operations. What changes is who answers the workload's system calls — and with it start-up time, throughput and which unusual calls and devices still work.