Visual walkthrough — Containers — namespaces, cgroups, difference from VMs

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

Hum is order mein build karte hain:

1. shared kernel par ek process,
2. use ek private view dete hain (namespaces),
3. use ek private root filesystem dete hain,
4. jo kuch woh use kar sakta hai usse cap karte hain (cgroups) CPU-fraction formula ke saath,
5. degenerate cases cover karte hain (koi namespace nahi, root-inside),
6. poori cheez ko VM se contrast karte hain,
7. ise ek picture mein compress karte hain.

Step 1 — Shuru karo EK bare process se, EK kernel par

KYA HAI. Har Linux machine ke neeche kernel baith a hai: code ka woh ek piece jo real hardware (CPU, RAM, disk, network card) ka maalik hai. Baaki sab process hai — ek running program — aur har process kernel se cheezein syscalls ke through maangti hai (dekho Linux Kernel — syscalls).

YAHAN SE KYU SHURU KAREIN. Ek container koi nayi tarah ki object nahi hai. Yeh bilkul yahi process hogi kuch extra settings ke saath. Toh kuch bhi isolate karne se pehle, dekho ek plain process kya dekh sakti hai: woh har doosri process ke saath global tables share karti hai — PIDs ki ek list, ek hostname, ek network stack, ek filesystem mount table.

PICTURE. Figure mein blue box kernel hai; yellow circle hamaari process hai. Dashed lines dikhati hain ki woh kernel ki global tables mein pahunch rahi hai (daayein taraf bani hain). Abhi kuch bhi private nahi — hamaari process poori building dekh sakti hai. Haara poora kaam hai un dashed lines ko kaatna aur usse private copies dena.

Step 2 — EK dashed line kaato: pehla namespace

KYA HAI. Hum kernel se request karte hain: "Mere naye child ko process-ID table ki apni private copy do." Tool hai clone syscall, ek flag bit ke saath jiska naam hai CLONE_NEWPID.

YEH TOOL KYU AUR DOOSRA NAHI. Hum permissions se doosri processes chhupane ki koshish kar sakte the, lekin woh phir bhi usi numbering mein rehti — hamaari process host ka PID 1, PID 2, … dekh leti. Iska ek hi saaf tarika hai — fresh table: ek namespace. Namespace literally hai "ek global table ki doosri, alag copy." Woh ek line kaatna aur ek blank table dena exactly wahi hai jo CLONE_NEWPID karta hai.

PICTURE. Figure mein wahi process hai, lekin ab PID wali dashed line kati hui hai (red X) aur ek nayi, khaali PID table ki taraf redirect ho gayi hai. Us fresh table mein hamaari process renumber ho jaati hai — woh PID 1 ban jaati hai, kyunki ek brand-new list 1 se count karna shuru karti hai.

$\underset{\text{make a child}}{\underbrace{\text{clone}}}\left(\underset{\text{"give it a fresh PID table"}}{\underbrace{\text{CLONE\_NEWPID}}}\right|\underset{\text{other flags OR-ed in}}{\underbrace{\dots }})$

• clone — woh syscall jo nayi process banata hai.
• CLONE_NEWPID — ek flag bit; ise set karna matlab "child ko apna PID namespace milega."
• | (OR) — flags combine karne ka tarika; har bit ek table ko private banata hai, toh zyada bits OR karo → zyada tables private.

Step 3 — SAARI lines kaato: namespaces ka full set

KYA HAI. Step 2 ko har us global table ke liye repeat karo jo kernel expose karta hai. Har ek ka apna flag hai.

KYU. Upar wale rule se, isolation ek conjunction hai: tum tabhi "akele" ho jab har shared cheez private ho. Ek chhoot gayi toh ek hole hai — jaise private PIDs lekin shared network stack matlab tum abhi bhi host ke IP addresses dekh sakte ho.

PICTURE. Saat dashed lines, saat red cuts, saat private tables:

Is point par process apni choti duniya dekh sakti hai. Lekin woh abhi bhi poori machine use kar sakti hai — kuch bhi roke RAM khaane se. Yeh Step 5 ka kaam hai. Pehle, "woh kya dekh sakti hai" ka woh ek piece jo apni khud ki picture maangta hai: filesystem.

Step 4 — Private root: mount namespace + chroot

KYA HAI. Mount namespace ke andar hum process ke / ko ek aisi directory ki taraf point karte hain jisme poora ek chhota filesystem hai (ek layered image).

YEH ALAG STEP KYU. "Apna root filesystem" hi woh cheez hai jo ek container ko machine jaisi feel deti hai: uske paas Alpine ya Ubuntu ka /bin, /etc, /usr hota hai — chahe kernel abhi bhi host ka hi ho. Yahi woh trick hai jise log "poora OS" samajhne ki galti karte hain. Yeh OS nahi hai; yeh sirf woh files hain jo ek OS ke saath aati hain, us ek shared kernel par run karti hain.

