كوبرنيتس Kubernetes هو نظام فعّال ومفتوح المصدر لإدارة التطبيقات المغلفة داخل الحاويات والمبنية في بيئة عنقودية (Clustered environment)، طوّرته في البداية شركة جوجل ثم حظي بدعم مؤسسة CNCF أو Cloud Native Computing Foundation، وهدفه الأساسي توفير طرق مرنة لإدارة الخدمات والمكونات الموزعة في بنية تحتية متنوعة التقنيات.
فإذا كنت تتساءل ما هو Kubernetes؟ وما مكوناته الأساسية وما المشكلات التي يحلّها؟ وأي نموذج يعتمد في نشر التطبيقات وتوسعتها؟ فسيُجيبك هذا المقال على كل تساؤلاتك تلك.
ما هو Kubernetes؟
كوبرنيتس Kubernetes في الأساس هو نظام لتشغيل التطبيقات المغلفة في الحاويات وتنسيقها ضمن بيئة عمل مكونة من عدة خوادم. وقد صُممت منصة Kubernetes لإدارة دورة حياة التطبيقات والخدمات المغلفة في الحاويات إدارةً كاملة وبطرق فعالة تجعلها قابلة للتنبؤ، وسهلة التوسعة، وعالية التوافرية.
يُمَكِّنُك كوبرنيتس Kubernetes من تحديد كيفية تشغيل تطبيقاتك، وطريقة تفاعلها مع التطبيقات الأخرى ومع المصادر الخارجية، ويمنحك القدرة على توسيع مواردها الحاسوبية أو إنقاصها حسب الحاجة، ويسهل إجراء التحديثات التدريجية rolling updates بسلاسة دون انقطاع الخدمة، وتبديل حركة مرور البيانات بين إصداراتها المختلفة لاختبار الميزات الجديدة أو للتراجع عن عمليات النشر المصحوبة بالأخطاء أو غير ذلك. وتأتي إمكاناته هذه مما يوفره لمستخدميه من واجهات استخدام، ومنصة قوية قابلة للبناء حسب تفضيلاتهم، ومختلف الأساسيات التي يحتاجونها ليُنشئوا بيئات تطبيقاتهم كما يريدون بمرونة وموثوقية عالية.
ولمزيد من المعلومات حول تقنية كوبرنتيس Kubernetes والاطلاع على أكثر الأسئلة شيوعًا حولها تتصحك بمطالعة الفيديو التالي:
بنية Kubernetes
سنتعرّف على بنية Kubernetes وطريقة تصميمها وتنظيمها لنفهم إمكاناته الكبيرة التي يوفرها للمطورين. يشبه Kubernetes نظامًا مكوّنًا من عدة طبقات، وتُجَرِّد كل طبقة منه التعقيدات الموجودة في الطبقات الأدنى منها.
سبيل المثال تتضمن كائنات Pod (التي تمثل أصغر وحدة في Kubernetes والتي سنشرحها بعد قليل) عدة حاويات، وتشير الخدمة (Service) إلى عدة كائنات Pod وتوفر نقطة وصول واحدة إليها وقِس على ذلك، فيخفف هذا التجريد على المطوّر كمية التفاصيل التي عليه التعامل معها، فنحن هنا نتعامل مع مفاهيم منطقية دون أن نربطها بآلة فيزيائية أو افتراضية معينة.
يضم Kubernetes في قاعدته عنقودًا cluster من الآلات الفيزيائية أو الافتراضية (VMs) يجمعها مع بعضها شبكة اتصال مشتركة، ويُعدّ هذا العنقود المنصة الفيزيائية التي تُضبَط فيها جميع مكونات Kubernetes، وإمكاناته، وأحمال العمل workloads، ويُقصد بأحمال العمل هنا تطبيقك الذي ستُشغله ضمن الحاوية سواء كان تطبيق ويب أو أي نوع آخر من التطبيقات.
تتمتع كل آلة ضمن العنقود بدورٍ خاص في نظام Kubernetes. ويعمل خادم واحد (أو مجموعة خوادم في عمليات النشر التي تتطلب توافرية عالية) دور الخادم الرئيسي master server، فيكون بمثابة بوابة العنقود أو عقله المُدبِّر، ويؤدي مهامًا مثل: إتاحة واجهة برمجة التطبيقات Kubernetes API للمستخدمين والعملاء، والتحقق من سلامة الخوادم الأخرى وتقسيم العمل عليها (بعملية تسمى "الجدولة scheduling")، بالإضافة إلى تنظيم الاتصال بين مكونات العنقود (أو ما يُعرف بتنسيق الحاويات container orchestration). إذًا فالخادم الرئيسي هو نقطة الاتصال الأساسية مع عنقود Kubernetes والمسؤول عن معظم أعماله المركزية.
تدعى الآلات الأخرى في العنقود عقدًا nodes: وهي مجموعة خوادم مسؤولة عن استقبال أحمال العمل workloads وتشغيلها باستخدام الموارد الحاسوبية المتوفرة لها المحلية والخارجية. وتُجَهَّز كل عقدة ببرنامج لتشغيل الحاويات مثل دوكر Docker أو روكيت rkt، إذ إن Kubernetes يُشغِّل التطبيقات والخدمات ضمن حاويات containers ليؤمن لها المستويات المرجوة من العزل والمرونة والإدارة الفعالة، وتتلقى العقدة تعليمات العمل الخاصة بها من الخادم الرئيسي، فتُنشئ بناءً عليها حاوياتٍ جديدة أو تُدمِّر حاوياتٍ أخرى، وتُعدِّل قواعد المرور عبر الشبكة لتُوجّه حركة البيانات حسب المطلوب.
تعمل التطبيقات والخدمات على العنقود وهي ضمن الحاويات (كما ذكرنا أعلاه)، وتتأكد المكونات الأساسية باستمرار من توافق الحالة المرغوبة للتطبيقات مع الحالة الفعلية للعنقود. أما المستخدمون فيتفاعلون مع العنقود عبر الاتصال مع خادم Kubernetes API الرئيسي مباشرةً أو بواسطة تطبيقات العملاء clients والمكتبات البرمجية.
والخطوة الأولى التي يبدأ بها تشغيل أي تطبيق أو خدمة هي إعداد خطة تصريحية declarative plan بصيغة JSON أو YAML تتضمن ما ينبغي إنشاؤه لتشغيل التطبيق، وكيف سيُدّار. ثم يُحلل الخادم الرئيسي هذه الخطة، ويحدد أنسب الطرق لتشغيلها على البنية التحتية المتوفرة له، وذلك عبر فحص المتطلبات اللازمة والحالة الحالية للنظام والموازنة بينهما. وتمثل مجموعة التطبيقات التي خصصها المستخدم لتعمل وفق خطة محددة الطبقة الأخيرة في نظام Kubernetes.
يجعل هذا النهج التصريحي من إدارة التطبيقات المعقدة أكثر سهولة وقابلية للتوسع ويسمح للمطورين بالتركيز على وصف ما يريدونه، بينما يتولى كوبرنيتس Kubernetes تفاصيل التنفيذ.
مكونات الخادم الرئيسي Master Server
يتحكم الخادم الرئيسي بعناقيد Kubernetes، ويؤمن نقطة اتصال رئيسية لمدراء الأنظمة administrators والمستخدمين، ويوفر العديد من الأنظمة لإدارة العقد العاملة worker nods الأقل منه تطورًا على نطاق العنقود.
بالعموم، تؤدي مكونات الخادم الرئيسي مجموعةً من الوظائف أبرزها: قبول طلبات المستخدمين، وتحديد أفضل الطرق لجدولة حاويات أحمال العمل workload containers، وإجراء المصادقة بين العملاء والعقد، وضبط قواعد التوجيه والوصول الشبكي على مستوى العنقود، وإدارة مهام التوسعة والتحقق من سلامة النظام.
تُثبَّت مكونات الخادم الرئيسي (التي سنذكرها تاليًا) على خادم واحد أو على عدة خوادم حسب الحالة.
المَخزَّن العام للإعدادات etcd
يُعدّ المَخزَّن العام للإعدادات واحدًا من أهم المكونات الضرورية لعمل عنقود Kubernetes، يوفره مشروع etcd الذي أنشأه فريق تطوير CoreOS (وهو نظام التشغيل الموجه للحاويات ويمكنك معرفة المزيد عنه بقراءة مقدّمة إلى مكونات نظام CoreOS). و etcd هو نظام لتخزين ملفات الإعدادت وإدارتها بشكل موزع، وهو عبارة عن مَخزَنَ قيم-مفاتيح موزّع على المستوى العام لنظام Kubernetes، ويتصف بأنه خفيف في استخدام الموارد، ويمكن تهيئته لتمرير الإعدادات بين عدة عقد.
إذ يُخزِّن Kubernetes بيانات الإعدادات التي يُسمح لكل عقدة بالوصول إليها في مَخزَّن etcd. وتستخدم مكونات Kubernetes هذه البيانات لاكتشاف الخدمة المطلوبة، وتهيئة نفسها للعمل حسب المعطيات الجديدة، وتساهم أيضًا في الحفاظ على حالة العنقود بواسطة ميزات، مثل: اختيار القائد leader election، والقفل الموزع distributed locking وغيرها. وتجري عملية تعيين القيم أو استردادها بواسطة واجهة برمجة تطبيقات HTTP/JSON API بسيطة تجعل العملية سلسة وواضحة.
يمكن بناء etcd على خادم رئيسي واحد أو جعله موزعًا على عدة آلات في بعض بيئات الإنتاج، والشرط الوحيد هو توفر اتصال شبكي يصله بجميع آلات العنقود.
خادم kube-apiserver API
خادم API من أهم الخدمات المحورية على الخادم الرئيسي لعنقود Kubernetes، ويُعدّ نقطة الإدارة الرئيسية للعنقود بأكمله فهو يسمح للمستخدم بإعداد أحمال العمل والوحدات التنظيمية، والتحقق من توافق تفاصيل الخدمة على الحاويات المنشورة مع البيانات الموجودة في مخزَّن etcd. يمكنك النظر إلى خادم API مثل جسر يصل المكونات ببعضها، ويعمل للحفاظ على سلامة العنقود، ولنقل المعلومات والأوامر عبره.
يطبق هذا الخادم واجهة برمجة تطبيقات من نوع RESTful API، وتضع شهرتها الواسعة العديد من المكتبات والأدوات في أيدي مستخدمي Kubernetes لتيسير عليهم التخاطب مع خادم API. يتوفر لخادم kube-apiserver عميلٌ افتراضي يدعى kubectl يتيح لك الاتصال مع عنقود Kubernetes من حاسبك المحلي.
مدير التحكم kube-controller-manager
مدير التحكم controller manager هو خدمة عامة تتولى عدة مسؤوليات ضمن العنقود، أولها إدارة المتحكمات المختلفة التي تنظم حالة العنقود، وإدارة دورات حياة حمل العمل workload، بالإضافة لبعض المهام الروتينية الأخرى. فعلى سبيل المثال: يفحص متحكم النظائر replication controller عدد النظائر المحددة لكائن pod معين (أي عدد تكراراته أو النسخ المماثلة له)، ويتأكد أن هذا العدد مطابقٌ للعدد الفعلي المنشور حاليًا على العنقود. تُكتب تفاصيل العمليات جميعها في etcd، ويراقب مدير التحكم التغييرات التي تطرأ على المعلومات ضمنه بواسطة خادم API.
عندما يحدث أي تغيير، يقرأ المتحكم المعلومات الجديدة، ويُطبق الإجراءات اللازمة للوصول إلى الحالة المطلوبة، فقد يعمل مثلًا على توسيع نطاق التطبيق أو تقليصه، أو على ضبط نقاط الوصول الخاصة به endpoints أو غير ذلك.
المُجَدّوِل kube-scheduler
الجدولة هي ربط أحمال العمل بالعقد؛ فتحدد خدمة المُجَدّوِل ما ستُنفذه كل عقدة. تقرأ الخدمة متطلبات تشغيل كل حمل عمل، وتُحلل مواصفات بيئة البنية التحتية الحالية المتوفرة، وبناءً على ذلك تقرر أي عقد أو مجموعة عقد هي المقبولة لتنفيذ العمل.
يتتبع المُجَدّوِل الإمكانات المتاحة على كل مضيف، ليضمن أن أحمال العمل لم تُجَدول على العقد بطريقة خاطئة تتعارض مع الموارد المتاحة. وبالتالي يعرف المُجَدّوِل في كل لحظة الموارد الإجمالية المتوفرة والموارد المخصصة حاليًّا لأحمال العمل.
مدير التحكم السحابي cloud-controller-manager
نظام Kubernetes قابلٌ للنشر في بيئات متعددة، ويمكنه التعامل مع خدمات البنى التحتية لمزودين مختلفين، فيأخذ معلومات عن حالة الموارد الحاسوبية التي توفرها للعنقود ويديرها حسب متطلباته. ولكونه يتعامل مع تمثيلات عامة للموارد الحاسوبية مثل: موازنات الحمل Load Balancers والحجوم التخزينية وغيرها، فإنه يحتاج لربط map هذه التمثيلات بالموارد الفعلية التي يوفرها له مزودو الخدمات السحابية المتعددون.
وهنا تبرز أهمية مدير التحكم السحابي، إذ يسمح لنظام Kubernetes بالتخاطب مع مزودي خدمات مختلفين في المزايا والإمكانات وواجهات API، مع الحفاظ على بنيته الداخلية عامة نوعًا ما بالرغم من تنوع الخدمات السحابية التي يتعامل معها. يعطي ذلك Kubernetes القدرة على تحديث معلومات الحالة لديه بناءً على المعلومات التي يوفرها له المزود السحابي، ويستخدمها لضبط الموارد السحابية المخصصة له لتلبي متغيرات العمل، فقد يُنشئ مثلًا خدمات سحابية إضافية عندما تزداد احتياجات العمل المطلوبة من العنقود.
مكونات خادم العقدة Node Server
العقد Nodes في Kubernetes هي الخوادم التي تعمل عليها حاويات التطبيق؛ تتطلب العقد بعض الضروريات لتؤدي أعمالها في التخاطب مع مكونات الخادم الرئيسي، وضبط إعدادات الاتصال الشبكي للحاويات، وتشغيل أحمال العمل التي يكلفها بها الخادم الرئيسي.
بيئة تشغيل الحاوية Container Runtime
بيئة تشغيل الحاوية Container Runtime من أهم مكونات العقدة، ودوكر Docker هو من أشهر بيئات التشغيل المعتمدة، لكنه ليس الوحيد، إذ يوجد بدائل له أخرى مثل rkt المطُور من قبل CoreOS وكان يُعتبر بديلاً أكثر أماناً وقابلية للتحكم مقارنة بدوكر و runc وهو مكون منخفض المستوى يستخدمه دوكر نفسه لتنفيذ الحاويات.
تتولى أدوات بيئة تشغيل الحاوية عمليات بدء تشغيل الحاويات وإدارتها، والحاويات Containers هي تطبيقات خفيفة مغلفة في بيئة تشغيل معزولة، وتُعدّ المكون الأساسي في وحدات عمل عنقود Kubernetes، فتشتمل كل وحدة عمل على حاوية واحدة ينبغي نشرها أو أكثر حسب متطلبات المشروع. وعندما ترد أحمال العمل إلى العنقود تعمل بيئة تشغيل الحاوية على تشغيل الحاويات المطلوبة لتنفيذ العمل.
نقطة اتصال العقدة kubelet
نقطة اتصال العقدة kubelet هي صلة الوصل التي تربط كل عقدة ببقية أجزاء العنقود. وهي خدمة صغيرة تنقل المعلومات ذهابًا وإيابًا بين العقدة وخدمات مستوى التحكم على الخادم الرئيسي، وتتخاطب أيضًا مع مخزن الإعدادات etcd لقراءة بيانات العمل منه أو كتابة بيانات جديدة فيه.
تتواصل kubelet مع مكونات الخادم الرئيسي لإتمام عملية المصادقة بين العقدة والعنقود، وللحصول على الأوامر وتفاصيل الأعمال المُسندة إليها، والتي تردها بصيغة بيان manifest أو خطة تحدد حمل العمل المطلوب ومعطيات parameters التشغيل. تحافظ kubelet على حالة العمل على العقدة، وتتحكم ببيئة تشغيل الحاوية لإنشاء الحاويات أو تدميرها حسب الحاجة.
الوكيل kube-proxy
يستخدم الوكيل لإدارة الشبكات الفرعية داخل المضيف، وجعل الخدمات متاحة بين المكونات، وهو خدمة صغيرة تدعى kube-proxy توجد على كل عقدة، توجه الطلبات الواردة إليها إلى الحاوية المسؤولة عن تنفيذها، وتجري نوعًا مبسطًا من موازنة الحمل Load Balancing، وتضمن أن سلوك الشبكة قابلًا للتنبؤ به، وأنها متاحة أو معزولة حيث ينبغي ذلك.
كائنات Kubernetes وأحمال العمل
يستخدم Kubernetes طبقات تجريد abstraction إضافية فوق الحاويات -التي تُعدّ الآلية الرئيسية لنشر التطبيقات المغلفة containerized applications- توفر هذه التجريدات للمستخدمين ميزات المرونة والتوسع وإدارة دورة الحياة، فبدلًا من تعاملهم مع الحاويات مباشرةً يتفاعلون مع المثيلات instances التي تتألف من مجموعة مكونات أولية يوفرها نموذج عمل كائن Kubernetes، سنعرض في هذه الفقرة كائنات Kubernetes وكيفية استخدامها للتعامل مع أحمال الحمل.
الكائنات Pods
الكائن Pod هو أصغر وحدة تنظيمية يتعامل معها عنقود Kubernetes، تتكون من حاوية أو مجموعة حاويات، فعند الإعداد لا نخصص الحاويات على مضيف معين، إنما نشير إليها بكائن Pod الذي تنتمي إليه.
تمثل الحاويات الموجودة في Pod واحد تطبيقًا واحدًا أي أنها تعمل معًا بارتباطٍ وثيق، فتتشارك دورة الحياة، وتُجدّوَل أعمالها على عقدة واحدة، وتُدار بصفتها وحدة واحدة، وتتقاسم بيئة التشغيل والموارد مثل: المساحات التخزينية وعناوين IP. فِكِّر دائمًا بالكائن Pod على أنه تطبيق واحد متجانس بالرغم من تعدد حاوياته، لتفهم كيف يتعامل معه العنقود، ويُدّير موارده، ويُجدّول مهامه.
يحتوي كل Pod على حاوية رئيسية لا غنى عنها تلبي الهدف العام من حمل العمل workload، وقد يحتوي حاويات أخرى اختيارية تؤدي مهامًا مساعدة حسب احتياجات مشروعك، تتضمن الحاويات المساعدة عادةً برامج مستقلة تعمل وتُدار فيها باستقلالية لكنها ترتبط بالمشروع بطريقة أو بأخرى، لذا توضع معه في كائن Pod واحد. على سبيل المثال: قد يتضمن Pod معين حاويةً رئيسية لتشغيل خادم التطبيق، وحاويةً مساعدة تتحسس لأي تغييرات تحدث على مستودع خارجي متعلق به، وتسحب الملفات المرتبطة منه إلى نظام الملفات المشترك داخل Pod. لا يُنصح عادةً بالتوسع الأفقي على مستوى كائنات Pods إذ تترك هذه المهمة عادة لكائنات أخرى بمستوى أعلى.
لا يُدّير المستخدمون عمومًا كائنات Pods بأنفسهم، فهي لا توفر لهم المميزات التي غالبًا ما يحتاجونها لإدارة تطبيقاتهم، مثل: الإدارة المتقدمة لدورة حياة التطبيق أو إدارة عمليات التوسعة Scaling، وبالمقابل تشجعهم بنية Kubernetes على استخدام كائنات بمستوى أعلى، تستخدم بدورها كائنات Pods أو قوالب Pods لتأدية الوظائف.
متحكمات النظائر ومجموعات النظائر
يعمل معظم من يستخدم Kubernetes مع نظائر متعددة للكائنات Pods مطابقة لها تمامًا، بدلًا من التعامل مع Pods مفردة. تُنشئ هذه النظائر انطلاقًا من قوالب Pod، وتوسعها أفقيًا متحكماتٌ خاصة تدعى متحكمات النظائر Replication Controllers ومجموعات النظائر Replication Sets.
متحكم النظائر replication controller هو أحد كائنات Kubernetes، مسؤول عن تحديد قالب Pod الذي ستُبنى النظائر انطلاقًا منه، وأيضًا عن تحديد معطيات التحكم التي تُمَكِّنهُ من إدارة التوسعة الأفقية لنظائر Pod فيزيد عدد النظائر قيد التشغيل أو ينقصها حسب الحاجة. تمثل هذه العملية طريقةً سهلة لموازنة الحمل وتحسين التوافرية availability داخل نظام Kubernetes، فالقالب الذي ستنشئ منه النظائر الجديدة، والذي يشبه إلى حدٍ كبير تعريف للكائن Pod، يكون مضمنًا embedded في إعدادات متحكم النظائر.
يتأكد متحكم النظائر باستمرار من تطابق عدد Pods المنشورة فعليًّا على العنقود مع العدد المطلوب والمحدد في إعدادته. وفي حال فشل أي Pod أو مضيف، سيستجيب المتحكم على الفور، ويبدأ بتشغيل Pods جديدة لتعويض النقص. أما إذا طرأ أي تغيير على عدد النظائر المحدد في إعداداته بالزيادة أو النقصان فسيُشغِّل المتحكم حاويات جديدة أو يدمر الحاويات الموجودة أصلًا ليصل للعدد المطلوب. يؤدي متحكم النظائر أيضًا مهمة التحديثات التدريجية rolling updates فيَنقُل مجموعة Pods إلى الإصدار الجديد بالتتابع واحدًا تلو الآخر حتى لا يسبب انقطاع كلي للخدمة فيؤثر على توافرية التطبيق.
مجموعات النظائر Replication sets تتمتع بتصميم مشابه لتصميم متحكم النظائر، مع مرونة أكبر في آلية تعريف المتحكم لكائنات Pods التي سيُدِّيرها. يتسع نطاق الاعتماد على مجموعات النظائر على حساب متحكمات النظائر، بسبب إمكاناتها الكبيرة في اختيار النظائر، لكنها بالمقابل قاصرة عن إجراء التحديثات التدريجية للتطبيق وترقية واجهاته الخلفية إلى إصدار جديد كما تفعل متحكمات النظائر، فقد صممت مجموعات النظائر لتعمل في وحدات تنظيمية أخرى أعلى منها مستوى تؤدي هذه المهمة.
تمامًا مثل Pods، تُعدّ متحكمات النظائر ومجموعات النظائر وحداتٍ أولية في نظام Kubernetes وناردًا ما يتعامل معها المستخدم العادي، رغم أنها توفر لتطبيقاته التوسعة الأفقية والوثوقية في العمل، إلَا أنها تفتقر لمميزات إدارة دورات الحياة بطريقة سلسة يفضلها المستخدمون والموجودة في مكونات Kubernetes الأكثر تعقيدًا.
النشر Deployments
يُعدّ النشر Deployments واحدًا من أشهر أحمال العمل التي تُنشئ وتُدار مباشرةً على Kubernetes. تستخدم عمليات النشر مجموعات النظائر بوصفها كتلة بناء أو مكون أساسي تُبنى منه، وهذا ما يمنح مجموعات النظائر المرونة التي تفتقدها في إدارة دورة الحياة.
للوهلة الأولى قد تبدو لك عمليات النشر deployments المكونة من اجتماع عدد من مجموعات النظائر مشابهة في وظائفها لمتحكمات النظائر، إلّا أنها في الواقع تعالج العديد من نقاط ضعفها في إطلاق التحديثات. فعند استخدام المتحكمات ينبغي عليك إعداد خطة لمتحكم النظائر الجديد الذي سيحل محل المتحكم الحالي، وستكون أعمال كثيرة مثل: سجلات تتبع الأحداث، واستعادة التطبيق في حال طرأ عطل في الشبكة، والتراجع عن التحديث rolling back، عملياتٍ صعبة التنفيذ أو تلقى مسؤوليتها على المستخدم.
إذًا فالنشر Deployments هو كائن عالي المستوى، ومصمم لتسهيل إدارة دورة حياة نظائر Pods، وهو أكثر الكائنات التي ستعمل معها مباشرةً في Kubernetes، إذ يمكنك تعديله بسهولة حسب ما تريد فكل ما يتطلبه الأمر تعديل إعداداته، وبعدها سيضبط Kubernetes مجموعات النظائر replica sets بناءً على إعداداتك، ويدير الانتقالات بين إصدارات التطبيق مع تفعيل اختياري لميزات مثل: سجل تتبع الأحداث والتراجع الآلي عن التحديث وغيرها.
مجموعات الحالة Stateful sets
مجموعات الحالة Stateful sets هي pod تحكم متخصصة نوعًأ ما، تضمن ترتيب طلبات إنشاء Pods في مجموعة الحالة، وأن يمتلك كل Pod في هذه المجموعة معرفًا فريدًا خاصًا به. وتوفر للمستخدمين تحكمًا دقيقًا في المشاريع ذات المتطلبات الخاصة سواءً على صعيد النشر أو الاستقرار الشبكي أو وجود البيانات الدائمة Persistent data التي تبقى متاحة لوقت طويل دون تغيير. فغالبًا ما ترتبط مجموعات الحالة بالتطبيقات الموجهة للبيانات، مثل قواعد البيانات التي تتطلب وصولًا دائمًا لوحدات التخزين نفسها في جميع الظروف حتى إذا أُعِيدَت جدولتها على عقدة جديدة.
توفر مجموعات الحالة مُعرِّفًا شبكيًا ثابتًا لكل Pod، هو اسمٌ عددي فريد يشير إلى Pod بعينها دائمًا حتى إذا انتقلت إلى عقدة أخرى. والأمر نفسه مع وحدات التخزين الدائمة التي تنتقل مع Pod إن أُعِيدَت جدولتها لسبب ما. علماً أن وحدات التخزين الدائمة هذه تبقى موجودة ولا تحذف تلقائيًا مع حذف Pod لمنع الفقدان غير المقصود للبيانات.
تنفذ مجموعات الحالة العمليات المناطة بها في أثناء النشر أو ضبط التوسعة وفقًا للمُعرِّف الفريد، ويعزز ذلك إمكانية التنبؤ والتحكم بترتيب التنفيذ، ويُعدّ مفيدًا في بعض المشاريع ذات الطبيعة الخاصة.
مجموعات برامج التشغيل الخلفية Daemon Sets
مجموعات البرامج الخفية Daemon sets هي نموذج متخصص آخر من متحكمات pod التي تُشَغِّل نسخة من pod معين على كل عقدة (أو مجموعة عقد مترابطة) في العنقود. وتبرز فائدتها عند نشر Pods الخدمية لعقد Kubernetes مثل Pods الصيانة وغيرها.
فعلى سبيل المثال تُعدّ خدمات نحو: جمع ملفات تسجيل الأحداث وإعادة توجيهها، وتنظيم المقاييس، وتشغيل الخدمات التي تزيد من إمكانات العقد وغيرها، حالات شائعة للاستفادة من مجموعات البرامج الخفية. ولا تخضع مجموعات البرامج الخفية لقيود الجدولة المفروضة على pods العادية والتي تربطها بمضيفين معينين، ذلك أنها تقدم خدمات أساسية ومطلوبة في كامل نظام Kubernetes حتى **على الخادم الرئيسي، الذي يُعدّ محظورًا على المجدول بسبب مسؤولياته الخاصة، إلّا أن مجموعات البرامج الخلفية تتجاوز هذه القيود لتتأكد من سلامة تشغيل الخدمات الرئيسية.
المهام Jobs والمهام الدورية Cron Jobs
تتصف معظم أحمال العمل التي أوردناها في المقال بدورة حياة طويلة الأمد تشبه دورة حياة الخدمة، لكن Kubernetes يستخدم أيضًا نوعًا آخر من أحمال العمل يسمى المهام jobs لتأمين سير عمل أشبه بالمأمورية المؤقتة task-based تخرج فيه الحاوية من الخدمة بعد مضي بعض الوقت وانتهاء مهمتها. تساعدك كائنات المهام Jobs على تنفيذ العمليات التي لا تتطلب تشغيل خدمات دائمة، مثل: العمليات الدفعية batch أو العمليات التي تُجرى لمرة واحدة.
تُبنى المهام الدورية cron jobs على المهام jobs. وهي تماثل جدولة المهام بتقنية cron في لينكس وغيره من أنظمة يونيكس المشابهة التي تُنَفَذ بموجبها السكربتات وفقًا لجدول زمني محدد، إذ توفر المهام الدورية في Kubernetes واجهة لتشغيل المهام بواسطة المجدول (مكون الخادم الرئيسي الذي ذكرناه سابقًا). تستخدم المهام الدورية لضبط تنفيذ مهمة معينة بوقت محدد في المستقبل، سواء لمرة واحدة أو لتكرار تنفيذها بانتظام. ويمكنك النظر إلى المهام الدورية في Kubernetes على أنها تطبيق لمهام cron التقليدية ولكن على منصة كاملة هي العنقود بدلًا من نظام تشغيل منفرد.
مكونات أخرى لنظام Kubernetes
يوفر Kubernetes عددًا من التجريدات إضافةً إلى أحمال العمل تساعدك على إدارة تطبيقاتك، والتحكم بالشبكات، وتأمين الاستمرارية وغير ذلك، سنناقش بعضًا منها أدناه:
خدمات Kubernetes
استخدمنا مصطلح "خدمة service" بالمعنى التقليدي كما في أنظمة يونيكس، أي للدلالة على العمليات طويلة الأمد، والتي غالبًا ما تتصل بالشبكة، وتستجيب للطلبات. إنما في Kubernetes تعمل الخدمة بصفتها موازن حمل أساسي داخلي ومرسال لوحدات pods. وتجمع الخدمة مجموعات منطقية من pods التي تؤدي الوظيفة نفسها، وتقدمها بوصفها كيان واحد.
يمكنك مثلًا نشر خدمة لتتبع الحاويات الخلفية من نوع معين وتوجيه الطلبات إليها. علمًا أن كل ما يحتاج المستهلكون الداخليون لمعرفته عن الخدمة هو نقطة النهاية الثابتة التي توفرها فقط دون أي تفاصيل أخرى، يتيح لك هذا التجريد توسيع نطاق وحدات العمل العاملة في الخلفية أو استبدالها حسب الحاجة، وسيبقى عنوان IP المخصص للخدمة ثابتًا بصرف النظر عن أي تغيير يطرأ على pods المرتبطة به. يكسبك نشر الخدمات قابلية الاكتشاف ويبسيط تصميم حاوياتك.
تفيدك الخدمات في الحالات التي تحتاج فيها للوصول إلى pods تطبيق آخر أو للاتصال مع مستهلكين خارجيين. فعلى سبيل المثال: إذا كان لتطبيقك عددٌ من pods العاملة على خوادم الويب ويتصل بها العملاء عن طريق الإنترنت، فإن بناء خدمة خاصة بهذه الحالة سيوفر لك التجريد اللازم. وهذا مثال آخر: لنفترض أن خوادم الويب في مشروعك بحاجة لتخزين البيانات واستردادها في قاعدة بيانات معينة، فيمكنك تأمين وصولها إلى pods قاعدة البيانات عبر بناء خدمة داخلية تتكفل بالأمر.
خدمات Kubernetes متاحة افتراضيًا داخل العنقود بعنوان IP الخاص بها، وإذا أردت طلبها من الخارج فيمكنك تحقيق ذلك بعدة طرق، تتمثل إحداها بفتح منفذ ثابت static port خاص بالخدمة على واجهة الشبكة الخارجية لكل عقدة، ثم توجيه حركة المرور الواردة إليه تلقائيًا إلى عنوان IP الداخلي للخدمة، وبالتالي إلى pods المناسبة. تسمى هذه الطريقة NodePort.
أو يمكنك استخدام خدمة خاصة من نوع موازن حمل LoadBalancer تُنشئ لك موازن حمل خارجي يوجه حركة البيانات نحو الخدمة الداخلية المقصودة، تُنَفَذ هذه الطريقة باستخدام تكامل موازن الحمل الخاص بمزود Kubernetes السحابي، إذ ينشئ مدير التحكم السحابي الموارد اللازمة ويربطها بعناوين خدمة موازن الحمل التي تشير لخدمتنا الداخلية المقصودة.
وحدات التخزين ووحدات التخزين الدائمة
تُعدّ مشاركة البيانات بين أكثر من حاوية مشاركةً موثوقة، والحفاظ عليها وضمان توفرها بين عمليات إعادة تشغيل الحاويات، تحدّيًا كبيرًا في العديد من بيئات الحاويات. وتوفر بعض بيئات تشغيل الحاويات آليات خاصة ترتبط وحدات التخزين بالحاوية، وتحافظ عليها بعد انتهاء عمر الحاوية، لكن هذه الآليات تفتقد غالبًا للمرونة في التنفيذ العملي.
يستخدم Kubernetes تجريدًا خاصًا لمعالجة هذا التحدّي يدعى وحدات التخزين volumes، يسمح للحاويات المغلفة في pod واحد بمشاركة البيانات فيما بينها، والإبقاء عليها متاحة لحين انتهاء عمل pod، وحتى إذا فشلت حاوية معينة أو توقفت لسبب من الأسباب فالبيانات المشتركة ستبقى قابلة للوصول طالما أن pod موجود، وعند إنهاء عمله يُحذف المجلد المشترك. يُسهّل ذلك مشاركة الملفات بين عناصر pod الواحد دون الحاجة لأي آليات خارجية معقدة، لكنه لا يُعدّ حلًا مناسبًا للبيانات الدائمة التي لا تتعلق بعمر pod بل تستمر بعدها.
لذا يوفر Kubernetes تجريدًا أقوى لتخزين البيانات الدائمة، يسمى وحدات التخزين الدائمة Persistent volumes، لا يرتبط بدورة حياة pod، ويسمح لمديري النظام بإعداد موارد التخزين على مستوى العنقود ليتمكن المستخدمون من حجزها لكائنات pod التي يُشغِّلونها حسب تفضيلاتهم. ويحدد كل مستخدم سياسة الاسترداد الخاصة به، التي تقرر فيما إذا كانت وحدة التخزين وبياناتها ستُحذف يدويًا من قبله أم آليًّا عند انتهاء عمر pod. يخفف استخدام وحدات التخزين الدائمة من المخاطر المترتبطة بحالات فشل العقدة، ويساعدك على زيادة مساحات التخزين المخصصة لصالح مشروعك عمّا هو متاحٌ له محليًّا على المضيف.
التعليقات التوضيحية Annotations والتسميات التوضيحية Labels
التسميات التوضيحية label هي تجريد تنظيمي في Kubernetes ينظم المفاهيم الأخرى في النظام ويوضحها، وهي علاماتٌ دلالية ترفق بكائنات Kubernetes لوسمها بوسمٍ خاص يشير لانتمائها لمجموعة معينة، أي أنها تُستَخدم لتصنيف الكائنات ولاستهداف مثيلات مختلفة لأغراض الإدارة أو التوجيه أو غيرها، فمثلًا تعتمد الخدمات على التسميات التوضيحية لمعرفة pods الواجهة الخلفية التي ينبغي توجيه الطلبات إليها، وكذلك الأمر مع كائنات التحكم التي تستعمل التسميات التوضيحية لتحديد pods التي ستعمل عليها.
تُوضع التسميات التوضيحية بهيئة أزواج مفتاح-قيمة، ويمكن أن تحظى الوحدة التنظيمية عدة لصائق، لكنها لا تحمل أبدًا إلّا بقيمة واحدة لكل مفتاح. ومفتاح "الاسم name" هو أشهر المفاتيح، ويُعدّ مُعَرِّفًا عامًا متعدد الأغراض، يمكنك أيضًا تصنيف الكائنات وفق معايير أخرى حسب احتياجات عملك، مثل: مرحلة التطوير، وإمكانية الوصول العام، وإصدار التطبيق… إلخ.
تشبه **التعليقات التوضيحية Annotations ** التسميات التوضيحية لكنها تترك لك الحرية في إرفاق أي تعليق تريده ضمن خانة القيمة للدلالة على الكائن ما دون الالتزام بمعايير محددة، في حين تفرض عليك التسميات التوضيحية قواعد معينة في كتابة المعلومات الدلالية لتجري مطابقتها عند اختيار pod. باختصار تساعدك التعليقات التوضيحية في إضافة بيانات تعريفية غنية للكائن لكنها لا تفيدك في تصنيفه أو تحديده لأمرٍ معين.
الخلاصة
يتيح Kubernetes لمستخدميه تشغيل مشاريعهم المغلفة في الحاويات على منصة قوية وعالية التجريد، وبطريقة تكفل لهم قابلية التوسع والتوافرية العالية. وعندما تبدأ بالتعرف عليه ستبدو لك بنيته معقدة، ويصعب التعامل معها، لكن ما أن تفهم أساسياتها وكيفية توافق عناصرها معًا ستشعر بمرونتها وفائدتها الكبيرة للمشاريع مفتوحة المصدر والتطوير السحابي الأصلي، وبمزيد من التدريب ستصبح قادرًا على استثمار ميزاتها المتنوعة لتشغيل أحمال العمل وإدارتها على نطاق واسع، ولإنشاء تطبيقاتك السحابية الأصلية.
ترجمة -وبتصرف- للمقال ?What is Kubernetes لصاحبه Justin Ellingwood.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.