كوبيرنيتيس

إدارة كائنات كوبيرنيتيس

كذلك، يوفر كوبيرنيتيس بعض الآليات التي تسمح للمرء بإدارة كائناته أو تحديدها أو معالجتها.

عقدة كوبيرنيتيس

من جانب آخر، Kube-proxy: Kube-proxy هو تطبيق لبروكسي الشبكة وموازن التحميل، وهو يدعم تجريد الخدمة إلى جانب تشغيل الشبكات الأخرى. وهي مسؤولة عن توجيه حركة المرور إلى الحاوية المناسبة بناءً على عنوان IP ورقم المنفذ للطلب الوارد.

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

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

إضافةً إلى ذلك، تعد Node ، المعروفة كذلك باسم Worker أو Minion ، عبارة عن آلة يتم نشر حاويات بها (أعباء العمل). كل عقدة في الكتلة يجب تشغيل حاوية وقت التشغيل مثل عامل الميناء، فضلا عن المكونات المذكورة أدناه، للتواصل مع الابتدائي لتكوين شبكة من هذه الحاويات.

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

مساحات

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

كائنات كوبيرنيتيس

كذلك، يعرّف كوبيرنيتيس مجموعة من الكتل البرمجية الإنشائية («البدائية»)، والتي توفر مجتمعة الآليات التي تنشر وتحافظ على نطاق التطبيقات على أساس وحدة المعالجة المركزية والذاكرة أو المقاييس المخصصة. كوبيرنيتيس مقترن بشكل فضفاض وقابل للامتداد لتلبية أعباء العمل المختلفة. يتم توفير هذه القابلية للتوسعة في جزء كبير منها بواسطة كوبيرنيتيس API ، والذي يستعمل من قبل المكونات الداخلية وكذلك الامتدادات والحاويات التي تعمل على كوبيرنيتيس. يمارس النظام الأساسي سيطرته على موارد الحوسبة والتخزين عن طريق تحديد الموارد على أنها كائنات، والتي يمكن إدارتها على هذا النحو. الكائنات الرئيسية هي:

هندسة

في هذا الإطار، إدارة وحدة التحكم هي عملية تدير وحدات تحكم كوبيرنيتيس الأساسية مثل DaemonSet Controller و Replication Controller. تتصل وحدات التحكم بخادم واجهة برمجة التطبيقات لإنشاء وتحديث وحذف الموارد التي تديرها (السنفات ونقاط نهاية الخدمة، إلخ)).

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

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

من جانب آخر، etcd: etcd عبارة عن مخزن بيانات مستمر وخفيف الوزن وموزع وذات قيمة كبيرة تم تطويره بواسطة CoreOS ويقوم بتخزين بيانات التكوين الخاصة بالكتلة بشكل موثوق، وهو ما يمثل الحالة الكلية للمجموعة في أي نقطة زمنية محددة. تمامًا مثل Apache ZooKeeper ، etcd هو نظام يدعم الاتساق على التوفر في حالة وجود قسم للشبكة (انظر نظرية CAP). هذا الاتساق أمر بالغ الأهمية لجدولة وخدمات التشغيل بشكل صحيح. يستعمل كوبيرنيتيس API Server واجهة برمجة التطبيقات الخاصة بمراقبة etcd لمراقبة الكتلة وطرح تغييرات التكوين المهمة أو ببساطة استعادة أي اختلافات في حالة الكتلة، والعودة إلى ما تم إعلانه من قبل الناشر. مثلًا، إذا حدد الناشر أن هناك ثلاث حالات لقرنة معينة يجب تشغيلها، يتم تخزين هذه الحقيقة في etcd. إذا تبين أن حالتين فقط قيد التشغيل، سيتم الكشف عن هذه الدلتا مقارنة ببيانات الخ، وسوف تستعمل كوبيرنيتيس هذا لجدولة إنشاء مثيل إضافي من هذا الملف.

ومن جهة أخرى، خادم API: يعد خادم API مكونًا رئيسيًا ويخدم واجهة برمجة تطبيقات كوبيرنيتيس باستخدام JSON عبر HTTP ، والذي يوفر كلاً من الواجهة الداخلية والخارجية لـ كوبيرنيتيس. يقوم خادم API بمعالجة والتحقق من طلبات REST وتحديث حالة كائنات API في etcd ، وبالتالي السماح للعملاء بتكوين عبء العمل والحاويات عبر عقد Worker.

طائرة التحكم كوبيرنيتيس (الابتدائي)

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

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

القرون

كذلك، يتم تعيين عنوان Pod Pod فريد لكل كتلة في كوبيرنيتيس داخل المجموعة، مما يسمح للتطبيقات باستخدام المنافذ دون التعرض لخطر التعارض. داخل الحاوية، يمكن لجميع الحاويات أن تشير إلى بعضها البعض على المضيف المحلي، ولكن الحاوية داخل الحافظة لا تملك أي وسيلة للتعامل مباشرة مع حاوية أخرى داخل حافظة أخرى؛ لذلك، يجب عليه استخدام عنوان IP Pod. يجب على مطور التطبيق ألا يستعمل عنوان بروتوكول الإنترنت (Pod IP) أبدًا للإشارة إلى / استدعاء قدرة في جراب آخر، لأن عناوين بروتوكول الإنترنت (بروتوكول الإنترنت) هي سريعة الزوال - قد يتم تعيين جراب معين يشيرون إليه إلى عنوان IP آخر لجهاز iPod عند إعادة التشغيل. بدلاً من ذلك، يجب عليهم استخدام إشارة إلى الخدمة، التي تحتوي على إشارة إلى جراب الهدف على عنوان IP Pod.

من جانب آخر، وحدة الجدولة الأساسية في كوبيرنيتيس هي جراب. ويضيف مستوى أعلى من التجريد من خلال تجميع المكونات في حاويات. يتكون الجراب من حاوية واحدة أو أكثر مضمونة أن تكون موجودة في الجهاز المضيف ويمكنها مشاركة الموارد.

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

خدمات

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

إضافات

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

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

وعلى صعيد آخر، DNS: يجب أن يكون لدى كافة مجموعات كوبيرنيتيس DNS الكتلة؛ إنها ميزة إلزامية. Cluster DNS هو خادم DNS ، إلى جانب خادم (خوادم) DNS الأخرى في بيئتك، والذي يقدم سجلات DNS لخدمات كوبيرنيتيس. تتضمن الحاويات التي بدأتها كوبيرنيتيس خادم DNS هذا تلقائيًا في عمليات البحث عن DNS الخاصة بهم.

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

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

الخدمات المصغرة

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

• انظر كذلك
• جنكينز
• المراجع

التسميات والمحددات

وفي هذا السياق، مثلًا، إذا كانت القرون الخاصة بالتطبيق تحتوي على تسميات tier نظام (مع قيم مثل front-end back-end ، مثلًا) و release_track (مع قيم مثل canary production مثلًا)، ثم عملية على الكل يمكن للعقد back-end canary استخدام محدد التسمية، مثل: tier=back-end AND release_track=canary

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

محددات المجال

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

أحجام

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