حول Pods
Pods هي أصغر وحدة API في Kubernetes. بشكل أكثر تقنية، Pods هي وحدة الجدولة الذرية في Kubernetes. لكن لماذا نحتاج إلى Pods؟ للإجابة على هذا السؤال، نحتاج أولاً إلى فهم جوهر الحاوية: الحاوية هي في الأساس عملية. هذا صحيح. الحاويات هي عمليات في نظام الحوسبة السحابية، وصور الحاويات هي في الأساس حزم تثبيت “.exe” لهذا النظام. Kubernetes، في هذا التشبيه، تعمل كنظام تشغيل.
العمليات ومجموعات العمليات
دعنا نسجل الدخول إلى جهاز Linux وننفذ الأمر التالي:
$ pstree -g
يعرض هذا الأمر الهيكل الشجري للعمليات الجارية حالياً في النظام. قد يبدو الإخراج كالتالي:
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
كما ترى، في نظام تشغيل حقيقي، لا تعمل العمليات بمعزل عن بعضها. بدلاً من ذلك، يتم تنظيمها في مجموعات عمليات. على سبيل المثال، البرنامج “rsyslogd” مسؤول عن معالجة السجلات في Linux. البرنامج الرئيسي لـ rsyslogd، “main”، ووحدة سجل النواة “imklog” التي يستخدمها ينتميان إلى مجموعة العمليات 1632. تتعاون هذه العمليات لتحقيق مسؤوليات برنامج rsyslogd.
يقوم Kubernetes بشكل أساسي بتعيين مفهوم “مجموعات العمليات” هذا على تقنية الحاوية ويجعله “مواطناً من الدرجة الأولى” في “نظام التشغيل” السحابي هذا. يتبنى Kubernetes هذا النهج لأن مهندسي Google أدركوا أن التطبيقات التي ينشرونها غالباً ما تظهر علاقات مشابهة لـ “العمليات ومجموعات العمليات”. على وجه التحديد، تتطلب هذه التطبيقات تعاوناً وثيقاً، مما يستلزم نشرها على نفس الجهاز. ستكون إدارة مثل هذه العلاقات التشغيلية دون مفهوم “المجموعات” صعبة للغاية. خذ rsyslogd كمثال. يتكون من ثلاث عمليات: وحدة imklog، ووحدة imuxsock، وعملية الوظيفة الرئيسية لـ rsyslogd نفسها. يجب أن تعمل هذه العمليات الثلاث على نفس الجهاز؛ وإلا، فإن اتصالها القائم على المقابس (sockets) وتبادل الملفات سيواجه مشاكل.
التواصل بين الحاويات
كما هو موضح في الرسم البياني أعلاه، تحتوي هذه Pod على حاويتين للمستخدم، A و B، وحاوية Infra. في Kubernetes، تم تصميم حاوية Infra لاستهلاك الحد الأدنى من الموارد وتستخدم صورة خاصة تسمى “k8s.gcr.io/pause”. تمثل هذه الصورة حاوية، مكتوبة بلغة التجميع، تبقى بشكل دائم في حالة “معلقة” (paused)، بحجم غير مضغوط يبلغ 100-200 كيلوبايت فقط.
بمجرد أن “تمتلك” حاوية Infra مساحة أسماء الشبكة (Network Namespace)، يمكن لحاويات المستخدم الانضمام إلى هذه المساحة. لذلك، إذا قمت بفحص ملفات Namespace لهذه الحاويات على الجهاز المضيف (المسار إلى هذا الملف مذكور سابقاً)، فستشير إلى نفس القيمة تماماً. وهذا يعني أنه بالنسبة للحاويات A و B داخل Pod، يمكنها التواصل مباشرة باستخدام “localhost”. إنها ترى نفس أجهزة الشبكة مثل حاوية Infra. تحتوي Pod على عنوان IP واحد فقط، وهو عنوان IP المرتبط بمساحة أسماء الشبكة الخاصة بـ Pod. بطبيعة الحال، يتم تخصيص جميع موارد الشبكة الأخرى لكل Pod وتتم مشاركتها من قبل جميع الحاويات داخل تلك Pod. دورة حياة Pod مرتبطة فقط بحاوية Infra ومستقلة عن الحاويات A و B.
علاوة على ذلك، بالنسبة لجميع حاويات المستخدم داخل نفس Pod، يمكن اعتبار حركة الدخول والخروج الخاصة بها على أنها تمر عبر حاوية Infra. هذا الجانب مهم لأنه إذا كنت ستطور إضافة شبكة (network plugin) لـ Kubernetes في المستقبل، يجب أن يكون تركيزك الأساسي على تكوين مساحة أسماء الشبكة الخاصة بـ Pod، وليس كيفية استخدام كل حاوية مستخدم لتكوين شبكتك. هذا الأخير غير مهم. هذا يعني أنه إذا كانت إضافة الشبكة الخاصة بك تعتمد على تثبيت حزم أو تكوينات داخل الحاوية، فهي ليست حلاً قابلاً للتطبيق. نظام الملفات الجذر لصورة حاوية Infra فارغ تقريباً، مما لا يترك لك مجالاً للتخصيص. على العكس من ذلك، هذا يعني أيضاً أن إضافة الشبكة الخاصة بك لا تحتاج إلى الاهتمام بحالة بدء تشغيل حاويات المستخدم بل تحتاج فقط إلى التركيز على تكوين Pod، أي مساحة أسماء الشبكة لحاوية Infra.
مع هذا التصميم، يصبح مشاركة الأحجام (volumes) أسهل بكثير. يمكن لـ Kubernetes تعريف جميع تكوينات الحجم على مستوى Pod. وبالتالي، فإن دليل المضيف المقابل للحجم فريد لكل Pod، وأي حاوية داخل Pod تحتاج فقط إلى التصريح بتركيب هذا الدليل.
فلسفة التصميم هذه لـ Pods، التي تعزز “علاقة فائقة القرب” بين الحاويات، تهدف إلى تشجيع المستخدمين على التفكير فيما إذا كانت التطبيقات التي تحتوي على مكونات متعددة غير مرتبطة وظيفياً تعمل في حاوية واحدة قد يتم تمثيلها بشكل أفضل كحاويات متعددة داخل Pod.
لفهم هذه العقلية، حاول تطبيقها على السيناريوهات التي يصعب حلها بحاوية واحدة. على سبيل المثال، تخيل تطبيقاً يقوم باستمرار بإخراج ملفات السجل إلى دليل “/var/log” داخل الحاوية. في هذه الحالة، يمكنك تركيب حجم داخل Pod على دليل “/var/log” لحاوية التطبيق. ثم، داخل نفس Pod، قم بتشغيل حاوية sidecar تعلن أيضاً عن تركيب نفس الحجم على دليل “/var/log” الخاص بها. من هناك، المهمة الوحيدة لحاوية sidecar هي قراءة ملفات السجل باستمرار من دليل “/var/log” الخاص بها وإعادة توجيهها إلى حلول التخزين مثل MongoDB أو Elasticsearch. هذا الإعداد يؤسس آلية أساسية لجمع السجلات.
على غرار المثال الأول، الوظيفة الرئيسية لـ sidecar في هذا السيناريو تدور أيضاً حول استخدام الحجم المشترك لعمليات الملفات. ومع ذلك، لا تهمل الخاصية الحاسمة الأخرى لـ Pods: جميع الحاويات داخل Pod تشترك في نفس مساحة أسماء الشبكة. هذا يسمح بتفويض العديد من التكوينات والمهام الإدارية المتعلقة بشبكة Pod إلى sidecar، متجاوزاً تماماً الحاجة إلى التدخل في حاويات المستخدم. مثال رئيسي على ذلك هو مشروع شبكة الخدمات Istio.
ملخص
في هذه المناقشة، تعمقنا في الأسباب الكامنة وراء الحاجة إلى Pods. باختصار، Pod هي الوحدة الأساسية داخل مجموعة Kubernetes، وتغلف حاوية واحدة أو أكثر (عادةً حاويات Docker). تشارك هذه الحاويات موارد الشبكة والتخزين. من منظور العمليات ومجموعات العمليات، يمكن اعتبار Pod كمجموعة عمليات خفيفة الوزن. إنها تمكن نشر وتوسيع نطاق وإدارة العديد من العمليات المتعاونة عن كثب (الحاويات) كوحدة متماسكة، مما يبسط نشر وتشغيل التطبيقات المعقدة. في المقالة التالية، سنقدم شرحاً أكثر تعمقاً لـ Pods.
Novita AI هي المنصة السحابية الشاملة التي تمكن طموحاتك في الذكاء الاصطناعي. مع واجهات برمجة تطبيقات متكاملة بسلاسة، وحوسبة بدون خادم، وتسريع GPU، نوفر الأدوات الفعالة من حيث التكلفة التي تحتاجها لبناء وتوسيع نطاق أعمالك المدعومة بالذكاء الاصطناعي بسرعة. تخلص من متاعب البنية التحتية وابدأ مجاناً - Novita AI تجعل أحلامك في الذكاء الاصطناعي حقيقة.
القراءة الموصى بها:
