تتيح لك
منصة Red Hat OpenShift Container Platform 4 إمكانية إنشاء
مضيفين لنشر الحاويات ، بما في ذلك في البنية التحتية لموفري الخدمات السحابية ، أو على منصات المحاكاة الافتراضية أو في الأنظمة المعدنية المجردة. لإنشاء منصة سحابة بالمعنى الكامل ، اضطررنا للسيطرة الصارمة على جميع العناصر المستخدمة وبالتالي زيادة موثوقية عملية التشغيل الآلي المعقدة.
كان الحل الواضح هو استخدام Red Hat Enterprise Linux CoreOS (بصيغة مختلفة من Red Hat Enterprise Linux) و CRI-O كمعيار ، وهنا ...
نظرًا لأن موضوع التنقل ناجح جدًا في العثور على أوجه التشابه في شرح تشغيل Kubernetes والحاويات ، فلنحاول التحدث عن مشكلات الأعمال التي حلها CoreOS و CRI-O ، باستخدام مثال
اختراع Brunel لإنتاج كتل تزوير . في عام 1803 ، تم تكليف مارك برونيل بتصنيع 100000 قطعة تزوير لتلبية احتياجات البحرية البريطانية المتنامية. كتلة الرفع هي نوع من الحفارات التي تستخدم لربط الحبال بالأشرعة. حتى بداية القرن التاسع عشر ، كانت هذه الكتل تصنع يدويًا ، لكن برونيل كان قادرًا على أتمتة الإنتاج وبدأ في إنتاج كتل قياسية باستخدام الآلات. يعني أتمتة هذه العملية أنه نتيجة لذلك ، كانت جميع الكتل متماثلة تقريبًا ، ويمكن استبدالها بسهولة في حالة حدوث عطل ، ويمكن تصنيعها بكميات كبيرة.
الآن تخيل أنه سيتعين على برونيل القيام بهذا العمل من أجل 20 نموذجًا مختلفًا للسفن (إصدارات Kubernetes) وخمسة كواكب مختلفة ذات تيارات بحرية ورياح مختلفة تمامًا (مزودي السحابة). بالإضافة إلى ذلك ، كان مطلوبًا أن تتصرف جميع السفن (مجموعات OpenShift) ، بغض النظر عن الكواكب التي يتم التنقل فيها ، بشكل مماثل من وجهة نظر النقباء (المشغلين الذين يتحكمون في تشغيل المجموعات). استمرارًا للتشبيه البحري ، لا يهم قباطنة السفينة مطلقًا أنواع كتل التزوير (CRI-O) المستخدمة في سفنهم - الشيء الرئيسي بالنسبة لهم هو أن هذه الكتل قوية وموثوقة.
OpenShift 4 ، كمنصة سحابية ، يواجه تحديًا تجاريًا مشابهًا للغاية. يجب إنشاء العقد الجديدة في وقت إنشاء الكتلة ، في حالة حدوث فشل في إحدى العقد ، أو عند تغيير حجم الكتلة. عند إنشاء عقدة جديدة وتهيئتها ، يجب تكوين مكونات المضيف المهمة ، بما في ذلك CRI-O ، وفقًا لذلك. كما هو الحال في أي إنتاج آخر ، يجب توفير "المواد الخام" في البداية. في حالة السفن ، تعمل المعادن والخشب كمواد خام. ومع ذلك ، إذا قمت بإنشاء مضيف لنشر حاويات في كتلة OpenShift 4 ، يجب أن يكون لديك ملفات التكوين وخوادم واجهة برمجة التطبيقات متوفرة عند الإدخال. بعد ذلك ، ستوفر OpenShift المستوى اللازم من الأتمتة طوال دورة الحياة بأكملها ، وتقدم الدعم اللازم للمنتج للمستخدمين النهائيين وبالتالي دفع الاستثمارات في المنصة.
تم إنشاء OpenShift 4 بطريقة توفر القدرة على تحديث النظام بشكل مريح طوال دورة حياة المنصة (للإصدارات 4.X) لجميع الموردين الرئيسيين للحوسبة السحابية ومنصات المحاكاة الافتراضية وحتى الأنظمة المعدنية المجردة. لهذا ، يجب إنشاء العقد على أساس عناصر قابلة للتبديل. عندما تتطلب الكتلة إصدارًا جديدًا من Kubernetes ، فإنها تتلقى أيضًا إصدار CRI-O المقابل على CoreOS. نظرًا لأن إصدار CRI-O مرتبط مباشرة بـ Kubernetes ، كل هذا يبسط إلى حد كبير أي تباينات للاختبار أو استكشاف الأخطاء وإصلاحها أو الدعم. بالإضافة إلى ذلك ، هذا النهج يقلل من تكاليف المستخدمين النهائيين وريد هات.
هذه نظرة جديدة بشكل أساسي على مجموعات Kubernetes ، والتي تضع الأساس للتخطيط لميزات جديدة مفيدة للغاية وجذابة. CRI-O (مشروع حاوية مفتوحة حاوية واجهة وقت التشغيل - مبادرة حاوية مفتوحة ، اختصار CRI-OCI) كان الخيار الأكثر نجاحاً لإنشاء جماعي للعقد ، وهو أمر ضروري للعمل مع OpenShift. سيحل CRI-O محل محرك Docker المستخدم سابقًا ، ويوفر لمستخدمي OpenShift محركًا للحاويات مملًا
اقتصاديًا ومستقرًا وبسيطًا ومملًا - نعم ، سمعت ذلك بشكل صحيح - مصمم خصيصًا للعمل مع Kubernetes.
عالم الحاويات المفتوحة
العالم منذ فترة طويلة تتحرك نحو الحاويات المفتوحة. سواء في Kubernetes أو في المستويات الأدنى ، فإن
تطوير معايير الحاويات يؤدي إلى نظام بيئي للابتكار على كل مستوى.
بدأ كل شيء مع إنشاء مبادرة الحاويات المفتوحة
في يونيو 2015 . في هذه المرحلة المبكرة من العمل ، تم تشكيل مواصفات
لصورة الحاوية
(الصورة) ووقت التشغيل . وقد جعل ذلك من الممكن ضمان أن الأدوات يمكن أن تستخدم معيارًا واحدًا
لصور الحاوية وتنسيقًا واحدًا للتعامل معها. تمت إضافة مواصفات
التوزيع لاحقًا ، مما سمح للمستخدمين بتبادل
صور الحاوية بسهولة.
ثم طور مجتمع Kubernetes معيارًا وحيدًا قابلاً للتوصيل يسمى
واجهة حاوية وقت التشغيل (CRI) . بفضل هذا ، تمكن مستخدمو Kubernetes من توصيل مختلف المحركات للعمل مع الحاويات بالإضافة إلى Docker.
رأى مهندسو Red Hat و Google طلبًا في السوق على محرك حاويات يمكنه قبول طلبات من Kubelet باستخدام بروتوكول CRI وقدم حاويات متوافقة مع مواصفات OCI المذكورة أعلاه. لذلك
كان هناك OCID . ولكن عفوا ، لأننا قلنا أن هذه المواد ستخصص ل CRI-O؟ في الواقع ، إنه بمجرد إصدار
الإصدار 1.0 ، تمت إعادة تسمية المشروع باسم CRI-O.
التين. 1.الابتكار مع CRI-O و CoreOS
مع إطلاق النظام الأساسي OpenShift 4 ، تم تغيير
محرك الحاوية المستخدم في النظام الأساسي الافتراضي ، وتم استبدال Docker بـ CRI-O ، مما أتاح بيئة إطلاق حاوية اقتصادية وثابتة ومملة ومملة تتطور بالتوازي مع Kubernetes. هذا يبسط إلى حد كبير دعم الكتلة والتكوين. يصبح تكوين محرك الحاوية والمضيف ، وكذلك إدارتها ، تلقائيًا في OpenShift 4.
توقف ، كيف يتم ذلك؟
هذا صحيح ، مع ظهور OpenShift 4 ، لم تعد هناك حاجة الآن للاتصال بالمضيفين الفرديين وتثبيت محرك حاوية ، أو تكوين التخزين ، أو تهيئة الخوادم للبحث ، أو تكوين شبكة. تم إعادة تصميم النظام الأساسي OpenShift 4 بالكامل لاستخدام
إطار المشغل ليس فقط فيما يتعلق بتطبيقات المستخدم النهائي ، ولكن أيضًا من حيث العمليات الأساسية على مستوى النظام الأساسي ، مثل نشر الصور أو تكوين النظام أو تثبيت التحديثات.
سمحت Kubernetes دائمًا للمستخدمين بإدارة التطبيقات من خلال تحديد الحالة المطلوبة واستخدام
وحدات التحكم للتأكد من أن الحالة الفعلية قريبة قدر الإمكان من الحالة المحددة. هذا
النهج باستخدام حالة معينة والحالة الفعلية يفتح فرصا كبيرة من وجهة نظر التنمية ومن وجهة نظر العمليات. يمكن للمطورين تحديد الحالة المطلوبة ،
ونقلها إلى المشغل في شكل ملف YAML أو JSON ، ومن ثم يمكن للمشغل إنشاء مثيل التطبيق الضروري في بيئة التشغيل ، في حين أن حالة التشغيل الخاصة بهذا المثيل سوف تتوافق تمامًا مع الحالة المحددة.
باستخدام عوامل التشغيل في النظام الأساسي ، يقدم OpenShift 4 هذا النموذج الجديد (باستخدام مفهوم المجموعة والحالة الفعلية) لإدارة RHEL CoreOS و CRI-O. تتم مهام تكوين وتعيين نظام التشغيل ومحرك الحاوية تلقائيًا باستخدام ما يسمى
مشغل تهيئة
الماكينة (MCO) . تعمل ميزة MCO على تبسيط عمل مسؤول الكتلة بشكل كبير ، وذلك من خلال أتمتة المراحل الأخيرة من التثبيت ، بالإضافة إلى العمليات اللاحقة بعد التثبيت (عمليات اليوم الثاني). كل هذا يجعل OpenShift 4 منصة سحابة حقيقية. سوف نتطرق إلى ذلك لاحقًا.
إطلاق الحاويات
أتيحت للمستخدمين الفرصة لاستخدام محرك CRI-O في منصة OpenShift بدءًا من الإصدار 3.7 في حالة Tech Preview ومن الإصدار 3.9 في حالة المتوفر بشكل عام (مدعوم حاليًا). بالإضافة إلى ذلك ، تستخدم Red Hat بشكل
مكثف CRI-O لإطلاق أعباء العمل على الإنتاج في OpenShift Online منذ الإصدار 3.10. كل هذا سمح للفريق الذي يعمل على CRI-O لاكتساب خبرة واسعة في الإطلاق الشامل للحاويات على مجموعات Kubernetes الكبيرة. للحصول على فهم أساسي لكيفية استخدام Kubernetes لـ CRI-O ، دعونا نلقي نظرة على الرسم التوضيحي التالي ، والذي يوضح كيفية عمل الهيكل.
التين. 2. كيف تعمل الحاويات في مجموعة Kubernetesيبسط CRI-O إنشاء مضيفات حاويات جديدة عن طريق مزامنة المستوى العلوي بأكمله عند تهيئة العقد الجديدة ، وعند إطلاق إصدارات جديدة من نظام OpenShift. يسمح تدقيق النظام الأساسي بأكمله بالتحديثات / الاستعادة للمعاملات ، ويمنع أيضًا الجمود في التبعيات بين نواة حاوية الذيل ومحرك الحاوية و Kubelets و Kubernetes Master. من خلال الإدارة المركزية لجميع مكونات النظام الأساسي ، مع التحكم في الإصدار وإدارته ، يمكنك دائمًا تتبع مسار واضح من الحالة "أ" إلى الحالة "ب". يعمل ذلك على تبسيط عملية التحديث وتحسين الأمان وتحسين تقارير الأداء والمساعدة في تقليل تكلفة تحديث الإصدارات الجديدة وتثبيتها.
مظاهرة قوة العناصر القابلة للتبديل
كما ذكرنا سابقًا ، فإن استخدام Machine Config Operator لإدارة مضيف الحاوية ومحرك الحاوية في OpenShift 4 يوفر مستوى جديدًا من الأتمتة التي لم تكن ممكنة على نظام Kubernetes من قبل. لإظهار الميزات الجديدة ، نعرض كيف يمكنك إجراء تغييرات على ملف crio.conf. من أجل عدم الخلط في المصطلحات ، حاول التركيز على النتائج.
أولاً ، دعنا ننشئ ما يسمى بتكوين وقت تشغيل الحاوية - تكوين وقت تشغيل الحاوية. النظر في هذا مورد Kubernetes الذي يمثل التكوين ل CRI-O. في الواقع ، هذه هي نسخة متخصصة لما يسمى MachineConfig ، وهو أي تكوين يتم نشره على جهاز RHEL CoreOS داخل نظام OpenShift.
تم اختراع هذا المورد المخصص ، الذي يسمى ContainerRuntimeConfig ، لتسهيل لمسؤولي نظام المجموعة تكوين CRI-O. هذه أداة قوية بما فيه الكفاية بحيث لا يمكن تطبيقها إلا على بعض العقد حسب إعدادات MachineConfigPool. النظر في هذه المجموعة من الآلات التي تخدم نفس الغرض.
انتبه إلى آخر سطرين سنقوم بتغييرهما في ملف /etc/crio/crio.conf. يشبه هذان الخطان الأسطر الموجودة في ملف crio.conf ، وهما:
vi ContainerRuntimeConfig.yaml
الاستنتاج:
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: set-log-and-pid spec: machineConfigPoolSelector: matchLabels: debug-crio: config-log-and-pid containerRuntimeConfig: pidsLimit: 2048 logLevel: debug
أرسل الآن هذا الملف إلى نظام Kubernetes وتحقق من إنشائه بالفعل. يرجى ملاحظة أن العملية تتم بنفس الطريقة المتبعة مع أي مورد Kubernetes آخر:
oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig
الاستنتاج:
NAME AGE set-log-and-pid 22h
بعد أن أنشأنا ContainerRuntimeConfig ، نحتاج إلى تعديل أحد MachineConfigPools لجعل Kubernetes يفهم أننا نريد تطبيق هذا التكوين على مجموعة محددة من الأجهزة في الكتلة. في هذه الحالة ، سوف نقوم بتغيير MachineConfigPool للعُقد الرئيسية:
oc edit MachineConfigPool/master
الخلاصة (للوضوح ، النقطة الرئيسية هي اليسار):
... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ...
عند هذه النقطة ، يبدأ MCO في إنشاء ملف crio.conf جديد للكتلة. في هذه الحالة ، يمكن عرض ملف التكوين الكامل باستخدام واجهة برمجة تطبيقات Kubernetes. تذكر ، ContainerRuntimeConfig هو مجرد نسخة متخصصة من MachineConfig ، لذلك يمكننا أن نرى النتيجة من خلال النظر إلى الخطوط في MachineConfigs:
oc get MachineConfigs | grep rendered
الاستنتاج:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
يرجى ملاحظة أن ملف التكوين الناتج للعقد الرئيسية تحول إلى إصدار أحدث من التكوينات الأصلية. لمشاهدته ، قم بتشغيل الأمر التالي. بشكل عابر ، نلاحظ أن هذا ربما يكون أحد أفضل البرامج النصية أحادية الخط في تاريخ Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
الاستنتاج:
pids_limit = 2048
تأكد الآن من تطبيق التكوين على جميع العقد الرئيسية. أولاً نحصل على قائمة العقد في الكتلة:
oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
الآن انظر إلى الملف المثبت. سترى أنه قد تم تحديث الملف بتوجيهات pid و debug الجديدة التي حددناها في مورد ContainerRuntimeConfig. الأناقة نفسها:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid'
الاستنتاج:
... pids_limit = 2048 ... log_level = "debug" ...
تم إجراء كل هذه التغييرات في المجموعة حتى بدون بدء SSH. تم إنجاز كل العمل من خلال الاتصال بالعقدة الرئيسية Kuberentes. وهذا هو ، تم تكوين هذه المعلمات الجديدة فقط على العقد الرئيسية. في الوقت نفسه ، لم تتغير العقد العاملة ، مما يدل على مزايا منهجية Kubernetes باستخدام مجموعة والحالات الحالية كما هو مطبق على مضيفي الحاويات ومحركات الحاويات مع عناصر قابلة للتبديل.
يوضح المثال أعلاه القدرة على إجراء تغييرات على مجموعة OpenShift Container Platform 4 صغيرة مع ثلاث عقد عمل أو إلى مجموعة إنتاج ضخمة بها 3000 عقدة. في أي حال ، سيكون مقدار العمل هو نفسه - وصغير جدًا - فقط قم بتكوين ملف ContainerRuntimeConfig ، وقم بتغيير تسمية واحدة في MachineConfigPool. ويمكنك القيام بذلك مع أي إصدار من منصة OpenShift Container Platform 4.X التي تستخدمها Kubernetes طوال دورة حياتها.
غالبًا ما تتطور شركات التكنولوجيا سريعًا لدرجة أننا لا نستطيع شرح سبب اختيارنا لبعض التقنيات للمكونات الأساسية. تاريخياً ، كانت محركات الحاويات هي العنصر الذي يتفاعل معه المستخدمون بشكل مباشر. منذ أن بدأت شعبية الحاويات بشكل طبيعي مع ظهور محركات الحاويات ، غالبًا ما يبدي المستخدمون اهتمامًا بها. هذا سبب آخر لاختيار Red Hat لـ CRI-O. تتطور الحاويات ، مع التركيز على تزامن اليوم ، وقد توصلنا إلى أن CRI-O توفر أفضل تجربة عند العمل مع OpenShift 4.