ملاحظة perev. : لقد كتبنا أكثر من مرة عن الحاوية وأوقات التشغيل الأخرى لـ Kubernetes. المنشور الجديد هو ترجمة للإعلان الأخير عن معلم هام في تطوير الحاوية ، تم نشره على المدونة الرسمية لمشروع Kubernetes. تم كتابة النص من قبل موظفي Google و IBM ، والتي (بالطبع ، مع Docker Inc) تساهم بشكل كبير في تحسين الحاوية.في وقت سابق من المدونة - في الملاحظة
جلبت الحاوية المزيد من خيارات وقت تشغيل الحاوية لـ Kubernetes - قدمنا نسخة ألفا من تكامل الحاوية مع Kubernetes. أدت الأشهر الستة القادمة من التطوير إلى حقيقة أن التكامل أصبح متاحًا للجمهور! هذا يعني أنه يمكنك الآن استخدام
الحاوية 1.1 كوقت تشغيل للحاويات في مجموعات Kubernetes في الإنتاج.
يعمل الحاوية 1.1 مع Kubernetes الإصدار 1.10 وأعلى ، ويدعم جميع ميزات Kubernetes. في البنية التحتية لاختبار Kubernetes ، أصبحت تغطية اختبارات تكامل الحاوية على Google Cloud Platform هي نفسها التكامل مع Docker (انظر
لوحة تحكم الاختبار ).
“نحن سعداء لرؤية الحاوية تصل بسرعة إلى هذا الإنجاز الهام. في Alibaba Cloud ، بدأنا في استخدام الحاوية بشكل نشط منذ أيامها الأولى ، وبفضل تركيزها على البساطة والموثوقية ، جعلنا الحاوية محرك الحاوية الافتراضي في منتج Kubernetes الخاص بخادمنا ، مما يضع متطلبات عالية على الأداء والاستقرار. سوف تكون Containerd بلا شك المحرك الرئيسي لعصر الحاوية وتؤدي إلى تطوير الابتكار ". - Xinwei ، مهندس بدوام كامل من Alibaba Cloud
التحسينات المعمارية
لقد تغيرت بنية دمج الحاوية مع Kubernetes مرتين. استقرت كل من خطواتها التطورية وحسنت كفاءة المكدس.
الحاوية 1.0 - CRI- الحاوية (لم تعد موجودة)
في الحاوية 1.0 ، كان خفي حاويات cri-containerd مطلوبًا للتفاعل بين
Kubelet و الحاوية
(كتبنا عنها في نهاية هذه المقالة - ترجمة تقريبًا ) . قدم هذا البرنامج الخفي طلبات إلى
واجهة وقت تشغيل الحاوية (CRI) من
Kubelet واستخدم الحاوية لإدارة الحاويات وصور الحاويات بشكل صحيح. أزال هذا النهج رابطًا إضافيًا واحدًا في المكدس عند مقارنته بتطبيق Docker CRI (
dockershim ) -
انظر الشكل أعلاه .
ومع ذلك ، كان cri-containerd و containerd 1.0 شاعرين منفصلين يتفاعلان عبر GRPC. جعل البرنامج الخفي الإضافي في هذه الحزمة الحياة صعبة للمستخدمين في فهم الجهاز وأثناء النشر ، كما أدى إلى زيادة النفقات غير الضرورية للتفاعل.
كونتينر 1.1 - المساعد CRI (الإصدار الحالي)
في الحاوية 1.1 ، تم إعادة تصميم برنامج cri-containerd إلى المكوّن الإضافي الحاوية CRI. تم إنشاء هذا المكون الإضافي في الحاوية 1.1 وتم تمكينه افتراضيًا. على عكس cri-containerd ، يتفاعل المكون الإضافي مع الحاوية عن طريق استدعاء الوظائف الضرورية مباشرة. جعلت الهندسة الجديدة التكامل أكثر استقرارًا وإنتاجية ، مما أدى إلى إزالة ارتباط آخر (GRPC) من المكدس. الآن يمكن استخدام الحاوية 1.1 مباشرة في Kubernetes ، ولم يعد برنامج cri-containerd خفيًا مطلوبًا.
الأداء
أحد الأهداف الرئيسية للحاوية 1.1 هو تحسين الأداء. تم تنفيذ التحسينات في منطقة وقت البدء والموارد المستخدمة من قبل الشيطان.
النتائج التالية هي مقارنة الحاوية 1.1 و Docker 18.03 CE. يستخدم الحاوية Integrd 1.1 المكون الإضافي CRI المدمج ، ويعمل التكامل مع Docker 18.03 CE مع dockershim. تم إنشاء النتائج باستخدام معيار أداء عقدة Kubernetes ، وهو جزء من
اختبارات e2e لعقد K8s . تتوفر معظم بيانات المقارنة بشكل عام على
لوحة معلومات أداء العقدة .
تأخير بدء الموقد
تظهر نتائج
المعيار القياسي لبدء تشغيل دفعة 105 pod أن تكامل الحاوية 1.1 لديه تأخير أقل في بدء pod من Docker 18.03 CE مع dockershim (كلما كان أصغر كلما كان ذلك أفضل).
وحدة المعالجة المركزية والذاكرة
في حالة الخمول ، يستهلك تكامل الحاوية 1.1 مع مداخن 105 معالجًا وذاكرة أقل من تكامل Docker 18.03 CE مع dockershim. قد تختلف النتائج اعتمادًا على عدد المداخن التي تم إطلاقها على العقدة - تم تحديد عدد 105 موقد ، لأن الافتراضي هو الآن الحد الأقصى لقيمة المداخن المخصصة على العقدة.
كما يتبين من الرسوم البيانية أدناه ، فإن تكامل الحاوية 1.1 مع
Kubelet يستهلك وحدة معالجة مركزية أقل بنسبة 30.89٪ وذاكرة RSS أقل بنسبة 11.30٪ (حجم المجموعة المقيمة) ، بالإضافة إلى ذاكرة RSS أقل بنسبة 12.78٪ يستهلكها وقت تشغيل الحاوية .
إضافة من المترجم
تجدر الإشارة إلى أن حل بديل آخر ، CRI-O ، مستمر في التطور. على وجه الخصوص ، في مؤتمر Open Source Summit Japan 2018 هذه الأيام ، قدم أحد موظفي NTT تقريرًا بمقارنة شاملة للبيئات القابلة للتنفيذ الموجودة للحاويات. وها هي إحدى شرائحه تقارن أدائهم:
crictl
تعد واجهة وحدة تحكم وقت تشغيل الحاوية (CLI) أداة مفيدة لتحديد المشاكل في النظام والتطبيق. عند استخدام Docker كبيئة حاوية في Kubernetes ، يذهب مسؤولو النظام أحيانًا إلى موقع Kubernetes لتشغيل أوامر Docker وجمع معلومات حول النظام و / أو التطبيق. على سبيل المثال ، يمكنهم استخدام
docker ps docker inspect للتحقق من حالة العملية ،
docker images للحصول على قائمة بالصور على العقدة ،
docker info للحصول على تكوين وقت التشغيل للحاويات ، إلخ.
بالنسبة إلى الحاوية وجميع البيئات الأخرى المتوافقة مع CRI مثل dockershim ، نوصي باستخدام
crictl كبديل CLI لأوامر وحدة التحكم Docker لتحليل المشاكل على القرون والحاويات وصور الحاويات المستضافة على عُقد Kubernetes.
crictl هي أداة مساعدة تقدم ميزات مشابهة لـ Docker CLI وتعمل بشكل جيد على قدم المساواة مع جميع بيئات وقت التشغيل للحاويات المتوافقة مع CRI. يمكن العثور عليها في
مستودع kubernetes-incubator / cri-tools ؛ الإصدار الحالي هو
أدوات cri-v1.11.0 (تم إصلاح الإصدار للإصدار الحالي قبل 3 أيام بدلاً من v1.0.0-beta.1 ، كما هو موضح في المقالة الأصلية ، الترجمة التقريبية ) . على الرغم من أن أداة
crictl مصممة لتكون مشابهة لـ Docker CLI ، مما يوفر انتقالًا بسيطًا للمستخدمين ، إلا أنها ليست نسخة كاملة منه. يتم وصف بعض الاختلافات الهامة أدناه.
الاستخدام المحدود: crictl هي أداة لاستكشاف الأخطاء وإصلاحها
crictl ليس بديلاً عن
kubectl docker أو
kubectl - يقتصر استخدامه على نطاق تحديد المشكلة وتحليلها. تقدم واجهة وحدة التحكم Docker مجموعة غنية من الأوامر ، مما يجعلها أداة تطوير مفيدة للغاية. ومع ذلك ، ليس هذا هو الخيار الأفضل لاستكشاف الأخطاء وإصلاحها على عقد Kubernetes. بعض أوامر Docker (على سبيل المثال ،
docker network Docker
docker build Docker) غير مجدية لـ Kubernetes ، وبعضها (مثل
docker rename Docker) يمكن أن يكسر كل شيء. الغرض من
crictl هو توفير أوامر كافية لتحديد المشاكل على العقد الآمنة للاستخدام في بيئات الإنتاج.
تركز Kubernetes
تقدم
crictl عرض حاوية أكثر قابلية للفهم في عالم Kubernetes. لا تعمل واجهة وحدة التحكم Docker مع مفاهيم Kubernetes الأساسية ، مثل تحت (pod) ومساحة الاسم (
مساحة الاسم ) ، مما يمنع التمثيل المرئي للحاويات والمداخن
(أهمية هذه المشكلة صحيحة ، بالفعل في سياق المراقبة ، تحدثنا عنها مؤخرًا في هذا التقرير - ملاحظة . perev. ) . أحد الأمثلة على ذلك هو
docker ps يظهر أسماء غامضة وحاوية لحاويات Docker وقائمة بحاويات الإيقاف المؤقت إلى جانب حاويات التطبيق:
ومع ذلك ، تعد
حاويات الإيقاف المؤقت جزءًا من تنفيذ الموقد ، حيث يتم استخدام حاوية واحدة لكل موقد ؛ لا يجب عرضها عند عرض الحاويات التي هي جزء من الموقد.
على النقيض من ذلك ، تم إنشاء crictl لـ Kubernetes. توفر الأداة مجموعات مختلفة من أوامر المداخن والحاويات. على سبيل المثال ، يعرض
crictl pods معلومات حول
crictl pods ،
crictl ps فقط معلومات حول حاويات التطبيقات. يتم تنسيق جميع البيانات في عرض جدول:
مثال آخر - في
crictl pods هناك حجة - مساحة الاسم ، والتي تسمح بتصفية القرون حسب مساحات الأسماء المحددة في Kubernetes:
لمزيد من المعلومات حول كيفية استخدام crictl مع الحاوية ، انظر هنا:
ولكن ماذا عن محرك Docker؟
غالبًا ما نسمع السؤال التالي: "هل التبديل إلى الحاوية يعني أنه لم يعد بإمكاني استخدام محرك Docker؟" ، والإجابة القصيرة عليه هي "لا".
تم بناء Docker Engine على أساس الحاوية. سيستخدم الإصدار التالي من Docker Community Edition (Docker CE) الحاوية الإصدار 1.1. وبناءً على ذلك ، سيكون له مكون إضافي مضمن وممكّن افتراضيًا من خلال CRI. هذا يعني أنه سيكون لدى المستخدمين الفرصة لمواصلة العمل مع Docker Engine لسيناريوهات نموذجية أخرى ، بالإضافة إلى القدرة على تكوين Kubernetes لاستخدام الحاوية الأساسية التي تأتي مع Docker Engine والتي يتم استخدامها في وقت واحد بواسطة Docker Engine على نفس المضيف. ألق نظرة على الرسم البياني المعماري أدناه لتوضيح كيفية استخدام الحاوية نفسها بواسطة Docker Engine و
Kubelet :
نظرًا لأن الحاوية تستخدم من قبل كل من
Kubelet و Docker Engine ، فإن المستخدمين الذين يختارون الاندماج مع الحاوية لن يحصلوا فقط على جميع الميزات الجديدة لـ Kubernetes ، والتحسينات في الأداء والاستقرار ، ولكن أيضًا خيار استخدام Docker Engine ، كما كان من قبل ، للاحتياجات الأخرى.
تضمن آلية
مساحة الاسم في الحاوية عدم
وصول Kubelet و Docker Engine إلى الحاويات والصور التي لم يتم إنشاؤها من قبلهم. هذا يعني أنهم لن يتدخلوا مع بعضهم البعض ، وكذلك:
- لن يرى المستخدمون الذين يدخلون
docker ps docker docker ps الحاويات التي تم إنشاؤها في Kubernetes. استخدم crictl ps لهذا. وبالعكس ، لن يرى المستخدمون الحاويات التي تم إنشاؤها في Docker CLI على Kubernetes أو الأمر crictl ps . crictl create و crictl run مخصصة لاستكشاف الأخطاء وإصلاحها فقط. لا يُنصح بتشغيل المداخن أو الحاويات يدويًا باستخدام crictl على عقد الإنتاج. - لن يرى المستخدمون الذين يدخلون
docker images docker images الصور من Kubernetes. للقيام بذلك ، استخدم الأمر crictl images . على العكس ، لن ترى Kubernetes الصور التي تم إنشاؤها بواسطة أوامر docker pull docker load docker build أوامر docker build . للقيام بذلك ، استخدم أمر crictl pull ، وكذلك ctr cri load ، إذا كنت تريد تحميل الصورة.
الملخص
- يحتوي الحاوية 1.1 على دعم CRI الأصلي. يمكن استخدامه مباشرة من قبل Kubernetes.
- الحاوية 1.1 جاهزة للإنتاج.
- يتميز الحاوية 1.1 بأداء جيد من حيث وقت بدء تشغيل الكود واستخدام موارد النظام.
- تعد Crictl أداة مساعدة لوحدة التحكم (CLI) للتواصل مع الحاوية 1.1 وبيئات وقت التشغيل الأخرى للحاويات التي تتوافق مع CRI من أجل تحديد المشكلات في العقدة.
- سيتم تضمين الحاوية 1.1 في الإصدار المستقر التالي من Docker CE. سيتم ترك المستخدمين مع خيار متابعة العمل مع Docker في حالات غير Kubernetes وتكوين Kubernetes لاستخدام الحاوية الأساسية التي تعد جزءًا من Docker.
نريد أن نشكر الجميع من Google و IBM و Docker و ZTE و ZJU والمطورين الأفراد الذين ساهموا وجعلوا كل هذا ممكنًا!
للحصول على قائمة مفصلة بالتغييرات في الحاوية 1.1 ، راجع
ملاحظات الإصدار .
كيف تحاول
تعليمات إعداد مجموعة Kubernetes لاستخدام الحاوية كوقت التشغيل الافتراضي:
kube-up.sh على الحملة العالمية للتعليم ، أثيرت باستخدام kube-up.sh ، - هنا ؛- لتثبيت مجموعة من العديد من العقد باستخدام Ansible و kubeadm - هنا ؛
- لإنشاء مجموعة من الصفر في Google Cloud - راجع " Kubernetes the Hard Way " ؛
- للتثبيت اليدوي من أرشيف tarball - هنا ؛
- للتثبيت باستخدام LinuxKit على جهاز افتراضي محلي - هنا .
كيف تساهم
البرنامج المساعد Containerd CRI - مشروع مفتوح المصدر على GitHub ، وهو جزء من الحاوية:
https://github.com/containerd/cri . نرحب بجميع التغييرات المقترحة في شكل أفكار وتذاكر وتصحيحات. يعد
دليل الخطوات الأولى لمطور البرامج هذا نقطة بداية جيدة لإجراء التغييرات.
ملاحظة من المترجم
اقرأ أيضا في مدونتنا: