Containers — namespaces, cgroups, difference from VMs: Question bank

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

Do words is poore page ko carry karte hain, toh inhe pehle pin karo:

namespaces = koi process kya DEKH sakta hai (isolation of view).
cgroups = koi process kya USE kar sakta hai (limits on resources).

Agar koi trap confuse kare, toh poochho: kya yeh dekhne ke baare mein hai (namespaces) ya use karne ke baare mein (cgroups) — ya phir kitne kernels exist karte hain (container vs VM)?

True or false — justify

A container runs its own operating-system kernel.

False. Ek container ek host process hai; yeh clone flags ke zariye host kernel share karta hai. Sirf ek VM hi apna guest kernel boot karta hai.

uname -r container ke andar host se alag kernel version dikhata hai.

False. Ek hi kernel hota hai, toh version string identical hogi. Ek alag result prove karega ki tum VM mein ho, container mein nahi.

Bina kisi VM ke Linux host pe Windows container run kar sakte ho.

False. Windows binaries Windows syscalls maangti hain jo Linux kernel implement nahi karta; "Docker for Windows" secretly ek lightweight Linux VM chalata hai jo Linux containers host kare.

cgroups containers ke beech isolation provide karte hain.

False. cgroups quantity (RAM, CPU) cap karte hain, visibility nahi. Namespaces ke bina ek process phir bhi host processes dekh aur unhe kill kar sakti hai — isolation namespaces se aata hai.

Do containers jinka memory.max = 512M hai, unhe 512 MB guarantee hai.

False. memory.max ek ceiling hai, reservation nahi. Yeh ek group ko 512 MB se zyada jaane se rokta hai lekin kuch promise nahi karta agar host ke paas RAM kam ho.

Mount namespace ke mounts delete karne se host ka mount table affect hota hai.

False. Ek mount namespace mount table ki ek private copy deta hai; andar ke changes andar hi rehte hain jab tak mount explicitly shared na ho.

Ek container inherently ek VM se zyada secure hota hai.

False. Ek kernel share karne ka matlab hai ek kernel bug ka shared blast radius; ek VM ka hardware-enforced boundary generally zyada strong hota hai, bas heavier bhi.

Sirf Namespaces se ek usable container banana possible hai.

False. Namespaces neighbours ko hide karte hain lekin fork-bomb ya memory hog ko nahi rokते; tumhe cgroups bhi chahiye usage cap karne ke liye. Tumhe dono chahiye.

chroot mount namespace jaisi isolation deta hai.

False. chroot sirf apparent root directory change karta hai aur se escape ho sakta hai; ek mount namespace poore mount table ko isolate karta hai aur ek real kernel boundary hai.

Spot the error

"Ek container ek OS boot karta hai, bas ek stripped-down wala."

Error hai "boots an OS." Ek container pehle se chal rahe host kernel pe ek process start karta hai — koi boot nahi, doosre kernel ka koi init nahi. Jo "OS" tum dekhte ho woh sirf files hain (ek image) aur namespaces.

"Container ke andar Root hamesha host pe root hota hai."

Ek user namespace ke saath, container UID 0 ek unprivileged host UID (jaise 100000) pe mapped hota hai. Rootless containers isi pe rely karte hain taaki container-root protected host files ko touch na kar sake.

"Namespaces ek special container daemon dwara create kiye jaate hain."

Yeh kernel syscalls dwara create hote hain — CLONE_NEW* ke saath clone, unshare, setns. Docker jaisa ek daemon sirf unhe call karta hai; yeh apni koi isolation invent nahi karta.

"docker exec aapka command run karne ke liye ek naya container start karta hai."

Yeh setns(fd, type) ke saath existing container ke namespaces mein join karta hai, phir wahan aapka command run karta hai. Koi naya container nahi, koi naye namespaces nahi — yeh pehle se open wale mein step karta hai.

"cgroup v2 mein har controller apni alag hierarchy mein reh sakta hai."

Yeh cgroup v1 ko describe karta hai. cgroup v2 ek unified hierarchy hai: ek tree, controllers per-node enabled hote hain. V1 ka multi-hierarchy design wahi cheez thi jise v2 ne replace kiya.

"Container ka IP address host ka IP address hai."

Apne network namespace ke saath ek container ka ek alag network stack hota hai — uske apne interfaces, IPs, aur ports — jo aam taur par ek virtual pair aur bridge ke zariye host se jude hote hain, host IP share karke nahi.

