بدءًا من الإصدار 1.20 ، يقوم Kubernetes بإسقاط Docker كوقت تشغيلحاوية.
لكن لا داعي للذعر. ليس كل شيء سيئًا كما يبدو للوهلة الأولى.
TL ؛ DR. يتخلى Kubernetes عن Docker لصالح أوقات تشغيل Container Runtime Interface (CRI) المصممة خصيصًا لـ Kubernetes. ستستمر صور Docker في العمل كالمعتاد في جميع أوقات التشغيل.
بالنسبة لمستخدمي Kubernetes ، لن يتغير الكثير. كل هذا لا يعني أن Docker سوف "يموت" أو أنه يجب / لا ينبغي استخدامه للتطوير بعد الآن. سيستمر Docker في كونه أداة رائعة لبناء الحاويات ،
docker build
وسيستمر تشغيل الصور التي تم إنشاؤها باستخدامه على مجموعة K8s.
إذا كنت تستخدم خدمات Kubernetes المُدارة مثل GKE أو EKS ، فيجب عليك التأكد من استخدام العاملين لديك لإصدار مدعوم من وقت التشغيل والقيام بذلك قبل إزالة دعم Docker في إصدار مستقبلي من K8s. إذا كانت العقد الخاصة بك تحتوي على تكوينات محددة ، فستحتاج على الأرجح إلى الترقية لتلبي متطلبات البيئة ووقت التشغيل المناسبة. نوصي بالاتصال بمزود الخدمة ومناقشة جميع مشكلات التخطيط الخاصة بالاختبار والترقية.
إذا قمت بطرح المجموعات بنفسك ، فستحتاج أيضًا إلى إجراء التغييرات المناسبة لتجنب المشاكل. عند الترقية إلى الإصدار 1.20 ، ستتلقى تحذيرًا بإيقاف Docker. يخطط المطورون للتخلي عن Docker تمامًا في الإصدار 1.23 ، والذي من المقرر إصداره في نهاية عام 2021. مع إصداره ، سيتعين عليك التبديل إلى إحدى البيئات القابلة للتنفيذ المتوافقة - على سبيل المثال ، containerd أو CRI-O. فقط تأكد من أن البيئة التي تختارها تدعم تكوينات Docker daemon التي تستخدمها (على سبيل المثال ، التسجيل).
ما سبب كل هذا الالتباس ولماذا يشعر الجميع بالقلق الشديد؟
في الواقع ، نحن نتحدث عن بيئتين مختلفتين تمامًا وهذا يسبب الارتباك. يوجد داخل مجموعة Kubernetes ما يسمى بوقت تشغيل الحاوية ، وهو مسؤول عن تحميل صور الحاوية وتشغيلها. وتحظى Docker بشعبية كبيرة كأداة لتنظيم هذه البيئة (الحاوية و CRI-O معروفان أيضًا على نطاق واسع). ومع ذلك ، لم يتم تصميم Docker ليتم تضمينه في Kubernetes ، وهذا يطرح عددًا من المشكلات.
"Docker" ليست أداة منفصلة ، ولكنها مجموعة تقنية كاملة ، وأحد مكوناتها يسمى "containerd" (لقد كتبنا عنها بمزيد من التفصيل هنا - تقريبًا. Transl.)ويعمل كوقت تشغيل عالي المستوى للحاويات. يعد Docker شائعًا وملائمًا نظرًا للعدد الهائل من الوظائف الإضافية للمستخدمين التي تبسط إلى حد كبير عملية التفاعل مع هذه الأداة أثناء التطوير. ومع ذلك ، فإن كل تحسينات تجربة المستخدم هذه غير ضرورية لـ Kubernetes ، لأنه ليس بشريًا.
يجبر مستوى التجريد هذا سهل الاستخدام مجموعة Kubernetes على استخدام أداة أخرى ، Dockershim ، للوصول إلى ما تحتاجه حقًا: containerd. وهذا أمر سيء ، لأن مثل هذه الطبقة الإضافية يجب أن تتم صيانتها ويمكن أن "تنكسر" أيضًا. في الواقع ، اتضح ما يلي: في Kubernetes v1.23 ، ستتم إزالة Dockershim من Kubelet - وفقًا لذلك ، سيفقد Docker الدعم كوقت تشغيل حاوية. السؤال الذي يطرح نفسه: إذا تم تضمين containerd بالفعل في Docker stack ، فلماذا يحتاج Kubernetes إلى Dockershim؟
النقطة المهمة هي أن Docker غير متوافق مع واجهة وقت تشغيل الحاوية.(CRI). إذا كان متوافقًا ، فلن نحتاج إلى طبقة إضافية وسيكون كل شيء رائعًا. ومع ذلك ، هذه ليست نهاية العالم وليست سببًا للذعر. فقط استبدل Docker runtime بآخر مدعوم.
يرجى ملاحظة أنه إذا كنت تستخدم مقبس Docker (
/var/run/docker.sock
) كجزء من سير عمل عادي ، فلن تتمكن من العمل معها بعد التبديل إلى بيئة أخرى. غالبًا ما يشار إلى هذا النمط باسم "Docker in Docker". هناك العديد من الأدوات المختلفة لحل هذه المشكلة ، بما في ذلك kaniko و img و buildah .
كيف سيؤثر هذا التغيير على المطورين؟ هل سنستمر في كتابة Dockerfiles؟ هل يجب أن نبني الصور باستخدام Docker؟
يتعلق هذا التغيير المثير للجدل ببيئة مختلفة تمامًا عن تلك التي يستخدمها معظم الأشخاص للتفاعل مع Docker. لا علاقة لتثبيت Docker للتطوير بوقت التشغيل داخل مجموعة Kubernetes. نعم ، هذا أمر محير ، أعلم ...
حتى بعد الابتكار ، سيظل Docker نفس الأداة المفيدة للمطورين. يمكن أن تعمل الصور التي تم إنشاؤها بواسطة Docker مع أكثر من مجرد Docker. هذه صور OCI كاملة. ستظهر أي صورة متوافقة مع OCI بالشكل نفسه على Kubernetes بغض النظر عن الأداة التي تم إنشاؤها باستخدامها. يعتبر كل من containerd و CRI-O رائعين في جلب هذه الصور وتشغيلها. هذا هو سبب إنشاء معيار الحاوية.
لذا ، التغييرات قادمة. بعض الناس ، بالطبع ، سيواجهون مشاكل معينة. لكن ليس هناك ما يدعو للندم أو القلق ، لأن التقدم شيء رائع. اعتمادًا على كيفية استخدامك لنظام Kubernetes ، يمكن أن يعني هذا إما التقاعس التام أو الحد الأدنى من الجهد بالنسبة لك. على المدى الطويل ، لن يؤدي مثل هذا الابتكار إلا إلى تسهيل الأمور.
إذا كانت التغييرات القادمة لا تزال تحيرك ، فأنت بخير. هناك العديد من الأجزاء المتحركة في Kubernetes ، ولا أحد خبير فيها بنسبة 100٪. لا تتردد في طرح أي أسئلة ، بغض النظر عن مستوى الخبرة أو الصعوبة! هدفنا هو إعداد الجميع قدر الإمكان للتغييرات القادمة. <3 نأمل أن يكون هذا المنشور قد أجاب على معظم أسئلتك وتبديد جميع المخاوف والمخاوف!
هل تحتاج إلى مزيد من الإجابات؟ تحقق من الأسئلة الشائعة حول إهلاك Dockershim .
PS من المترجم
يمكنك أيضًا العثور على إجابة مفصلة من Tim Hockin ، أحد مطوري Kubernetes ، في المناقشة حول هذا الموضوع على Reddit .
اقرأ أيضًا على مدونتنا: