داستان منسوخ شدن داکر در کوبرنتیز

داستان منسوخ شدن داکر در کوبرنتیز “Kubernetes is deprecating Docker” رو بذارید از اینجا شروع کنم که طی چند روز گذشته بیش از 200 تماس، پیام و ایمیل داشتم که همه این ارتباطات بخاطر عدم اطلاع رسانی درست خبر منسوخ شدن داکر در کوبرنتیز توسط افراد غیر متخصص در فضای مجازی بوده و اطلاع رسانی نادرست باعث شده خیلی ها که کسب و کار و کل برنامه هاشون روی این بستر بوده وارد شوک بشن و به دنبال راه چاره بگردن که باعث شد تصمیم بگیرم جزییات این خبر رو به صورت فنی و کامل در اختیارتون بذارم تا از نگرانی های ممکن در بیاید.

داکر چیه و چه کاری رو انجام میده؟

قطعا وقتی دارید این پست رو میخونید میدونید داکر چیه ولی این قسمت رو برای افرادی میذارم که دقیقا تفاوت داکر و کوبرنتیز رو نمیدونن. داکر یکی از پلتفرم هایی هست که برای پیاده سازی محیط های کانتینری مورد استفاده قرار میگیره و میشه گفت بخاطر اینکه یکی از پروژه هایی بوده که به خوبی کانتینرها رو تجاری سازی کرده به عنوان محبوبترین پلتفرم کانتینری شناخته میشه. این پلتفرم طی چند سال اخیر از یک معماری یکپارچه به سمت مایکروسرویس شدن حرکت کرده و در حال حاضر بخش های اصلی اون که به صحبت ما مرتبط میشه در تصویر زیر مشخص شده. در این سیستم یک سرویس به اسم containerd نقش یک اجرا کننده سطح بالا(High-level) کانتینر رو به عهده داره که میتونه Image های کانتینر رو بگیره و درخواست ساخت، اجرا، توقف و… کانتینر رو صادر کنه. در بخش زیری این سرویس، سرویس runc وجود داره که به عنوان اجرا کننده سطح پایین(Low-level)، وظیفه داره با توجه به زیرساخت و سیستم عامل، کارهای لازم مثل ساخت namespace ها و محدود کردن کانتینر با cgroups رو انجام بده و در نهایت کانتینر رو به صورت فیزیکی اجرا کنه.

کوبرنتیز چیه و چه کاری رو انجام میده؟

اینو هم قطعا همه میدونید ولی برای اینکه یکم داستان شفاف‌تر بشه ی کوچولو در موردش میگم. کوبرنتیز یک پلتفرم هماهنگ کننده(Orchestration) و مدیریت کننده کانتینرها است که به ما کمک میکنه در محیط هایی که تعداد زیادی کانتینر داریم، راحتتر اونا رو مدیریت کنیم و در کنار مدیریت راحتتر بتونیم پترن های مختلف استقرار و توزیع برنامه ها رو به خوبی پیاده سازی کنیم. کوبرنتیز برای اجرای کانتینرها به یک Container Runtime نیاز داره که همونطور که در بالا اشاره کردم، داکر به عنوان محبوبترین پلتفرم اجرای کانتینرها میتونه همراه با کوبرنتیز استفاده بشه و خدمت لازم رو ارایه کنه. زمانی که ما در کوبرنتیز درخواستی میدیم که به اجرای یک کانتینر ختم میشه، سرویس kubelet این درخواست رو میگیره و با اجرا کننده کانتینر صحبت و کانتینرهای مورد نیاز رو اجرا میکنه. در زمان های قبل که تعداد Container Runtime ها زیاد نبود یا اصلا چیزی بجز داکر وجود نداشت، این ارتباط به صورت مستقیم برقرار میشد ولی بعدها با به وجود اومدن کانتینر Runtime های جدید این نیاز حس شد که کوبرنتیز باید از اونا هم پشتیبانی کنه که برای این کار، مصرف کننده باید سورس kubelet رو باز میکرد، درایور ارتباطی رو قرار میداد و سرویس kubelet رو دوباره کامپایل و اجرا میکرد و از اونجایی که این فرآیند زمان بر و بسیار تخصصی بود، تصمیم گرفتن کار رو راحتتر کنن و از نسخه 1.5 کوبرنتیز استانداردی موسوم به CRI یا Container Runtime Interface به وجود اومد که این اجازه رو به مصرف کننده میداد که بدون تغییر کد و کامپایل کردن مجدد kubelet، هر Runtime ای که با CRI سازگار هست رو استفاده کنه. در این بین داکر که برای ارتباط با انسان طراحی شده و چیزی از ارتباط با CRI نمیفهمید باید کنار گذاشته میشد و از اونجایی که از ابتدا داکر به عنوان موتور اصلی در کوبرنتیز مورد استفاده بود و دیگر Runtime ها هم چندان Production-ready نبودن عملا حذف اون امکان پذیر نبود. در نتیجه تیم توسعه کوبرنتیز تصمیم گرفتن که یک رابط برای ارتباط kubelet با docker درست کنن که از سمتی CRI رو متوجه بشه و از سمتی هم بتونه با موتور داکر صحبت کنه و اسم این رابط رو dockershim گذاشتن و اینطوری بود که ارتباط لازم مجددا برقرار میشد.

ورود containerd و سازگاری با CRI کوبرنتیز:

همونطور که در قسمت داکر گفتم، داکر هم طی این مدت از معماری یکپارچه به سمت مایکروسرویس رفت و containerd به وجود اومد، با ورود اولین نسخه استیبل containerd، تیم توسعه همین پروژه یک رابط CRI به اسم cri-containerd درست کردن که ارتباط kubelet و containerd رو برقرار میکرد. این رابط در نسخه 1.1 به یک پلاگین تبدیل شد و به خود رانتایم containerd چسبید که اخیرا هم کدبیس این پلاگین به کدبیس اصلی containerd منتقل شده(گیتهاب پروژه). از اون طرف هم تو سال 2018 وقتی کوبرنتیز این شرایط رو دید، اعلام کرد که با استیبل شدن containerd و فراهم شدن رابط CRI لازم، عملا docker و dockershim یک لایه اضافی هستن و باعث شدن پرفورمنس کار پایین بیاد و میشه بجای پیچیده کردن کار، مستقیم از خود containerd استفاده کرد(از اینجا بخونید). تو این بلاگ پست به وضوح اشاره کرده که چه تفاوتی تو پرفورمنس بوجود اومده و چرا باید از containerd استفاده کنیم. تو تصویر پایین داستان کم کردن واسط ها به خوبی بیان شده که برای دیدن میزان افزایش پرفورمنس هم میتونید به همون لینکی که دادم برید.

ورود CRI-O، همه چیزی که کوبرنتیز لازم دارد:

با اومدن این Container Runtime و پیام همه چیزی که کوبرنتیز نیاز دارد به دنیایی با پرفورمنس بالاتر رسیدیم، چرا که این وسط دیگه هیچ لایه اضافه ای وجود نداره و ارتباط اجرا کننده سطح بالا که CRI-O باشه با اجرا کننده سطح پایین که runc باشه به طور مستقیم برقرار شده و از طرفی هم این رانتایم صرفا و به طور بهینه برای کوبرنتیز طراحی و پیاده سازی شده. از این لینک به سایت پروژه سر بزنید. تصویر زیر تغییرات اتفاق افتاده در طول زمان تا به امروز رو نشون میده.

خوب بریم سر اصل داستان:

خبری که اخیرا توسط کوبرنتیز منتشر شد(خبر رسمی) عنوان کرد که از نسخه 1.20 دیگه از داکر پشتیبانی نمیکنه و باید برای استفاده از کوبرنتیز به Container Runtime های دیگه مهاجرت کرد. با نشر این خبر چنان سر و صدایی در شبکه های اجتماعی بلند شد که انگار آسمون به زمین اومده و انقدر بعضی افراد به این خبر غیر تخصصی دامن زدن که هنوز من دارم جواب پیام یکسری افراد نگران رو میدم که در این فکر بودن که قراره چه بلایی سر کسب و کار و آینده کارشون بیاد و در پی راه چاره بودن. از همینجا از این افراد غیر متخصص میخوام که تا چیزی رو دقیق نمیدونید خبر نادرست منتشر نکنید. در زیر یکسری موارد رو باید روشن کنیم که خیال همه راحت بشه و انقدر دنبال راه چاره نباشن.

سوال: چرا این اتفاق اصلا رخ داد و داکر رو منسوخ کردن؟

این داستان بر خلاف چیزی که در فضای مجازی و شبکه های اجتماعی گفته میشه، هیچ ربطی به شکستن انحصار طلبی و خراب کردن برند و… نداره و صرفا دلیلش اینه که توسعه dockershim برای تیم کوبرنتیز ی کار اضافی هست و از طرفی هم پرفورمنس فرآیند رو کم میکنه. از اون سمت هم وجود containerd باعث شده عملا نیازی به خود داکر نداشته باشیم و راحت تمام کارهای لازم رو انجام بدیم. جالبه بدونید در حال حاضر نزدیک به 80درصد افرادی که از کوبرنتیز استفاده میکنن، بدون اینکه مطلع باشن دارن از containerd استفاده میکنن و ارتباطشون چیزی مثل تصویر زیر هست.

سوال: خوب چه کاری بود این خبر رو بدن؟ همون فرمون میرفتن…

واقعیت داستان اینه که نگهداری، توسعه و بروزرسانی dockershim یک کار اضافی بوده که توسط تیم کوبرنتیز انجام میشده و در بعد فنی این موضوع هم dockershim فعلی از user namespace و cgroupsv2 پشتیبانی نمیکنه. پس دلیل محکمی برای ادامه اون نیست.

سوال: تکلیف برنامه هایی که الان داریم چی میشه؟

هیچ مشکلی پیش نمیاد! چرا که این وسط سازمان OCI یکسری استاندارد برای Runtime ها و Image ها تعریف کرده و خوشبختانه Runtime هایی که نام بردیم همه بر این اساس کار میکنن و هر برنامه ای که با داکر ساختید به خوبی پشتیبانی و اجرا میشن.

سوال: تا کی وقت داریم مهاجرت کنیم و به چی مهاجرت کنیم؟

به گفته کوبرنتیز dockershim در نسخه 1.23 در سال 2021 حذف میشه ولی سوال اینجاست که الان اصلا از dockershim استفاده می کنید؟ در پست بعدی نحوه تشخیص و مهاجرت رو بهتون میگم اما اینکه containerd یا CRI-O رو انتخاب کنید به پارامترهای مختلفی بستگی داره و راحتترین پارامتر اینه که اگر الان dockershim به خوبی براتون کار میکنه، قطعا containerd هم به خوبی کار خواهد کرد. تو این دوتا لینک لیست پلتفرم هایی که به containerd و CRI-O مهاجرت کردن اورده شده و همچنین نصاب های رسمی مثل Kubespray در حال حاضر همه Runtime هارو پشتیبانی میکنن.

سوال: تکلیف docker و dockershim چی میشه؟

طبق آخرین اخبار(خبر رسمی) شرکت Mirantis و Docker به این توافق رسیدن که با همکاری هم به طور مستقل و خارج از روند توسعه کوبرنتیز، dockershim2 رو توسعه بدن و امکاناتی که نیاز هست رو اضافه کنن. پس کلا نگرانی نداشته باشید.

امیدوارم که این پست به کارتون بیاد و اگر نگران بودید دیگه نباشید.

در صورت نیاز به بررسی های بیشتر با من در ارتباط باشید.

تو پست بعدی نحوه بررسی Runtime فعلی و چگونگی مهاجرت رو بهتون آموزش میدم.

موفق و پیروز باشید.