Containers — namespaces, cgroups, difference from VMs: Worked examples

4.2.41 · D3 · Coding › Operating Systems › Containers — namespaces, cgroups, difference from VMs

Yeh page Containers — namespaces, cgroups, difference from VMs ka drill floor hai. Hum parent se do ideas lete hain — namespaces (ek process kya DEKH sakta hai) aur cgroups (ek process kya USE kar sakta hai) — aur unhe har us case se guzarte hain jo ek real machine ya exam throw kar sakti hai.

Shuru karne se pehle, ek reminder taaki kuch bhi use hone se pehle build ho jaye:

Definition Teen numbers jo cgroups compute karwate hain

quota — kitne microseconds ka CPU time ek group ko har window ke andar allowed hai. Ek microsecond ( $μ s$ ) ek second ka ek millionth hota hai, $1 0^{- 6} s$ .
period — us window ki length microseconds mein. Kernel har period mein quota fresh deta hai.
memory.max — ek byte count. Ek byte storage ka ek character hai; $1 MiB = 1024 \times 1024 = 1048576$ bytes (mebibyte, powers of two — decimal megabyte nahi). Ek step upar, $1 GiB = 1024 MiB$ (ek gibibyte).
pids.max — ek plain count ki group mein ek saath kitne processes (tasks) ho sakte hain. Count cross karo aur agla fork refuse ho jaata hai. Yeh fork-bomb ka brake hai.

Woh ek formula jo hum baar baar use karte hain: $CPU share = \frac{quota}{period} cores$ Ratio kyun, subtraction kyun nahi? Kyunki "share of a core" relative hota hai — tum chahte ho ki har window ka kitna fraction tum jaag rahe ho, aur ek fraction hamesha part ka whole se division hota hai.

Scenario matrix

Containers ke baare mein har sawaal inhi cells mein se ek mein aata hai. Neeche diye worked examples mein se har ek us cell ke saath tagged hai jo woh cover karta hai, aur saath mein yeh sab hit karte hain.

#	Case class	Tricky part	Example
A	CPU quota < period (fraction of a core)	share below 1	Ex 1
B	CPU quota = period (exactly one core)	boundary value	Ex 2
C	CPU quota > period (multiple cores)	share above 1	Ex 3
D	Degenerate quota = `max` (unlimited)	division by "infinity"	Ex 4
E	Memory limit + OOM decision	byte arithmetic, over/under	Ex 5
F	PID namespace numbering	"PID 1" ka surprise	Ex 6
G	User namespace UID mapping	root-inside ≠ root-outside	Ex 7
H	Container vs VM word problem	kaunsa, aur kyun	Ex 8
I	Exam twist: cgroup without namespace	isolation vs limits confusion	Ex 9

Agla figure ek CPU ki timeline hai. Time left se right chalti hai; har period ek box hai; har box ka shaded part woh quota hai jo group ko run karne ki allowed hai. Dekho ki fraction chaaron cases mein kaise badlta hai — woh fraction hi answer hai. (Case C ko zyada se zyada ek core chahiye, isliye usse ek se zyada aise timelines chahiye — hum usse Ex 3 mein words mein handle karte hain.)

Figure — Containers — namespaces, cgroups, difference from VMs

Worked example Ex 1 — Case A:

cpu.max = "25000 100000" Ek container cpu.max = "25000 100000" ke saath configured hai. Usse kitne cores milte hain?

Forecast: padhne se pehle guess karo — kya yeh ek poore core se zyada hai ya kam? (Quota box sirf partly filled hai, toh… kam.)

Do numbers padho: $quota = 25000 μ s$ , $period = 100000 μ s$ . Yeh step kyun? cpu.max hamesha "quota period" us order mein store karta hai; poore calculation ko dono chahiye, isliye pehle hum inhe naam dete hain.
Formula apply karo: $\frac{25000}{100000} = 0.25$ . Yeh step kyun? Hum chahte hain ki har window ka fraction kya hai jab group jaag raha hai — figure mein pehla shaded box dekho: ek quarter filled.
Interpret karo: 0.25 cores, yaani ek CPU ka 25%.

Verify karo: units — $μ s / μ s$ cancel ho jaate hain, ek pure number of cores bachta hai. Sanity check: $0.25 < 1$ , match karta hai "quota period se chota → ek core se kam." ✓

Worked example Ex 3 — Case C: more than one core

cpu.max = "300000 100000" ek 8-core machine par. Cores granted? Koi cap issue?

Forecast: quota, period se bada hai — kya tum ek single window mein ek core se zyada use kar sakte ho?

Compute karo: $\frac{300000}{100000} = 3$ . Yeh step kyun? Same ratio; yahan numerator denominator se zyada hai, isliye answer 1 se zyada hai.
Interpret karo: 3 cores. Figure ke last panel mein box completely full draw kiya gaya hai — woh sirf ek core saturated dikhata hai. Actually $3 \times$ tak pahunchne ke liye, group teen cores par saath mein run karta hai, har ek period ke andar fully used; imagine teen copies of that full box parallel mein stack ki hain. Yeh step kyun? Ek single core ek window mein 100% se zyada nahi de sakta; scheduler extra quota ko kai cores par simultaneously spread karta hai. Yahan scheduler CFS (Completely Fair Scheduler) hai, Linux ka default process scheduler — woh machinery jo decide karti hai ki kaunsa task kaunse core par aur kitni der tak run karta hai (dekho Scheduling — CFS and CPU shares). Figure sirf ek core ki timeline draw karta hai, isliye "3 cores" arithmetic se aata hai, picture se nahi.
Feasibility check karo: $3 \leq 8$ cores exist karte hain, isliye grantable hai.

Verify karo: $300000/100000 = 3$ (exactly); $3 \leq 8$ . Agar host mein sirf 2 cores hote toh effective cap 2 hoti, lekin configured share phir bhi 3 hai. ✓

Worked example Ex 4 — Case D (degenerate): unlimited CPU

cpu.max = "max 100000". Woh share kya hai, aur hum formula mein directly plug kyun nahi kar sakte?

Forecast: kaunsa number, 100000 se divide hone par, "no limit" ka matlab hai?

Literal max ko recognize karo: yeh ek number nahi hai, yeh woh keyword hai jiska matlab hai "koi quota enforce nahi." Yeh step kyun? Blindly $max /100000$ karna ek category error hai — divide karne ke liye koi finite quota nahi hai.
Limit ko conceptually interpret karo: jaise quota $\to \infty$ , $share = quota / period \to \infty$ , yaani uncapped — group har core use kar sakta hai jo scheduler dega. Yeh step kyun? Yeh degenerate input Case C ka limiting behaviour hai jo infinity tak push hua hai; shaded region har core ke har box ko fill kar degi.
Answer: unlimited CPU (ek naye cgroup ka default).

Verify karo: consistency check — Case C growing quota ke saath (1×, 3×, 10× period) 1, 3, 10 cores deta hai; trend ka koi ceiling nahi hai, confirming max = ∞ = uncapped. ✓

Memory: case E

Worked example Ex 5 — Case E: OOM-kill decision

memory.max = 268435456. Process ka resident memory (RSS) $250 MiB$ tak chadh jaata hai, phir $260 MiB$ tak. Har point par: killed ya safe?

Forecast: $268435456$ bytes kitne MiB hain — aur kya 260 usse upar hai ya neeche?

Limit ko MiB mein convert karo: $\frac{268435456}{1048576} = 256$ MiB. Yeh step kyun? Knob raw bytes mein hai lekin usage MiB mein quoted hai; hume like ke saath like compare karna hai (dekho Docker images and layered filesystems (overlayfs) ki yeh bytes kahan rehte hain).
$250$ MiB vs $256$ MiB compare karo: $250 < 256$ → safe. Yeh step kyun? cgroup memory controller tab hi act karta hai jab group ki total charged memory cap se zyada ho; usse neeche rehna kuch trigger nahi karta.
$260$ MiB vs $256$ MiB compare karo: $260 > 256$ → cap se upar → kernel pehle reclaim karne ki koshish karta hai, phir agar nahi kar paya toh OOM-killer fire karta hai aur group mein ek process kill karta hai. Yeh step kyun? memory.max ek hard ceiling hai; guest ki taraf se swap karne ke liye koi VM nahi hai — wohi host kernel isse enforce karta hai.

Verify karo: $268435456 = 256 \times 1048576$ ✓; $250 < 256 \leq 260$ , isliye exactly do points mein se ek over hai. Units sab MiB. ✓

Namespaces: cases F and G

Agla figure do process tables side by side dikhata hai: host ka table (bahut saare PIDs) aur container ka private PID-namespace table (1 se renumbered). Red arrow follow karo — yeh wahi running process hai jo do alag ID badges pehne hai.

Worked example Ex 6 — Case F: "PID 1" ka surprise

Host par, ps tumhara shell PID 4021 dikhata hai. Tum unshare --pid --fork --mount-proc bash run karte ho aur andar echo $$ run karte ho. Woh kaunsa PID print karta hai, aur kya host-4021 abhi bhi exist karta hai?

Forecast: ek fresh PID namespace counting kahaan se shuru karta hai?

unshare --pid naye bash ko uska apna PID table deta hai. Yeh step kyun? Parent se yaad karo: har CLONE_NEWPID ek global PID list ko privatise karta hai (built via Processes and the clone/fork syscall).
Ek naya PID namespace 1 se number karta hai, isliye pehla process is mein PID 1 hai. echo $$ 1 print karta hai. Yeh step kyun? Figure ka right table 1 se shuru hota hai; abhi simply koi aur entry nahi hai.
Host view unchanged hai: wahi process host namespace mein still PID 4021 hai (red arrow — ek process, do numbers). Yeh step kyun? Namespaces views relabel karte hain; woh process ko host ki accounting se delete nahi karte.

Verify karo: do truths saath exist karte hain — andar PID $= 1$ , bahar PID $= 4021$ . Koi contradiction nahi kyunki ek process ka ek ID per namespace hota hai jisme woh belong karta hai. ✓

Worked example Ex 7 — Case G: root inside ≠ root outside

Ek rootless container container UIDs $0 \dots 65535$ ko host UIDs par map karta hai jo $100000$ se shuru hote hain. Andar, whoami root (UID 0) kehta hai. Host UID actually kya hai, aur kya woh host par /etc/passwd delete kar sakta hai?

Forecast: agar inside-0, outside-100000 par map hota hai, toh outside-100000 ke paas actually kya powers hain?

Prerequisite check karo: host ke paas launching user ko subordinate UIDs allocated hone chahiye, jaise /etc/subuid mein ek line alice:100000:65536. Tabhi user namespace $0 \dots 65535$ ko host $100000 \dots 165535$ par map kar sakta hai. Yeh step kyun? Kernel ek aise range mein mapping refuse karta hai jo user ko kabhi delegated nahi hua; /etc/subuid grant ke bina unshare --user --map-root simply fail ho jaata hai, isliye poora example iska presuppose karta hai.
Mapping apply karo: container UID $0 \mapsto$ host UID $0 + 100000 = 100000$ . Yeh step kyun? Ek user namespace ek shift table hai: $host_uid = map_base + container_uid$ delegated range ke andar.
Host UID $100000$ ek ordinary, unprivileged account hai — /etc ka kuch bhi uska nahi hai. Yeh step kyun? Sirf host UID $0$ real root hai; $100000 \neq = 0$ , isliye koi host-root powers nahi.
Isliye container-root host ka /etc/passwd delete nahi kar sakta — write host UID 100000 ke against check hoti hai aur deny ho jaati hai.

Verify karo: $0 + 100000 = 100000 \neq = 0$ ; aur $100000 + 65535 = 165535 \leq$ delegated top, isliye mapping legal hai. # prompt aur whoami=root inside-namespace truths hain; file-permission check host UID use karta hai. Sab consistent hai. ✓

Container vs VM: cases H and I

Worked example Ex 8 — Case H (word problem): sahi box choose karo

Ek team ko ek host par ek small Linux web service ki 1000 copies run karni hain, har ek ko $\leq 128 MiB$ RAM chahiye, milliseconds mein start hona chahiye, sab ek hi company par trust karte hain. Container ya VM? RAM difference dikhao.

Forecast: 1000× par "own kernel" ka cost sabse zyada kahaan bite karta hai?

Har VM ko apna guest kernel + base OS boot karna padta hai, roughly $\geq 512 MiB$ sirf OS ke liye app se pehle. Total OS overhead $\approx 1000 \times 512 = 512000 MiB$ , jo hai $512000/1024 = 500 GiB$ (gibibytes — upar defined). Yeh step kyun? Ek VM ek full OS duplicate karta hai (dekho Virtualization and Hypervisors (Type 1 vs Type 2)); woh fixed tax count se multiply hota hai.
Har container ek host kernel share karta hai — uska OS overhead $\approx 0$ hai; sirf app ka $128 MiB$ count karta hai. Total app RAM $\approx 1000 \times 128 = 128000 MiB = 125 GiB$ , koi per-instance kernel tax nahi. Yeh step kyun? Ek kernel = container; kernel cost ek baar pay hoti hai, 1000 baar nahi.
Decide karo: same OS, same trust domain, ms startup, huge count → containers.

Verify karo: VM OS tax $= 1000 \times 512 = 512000 MiB$ ; container OS tax $= 0$ . Container plan poore $500 GiB$ duplicate kernels bachata hai — scale par decisive. ✓

Worked example Ex 9 — Case I (exam twist): cgroup lekin koi namespace nahi

Ek process ko ek cgroup mein rakha jaata hai jisme pids.max = 100 aur memory.max = 256M hai, lekin usse koi namespace nahi diya jaata. Us process se, kya tum (a) host ko fork-bomb kar sakte ho, (b) host PID 4021 dekh aur kill kar sakte ho?

Forecast: do features mein se kaunsa visibility control karta hai, aur kya humne use turn on kiya?

(a) Fork-bomb: pids.max = 100 group ko 100 tasks par cap karta hai → bomb 100 par ruk jaata hai, 101vaan fork refuse ho jaata hai. Yeh step kyun? cgroups quantity limit karte hain; pids controller group ke tasks count karta hai aur cap ke baad agla fork refuse karta hai (from Linux Kernel — syscalls).
(b) Visibility: koi PID namespace nahi hone se, yeh process host ki single global PID table share karta hai. Yeh step kyun? View ki isolation sirf namespaces se aati hai — aur humne koi add nahi kiya.
(b) Result: yeh host PID 4021 shared table mein dekh sakta hai, aur agar yeh host par sufficient privilege ke saath run karta hai (jaise host root ke roop mein, ya PID 4021 ke owner ke roop mein) toh yeh use kill kar sakta hai — cgroup ne kabhi process chupaaya nahi aur na signal block kiya. pids.max/memory.max limits constrain karte hain ki woh kitna consume kar sakta hai, kise dekh sakta hai ya signal kar sakta hai nahi. Yeh step kyun? Yeh twist ka poora point hai: caps aur isolation orthogonal hain. Ek resource limit kisi target ko view se remove nahi karta aur na hi ek kill syscall ko deny karta hai jo permission check otherwise allow karta.

Verify karo: cgroup caps satisfied ( $\leq 100$ pids, $\leq 256$ MiB) phir bhi host PID 4021 visible aur killable rehta hai — parent ka rule prove karta hai: cgroups = limits, namespaces = isolation; dono chahiye. ✓

Recall Poore matrix par self-test

cpu.max = "50000 200000" kitne cores deta hai? ::: $50000/200000 = 0.25$ cores memory.max = 134217728 kitne MiB hai? ::: $134217728/1048576 = 128$ MiB Naya PID namespace: pehle process ko kaunsa PID milta hai? ::: 1 User-ns container-0 ko base 100000 par map karta hai → host UID? ::: 100000 (unprivileged, root nahi) Us mapping ke allow hone ke liye /etc/subuid mein kya hona chahiye? ::: user ke liye ek delegated range, jaise alice:100000:65536 Cgroup alone, koi namespace nahi: kya woh host processes hide kar sakta hai? ::: Nahi — sirf namespaces view isolate karte hain memory.current RSS ke saath kya charge karta hai? ::: reclaimable page cache (isliye charged memory > RSS)

Parent topic par wapas jao · prerequisite: Processes and the clone/fork syscall · related: Scheduling — CFS and CPU shares, Networking — virtual interfaces and bridges, Filesystems — mount and chroot.

Scenario matrix

CPU share: cases A, B, C, D

Memory: case E

Namespaces: cases F and G

Container vs VM: cases H and I