PICTURE. Host ka real filesystem tree blue mein bana hai. Ek subtree — container ki image — green mein highlight hai. Ek green arrow us subtree ke top ko sirf container ke liye / relabel karta hai. Andar se, upar ka blue hissa simply view se gone hai: mount table mein uska koi entry nahi, toh usse naam nahi diya ja sakta.

Step 5 — Jo woh USE kar sakta hai usse cap karo: cgroups aur CPU-fraction formula

KYA HAI. Hum apni ab-isolated process ko ek cgroup (control group) mein daalte hain aur ek controller attach karte hain jo ek resource limit karta hai. CPU lo.

YEH NAYI MECHANISM KYU. Namespaces ne sirf visibility badli thi — unhone kabhi nahi chhhua ki ek process kitna consume kar sakti hai. Perfect namespaces wali process abhi bhi threads spin up karke har core hog kar sakti hai, apne neighbours ko bhookha maar sakti hai. Quantity limit karna alag kaam hai, isliye kernel alag tool use karta hai: cgroups, jo scheduler ke upar baithe hain (Scheduling — CFS and CPU shares).

PICTURE — CPU time ka leaky-bucket. cpu.max knob mein do numbers hote hain, dono microseconds mein:

$\text{cpu.max}=\underset{\text{µs of CPU you may spend}}{\underbrace{\text{quota}}}\underset{\text{length of each refill window}}{\underbrace{\text{period}}}$

Har period µs mein kernel tumhara bucket quota µs runtime se refill karta hai. Sab kharach karo aur tum frozen ho jaate ho agla refill aane tak. Time ke saath average lene par tum paate ho:

$\boxed{\text{CPU share}=\frac{\text{quota}}{\text{period}}\text{cores}}$

• quota — microseconds of CPU jo tumhe har window mein allow hai.
• period — har window kitni lambi hoti hai.
• ratio — ek core ka fraction jo tum average karte ho, kyunki diya gaya runtime ÷ beeta hua time = fraction busy.

Figure mein x-axis par time hai jo period-long windows mein bata hua hai. Har window ke andar width quota ki ek green bar tumhari allowed run-time hai; uske baad ek red "frozen" bar agali window tak. Dashed line long-run average hai — fraction $\text{quota}/\text{period}$.

Doosre controllers bhi usi tarah kaam karte hain — ek number jo tum likhte ho, ek limit jo kernel enforce karta hai:

Step 6 — Degenerate cases (taaki koi surprise na aaye)

Har real setup "namespaces hain?" aur "cgroups hain?" ka combination hai. Figure ek 2×2 grid hai — charon corners cover karo:

Case A — koi namespace nahi, koi cgroup nahi (plain process). Sab dikhta hai, kuch bhi use kar sakta hai. Container nahi hai. Yeh Step 1 hai.

Case B — sirf cgroup, koi namespace nahi. Yeh limited hai (RAM hog nahi kar sakta) lekin isolated nahi — woh abhi bhi host processes ko ls aur kill kar sakta hai kyunki uski PID/mount/net tables wahi shared hain.

Case C — sirf namespaces, koi cgroup nahi. Yeh isolated hai (apna view) lekin unlimited — woh poori machine ko fork-bomb kar sakta hai kyunki kuch cap nahi karta. Limits ke bina isolation matlab ek container jo apna host DoS kar sakta hai.

Case D — dono (ek real container). Private view aur capped usage. Yahi goal hai.

Root-inside edge case. PID/mount duniya ke andar, whoami root (UID 0) print kar sakta hai. Kya iska matlab host-root hai?

Step 7 — Container vs VM: kernels gino

KYA HAI. Apne tayyar container ko virtual machine ke saath rakho aur ek structural difference dekho.

KYU MATTER KARTA HAI. Weight, speed, aur security ke baare mein sab kuch ek single fact se aata hai: kitne kernels chal rahe hain.

PICTURE — side by side.

• VM (left). Ek hypervisor hardware emulate karta hai (dekho Virtualization and Hypervisors (Type 1 vs Type 2)); uske upar har VM ek pura guest kernel + OS boot karta hai. Do boxes → do kernels. Mazboot walls (hardware-enforced), lekin boot karne mein GBs aur seconds.
• Container (right). Hamaara process group ek host kernel share karta hai; isolation wahi namespaces+cgroups hai jo humne abhi build kiye. Ek kernel. MBs aur milliseconds, lekin ek kernel bug shared blast radius hai.

Ek-picture summary

Final figure poori derivation ko ek diagram mein stack karta hai: neeche single host kernel (Step 1); uske upar hamaari process saat namespace curtains mein wrapped (Steps 2–4) jisse usse private view milta hai; uske around ek cgroup meter (Step 5) jo CPU/RAM cap karta hai; aur side mein, contrast ke liye VM apne extra kernel ke saath (Step 7). Woh stack hi ek container hai.

Flashcards