"cpu.max ko bada number dene se container ko doosron ke upar priority milti hai."

cpu.max ek upper limit set karta hai (quota/period), priority nahi. Relative priority CPU shares/weight se aati hai CFS scheduler ke under — yeh ek alag knob hai.

Why questions

Ek container milliseconds mein kyun start ho sakta hai jabki VM seconds leta hai?

Ek container sirf ek process fork karta hai aur uske namespaces/cgroups swap karta hai; ek VM ko hardware emulate karna hota hai aur pehle poora guest kernel + OS boot karna hota hai.

Naye PID namespace mein pehla process PID 1 kyun ban jaata hai?

Ek fresh PID namespace apni numbering 1 se shuru karta hai, toh host ke hundreds of PIDs is private table mein invisible hain — iske andar enter karne wala pehla process number 1 le leta hai.

Hum ek master "isolate" flag ki jagah kai CLONE_NEW* flags ko OR kyun karte hain?

Har flag exactly ek global table (PIDs, mounts, net…) ko privatise karta hai. OR karne se tum choose kar sakte ho kaunse resources isolate karne hain — jaise network share karo lekin filesystem nahi — jo fine-grained control deta hai.

Shared kernel ko "shared blast radius" kyun kaha jaata hai?

Sare containers usi kernel code pe execute karte hain, toh ek kernel vulnerability ya panic har container ko compromise ya crash kar sakta hai ek saath — VMs ke unlike, jinka har ek independent kernel hota hai.

Kisi PID ko cgroup.procs mein likhne se limits immediately enforce kyun hone lagti hain?

Woh write process ko group mein move karta hai; tab se wahi host kernel uski usage controllers ke against account karta hai aur caps enforce karta hai (jaise memory.max ke baad OOM-kill).

Rootless containers kyun exist karte hain agar container-mein-root pehle se isolated lagta hai?

Kyunki user namespace ke bina, ek container escape real host root ki tarah act kar sakta hai. Container-root ko ek unprivileged host UID pe map karna escape se hone wale damage ko kam karta hai.

Edge cases

Ek process ek cgroup mein hai lekin host ke saath sare namespaces share karta hai — kya yeh container hai?

Nahi. Yeh ek resource cap wala normal process hai: yeh phir bhi host processes ko dekh aur kill kar sakta hai. Container ko isolation ke liye namespaces chahiye, sirf cgroup nahi.

Ek process ko har CLONE_NEW* namespace milta hai lekin koi cgroup limits nahi — kya yeh isolated hai?

View-isolated, haan; usage-limited, nahi. Yeh kuch bhi shared nahi dekhta, lekin kuch bhi isse saara RAM/CPU consume karne ya host ko fork-bomb karne se nahi rokta.

memory.max process ki current usage se neeche set ki gayi — kya hoga?

Kernel pages reclaim karne ki koshish karta hai; agar woh new limit ke neeche nahi aa sakta, toh woh group mein ek process ko OOM-kill karta hai. Limit continuously enforce hoti hai, sirf fork time pe nahi.

cpu.max mid-period mein apna poora quota use kar leta hai — process kya karta hai?

Yeh frozen (throttled) ho jaata hai jab tak next period quota refill nahi kar deta, phir resume hota hai. Samay ke saath yeh exactly quota/period of one core average karta hai.

pids.max = 100 hai aur fork-bomb hit karta hai — kya rukta hai?

Group mein naye fork/clone calls fail ho jaate hain jab 100 tasks exist ho jaate hain, bomb ko group ke andar rok deta hai bina host ke doosre processes ko touch kiye.

Ek container jisme koi network namespace nahi — uska network view kaisa hai?

Yeh seedha host ka network stack share karta hai: same interfaces, IPs, aur ports. Networking ki isolation tabhi aati hai jab ek net namespace create ki jaaye.

Recall Ek rule jo zyaatar traps resolve karta hai

"See vs Use, Curtains vs Chores; one kernel = container, many kernels = VM." Namespaces ::: curtains — control karta hai ki tum kya DEKHTE ho. cgroups ::: chores — cap karta hai ki tum kya USE karte ho. Container ::: existing ghar mein ek parda-lagaa kamra (ek kernel). VM ::: paas mein bilkul naya ghar (apna kernel).