OS-level virtualization: no hypervisor at all

المحاكاة الافتراضية على مستوى نظام التشغيل: بلا hypervisor إطلاقاً

Slide 25 calls containers OS-level virtualization. There is no hypervisor and no guest kernel. The line that matters is the system call interface, the entry point through which user-space code asks the kernel for anything.

تسمّي الشريحة 25 الحاويات OS-level virtualization. فلا يوجد hypervisor ولا نواة ضيفة (guest kernel). والخط المهم هو system call interface، أي نقطة الدخول التي يطلب منها كود user space أي شيء من النواة.

• Above the line (isolated): each container's own user space, its application and libraries.

  فوق الخط (معزول): user space الخاص بكل حاوية، أي تطبيقها ومكتباتها.

• Below the line (shared): one host kernel and the hardware, used by every container.

  تحت الخط (مشترك): نواة مضيفة واحدة والعتاد، تستخدمهما كل الحاويات.

Three consequences follow. Containers are light and fast (starting one is starting a process). They are tied to the host's OS family (a Linux host runs only Linux containers). And their security boundary is weaker than a VM's: one kernel bug can be a door between every container on the host.

ينتج عن ذلك ثلاث نتائج. الحاويات خفيفة وسريعة (تشغيل حاوية يعني تشغيل عملية). وهي مرتبطة بعائلة نظام المضيف (مضيف Linux لا يشغّل إلا حاويات Linux). وحدودها الأمنية أضعف من حدود VM: فثغرة واحدة في النواة قد تكون باباً بين كل الحاويات على المضيف.

In the cloud the two are combined, not rivals: containers usually run inside VMs. The VM separates tenants; the containers package apps inside each VM. The worker nodes of EKS, GKE and AKS are VMs.

وفي السحابة يجتمع الاثنان ولا يتنافسان: الحاويات تعمل عادةً داخل أجهزة افتراضية. فالـ VM يفصل بين العملاء، والحاويات تحزم التطبيقات داخل كل VM. وعُقد العمل (worker nodes) في EKS وGKE وAKS كلها VMs.

Two problems, two kernel features (slide 26)

مشكلتان، وميزتان في النواة (الشريحة 26)

The slide's example: one server runs a database and a web server as plain processes. Two different things go wrong, and Linux fixes each with a different feature.

مثال الشريحة: خادم واحد يشغّل قاعدة بيانات وخادم ويب كعمليتين عاديتين. ويحدث خطآن مختلفان، ويعالج Linux كلاً منهما بميزة مختلفة.

المشكلة الأولى: العمليات ليست محصورة في مساحتها، فهي ترى وتلمس PIDs وports وملفات بعضها، والحل مساحات منفصلة داخل النواة، والميزة هي namespaces، وهي تجيب عن سؤال: ماذا أستطيع أن أرى؟ والمشكلة الثانية: العمليات تتنافس على نفس المعالج والذاكرة وI/O، والحل حدود على استهلاك الموارد، والميزة هي cgroups، وهي تجيب عن سؤال: كم أستطيع أن أستخدم؟

Namespaces: what a process can SEE (slide 27)

Namespaces: ما الذي تستطيع العملية أن SEE (تراه) (الشريحة 27)

A namespace wraps a global kernel resource so that the processes inside it appear to have their own private instance. There is one kernel and many views. Run unshare --fork --pid --mount-proc bash and ps a inside shows only two processes, with your shell as PID 1, while the host still sees the same shell under a large global PID such as 24517.

الـ namespace يغلّف مورداً عاماً في النواة بحيث تبدو العمليات بداخله وكأن لها نسخة خاصة منه. فهناك نواة واحدة ورؤى كثيرة. شغّل unshare --fork --pid --mount-proc bash، وسيُظهر ps a بالداخل عمليتين فقط، والـ shell الخاص بك هو PID 1، بينما يرى المضيف نفس الـ shell برقم عام كبير مثل 24517.

الأنواع الثمانية: PID يعزل أرقام العمليات ويبدأ من 1. وNetwork يعزل الواجهات وIP stack وجداول التوجيه والمنافذ، فتستطيع حاويتان الاستماع على المنفذ 80 معاً. وMount يعزل نقاط التركيب فتكون لكل حاوية شجرة ملفات خاصة. وUTS يعزل اسم المضيف. وIPC يعزل كائنات الاتصال بين العمليات. وUser يعزل معرّفات المستخدمين، فيكون root بالداخل مستخدماً عادياً بالخارج. وCgroup يعزل جذر cgroup الذي تراه العملية. وTime يعزل إزاحات الساعة.

