ملاحظة perev. : لقد كتبنا بالفعل أكثر من منشور واحد (انظر الروابط في نهاية المقالة) حول أوقات تشغيل الحاويات (أوقات تشغيل الحاويات) - كقاعدة ، تتم مناقشتها في سياق Kubernetes. ومع ذلك ، غالبًا ما أثارت هذه المواد أسئلة القراء ، مما يشير إلى عدم فهم من أين أتى المشروع التالي ، وكيف يرتبط بالآخرين وما يحدث بشكل عام في "حديقة الحيوانات" هذه الحاوية بأكملها.
يقدم مقال نشره مؤخرًا Phil Estes ، المدير الفني للحاوية والعمارة في Linux Watson & Cloud Platform لنظام التشغيل Linux ، نظرة استرجاعية ممتازة حول كيفية التنقل واكتساب فهم أوسع لمن فقد (أو لم يسبق له مثيل) سلسلة الأحداث. كونه أحد المشرفين على Moby ومشاريع الحاويات ، وعضو في اللجان الفنية لمبادرة الحاويات المفتوحة (OCI) و Moby ، ولديه أيضًا وضع Docker Captain ، يكتب المؤلف عن الماضي والحاضر والمستقبل للعالم الجديد الرائع لأوقات تشغيل الحاويات. ولأكثر الكسل ، تبدأ المادة بـ TL مضغوط ؛ DR حول الموضوع ... النتائج الرئيسية
- مع مرور الوقت ، نما الاختيار بين أوقات تشغيل الحاويات ، مما يوفر خيارات أكثر من محرك Docker الشهير.
- نجحت مبادرة الحاويات المفتوحة (OCI) في توحيد مفهوم صورة الحاوية وصورة الحاوية من أجل ضمان قابلية التشغيل البيني ("قابلية التشغيل البيني" - ترجمة تقريبًا) بين بيئات وقت التشغيل.
- أضافت Kubernetes واجهة حاوية وقت التشغيل (CRI) ، والتي تسمح للحاويات بالاتصال ببيئات وقت التشغيل مع طبقة التنسيق الأساسية في K8s.
- تتيح الابتكارات في هذا المجال للحاويات الاستفادة من المحاكاة الافتراضية خفيفة الوزن وتقنيات العزل الفريدة الأخرى لمتطلبات الأمان المتزايدة.
- مع OCI و CRI ، أصبحت إمكانية التشغيل البيني والاختيار حقيقة في النظام البيئي لبيئات وقت التشغيل وحاويات التنسيق.
لقد كانت تكنولوجيا الحاوية موجودة منذ فترة طويلة في عالم نظام التشغيل Linux - ظهرت الأفكار الأولى حول مساحات أسماء منفصلة لأنظمة الملفات والعمليات منذ أكثر من عقد من الزمان. وفي الماضي القريب نسبيًا ، ظهر LXC وأصبح الطريقة القياسية لمستخدمي Linux للتفاعل مع تقنية العزل القوية المخفية في نواة Linux.
ومع ذلك ، على الرغم
من محاولات
LXC لإخفاء تعقيد الجمع بين "الدواخل" التكنولوجية المختلفة لما نسميه عادة حاوية اليوم ، ظلت الحاويات نوعًا من السحر وأصبحت أقوى فقط في عالم ذوي المعرفة الخاصة ، ولم تنتشر على نطاق واسع بين الجماهير.
تغير كل شيء في عام 2014 مع
Docker ، عندما ظهر غلاف جديد
وصديق للمطورين لنفس تقنية نواة Linux التي كانت LXC في الخدمة - بعد كل شيء ، استخدمت الإصدارات المبكرة من Docker "من وراء الكواليس" LXC ، وأصبحت الحاويات - ظاهرة كتلة حقيقية ، حيث أن المطورين كانوا مشبعين ببساطة وإمكانيات إعادة استخدام صور حاوية Docker والأوامر البسيطة للعمل معهم.
بالطبع ، لم يكن Docker هو الشخص الوحيد الذي أراد الحصول على حصة في سوق الحاويات عندما لم يكن الضجيج الذي رافقهم يفكر في الهدوء بعد أول اهتمام متفجر في عام 2014. على مر السنين ، ظهرت مجموعة متنوعة من الأفكار البديلة لبيئات الحاويات القابلة للتنفيذ من
CoreOS (rkt) و
Intel Clear Containers و
hyper.sh (خفيفة الوزن الافتراضية المستندة إلى الحاوية) ، بالإضافة إلى
التفرد والتغيير في عالم أبحاث الحوسبة عالية الأداء (HPC).
استمر السوق في النمو والنضج ، ومع
مبادرة الحاوية المفتوحة (OCI) جاءت الجهود لتوحيد الأفكار الأولية التي يروج لها Docker. اليوم ، العديد من بيئات الحاويات القابلة للتنفيذ إما متوافقة بالفعل مع OCI ، أو في طريقها إلى ذلك ، مما يوفر للمصنعين ظروفًا متساوية للترويج لميزاتهم وقدراتهم التي تركز على تطبيق معين.
شعبية Kubernetes
كانت المرحلة التالية في تطور الحاويات هي الجمع بين حاويات الحوسبة الموزعة والخدمات الدقيقة مع الحاويات - وكل هذا في العالم الجديد للتطور السريع وتكرار النشر (يمكننا القول أن DevOps) ، الذي كان يكتسب زخمًا نشطًا جنبًا إلى جنب مع شعبية Docker.
على الرغم من وجود
Apache Mesos ومنصات تنسيق البرامج الأخرى قبل سيطرة
Kubernetes ، فقد
انطلقت K8s بسرعة من مشروع صغير مفتوح المصدر من Google إلى المشروع الرئيسي
للحوسبة السحابية الأصلية (CNCF) .
ملاحظة perev. : هل تعلم أن CNCF ظهرت في عام 2015 بمناسبة إصدار Kubernetes 1.0؟ في الوقت نفسه ، نقلت Google المشروع إلى منظمة مستقلة جديدة أصبحت جزءًا من مؤسسة Linux.
حدث إطلاق K8s 1.0 برعاية جهات أخرى مثل Mesosphere و CoreOS و Mirantis و OpenStack و Bitnami
من الأخبار حول إصدار Kubernetes 1.0 على ZDNetحتى بعد أن قامت شركة Docker بإطلاق منصة
التناغم المنافس ،
Swarm ، والمدمجة في Docker وتتميز ببساطة Docker والتركيز على تكوين المجموعة الآمنة الافتراضية ، لم يعد هذا كافيًا لكبح الاهتمام المتزايد بـ Kubernetes.
ومع ذلك ، تم الخلط بين العديد من أصحاب المصلحة خارج المجتمعات السحابية الأصلية سريعة النمو. لم يتمكن مراقب عادي من معرفة ما يحدث: Kubernetes يقاتلون مع Docker أو تعاونهم؟ نظرًا لأن Kubernetes كانت مجرد منصة تنسيق ، فقد كانت هناك حاجة إلى بيئة حاوية قابلة للتنفيذ من شأنها إطلاق الحاويات المنسقة مباشرة في Kubernetes. منذ البداية ، استخدمت Kubernetes محرك Docker ، وعلى الرغم من التوتر التنافسي بين Swarm و Kubernetes ، كان Docker لا يزال وقت التشغيل الافتراضي وكان مطلوبًا لكي تعمل مجموعة Kubernetes.
مع وجود عدد قليل من أوقات تشغيل الحاويات بخلاف Docker ، بدا واضحًا أن إقران وقت التشغيل مع Kubernetes يتطلب واجهة مكتوبة خصيصًا - shim - لكل وقت تشغيل. جعل عدم وجود واجهة واضحة لتنفيذ أوقات تشغيل الحاوية من الصعب جدًا إضافة دعم لأوقات التشغيل الجديدة في Kubernetes.
واجهة وقت تشغيل الحاوية (CRI)
لحل التعقيد المتزايد لتنفيذ أوقات التشغيل في Kubernetes ، حدد المجتمع وظائف خاصة بالواجهة يجب أن يقوم وقت تشغيل الحاوية بتنفيذها داخل Kubernetes - تسميتها
واجهة وقت تشغيل الحاوية (CRI) ( ظهرت في Kubernetes 1.5 - ترجمة تقريبًا.) . لم يساعد هذا الحدث فقط مشكلة العدد المتزايد من أجزاء قاعدة كود Kubernetes التي تؤثر على استخدام أوقات تشغيل الحاوية ، ولكنه ساعد أيضًا على فهم الوظائف التي يجب أن تدعمها أوقات التشغيل المحتملة إذا كانوا يريدون الامتثال لـ CRI.
كما قد تتوقع ، تتوقع CRI أشياء بسيطة جدًا من وقت التشغيل. يجب أن تكون مثل هذه البيئة قادرة على بدء وإيقاف القرون ، والتعامل مع جميع العمليات مع الحاويات في سياق القرون (بدء ، توقف ، إيقاف مؤقت ، قتل ، حذف) ، وكذلك دعم إدارة صور الحاوية باستخدام التسجيل. هناك أيضًا وظائف مساعدة لجمع السجلات والمقاييس وما إلى ذلك.
عندما تظهر ميزات جديدة في Kubernetes ، إذا كانت تعتمد على طبقة وقت تشغيل الحاوية ، يتم إجراء هذه التغييرات على واجهة برمجة تطبيقات CRI ذات الإصدار. وهذا بدوره يخلق اعتمادًا وظيفيًا جديدًا على Kubernetes ويتطلب إصدار إصدارات أحدث من أوقات التشغيل التي تدعم الميزات الجديدة (أحد الأمثلة الأخيرة هو مساحات أسماء المستخدمين).
منظر CRI الحالي
اعتبارًا من 2018 ، هناك العديد من الخيارات للاستخدام كأوقات تشغيل للحاويات في Kubernetes. كما هو موضح في الرسم التوضيحي أدناه ، لا يزال Docker مع
dockershim أحد الخيارات الحقيقية التي تنفذ واجهة برمجة تطبيقات CRI. وفي الواقع ، في معظم منشآت Kubernetes اليوم ، هو ، Docker ، الذي يبقى وقت التشغيل الافتراضي.
كانت إحدى النتائج المثيرة للاهتمام للتوتر بين استراتيجية تنظيم Docker مع Swarm ومجتمع Kubernetes هي مشروع مشترك ، أخذ أساس وقت التشغيل من Docker وجمع منه مشروع مفتوح المصدر جديد تم تطويره بشكل مشترك -
الحاوية . بمرور الوقت ، تم نقل الحاوية إلى CNCF ، وهي نفس المنظمة التي تدير وتملك مشروع Kubernetes.
( ملاحظة ترجمة : وصفنا مظهر الحاوية بمزيد من التفصيل في مقالة منفصلة .)
من الإعلان عن الحاوية على مدونة Dockerكونتيند ، كونه تطبيقًا بسيطًا وأساسيًا ومستندًا إلى الشركة (غير معني
) لوقت التشغيل لكل من Docker و Kubernetes (عبر CRI) ، بدأ في اكتساب شعبية كبديل محتمل لـ Docker في العديد من منشآت Kubernetes. حتى الآن ، يحتوي كل من IBM Cloud و Google Cloud على مجموعات مستندة إلى الحاوية في الوصول المبكر / الوضع التجريبي. وعدت Microsoft Azure أيضًا بالتبديل إلى الحاوية في المستقبل ، ولا تزال Amazon تدرس خيارات مختلفة لأوقات التشغيل لحلول الحاويات الخاصة بها (ECS و EKS) ، مع الاستمرار في استخدام Docker.
دخلت Red Hat مساحة
وقت تشغيل الحاوية عن طريق إنشاء تطبيق CRI بسيط يسمى
cri-o استنادًا إلى تنفيذ مرجع OCI ،
runc . تعتمد Docker و containerd أيضًا على runc ، لكن منشئو cri-o يدعون أن أوقات تشغيلهم "كافية" لـ Kubernetes وأنهم لا يحتاجون إلى المزيد - لقد أضافوا أكثر الوظائف الضرورية لتنفيذ Kubernetes CRI على ثنائي runc الأساسي.
( ملاحظة مترجمة : لقد كتبنا المزيد عن مشروع CRI-O في هذه المقالة ، وهنا عن المزيد من التطوير في شكل بودمان.)مشاريع افتراضية خفيفة الوزن: Intel Clear Containers و hyper.sh - ظهرت في براري مؤسسة OpenStack Foundation ،
حاويات Kata ، وتقدم رؤيتهم للحاويات الافتراضية للعزل الإضافي باستخدام تطبيق CRI يسمى
frakti . يعمل كل من cri-o و containerd أيضًا مع حاويات Kata ، بحيث يمكن تحديد وقت التشغيل المتوافق مع OCI كخيار للتوصيل.
التنبؤ بالمستقبل
إن القول بأنك تعرف أن المستقبل ليس من الحكمة في العادة ، ولكن يمكننا على الأقل إصلاح بعض الاتجاهات الناشئة حيث ينتقل النظام البيئي للحاويات من الحماس والضجيج إلى مرحلة أكثر نضجًا من وجودنا.
كانت هناك مخاوف مبكرة من أن النظام البيئي للحاوية سيشكل بيئة مجزأة ، حيث سيخرج المشاركون المختلفون بأفكار مختلفة وغير متوافقة حول ماهية الحاوية. بفضل عمل OCI والإجراءات المسؤولة للبائعين الرئيسيين والمشاركين ، رأينا بيئة صحية في الصناعة بين عروض البرامج التي تفضل التوافق مع OCI.
حتى في البيئات الأحدث حيث واجه معيار استخدام Docker مقاومة أقل بسبب القيود الحالية - على سبيل المثال ، في HPC - لفتت جميع محاولات إنشاء بيئات حاويات حاوية غير Docker الانتباه أيضًا إلى OCI. المناقشات جارية حول ما إذا كان OCI يمكن أن يكون حلاً قابلاً للتطبيق للاحتياجات المحددة لمجتمعات العلماء والباحثين.
إضافة إلى هذا توحيد معايير أوقات تشغيل الحاويات في Kubernetes باستخدام CRI ، يمكننا أن نتخيل عالمًا حيث يمكن للمطورين والمسؤولين اختيار الأدوات المناسبة ومجموعات البرامج لمهامهم ، والانتظار ومراقبة التشغيل المتبادل في جميع أنحاء النظام البيئي للحاوية.
فكر في مثال محدد لفهم هذا العالم بشكل أفضل:
- يستخدم مطور لديه MacBook Docker لنظام Mac لتطوير تطبيقه ، بل ويستخدم دعم Kubernetes المدمج (يعمل Docker مثل وقت تشغيل CRI هنا) لمحاولة نشر التطبيق الجديد على حوامل K8s.
- يمر التطبيق من خلال CI / CD في برنامج البائع ، والذي يستخدم رمز runc ورمز خاص (مكتوب بواسطة البائع) لحزم صورة OCI وتحميلها في سجل الشركات للحاويات للاختبار.
- يعمل تثبيت مجموعة Kubernetes الداخلي ، الذي يعمل مع الحاوية كوقت تشغيل CRI ، على تشغيل مجموعة من الاختبارات للتطبيق.
- اختارت هذه الشركة ، لسبب ما ، حاويات Kata لأحمال عمل معينة في الإنتاج ، لذلك عند نشر التطبيق ، يبدأ في حاويات تم تكوين الحاوية لاستخدام حاويات Kata كوقت تشغيل بدلاً من runc.
يعمل السيناريو بأكمله الموضح بشكل رائع بسبب التوافق مع مواصفات OCI لبيئات وقت التشغيل والصور ، وحقيقة أن CRI توفر المرونة لاختيار وقت التشغيل.
هذه المرونة والاختيار المحتملان تجعل النظام البيئي للحاوية رائعًا حقًا وهي أيضًا شرط مهم للغاية لنضج الصناعة ، التي نمت بسرعة كبيرة منذ عام 2014. على عتبة 2019 والسنوات التالية ، أرى مستقبلًا مشرقًا مع الابتكارات المستمرة والمرونة لأولئك الذين يستخدمون وينشئون منصات تعتمد على الحاويات.
يمكن العثور على مزيد من المعلومات حول هذا الموضوع في حديث حديث لـ Phil Estes على QCon NY: "
CRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!؟ "
ملاحظة من المترجم
اقرأ أيضا في مدونتنا: