ما هو Kubernetes؟

مقدمة

كوبرنيتيس هو نظام مفتوح المصدر قوي، تم تطويره أولاً بواسطة جوجل ومدعوم حاليًا من قِبل مؤسسة الحوسبة السحابية الأصلية (CNCF)، لإدارة التطبيقات المحايدة للحاويات في بيئة متجانسة. يهدف إلى توفير طرق أفضل لإدارة المكونات والخدمات الموزعة ذات الصلة عبر بنية تحتية متنوعة. للمزيد من المعلومات حول كوبرنيتيس، استكشف الدليل أدناه. إذا كنت تبحث عن خدمة استضافة كوبرنيتيس مُدارة، تحقق من خدمتنا البسيطة والمُدارة لكوبرنيتيس التي تم بناؤها للنمو.

في هذا الدليل، سنناقش ما هو كوبرنيتيس، وبعض المفاهيم الأساسية لكوبرنيتيس. سنتحدث عن بنية النظام، والمشاكل التي يحلها، والنموذج الذي يستخدمه للتعامل مع النشر وتوسيع التطبيقات المحايدة للحاويات.

ما هو كوبرنيتيس؟

كوبرنيتيس، على المستوى الأساسي، هو نظام لتشغيل وتنسيق التطبيقات المحايدة للحاويات عبر مجموعة من الأجهزة. إنه منصة مصممة لإدارة الحياة بالكامل للتطبيقات والخدمات المحايدة للحاويات باستخدام أساليب توفير القدرة على التنبؤ والتوسعة والتوافر العالي.

كمستخدم لـ Kubernetes، يمكنك تحديد كيفية تشغيل تطبيقاتك والطرق التي يجب أن تكون متاحة لها للتفاعل مع التطبيقات الأخرى أو العالم الخارجي. يمكنك توسيع خدماتك أو تقليلها، وتنفيذ تحديثات متداولة بانسيابية، وتبديل حركة المرور بين إصدارات مختلفة من تطبيقاتك لاختبار الميزات أو التراجع عن النشرات المشكلة. يوفر Kubernetes واجهات ومكونات أساسية قابلة للتركيب تمكنك من تحديد وإدارة تطبيقاتك بدرجات عالية من المرونة والقوة والموثوقية.

تنظيم Kubernetes

لفهم كيفية قدرة Kubernetes على توفير هذه القدرات، من المفيد الحصول على فكرة عن كيفية تصميمها وتنظيمها على مستوى عالٍ. يمكن تصور Kubernetes كنظام يتم بناؤه بطبقات، حيث يجري كل طبقة أعلى تجريد القدرة التي توجد في الطبقات السفلى.

في أساسه، يجمع Kubernetes بين الأجهزة الفردية الفعلية أو الافتراضية في مجموعة باستخدام شبكة مشتركة للتواصل بين كل خادم، مرة أخرى سواء كانت الأجهزة الفعلية أو الافتراضية. تُعتبر هذه المجموعة المجموعة Kubernetes المنصة الفعلية حيث يتم تكوين جميع مكونات Kubernetes وإمكانياتها وأعباء العمل.

الخادم الرئيسي.

العُقَد الحاويات

كما هو مذكور أعلاه، تُشغل التطبيقات والخدمات نفسها على العُقد داخل حاويات. تضمن المكونات الأساسية أن الحالة المطلوبة للتطبيقات تتطابق مع الحالة الفعلية للعُقد. يتفاعل المستخدمون مع العُقد عن طريق التواصل مع خادم واجهة برمجة التطبيقات الرئيسي لكوبرنيتس إما مباشرة أو باستخدام العملاء والمكتبات. لبدء تشغيل تطبيق أو خدمة، يُقدَّم خطة تصريحية في شكل JSON أو YAML تحدد ما يجب إنشاؤه وكيفية إدارته. ثم يأخذ خادم الماستر الخطة ويحدد كيفية تشغيلها على البنية التحتية عن طريق فحص المتطلبات والحالة الحالية للنظام. هذه المجموعة من التطبيقات المحددة من قبل المستخدمين والتي تعمل وفقًا لخطة محددة تمثل الطبقة النهائية لكوبرنيتس.

مكونات خادم الماستر

كما وصفنا أعلاه، يعمل خادم الماستر كخطة تحكم أساسية لعُقد كوبرنيتس. يعتبر نقطة الاتصال الرئيسية للمسؤولين والمستخدمين، ويوفر أيضًا العديد من الأنظمة على مستوى العُقد لعُقد العمل الذي ليس فيه عقدة العمل متطورة نسبيًا. بشكل عام، تعمل المكونات على خادم الماستر معًا لقبول طلبات المستخدمين، وتحديد أفضل الطرق لجدولة حاويات عبء العمل، ومصادقة العملاء والعُقد، وضبط الشبكات على مستوى العُقد، وإدارة مسؤوليات التوسع وفحص الصحة.

يمكن تثبيت هذه المكونات على جهاز واحد أو يمكن توزيعها عبر عدة خوادم. سنلقي نظرة على كل من المكونات الفردية المرتبطة بخوادم الماستر لعناقيد Kubernetes في هذا القسم.

etcd

أحد المكونات الأساسية التي تحتاج إليها Kubernetes للعمل هو متجر تخزين التكوين العالمي المتاح. المشروع etcd، المطور من قبل فريق CoreOS (نظام التشغيل)، هو متجر مفاتيح قيم موزع خفيف الوزن يمكن تكوينه ليمتد عبر عدة عقد.

يستخدم Kubernetes etcd لتخزين بيانات التكوين التي يمكن الوصول إليها من قبل كل العقد في العنقود. يمكن استخدام هذا لاكتشاف الخدمات ويمكن أن يساعد المكونات على تكوين أو إعادة تكوين أنفسها وفقًا للمعلومات الحديثة. كما يساعد في الحفاظ على حالة العنقود مع ميزات مثل انتخاب القائد والقفل الموزع. من خلال توفير واجهة برمجة تطبيقات بسيطة HTTP/JSON، فإن واجهة تعيين القيم أو استرجاعها مباشرة جدًا.

مثل معظم المكونات الأخرى في الطائرة التحكمية، يمكن تكوين etcd على خادم ماستر واحد أو، في السيناريوهات الإنتاجية، توزيعه بين عدة أجهزة. المتطلب الوحيد هو أن يكون متاحًا عبر الشبكة لكل من أجهزة Kubernetes.

خدمة kube-apiserver

واحدة من أهم خدمات الماستر هي خادم واجهة برمجة التطبيقات. هذه هي النقطة الرئيسية لإدارة العنقود بأكمله حيث تتيح للمستخدم تكوين أحمال العمل والوحدات التنظيمية في Kubernetes. كما أنه مسؤول أيضًا عن التأكد من أن متجر etcd وتفاصيل الخدمة للحاويات المنشأة متفقة. يعمل كجسر بين مكونات مختلفة للحفاظ على صحة العنقود ونشر المعلومات والأوامر.

يقوم خادم واجهة برمجة التطبيقات بتنفيذ واجهة RESTful، مما يعني أن العديد من الأدوات والمكتبات المختلفة يمكنها التواصل معه بسهولة. يتوفر عميل يسمى kubectl كطريقة افتراضية للتفاعل مع عنقود Kubernetes من جهاز كمبيوتر محلي.

خادم مدير التحكم في kube

مدير التحكم هو خدمة عامة لها العديد من المسؤوليات. في المقام الأول، يدير مدير التحكم مراقبين مختلفين ينظمون حالة العنقود، ويديرون دورات حياة الأحمال العمل، ويقومون بالمهام الروتينية. على سبيل المثال، يضمن مراقب الاستنساخ أن عدد النسخ المطابقة (النسخ المتطابقة) المحددة للقرعة يتطابق مع العدد المنشأ حاليًا على العنقود. يتم كتابة تفاصيل هذه العمليات إلى etcd، حيث يراقب مدير التحكم التغييرات من خلال خادم واجهة برمجة التطبيقات.

عند رؤية تغيير، يقرأ المتحكم المعلومات الجديدة وينفذ الإجراء الذي يحقق الحالة المرغوبة. يمكن أن يتضمن ذلك توسيع تطبيق أو تقليله، وضبط نقاط النهاية، وما إلى ذلك.

kube-scheduler