The slide's example: a web server process (server.js) runs in one namespace and MongoDB runs in another. The slide also says "an isolated workspace is referred to as a container", which oversimplifies: a single namespace is not a container. A real container combines several namespaces with cgroups and its own root filesystem.

مثال الشريحة: عملية خادم ويب (server.js) تعمل في namespace، وMongoDB في آخر. وتقول الشريحة أيضاً إن "مساحة العمل المعزولة تُسمّى حاوية"، وهذا تبسيط زائد: فـ namespace واحد ليس حاوية. الحاوية الحقيقية تجمع عدة namespaces مع cgroups ونظام ملفات جذري خاص بها.

Cgroups: what a process can USE (slide 28)

Cgroups: ما الذي تستطيع العملية أن USE (تستهلكه) (الشريحة 28)

Control groups organise processes into hierarchical groups whose use of CPU, memory, disk I/O and network can be limited and monitored. Each resource is enforced by a controller (cpu, memory, io, pids, cpuset). The slide gives four functions:

تنظّم control groups العمليات في مجموعات هرمية يمكن تقييد ومراقبة استهلاكها للمعالج والذاكرة وdisk I/O والشبكة. وكل مورد يفرضه controller خاص (cpu وmemory وio وpids وcpuset). وتذكر الشريحة أربع وظائف:

الوظائف الأربع: Limiting أي حد صارم على المعالج والذاكرة وعرض I/O (الملفات cpu.max وmemory.max وio.max). وPrioritization أي حصص نسبية عند التنافس (cpu.weight وio.weight). وAccounting أي قياس الاستهلاك وتسجيله (cpu.stat وmemory.current). وControl أي تجميد المجموعة كلها أو إذابتها (cgroup.freeze)، وهو أساس checkpoint/restart بأداة CRIU.

Cgroups do not checkpoint anything by themselves. The freezer only stops every task at once so that a user-space tool such as CRIU can write a consistent checkpoint to disk and restore it later, possibly on another node.

الـ cgroups لا تصنع checkpoint بنفسها. فالـ freezer يوقف كل المهام دفعة واحدة فقط، لكي تكتب أداة في user space مثل CRIU نسخة متسقة على القرص وتستعيدها لاحقاً، وربما على عقدة أخرى.

Worked: reading a quota and a weight

مثال محلول: قراءة الحصة (quota) والوزن (weight)

1) hard limit.  cpu.max = "50000 100000"
   quota  = 50,000 us of CPU time
   period = 100,000 us
   CPUs   = 50000 / 100000 = 0.5 CPU

   on a 4-core host: 0.5 / 4 = 12.5% of the machine.
   once the group burns 50 ms in a 100 ms period it
   waits for the next period, EVEN IF the host is idle.

   docker --cpus=1.5  ->  cpu.max = "150000 100000"
                          = 1.5 CPUs

2) weight (soft share).  three busy containers,
   cpu.weight 100, 100, 200 (sum = 400), no cpu.max:

   A = 100/400 = 25%
   B = 100/400 = 25%
   C = 200/400 = 50%

   if A and B go idle, C may take 100%.
   weights only matter under contention.

3) both at once.  1-CPU host, X has weight 300 and
   cpu.max "50000 100000"; Y has weight 100, no cap.

   by weight:  X = 300/400 = 0.75 CPU
   but X is capped at 0.5 CPU, so X gets 0.5
   Y takes the rest:          Y gets 0.5

4) memory.  memory.max = 512M (536870912 bytes).
   the app grows past 512 MiB, the kernel cannot
   reclaim enough  ->  OOM killer kills a process
   INSIDE that cgroup only. the neighbours survive.

This is how to read the slide's picture of four groups at 25% each: with equal weights, each gets a quarter only while all four are busy. A limit is a ceiling that holds even on an idle machine; a weight is a share that matters only under contention.

وهكذا تُقرأ صورة الشريحة لأربع مجموعات بنسبة 25% لكل منها: مع أوزان متساوية، تحصل كل مجموعة على الربع فقط ما دامت الأربع مشغولة. فالحد (limit) سقف يبقى حتى على جهاز خامل، والوزن (weight) حصة لا تهم إلا عند التنافس.

Everything on one card

كل شيء في بطاقة واحدة