ماجرای کوبرنتیز و اعلام عدم پشتیبانی از Docker از نسخه بعد!
از دیروز ۲ دسامبر خبری اومده که باعث تعجب خیلیها توی توئیتر و لینکدین شده. خبر اینه:
برداشتهای ناقص از این خبر باعث شده خیلیها نگران وضعیت سرویسهاشون بشن. سعی کردم تو این متن مختصر و شفاف توضیح بدم دقیقا چه اتفاقی قراره بیافته. در کل خیلی جای نگرانی نیست :)
- سوال اساسی: ما همچنان میتونیم سرویس هامون رو با Dockerfile بسازیم و از ایمیج هاش تو کوبر استفاده کنیم؟
بله همچنان میتونیم و در آینده نیز مشکلی نیست :)
پس داستان چیه؟برای پاسخ مشروح به ادامه متن توجه بفرمایید :)
۱- موضوع از اینجا شروع میشه، «CRI چیه؟» (داخل پرانتز بگم کل دعوا سر همین CRIعه)
کوبر برای بخشهای مختلف خودش مثل «مدیریت شبکه» یا «مدیریت کانتینرها» نمیاد خودش همه چی رو پیادهسازی کنه، بهجاش چیکار میکنه؟ میاد یه سری استاندارد تعریف میکنه و هر شخص مستقلی میتونه پیادهسازی خودش رو برای اون استاندارد داشته باشه و توی کوبر استفاده کنه.
مثلا برای شبکه کوبر CNI یا Container Network Interface رو تعریف میکنه و کلی ملت میان پیادهسازی های مختلف رو بر اساس این CNI انجام میدن مثل calico flannel، و هرکسی بین گزینههای موجود یکی رو برای کلاسترش انتخاب میکنه.
برای اجرای کانتینر هم داستان همینه، کوبر اومده CRI یا Container Runtime Interface رو مشخص کرده و بقیه میان پیادهسازی میکنن. الان چندتا گزینه برای مدیریت اجرای کانتینر توی محیط کوبر وجود داره که سه تا از معروفترینشون ایناست:
۲- این سه تا چیکار میکنن؟
این سرویسها مسئول اجرای کانتینر توی کلاستر کوبر هستن. یعنی وقتی دولوپر کدش رو زد و ایمیج دلخواهش رو ساخت، یکی تو کوبر باید باشه بره این ایمیجها رو pull کنه و از روش کانتینر بسازه، پراسسش رو اجرا کنه و کلی کارهای جذاب دیگه :)، توی کلاستر کوبر این وظایف با kubelet هست اما kubelet توی لایههای پایینتر از پیاده سازیهای مختلف که طبق CRI هستن استفاده میکنه مثل docker، containerd و cri-o.
۳- الان دقیقا کوبر چیو میخواد دپریکیت کنه؟
کوبر میگه من از نسخه 1.23 به بعد دیگه Docker رو به عنوان CRI قبول ندارم! و پیشنهاد کرده برید از اون دوتای دیگه استفاده کنین.
از نسخه 1.20 وقتی kubelet میاد بالا اگه CRI استفاده شده داکر باشه یه deprecation warning میده اما همچنان اجازه میده داکر اجرا بشه. از نسخه 1.23 یعنی اواخر 2021 دیگه کلا اجازهی اجراشم نمیده.
۴- مشکل کوبر با داکر چیه؟
داکر یه چیز خیلی خوبه و کلی کارها رو راحت کرده. همچنان هم تا سالها قطعا یکی از پرکاربردترین تکنولوژیها توی استک IT خواهد بود.
داکر مجموعهای از امکانات رو کنار هم جمع کرده و بصورت کاملا user friendly و stable در اختیار کاربرا گذاشته، یکی از این امکانات همون containerd خودمونه :) یعنی داکر خودش برای مدیریت کانتینرها از containerd استفاده میکنه. داکر کلی چیز میز جذاب و مفید دیگه رو با یه UX فوقالعاده کنار هم جمع کرده، توسعه و دپلوی رو راحت کرده و خلاصه دنیا رو راحت کرده اما برای انسان ها نه کوبرنتیز!
«داکر اساسا برای اینکه CRI خوبی درون کوبر باشه طراحی نشده!» با اینکه خودش از containerd استفاده میکنه اما وقتی کوبر میخواد از داکر استفاده کنه یه سری مشکلاتی داره که کوبریها مجبور شدن برن یه سرویس دیگه به اسم Dockershim بنویسن و به kubelet اضافه کنن تا بتونن از داکر استفاده کنن :|
الان کوبر میگه خب چه کاریه! من برای استفاده از containerd باید لقمه رو دور سرم بچرخونم و یه سرویس دیگه بنویسم که خودش پیچیدگی رو زیاد میکنه و خطر ناپایداری برای کل سیستم داره. لذا تصمیم گرفته دیگه Docker رو به عنوان CRI نپذیره.
یعنی CRI اگه داکر باشه روند اجرا اینجوری میشه:
kubelet -> dockershim -> docker -> containerd
در صورتیکه داکر نباشه روند اجرای cri توی کلاستر کوبر اینجوری میشه:
kubelet -> containerd
در واقع اصل داستان اینه:
«کوبر میخواد dockershim رو از توی kubelet حذف کنه. این یعنی دیگه داکر نمیتونه به عنوان CRI توی کوبر استفاده بشه.»
(حدودا دو ماهه این قضیه باز شده و الان دیگه اعلام رسمی شده که از نسخه 1.23 این اتفاق می افته)
۵- برگردیم به سوال اساسی: ما همچنان میتونیم سرویس هامون رو با Dockerfile بسازیم و از ایمیج هاش تو کوبر استفاده کنیم؟ بله. چرا؟
ایمیجهایی که داکر میسازه اینجوری نیست که Docker-specific باشه و فقط خودش بفهمه چی ساخته. ایمیجهای داکر منطبق با ساختار OCI (Open Container Initiative) image هستن، و این ساختار رو اون دوتا یعنی containerd و CRI-O هم پشتیبانی میکنن. لذا همچنان میشه مثل قبل کد زد و با Dockerfile ایمیج ساخت و تو کوبر اجراش کرد. دوشواری نداره.
۶- یعنی کلا آب از آب تکون نمیخوره؟ مگه میشه :/
با تغییر CRI -که سالهاست تو اغلب کلاسترها Docker هست- حتما یه سری مشکلاتی رخ میده ولی خیلی حاد نیستن. مثلا اگه کسی برای Docker in Docker توی کوبرش مستقیم از var/run/docker.sock/ استفاده کرده باشه قاعدتا به مشکل میخوره و باید بره سراغ سولوشنهای دیگهای مثل kaniko, img یا buildah.
امیدوارم مطلب مفیدی بوده باشه و از خوندنش لذت برده باشید
اگه مطلب رو دوست داشتید ❤️ کنید و نظرتون رو کامنت کنید. ری اکشن شما مزید ابتهاج خاطر نویسنده و دیگر خوانندگان است :)
منبع اصلی:
مطلبی دیگر از این انتشارات
بازطراحی سازمان برای تحول دیجیتال (قسمت اول)
مطلبی دیگر از این انتشارات
چرا گوگل از ریپوزیتوری مشترکی با حجم ۸۶ ترابایت استفاده میکند
مطلبی دیگر از این انتشارات
چگونه گرافانا بالا بیاریم !؟