العملية التي تعين فعلاً الأعباء العمل إلى العقدة المحددة في المجموعة هي المجدول. يقوم هذا الخدمة بقراءة متطلبات تشغيل الأعباء، وتحليل بيئة البنية التحتية الحالية، ووضع العمل على عقدة أو عقدات مقبولة.

المجدول مسؤول عن تتبع السعة المتاحة على كل مضيف للتأكد من عدم جدولة الأعباء بزيادة عن الموارد المتاحة. يجب أن يعرف المجدول السعة الإجمالية بالإضافة إلى الموارد المخصصة بالفعل للأعباء الحالية على كل خادم.

cloud-controller-manager

يمكن نشر Kubernetes في العديد من البيئات المختلفة ويمكنه التفاعل مع مقدمي البنية التحتية المختلفة لفهم وإدارة حالة الموارد في المجموعة. بينما يعمل Kubernetes مع التمثيلات العامة للموارد مثل التخزين القابل للتركيب وموازنة الحمل، يحتاج إلى طريقة لتعيين هذه الموارد إلى الموارد الفعلية التي توفرها مزودات السحابة غير المتجانسة.

تعمل مديرات تحكم السحابة كاللاصق الذي يسمح لـ Kubernetes بالتفاعل مع مزودي خدمة ذوي إمكانيات وميزات وواجهات برمجة مختلفة مع الحفاظ على هياكل داخلية نسبياً عامة. يتيح هذا لـ Kubernetes تحديث معلومات حالته وفقًا للمعلومات التي يتم جمعها من مزود السحابة، وضبط موارد السحابة حسب الحاجة في النظام، وإنشاء واستخدام خدمات سحابية إضافية لتلبية متطلبات العمل المُقدمة إلى العقدة.

مكونات خادم العقدة

في Kubernetes، تُعرف الخوادم التي تقوم بأداء العمل من خلال تشغيل الحاويات باسم العقد. يتضمن خادم العقدة بعض المتطلبات الضرورية للتواصل مع مكونات الماستر، وتكوين شبكة الحاويات، وتشغيل الأعباء الفعلية المُخصصة لها.

A Container Runtime

أول مكون يجب أن يتوفر في كل عقدة هو مشغل الحاويات. عادةً ما يتم تلبية هذا المتطلب من خلال تثبيت وتشغيل Docker، ولكن هناك بدائل مثل rkt و runc متاحة أيضًا.

المحرك التشغيلي للحاوية مسؤول عن بدء وإدارة الحاويات، التطبيقات المحاصرة في بيئة تشغيلية معزولة نسبيًا ولكن خفيفة الوزن. كل وحدة عمل في العنقود، على المستوى الأساسي لها، مُنفذة على شكل حاويات واحدة أو أكثر يجب نشرها. المحرك التشغيلي للحاوية على كل عقدة هو المكون الذي يشغل في النهاية الحاويات المُعرفة في الأعباء التي تُقدم إلى العنقود.

kubelet

نقطة الاتصال الرئيسية لكل عقدة مع مجموعة العنقود هي خدمة صغيرة تسمى kubelet. هذه الخدمة مسؤولة عن إرسال المعلومات إلى ومن خدمات سيطرة الطائرة، بالإضافة إلى التفاعل مع مخزن etcd لقراءة تفاصيل التكوين أو كتابة قيم جديدة.

تتواصل خدمة kubelet مع مكونات الماستر للمصادقة على العنقودة وتلقي الأوامر والأعمال. يتم استلام العمل على شكل توضيح يعرف الأعباء ومعلمات التشغيل. يتولى عملية kubelet بعد ذلك مسؤولية الحفاظ على حالة العمل على خادم العقدة. يتحكم في المحرك التشغيلي للحاوية لبدء أو تدمير الحاويات حسب الحاجة.

kube-proxy

لإدارة تقسيم الشبكة النصفية لكل مضيف فردي وجعل الخدمات متاحة للمكونات الأخرى، يتم تشغيل خدمة وكيل صغيرة تسمى kube-proxy على كل خادم عقدة. تقوم هذه العملية بتوجيه الطلبات إلى الحاويات الصحيحة، ويمكنها أيضًا القيام بتوازن الحمل البسيط، وهي بشكل عام مسؤولة عن التأكد من أن بيئة الشبكات قابلة للتنبؤ والوصول إليها، ولكن مع عزل حيثما يكون ذلك مناسبًا.

