This simulator puts two containers on one Linux host and lets you change the rules that isolate them. Container A is an always-runnable process with a CPU quota, a memory limit and an optional PID namespace; container B is a sibling that keeps running when A is throttled or killed. Every reading is calculated by a deterministic model, not scripted.
• A 3D cutaway of the host CPU and RAM, a shared Linux kernel layer, two container process domains and a CPU-quota timeline, each selectable for an explanation. • Sliders for Container A CPU quota (10 to 100 percent of one CPU), the size of A's allocation attempt (64 to 1024 MiB) and A's memory limit (128 to 1024 MiB), plus a checkbox for a separate PID namespace. • Six live readouts: A CPU time used, A throttled time, the current quota period, A resident memory, the OOM kill count and the process ID A can see. • Orbit, focus, auto-rotate, label and expand controls for the scene, plus a Restart trial button, pause and step controls, and a playback speed selector.
A namespace changes what a process can see; a cgroup changes how much it can use. In this lab, turning on the PID namespace makes A appear as PID 1 inside its own domain while the host still knows it as PID 4101, yet the CPU budget stays exactly the same — removing PID isolation does not remove limits. The CPU quota works per 100 ms period: A runs for quota percent of the period, then waits, so a 25 percent quota gives it 25 ms of every 100 ms and leaves the rest for B. The memory limit is checked against the allocation attempt: if the attempt exceeds the limit, A is killed once and its resident memory drops to zero while B keeps running.
The model has one always-runnable task in A, one sibling B and one CPU. Quota runtime is idealized as a contiguous block at the start of each period, and the OOM kill is a deterministic no-swap allocation failure rather than a full Linux reclaim and victim-selection model. All timings and capacities are teaching parameters, not cloud-provider performance guarantees, and the hardware geometry is representative. The key point it demonstrates is structural: containers share one kernel, unlike virtual machines, which each boot their own.
No. Containers share the host kernel; namespaces change which processes and resources each container can see, and cgroups account for and limit its CPU and memory. That is why a container starts quickly compared with a virtual machine, and why a kernel-level problem affects every container on the host.
No. Namespace visibility and cgroup constraints are independent mechanisms. In the lab, unticking the PID namespace makes A show the host PID 4101 instead of PID 1, but its CPU quota throttling and memory limit behave exactly as before.
It gives Container A 25 ms of run time in every 100 ms scheduling period. Once that budget is used, A is throttled until the next period begins, which you can see in the A CPU time used and A throttled time readouts. Container B uses the remaining time.
When A's allocation attempt is larger than its memory limit. The model then kills A once, stops it executing and releases its modeled memory, and increments the OOM kill count. Real Linux adds reclaim, swap and victim-selection logic that this deterministic model intentionally leaves out.