ভার্চুয়ালাইজেশন, কনটেইনার ও ক্লাউড

লেসন

1. 01ভার্চুয়ালাইজেশন তত্ত্ব — Popek-Goldberg থিওরেম ও Trap-and-EmulatePopek ও Goldberg-এর ১৯৭৪ সালের থিওরেম বলে দেয় একটা VMM কবে trap-and-emulate দিয়ে বানানো সম্ভব — শর্ত একটাই, sensitive instruction-এর সেট privileged instruction-এর সেটের subset হতে হবে; x86-এর POPF-এর মতো instruction (sensitive, কিন্তু privileged না) এই শর্ত ভেঙে দেখায় কেন classic x86 কখনো বিশুদ্ধ trap-and-emulate দিয়ে virtualize করা যায়নি।কঠিন৫৫ মিনিটEXPERIMENTBUILD
2. 02Hypervisor-এর ধরন — Type-1 বনাম Type-2Hypervisor হলো তাত্ত্বিক VMM-এর বাস্তব সফটওয়্যার — Type-1 সরাসরি hardware-এর উপর privileged layer হিসেবে বসে (Xen, ESXi), Type-2 host OS-এর একটা সাধারণ application হিসেবে চলে (VirtualBox, Parallels), আর KVM-এর মতো ডিজাইন এই দুইয়ের সীমারেখাকে ইচ্ছাকৃতভাবে ঝাপসা করে দেয়।মাঝারি৪৫ মিনিটEXPERIMENTBUILD
3. 03Hardware Virtualization — VT-x, EPT আর CPU নিজেই কীভাবে Popek-Goldberg সমস্যা সমাধান করল`hypervisor-types` লেসনে দেখা x86-এর Popek-Goldberg ফাঁকটা (কিছু sensitive instruction privileged-ই না, তাই ধরাই যায় না) বন্ধ করতে Intel VT-x আর AMD-V CPU-তে একটা নতুন মাত্রা যোগ করে — VMX root/non-root mode — যেখানে প্রতিটা sensitive instruction hardware-নিয়ন্ত্রিতভাবে VM-exit ট্রিগার করতে পারে; এই লেসন সেই VM-exit/VM-entry-র পূর্ণ যন্ত্রপাতি, তার আসল খরচ, আর memory-virtualization-এর জন্য EPT/NPT কীভাবে shadow page table-এর ট্র্যাপ-ভারী সমাধানকে একটা hardware-walked দ্বিতীয় translation স্তর দিয়ে প্রতিস্থাপন করে — এবং তার নিজস্ব নতুন খরচ (গভীরতর TLB-miss walk) নিয়ে আসে — তা সংখ্যাসহ দেখায়।অ্যাডভান্সড৫৫ মিনিটEXPERIMENTBUILD
4. 04KVM ও QEMU — kernel-ই hypervisor, userspace-ই বাকি সব হার্ডওয়্যারKVM একটা kernel module যা শুধু CPU আর memory virtualization দেয় ioctl দিয়ে; QEMU একটা userspace প্রোগ্রাম যা সবসময় device emulation করে আর CPU execution-এর জন্য হয় নিজস্ব software translator নাহয় KVM ব্যবহার করে — দুইটা মিলে গঠন করে আজকের Linux hypervisor stack, আর `ioctl(KVM_RUN)`-ই তাদের মাঝের একমাত্র সেতু।কঠিন৫০ মিনিটEXPERIMENTBUILD
5. 05Paravirtualization ও virtio — গেস্ট যখন নিজেই জানে সে ভার্চুয়ালParavirtualization মানে guest OS-কে সত্য বলে দেওয়া যে সে ভার্চুয়াল, আর তাকে hypercall দিয়ে সরাসরি hypervisor-এর সাথে সহযোগিতা করতে শেখানো — ঐতিহাসিকভাবে Xen-এর পুরো CPU-এমুলেশনে, আজ প্রধানত virtio-র ring-buffer I/O-তে, যেখানে batching VM-exit সংখ্যা ৯৯%-এর বেশি কমিয়ে দেয়।কঠিন৫০ মিনিটEXPERIMENTBUILD
6. 06Container বনাম VM — দুইটা সম্পূর্ণ ভিন্ন Isolation Boundaryএই module এতদিন যা শিখিয়েছে তার সবটাই এক ধরনের isolation-এর গল্প — একটা guest পুরো hardware-এর বিভ্রম পায়, নিজস্ব সম্পূর্ণ kernel নিয়ে। আজ সেই গল্পের বিপরীত মেরুতে দাঁড়িয়ে দেখব দ্বিতীয় ধরনের isolation — container, যেখানে কোনো দ্বিতীয় kernel নেই, শুধু একই host kernel-এর ওপর namespace আর cgroup দিয়ে বেড়া দেওয়া প্রসেস। দুইটার মধ্যেকার পার্থক্যটাই ঠিক করে দেয় স্টার্টআপ গতি, density, আর সবচেয়ে গুরুত্বপূর্ণভাবে — আক্রমণকারী ঠিক কী ভাঙলে বাইরে বেরিয়ে আসতে পারবে।কঠিন৫০ মিনিটEXPERIMENTBUILD
7. 07Linux Namespaces গভীরে — সাতটি isolation primitive-এর ভেতরের যন্ত্রoperating-systems/namespaces-and-cgroups লেসন namespace-এর একটা survey-level পরিচয় দিয়েছিল — এই লেসন সেই ভূমি থেকে অনেক গভীরে যায়: প্রতিটা CLONE_NEW* flag-এর exact hex constant, PID-1-এর সিগন্যাল-হ্যান্ডলিং quirk, chroot বনাম pivot_root-এর নির্ভুল পার্থক্য, আর user namespace-এর UID/GID mapping-এর গাণিতিক যন্ত্র, একটা সত্যিকার চলমান Python simulation দিয়ে।অ্যাডভান্সড১ ঘণ্টাEXPERIMENTBUILD
8. 08cgroups v2 — কে কতটুকু ব্যবহার করতে পারবে, তার নির্ভুল নিয়ন্ত্রণnamespaces-deep-dive লেসন দেখিয়েছিল namespace শুধু 'দৃশ্যমানতা' নিয়ন্ত্রণ করে, 'ব্যবহার' না — এই লেসন সেই বাকি অর্ধেক সম্পূর্ণ করে। cgroups v2-এর unified hierarchy, cpu.max/cpu.weight, memory.max/memory.high, io.max — প্রতিটার নির্ভুল mechanics, আর একটা সত্যিকার চালানো Python simulation দিয়ে cpu.max-এর quota/period থ্রটলিং হাতে-কলমে verify করা।কঠিন৫০ মিনিটEXPERIMENTBUILD
9. 09Overlay Filesystem ও Image Layer — একই বেস, হাজার container, একটাই কপিএকই মেশিনে একশোটা container, প্রতিটাই একটা Ubuntu base image থেকে বানানো — যদি প্রতিটার filesystem-এর নিজস্ব, সম্পূর্ণ কপি লাগত, ডিস্ক আর pull-time দুটোই দ্রুত অসহনীয় হয়ে উঠত। এই লেসন সেই সমস্যার সমাধান — OverlayFS-এর lowerdir/upperdir/merged/workdir মেকানিজম, copy-on-write-এর নির্ভুল সেমান্টিক্স, আর কীভাবে Docker image layer এই একই যন্ত্রের ওপর দাঁড়িয়ে content-addressing দিয়ে ডিস্ক আর ব্যান্ডউইথ দুটোই বাঁচায় — এই তিনটাকে একটা একক, ধারাবাহিক ব্যাখ্যায় জোড়া দেয়।কঠিন৫৫ মিনিটEXPERIMENTBUILD
10. 10Container Runtime ও OCI — docker run থেকে kernel syscall পর্যন্ত সম্পূর্ণ পথএই module-এর আগের লেসনগুলো namespace, cgroup, আর overlay filesystem-এর ভেতরের kernel mechanics আলাদা আলাদাভাবে দেখিয়েছে — এই লেসন সেগুলোকে একসাথে জোড়া দিয়ে module-এর কেন্দ্রীয় প্রশ্নের উত্তর দেয়: docker run লিখলে ঠিক কোন সফটওয়্যার-স্তর, কোন ক্রমে, কোন syscall চালায়। OCI-এর Image আর Runtime spec-এর বিভাজন, runc-এর one-shot প্রকৃতি, আর containerd/containerd-shim-এর persistent daemon architecture — এই তিনটা মিলেই সেই সম্পূর্ণ উত্তর, একটা হাতে-চালানো Python simulation দিয়ে verify করা।অ্যাডভান্সড৫৫ মিনিটEXPERIMENTBUILD
11. 11Container Networking — veth, bridge, ও NAT দিয়ে একটা isolated namespace-কে জগতের সাথে জোড়া লাগানোlinux-namespaces-deep-dive লেসন একটা network namespace-কে সম্পূর্ণ বিচ্ছিন্ন রেখে থামিয়েছিল — শুধু একটা নিষ্ক্রিয় loopback। এই লেসন সেই বিচ্ছিন্নতা ভাঙে: veth pair দিয়ে namespace-কে host-এর সাথে, Linux bridge দিয়ে একাধিক container-কে একে অপরের সাথে, আর iptables MASQUERADE দিয়ে পুরো ব্যবস্থাকে internet-এর সাথে জোড়া লাগানো — শেষে CNI, যে standard interface দিয়ে এই পুরো কাজটাই একটা pluggable বহিরাগত প্রোগ্রামের হাতে তুলে দেওয়া হয়।অ্যাডভান্সড৫৫ মিনিটEXPERIMENTBUILD
12. 12Kubernetes Architecture — Control Plane আর Worker Node-এর স্থাপত্যশত শত container, বহু মেশিন জুড়ে — কে ঠিক করবে কোনটা কোথায় চলবে, কে ব্যর্থতা সামলাবে, কে ট্রাফিক রুট করবে? Kubernetes এই প্রশ্নের উত্তর — Google-এর Borg-এর সরাসরি উত্তরসূরি একটা orchestrator, যার control plane (API server, etcd, scheduler, controller-manager) আর worker node (kubelet, kube-proxy, container runtime) স্পষ্টভাবে আলাদা। etcd নিজের consistency পায় Raft থেকে — ঠিক সেই protocol যা আগের লেসনে হাতে বানানো হয়েছিল — আর controller-manager-এর reconciliation loop-ই Kubernetes-এর কেন্দ্রীয় ডিজাইন-দর্শন।অ্যাডভান্সড৫৫ মিনিটEXPERIMENTBUILD
13. 13Pod, Controller, Service, ও Ingress — Kubernetes-এ একটা App বাঁচিয়ে রাখার চারটা স্তরkubernetes-architecture লেসন কন্ট্রোল প্লেনের reconciliation loop-টা দেখিয়েছিল বিমূর্তভাবে — আজ সেই loop-টাকে চারটা নির্দিষ্ট, প্রতিদিন ব্যবহৃত object-এর ওপর বসিয়ে দেখব। Pod কেন scheduling-এর atomic unit, কেন একটা মৃত Pod কখনো 'সারানো' হয় না বরং নতুন একটা দিয়ে বদলানো হয়, আর সেই disposability যে সমস্যা তৈরি করে — কার IP-তে কল করব যদি IP-ই টেকে না — তার সমাধান হিসেবে Service আর Ingress। প্রতিটা স্তর আগেরটার তৈরি করা একটা নির্দিষ্ট গর্ত ভরাট করে।কঠিন৫৫ মিনিটEXPERIMENTBUILD
14. 14Service Discovery — Kubernetes-এ DNS কীভাবে নাম থেকে Pod-এ পৌঁছায়একটা Pod থেকে অন্য একটা Service-এ পৌঁছানোর প্রথম ধাপ কোনো routing rule না — একটা DNS query। CoreDNS, নিজেই ক্লাস্টারের ভেতরে চলা কিছু সাধারণ Pod, API server watch করে লাইভ রেকর্ড বানায়; সেই রেকর্ড থেকে পাওয়া ClusterIP-টাই তারপর kube-proxy-র হাতে তুলে দেওয়া হয় আসল প্যাকেট রাউট করার জন্য।মাঝারি৪০ মিনিটEXPERIMENTBUILD
15. 15Load Balancing — L4 বনাম L7 আর অ্যালগরিদমের গণিতservice-discovery lesson backend-দের কোথায় আছে খুঁজে বের করেছিল; আজ প্রশ্নটা তার পরের ধাপ — সেই backend-দের মধ্যে একটা নির্দিষ্ট request ঠিক কোনটার কাছে যাবে। L4 বনাম L7-এর precise পার্থক্য, চারটা classic অ্যালগরিদম, consistent hashing-এর ring-গণিত, আর health check যা এই পুরো সিদ্ধান্তকে production-এ নিরাপদ রাখে — সবকিছুর পেছনে নিজে-চালানো সংখ্যা।কঠিন৫০ মিনিটEXPERIMENTBUILD
16. 16Reverse Proxy — nginx, Envoy, আর Service Mesh-এর জন্মReverse proxy হলো সেই সফটওয়্যার যা clients-এর চোখে 'একটা সার্ভার' হয়ে দাঁড়ায় অথচ পেছনে backend-এর একটা পুরো fleet লুকিয়ে রাখে — nginx এই কাজটা config-file আর reload দিয়ে করে, Envoy করে streaming xDS API দিয়ে যাতে reload ছাড়াই backend পরিবর্তন সাথে সাথে প্রতিফলিত হয়। সেই একই idea যখন cluster-এর প্রতিটা service instance-এর পাশে একটা করে ছোট sidecar Envoy বসিয়ে সবার জন্য এক করে দেওয়া হয়, তখন জন্ম হয় service mesh-এর।কঠিন৫০ মিনিটEXPERIMENTBUILD
17. 17Object Storage-এর অন্দরমহল — Flat Namespace, Consistency, আর Erasure CodingObject storage-এ 'folder' একটা illusion — bucket-এর ভেতরে সবকিছু আসলে flat key, listing মানে prefix query; S3 বহু বছর eventually consistent ছিল, ২০২০-এ strong হলো; আর durability আসে replication বা তার চেয়ে সস্তা এক পথে — erasure coding দিয়ে, যেখানে k-টা data chunk + m-টা parity chunk-এর যেকোনো k-টা বেঁচে থাকলেই পুরো object ফিরে আসে।কঠিন৫০ মিনিটEXPERIMENTBUILD
18. 18Cloud Networking — VPC, Subnet ও Security Group দিয়ে shared physical network-এর ভেতরে নিজের একচ্ছত্র জগৎ বানানোcontainer-networking লেসন একটা single host-এর ভেতরে veth/bridge/NAT দিয়ে network ভার্চুয়ালাইজ করেছিল। এই লেসন ঠিক একই ভাবনাটা cloud-scale-এ নিয়ে যায় — VPC দিয়ে shared physical network-এর ভেতরে নিজের একচ্ছত্র CIDR block দাবি করা, subnet ও route table দিয়ে সেই block-কে public/private ভাগে সাজানো, আর security group/NACL দিয়ে প্রতিটা স্তরে traffic filter করা।কঠিন৫০ মিনিটEXPERIMENTBUILD
19. 19Infrastructure as Code ও Terraform — Provisioning-এ Reconciliation Loopcloud-networking-vpc লেসন হাতে-কলমে VPC/subnet/security-group বানিয়েছে — কনসোলে ক্লিক করে, বা এক-এক করে CLI কমান্ড চালিয়ে। আজ প্রশ্ন: এই একই resource-গুলো যদি ডজন-ডজন environment জুড়ে, বারবার, নির্ভুলভাবে বানাতে হয়? Terraform আর তার HCL ভাষা উত্তর — একটা declarative বর্ণনা লিখুন, tool নিজে বের করুক কী করতে হবে। এই লেসনের কেন্দ্রীয় দাবি: terraform plan/apply cycle ঠিক সেই একই declarative-reconciliation প্যাটার্ন যা kubernetes-architecture লেসনে controller-manager-এ দেখা গেছে — শুধু domain বদলেছে, container scheduling থেকে cloud provisioning-এ।কঠিন৫০ মিনিটEXPERIMENTBUILD
20. 20Observability — Metrics, Logs, আর Trace কীভাবে একসাথে কাজ করেMetrics সংখ্যা বলে, logs ঘটনা বলে, trace ইতিমধ্যে distributed-tracing লেসনে path বলে দিয়েছে — আজ দেখব এই তিন pillar কীভাবে একটা containerized platform-এ sidecar/collector দিয়ে জড়ো হয়ে, shared trace_id দিয়ে জোড়া লেগে, একটা সম্পূর্ণ observability picture বানায়; আর কেন Kubernetes-এর disposable Pod-এর নাম metric label হিসেবে ব্যবহার করলে backend চুপচাপ ভেঙে পড়তে পারে — বাস্তব হিসাব-সহ।কঠিন৫০ মিনিটEXPERIMENTBUILD
21. 21Serverless-এর ভেতরের কাজ — FaaS, Cold Start, আর Firecracker microVMএই module-এর প্রথম অর্ধেক (hardware-virtualization পর্যন্ত) দেখিয়েছে কীভাবে VT-x/EPT একটা guest-কে সম্পূর্ণ, শক্তভাবে বিচ্ছিন্ন একটা কম্পিউটারের বিভ্রম দেয়, দ্বিতীয় অর্ধেক (container-runtime-oci পর্যন্ত) দেখিয়েছে কীভাবে namespace/cgroup আর OCI runtime সেই একই বিচ্ছিন্নতা অনেক সস্তায়, অনেক দ্রুত, একটাই kernel শেয়ার করে দেয়। এই লেসন এই দুইটা arc-কে একটা বাস্তব সিস্টেমে মুখোমুখি দাঁড় করায় — serverless/FaaS platform-কে প্রতিটা customer-এর untrusted function-এর জন্য, প্রতিটা invocation-এ, সাব-সেকেন্ড লেটেন্সিতে, একটা নতুন, নিরাপদভাবে বিচ্ছিন্ন execution environment বানাতে হয়। container যথেষ্ট নিরাপদ না (আগের multi-tenant আলোচনার সরাসরি প্রয়োগ), full VM যথেষ্ট দ্রুত না — আর AWS-এর Firecracker ঠিক এই দুইয়ের সংযোগস্থলে দাঁড়িয়ে থাকা, module-এর দুইটা arc-এরই সরাসরি ফসল একটা বাস্তব সমাধান।অ্যাডভান্সড৫৫ মিনিটEXPERIMENTBUILD
22. 22Edge Computing ও Cloudflare Workers — Isolation Spectrum-এর শেষ বিন্দুএই module-এর একদম শেষ লেসন — VM থেকে শুরু করে microVM পর্যন্ত isolation-কে দ্রুততর করার যে যাত্রা এতদিন দেখা হলো, আজ সেই যাত্রার সবচেয়ে চরম বিন্দুতে দাঁড়াবো। Cloudflare Workers-এর V8 isolate মডেল প্রমাণ করে — সিঙ্গেল-ডিজিট মিলিসেকেন্ড cold start পেতে হলে আর নতুন কিছু বুট করাই বন্ধ করতে হয়; বরং একটা ইতিমধ্যে-চলমান engine-এর ভেতরে নতুন heap allocate করাই যথেষ্ট। বিনিময়ে isolation নির্ভর করে hardware বা kernel বাউন্ডারির বদলে ভাষা-runtime নিজের memory-safety-র ওপর — module-জোড়া isolation-spectrum-এর একদম শেষ, দ্রুততম, কিন্তু সবচেয়ে দুর্বল-boundary বিন্দু।কঠিন৫০ মিনিটEXPERIMENTBUILD

যা যা থাকছে

• Virtualization তত্ত্ব — Popek-Goldberg
• Hypervisor type 1 vs type 2
• Hardware virtualization — VT-x, EPT
• KVM ও QEMU
• Paravirtualization
• Containers vs VMs — প্রকৃত পার্থক্য
• Linux namespaces (pid, net, mnt, uts, ipc, user, cgroup)
• cgroups v2 — CPU, memory, IO limits
• Overlay filesystems ও image layers
• Container runtime — runc, containerd, OCI spec
• Container networking — veth, bridge, CNI
• Kubernetes architecture — API server, etcd, scheduler, kubelet
• Pods, controllers, services, ingress
• Service discovery ও DNS in k8s
• Load balancing — L4 vs L7
• Reverse proxy — nginx, envoy
• Object storage-এর internals (S3 model)
• Cloud networking — VPC, subnet, security group
• Infrastructure as Code — Terraform model
• Observability — metrics, logs, traces
• Serverless-এর নিচে কী
• Edge computing ও Cloudflare Workers model

প্রজেক্ট