كائنات وأعباء عمل Kubernetes

في حين أن الحاويات هي الآلية الأساسية المستخدمة لنشر التطبيقات المحاكية للحاويات، يستخدم Kubernetes طبقات إضافية من التجريد فوق واجهة الحاوية لتوفير ميزات التحجيم والصمود وإدارة دورة الحياة. بدلاً من إدارة الحاويات مباشرة، يقوم المستخدمون بتعريف الحالات والتفاعل مع النماذج الأساسية المتنوعة المقدمة من طرف نموذج الكائنات Kubernetes. سنتطرق إلى أنواع الكائنات المختلفة التي يمكن استخدامها لتعريف هذه الأعباء العاملة أدناه.

الهياكل

A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.

A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.

عادةً ما تتكون الأشباه (البودات) من حاوية رئيسية تلبي الغرض العام للعبء العملي، واختيارياً بعض الحاويات المساعدة التي تسهل المهام ذات الصلة الوثيقة. هذه برامج تستفيد من تشغيلها وإدارتها في حاوياتها الخاصة، ولكنها مرتبطة بشكل وثيق بالتطبيق الرئيسي. على سبيل المثال، قد يحتوي الأشباه على حاوية واحدة تعمل كخادم للتطبيق الرئيسي وحاوية مساعدة تقوم بسحب الملفات إلى نظام الملفات المشترك عند اكتشاف تغييرات في مستودع خارجي. يُ desالتجميع الأفقي عادة على مستوى الأشباه لأن هناك كائنات أعلى مستوى أكثر ملاءمة للمهمة.

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

متحكمات التكرار ومجموعات التكرار

في كثير من الأحيان، عند العمل مع كوبرنيتس، بدلاً من العمل مع أشباه فردية، ستقوم بإدارة مجموعات من الأشباه المتكررة المتطابقة. يتم إنشاؤها من قوالب الأشباه ويمكن توسيعها أفقيًا بواسطة متحكمات تعرف باسم متحكمات التكرار ومجموعات التكرار.

A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.

يتحمل مُتحكّم التكرار مسؤولية التأكد من مطابقة عدد القُرب المنتشرة في العقد مع عدد القُرب في تكوينه. إذا فشل قُربٌ معين أو المضيف الأساسي، سيقوم المُتحكم ببدء قُرب جديدة للتعويض. إذا تغير عدد التكرارات في تكوين مُتحكّم معين، يقوم المُتحكم إما ببدء أو قتل حاويات ليتماشى مع العدد المطلوب. يمكن لمُتحكمات التكرار أيضًا تنفيذ التحديثات التدويرية لتحويل مجموعة من القُرب إلى إصدار جديد تباعًا، مما يقلل من تأثير توافر التطبيق.

مجموعات التكرار هي تطوير لتصميم مُتحكم التكرار مع مرونة أكبر في كيفية تحديد المُتحكم للقُرب التي يُفترض أن يديرها. تبدأ مجموعات التكرار في استبدال مُتحكمات التكرار بسبب قدراتها الأكبر على اختيار التكرارات، ولكنها غير قادرة على تنفيذ التحديثات التدويرية لتحويل الخلفيات إلى إصدار جديد كما يمكن لمُتحكمات التكرار. بدلاً من ذلك، تُقصد مجموعات التكرار للاستخدام داخل وحدات إضافية وأعلى مستوى توفر تلك الوظيفة.

مثل القُرب، فإن كل من مُتحكمات التكرار ومجموعات التكرار نادرًا ما تكون الوحدات التي ستعمل معها مباشرة. بينما يعتمدون على تصميم القُرب لإضافة التوسع الأفقي وضمانات الاعتمادية، إلا أنهم يفتقرون إلى بعض إمكانيات إدارة دورة حياة الخط الدقيقة التي توجد في الكائنات المعقدة أكثر.

النشرات

النشر هي واحدة من أكثر الأعباء شيوعًا لإنشاءها وإدارتها مباشرة. تستخدم النشر مجموعات النسخ كبنية أساسية، مضيفة وظائف إدارة الدورة الحياتية المرنة إلى الخليط.

في حين قد تبدو النشرات المبنية باستخدام مجموعات النسخ مكررة للوظائف المُقدمة من قِبل مراقبي النسخ، إلا أن النشرات تحل العديد من نقاط الألم التي كانت موجودة في تنفيذ التحديثات المتداولة. عند تحديث التطبيقات باستخدام مراقبي النسخ، يُطلب من المستخدمين تقديم خطة لمراقب نسخ جديد يستبدل المراقب الحالي. عند استخدام مراقبي النسخ، المهام مثل تتبع التاريخ، والاستعادة من فشل الشبكة أثناء التحديث، والتراجع عن التغييرات السيئة إما صعبة أو تترك كمسؤولية للمستخدم.

النشرات هي كائنات عالية المستوى مصممة لتسهيل إدارة دورة حياة البواد المكررة. يمكن تعديل النشرات بسهولة عن طريق تغيير التكوين وسيقوم Kubernetes بضبط مجموعات النسخ، وإدارة الانتقالات بين إصدارات التطبيق المختلفة، والحفاظ اختياريًا على تاريخ الأحداث وإمكانيات التراجع تلقائيًا. بسبب هذه الميزات، من المحتمل أن تكون النشرات هي نوع كائن Kubernetes الذي ستتعامل معه بشكل متكرر.

مجموعات الحالة

مجموعات الحالة هي متحكمات البود المتخصصة التي توفر ضمانات الترتيب والتمييز. في الأساس، يتم استخدام هذه للحصول على مزيد من التحكم المفصل عند وجود متطلبات خاصة تتعلق بترتيب النشر، والبيانات الدائمة، أو الشبكات المستقرة. على سبيل المثال، يرتبط مجموعات الحالة غالبًا بتطبيقات تتمحور حول البيانات، مثل قواعد البيانات، التي تحتاج إلى الوصول إلى نفس الأحجام حتى إذا تم إعادة جدولتها إلى عقدة جديدة.

توفر مجموعات الحالة معرف شبكي مستقرًا عن طريق إنشاء اسم فريد مبني على الأرقام لكل بود، والذي سيستمر حتى لو كان البود بحاجة للتحرك إلى عقدة أخرى. وبالمثل، يمكن نقل أحجام التخزين الدائمة مع بود عند الحاجة إلى إعادة جدولته. تظل الأحجام قائمة حتى بعد حذف البود لمنع فقدان البيانات العرضي.

عند نشر أو تعديل الحجم، تقوم مجموعات الحالة بتنفيذ العمليات وفقًا للمعرف المرقم في اسمها. وهذا يوفر تنبؤًا وتحكمًا أكبر في ترتيب التنفيذ، مما يمكن أن يكون مفيدًا في بعض الحالات.

مجموعات الشياطين

مجموعات الشياطين هي شكل آخر متخصص من متحكمات البود التي تقوم بتشغيل نسخة من بود على كل عقدة في العنقود (أو جزء منه، إذا تم تحديده). يكون هذا الأمر مفيدًا بشكل أكبر عادة عند نشر البود التي تساعد في أداء الصيانة وتقديم الخدمات لعقد كوبرنيتيس نفسه.

على سبيل المثال، جمع وتوجيه السجلات، وتجميع المقاييس، وتشغيل الخدمات التي تزيد من قدرات العقدة ذاتها هي مرشحات شائعة لمجموعات السايدمون. نظرًا لأن مجموعات السايدمون غالبًا ما توفر خدمات أساسية وتكون مطلوبة في جميع أنحاء الأسطول، يمكنها تجاوز قيود جدولة الأقراص التي تمنع المراقبين الآخرين من تعيين الأقراص لمضيفين معينين. على سبيل المثال، بسبب مسؤولياته الفريدة، يتم تكوين خادم الماستر بشكل متكرر ليكون غير متاح لجدولة الأقراص العادية، ولكن مجموعات السايدمون لديها القدرة على تجاوز القيد على أساس القرص إلى أساس القرص للتأكد من تشغيل الخدمات الأساسية.

الوظائف والمهام المجدولة

