الحاوية إلى الناقل: CRI-O هي الآن الافتراضي في OpenShift Container Platform 4

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

كان الحل الواضح هو استخدام Red Hat Enterprise Linux CoreOS (أنواع مختلفة من Red Hat Enterprise Linux) و CRI-O كمعيار ، وإليك السبب ...

نظرًا لأن موضوع التنقل مفيد جدًا للعثور على المقارنات عند شرح عمل Kubernetes والحاويات ، فلنحاول التحدث عن مشكلات العمل التي تحلها CoreOS و CRI-O ، باستخدام مثال اختراعات برونيل لإنتاج كتل تزوير. في عام 1803 ، تم تكليف مارك برونيل بمهمة صنع 100 قطعة تزوير لتلبية احتياجات البحرية البريطانية المتنامية. كتلة تزوير هي نوع من الحفارات التي تستخدم لربط الحبال بالأشرعة. حتى بداية القرن التاسع عشر ، كانت هذه الكتل تُصنع يدويًا ، لكن برونل تمكن من أتمتة الإنتاج وبدأ في صنع كتل قياسية باستخدام أدوات آلية. تعني أتمتة هذه العملية أن النتيجة كانت أن جميع الكتل كانت متشابهة تقريبًا ، ويمكن استبدالها بسهولة في حالة حدوث عطل ، ويمكن إنتاجها بكميات كبيرة.

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

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

تم تصميم OpenShift 4 لتوفير ترقيات سهلة للنظام طوال دورة حياة النظام الأساسي (للإصدارات 4.X) لجميع موفري السحابة الرئيسيين ومنصات المحاكاة الافتراضية وحتى الأنظمة المعدنية. للقيام بذلك ، يجب إنشاء العقد على أساس العناصر القابلة للتبديل. عندما تتطلب الكتلة إصدارًا جديدًا من Kubernetes ، فإنها تحصل أيضًا على الإصدار المقابل من CRI-O على CoreOS. نظرًا لأن إصدار CRI-O مرتبط مباشرة بـ Kubernetes ، فإن هذا يبسط إلى حد كبير أي مقايضات للاختبار أو استكشاف الأخطاء وإصلاحها أو الدعم. بالإضافة إلى ذلك ، يقلل هذا الأسلوب من التكاليف للمستخدمين النهائيين وشركة Red Hat.

هذه طريقة جديدة في الأساس للنظر إلى مجموعات 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 في حالة المعاينة التقنية ومن الإصدار 3.9 في الحالة المتوفرة بشكل عام (مدعوم حاليًا). بالإضافة إلى ذلك ، تستخدم Red Hat على نطاق واسع CRI-O لتشغيل أحمال عمل الإنتاج في OpenShift Online منذ الإصدار 3.10. كل هذا سمح للفريق العامل على CRI-O باكتساب خبرة واسعة في حاويات الإطلاق الجماعي على مجموعات Kubernetes الكبيرة. للحصول على فهم أساسي لكيفية استخدام Kubernetes لـ CRI-O ، دعنا نلقي نظرة على الرسم التوضيحي التالي ، والذي يوضح كيفية عمل الهندسة المعمارية.

أرز. 2. كيف تعمل الحاويات في مجموعة Kubernetes

يبسط CRI-O إنشاء مضيفات حاوية جديدة من خلال مزامنة المستوى الأعلى بأكمله عند تهيئة العقد الجديدة ، وعندما يتم إصدار إصدارات جديدة من النظام الأساسي OpenShift. تسمح مراجعة النظام الأساسي بالكامل بتحديثات المعاملات / التراجع ، كما تمنع حدوث حالات توقف تام في التبعيات بين قلب ذيل الحاوية ومحرك الحاوية والعقد (Kubelets) وعقدة Kubernetes Master. من خلال الإدارة المركزية لجميع مكونات النظام الأساسي ، مع تعيين الإصدار والتحكم ، يمكنك دائمًا تتبع مسار واضح من الحالة "أ" إلى الحالة "ب". هذا يبسط عملية الترقية ، ويحسن الأمان ، ويحسن تقارير الأداء ، ويساعد على تقليل تكلفة الترقيات والإصدارات الجديدة.

إظهار قوة العناصر القابلة للتبديل

كما ذكرنا سابقًا ، يوفر استخدام مشغل تكوين الجهاز لإدارة مضيف الحاوية ومحرك الحاوية في 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 API. تذكر أن 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.

المصدر: www.habr.com