الأعباء العملية التي وصفناها حتى الآن قد افترضت جميعها دورة حياة تشبه الخدمة طويلة الأمد. يستخدم Kubernetes عبء عمل يسمى الوظائف لتوفير سير عمل مستند إلى المهام أكثر حيث يتوقع أن تنتهي حاويات التشغيل بنجاح بعد فترة من الزمن بمجرد أن يكملوا عملهم. الوظائف مفيدة إذا كنت بحاجة إلى أداء عمل مرة واحدة أو معالجة دفعية بدلاً من تشغيل خدمة مستمرة.

بناء الوظائف هي وظائف cron. مثل السخانات التقليدية cron على أنظمة Linux ومشابهة لنظام Unix التي تنفذ النصوص بجدول زمني، توفر وظائف cron في Kubernetes واجهة لتشغيل الوظائف مع مكون جدولة. يمكن استخدام وظائف cron لجدولة وظيفة للتنفيذ في المستقبل أو بشكل منتظم ودوري. تعتبر وظائف cron في Kubernetes في الأساس إعادة تنفيذ لسلوك cron الكلاسيكي، باستخدام العنقود كمنصة بدلاً من نظام تشغيل واحد.

مكونات Kubernetes الأخرى

بعد الأحمال العمل التي يمكنك تشغيلها على عنقود، يوفر Kubernetes عددًا من التجريدات الأخرى التي تساعدك في إدارة تطبيقاتك، والتحكم في الشبكات، وتمكين الاستمرارية. سنناقش بعض الأمثلة الشائعة هنا.

خدمات Kubernetes

حتى الآن، كنا نستخدم مصطلح “الخدمة” بالمعنى التقليدي المشابه لنظام Unix: للدلالة على العمليات الجارية لفترة طويلة، المتصلة بالشبكة في كثير من الأحيان، وقادرة على الاستجابة للطلبات. ومع ذلك، في Kubernetes، تعتبر الخدمة مكونًا يعمل كموازي للتوازن الحمل الداخلي الأساسي والسفير للمجريات. تقوم الخدمة بتجميع مجموعات منطقية من المجريات التي تؤدي نفس الوظيفة لتقديمها ككيان واحد.

يتيح لك ذلك نشر خدمة يمكنها تتبع وتوجيه جميع حاويات الخلفية من نوع معين. يحتاج المستهلكون الداخليون فقط إلى معرفة النقطة النهائية الثابتة التي توفرها الخدمة. في الوقت نفسه، تسمح لك التجريد الخاص بالخدمة بتوسيع الحجم أو استبدال وحدات العمل الخلفية حسب الحاجة. يبقى عنوان IP للخدمة ثابتًا بغض النظر عن التغييرات في البودات التي يتم توجيهها إليها. من خلال نشر خدمة، يمكنك بسهولة الحصول على القابلية للكشف وتبسيط تصاميم الحاويات الخاصة بك.

في أي وقت تحتاج فيه إلى توفير الوصول إلى واحد أو أكثر من البودات لتطبيق آخر أو للمستهلكين الخارجيين، يجب عليك تكوين خدمة. على سبيل المثال، إذا كانت لديك مجموعة من البودات التي تعمل كخوادم ويب يجب أن تكون قابلة للوصول من الإنترنت، ستوفر الخدمة التجريد اللازم. وبالمثل، إذا كانت خوادم الويب الخاصة بك بحاجة إلى تخزين واسترجاع البيانات، فسترغب في تكوين خدمة داخلية لإعطائها وصولًا إلى بودات قاعدة البيانات الخاصة بك.

على الرغم من أن الخدمات، بشكل افتراضي، متاحة فقط باستخدام عنوان IP يمكن توجيهه داخليًا، إلا أنه يمكن جعلها متاحة خارج العنقود عن طريق اختيار إحدى الاستراتيجيات المتعددة. يعمل تكوين الـ NodePort عن طريق فتح منفذ ثابت على واجهة الشبكة الخارجية لكل عقدة. سيتم توجيه حركة المرور إلى المنفذ الخارجي تلقائيًا إلى البودات المناسبة باستخدام خدمة عنوان IP الداخلية للعنقود.

بدلاً من ذلك، ينشئ نوع الخدمة LoadBalancer محول حمولة خارجي لتوجيه إلى الخدمة باستخدام تكامل محمل الحمل Kubernetes لموفر السحابة. سيقوم مدير تحكم السحابة بإنشاء المورد المناسب وتكوينه باستخدام عناوين خدمة الخدمة الداخلية.

الأحجام والأحجام الدائمة

مشاركة البيانات بموثوقية وضمان توفرها بين إعادة تشغيل الحاويات تعتبر تحديًا في العديد من بيئات الحاويات. غالبًا ما توفر برامج تشغيل الحاويات آلية ما لربط التخزين بحاوية يستمر بعد نهاية عمر الحاوية، ولكن التنفيذات غالبًا ما تفتقر إلى المرونة.

للتعامل مع هذا، يستخدم Kubernetes تجريبته الخاصة بالأحجام التي تسمح بمشاركة البيانات بين جميع الحاويات داخل القروب والبقاء متاحة حتى يتم إنهاء القروب. هذا يعني أن القروبات المرتبطة بشكل وثيق يمكنها مشاركة الملفات بسهولة دون آليات خارجية معقدة. فشل الحاويات داخل القروب لن يؤثر على الوصول إلى الملفات المشتركة. بمجرد إنهاء القروب، يتم تدمير الحجم المشترك، لذلك ليس هو حلاً جيداً للبيانات الدائمة بالفعل.

الأحجام الدائمة هي آلية لتجريد التخزين الأكثر صلابة الذي لا يرتبط بدورة حياة القروب. بدلاً من ذلك، تسمح للمسؤولين بتكوين موارد التخزين للعنقود يمكن للمستخدمين طلبها والمطالبة بها للقروبات التي يقومون بتشغيلها. بمجرد الانتهاء من القروب من حجم دائم، يحدد سياسة إعادة التسخير للحجم ما إذا كان سيتم الاحتفاظ بالحجم حتى يتم حذفه يدويًا أو إزالته مع البيانات على الفور. يمكن استخدام البيانات الدائمة للحماية من فشل العقدة وتخصيص كميات أكبر من التخزين مما هو متاح محليًا.

التسميات والتعليقات

A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.

التسميات تعطى على شكل أزواج بسيطة مفتاح-قيمة. يمكن أن يحتوي كل وحدة على أكثر من تسمية واحدة، ولكن يمكن لكل وحدة أن تحتوي فقط على إدخال واحد لكل مفتاح. عادةً ما يُستخدم مفتاح “الاسم” كمُعرِّف عام، ولكن يمكنك تصنيف الكائنات بشكل إضافي حسب معايير أخرى مثل مرحلة التطوير، وإمكانية الوصول العامة، ونسخة التطبيق، إلخ.

التعليقات هي آلية مماثلة تسمح لك بإرفاق معلومات مفتاح-قيمة تعسفية بكائن. بينما يجب استخدام التسميات للمعلومات الدلالية المفيدة لمطابقة وعاء مع معايير الاختيار، فإن التعليقات أكثر حرية ويمكن أن تحتوي على بيانات أقل تنظيمًا. بشكل عام، تعد التعليقات وسيلة لإضافة بيانات الوصف الغنية إلى كائن ليست مفيدة لأغراض الاختيار.

الاستنتاج

التكنولوجيا الحديثة تحظى بالكثير من الاهتمام والتطور في الوقت الحالي. هناك العديد من المشاريع المثيرة التي تسمح للمستخدمين بتشغيل أحمال عمل محتويات الحاويات بشكل قابل للتوسع وعالي التوفر على منصة مجردة تماما. على الرغم من أن البنية التحتية والمكونات الداخلية لمشروع كوبرنيتس يمكن أن تبدو صعبة في البداية، إلا أن قوتها ومرونتها ومجموعة الميزات القوية التي توفرها لا تضاهى في عالم المصدر المفتوح ولتطوير البرامج السحابية الأصلية. من خلال فهم كيفية تركيب العناصر الأساسية معًا، يمكنك أن تبدأ في تصميم أنظمة تستغل تمامًا إمكانات المنصة لتشغيل وإدارة أحمال العمل الخاصة بك على نطاق واسع، وبناء تطبيقات سحابية أصلية مذهلة.