آماده شدن برای پایان Dockershim در AKS

تغییرات بزرگی در نحوه مدیریت کانتینرها توسط Kubernetes رخ می دهد. در اینجا نحوه اطمینان از آماده بودن برنامه های Azure Kubernetes Service آورده شده است.

تاریخچه کانتینرهای مدرن طولانی و پیچیده است، به روزگار مین‌فریم و سپس از طریق فناوری‌هایی مانند Solaris Zones تا پذیرش cgroup‌ها توسط لینوکس به‌عنوان پایه‌ای از ویژگی‌های مجازی‌سازی در سطح سیستم‌عامل آن بازمی‌گردد. آن کانتینرهای لینوکس (LXC) بخش مهمی از پلتفرم اولیه Docker بودند و یک فضای کاربری مجزا برای میزبانی و اجرای کانتینرهای Docker فراهم می‌کردند.

با ادامه تکامل کانتینرها، داکر محیط زمان اجرا خود را توسعه داد که توسط بسیاری از پلتفرم های میکروسرویس منبع باز مانند Kubernetes پذیرفته شد. این باعث شده است که Docker رایج ترین راه برای ساخت، بسته بندی و استقرار کانتینرها باشد. با این حال، همچنین باعث شد که نسخه‌های اولیه Kubernetes از چندین رابط زمان اجرا کانتینر پشتیبانی کنند و به شما امکان می‌دهد کانتینرها را با استفاده از زمان‌های اجرا متفاوت در یک برنامه نصب کنید.

حرکت Kubernetes به استفاده از OCI و Dockershim

در طول زمان هر دو Docker و Kubernetes تکامل یافته اند. قالب تصویر کانتینر Docker به عنوان مبنایی برای تعریف زمان اجرا در Open Container Initiative (OCI) در کنار یک استاندارد Kubernetes CRI (رابط زمان اجرا کانتینر) که در زمان اجرا کانتینر استاندارد OCI runc پیاده سازی شده است. این منجر به توسعه مشخصات کانتینر باز شد که ابزارهایی برای مدیریت چرخه زندگی کامل یک کانتینر در بسیاری از موارد مانند Docker اما با ادغام عمیق در اکوسیستم Kubernetes.

حرکت Kubernetes به استفاده از OCI برای مدیریت کانتینرهای غلاف با استفاده از CRI مستلزم پیاده‌سازی شیمی بود که تماس‌های OCI را به تماس‌های Docker تبدیل می‌کرد و یک لایه اضافی در مدیریت کانتینر Kubernetes قرار می‌داد که سایر کانتینرهای کاملاً سازگار با OCI به آن نیازی ندارند. با توجه به اینکه تمام مدیریت کانتینر Kubelets اکنون از طریق CRI انجام می شود، تیم Kubernetes تصمیم گرفت که این Dockershim فقط یک نقطه توقف باشد، و به نصب‌های Kubernetes اجازه می‌دهد تا به پلتفرم‌های کانتینر آماده CRI مهاجرت کنند، به خصوص که میزبان کانتینر آماده CRI برای کانتینرهای ویندوز وجود نداشت – یک نیاز ضروری برای لاجوردی.

یک مشکل دیگر این بود که پشتیبانی از Dockershim با کد سخت توسط سایر بخش‌های Kubernetes و سایر پروژه‌هایی که در بالای پلتفرم ساخته شده بودند استفاده می‌شد. نتیجه کدی بود که می توانست شکننده و باگ باشد. تیم Kubernetes در نهایت Dockershim را منسوخ کرد و به توسعه دهندگان فرصت داد تا قبل از حذف آن را کنار بگذارند. اعلامیه اصلی گفته بود که مدتی پس از انتشار Kubernetes 1.23 منتشر خواهد شد.

آن روز خیلی زود می آید< /a>. با انتشار April 2022 Kubernetes 1.24، پشتیبانی Dockershim به طور کامل حذف خواهد شد. مایکروسافت از نسخه‌های جدید Kubernetes بسیار نزدیک به راه‌اندازی پشتیبانی می‌کند، بنابراین وقت آن است که بررسی کنید آیا این تغییر شکسته روی کد شما تأثیر می‌گذارد یا خیر.

چگونه Azure امروز از Dockershim استفاده می کند

در حال حاضر، استخرهای گره لینوکس Azure Kubernetes ایجاد شده با Kubernetes 1.19 یا جدیدتر از قبل در حال اجرا هستند. این بدان معنی است که شما مجبور نیستید از Dockershim استفاده کنید، زیرا AKS از رابط Runtime Container Kubernetes برای اتصال مستقیم Kubelets به Containerd استفاده می کند. این کار مجموعه‌ای از مراحل مدیریت و رابط‌ها را از AKS حذف می‌کند، بنابراین برنامه‌های شما باید پاسخگوتر باشند، سریع‌تر مقیاس شوند و از منابع کمتری استفاده کنند. با پشتیبانی Docker، Kubelets شما باید قبل از اتصال به موتور Docker زیرین، قبل از اتصال به اجرای کانتینر Docker، ابتدا به Dockershim متصل شود.

این دو نکته مهم هستند، به خصوص اگر از Kubernetes در ارتباط با KEDA (مقیاس‌سازی خودکار رویداد محور مبتنی بر Kubernetes) یا سایر ابزارهای رویداد محور استفاده می‌کنید. ایجاد پادهای جدید در صورت نیاز سریعتر خواهد بود و به برنامه شما امکان می دهد سریعتر به تقاضای افزایش یافته پاسخ دهد. همچنین می‌تواند منجر به صرفه‌جویی در هزینه‌های طولانی‌مدت شود، زیرا به شما امکان می‌دهد در موارد بیشتری که تحمل برنامه شما برای تأخیر می‌تواند از زمان صرف شده برای راه‌اندازی یک نمونه کانتینر پشتیبانی کند، به صفر کاهش دهید.

ظروف مبتنی بر ویندوز ممکن است بیشتر مشکل ساز باشند. مایکروسافت تنها در سال ۲۰۲۱ شروع به ایجاد پیش‌نمایش پشتیبانی از Windows برای Containerd کرد که به هدرهای صریح در پیکربندی کلاستر شما نیاز داشت. با انتشار Kubernetes 1.23 توسط AKS، در فوریه ۲۰۲۲، در دسترس عموم قرار خواهد گرفت.

درک این نکته مهم است که حذف Dockershim از Kubernetes مانع از اجرای تصاویر Docker در محیط AKS شما نمی‌شود. با این حال، این کانتینرها در Docker اجرا نمی شوند، زیرا داکر از Kubernetes CRI پشتیبانی نمی کند. در عمل، آنها در سایر زمان‌های اجرا سازگار با OCI اجرا می‌شوند، زیرا Docker مشخصات تصویر ظرف OCI را پیاده‌سازی می‌کند.

به روز رسانی AKS node pools برای استفاده از containerd

اگرچه برخی از نمونه‌های قدیمی‌تر Kubernetes همچنان اجرا می‌شوند، پشتیبانی نمی‌شوند. همانطور که مایکروسافت ابزارهای Kubernetes Azure را به‌روزرسانی می‌کند، در نهایت پشتیبانی از نسخه‌های قدیمی‌تر را حذف می‌کند، بنابراین در صورت لزوم باید کلاسترهای مبتنی بر Docker را به‌روزرسانی کنید. چرخه عمر پشتیبانی خود Kubernetes این است که از هر نسخه کوچک تا ۱۲ ماه پشتیبانی کند (افزایشی نسبت به پشتیبانی نه ماهه اصلی). با انتشار یک نسخه کوچک جدید تقریباً هر سه تا چهار ماه یکبار، مایکروسافت متعهد به پشتیبانی از سه نسخه کوچک آخر Kubernetes. زمانی که Kubernetes 1.22 با انتشار عمومی Kubernetes 1.25، احتمالاً در ژانویه یا فوریه ۲۰۲۳، پشتیبانی نمی‌شود، حدود یک سال فرصت می‌دهد تا برنامه‌های AKS خود را ارتقا دهید.

خوشبختانه روند ارتقاء برنامه های Kubernetes در حال اجرا در AKS نسبتاً ساده است. اگر از لینوکس استفاده می‌کنید، از قبل از یک کانتینر مبتنی بر استفاده می‌کنید. محیط. اگر هنوز از نسخه قدیمی‌تر و پشتیبانی‌نشده استفاده می‌کنید، ارتقای نمونه شما به‌طور خودکار شما را به استفاده از Container به‌روزرسانی می‌کند. هیچ تغییری در رجیستری ها یا کانتینرهای شما لازم نیست، و می توانید با استفاده از Docker برای ساخت و آزمایش بر روی سیستم های خود ادامه دهید. هیچ مشکلی وجود ندارد، اما ایده خوبی است که یک سیستم آزمایشی را با استفاده از آخرین نسخه AKS Kubernetes راه اندازی کنید تا مطمئن شوید که برنامه شما در آخرین محیط کار می کند.

چیزها اگر از کانتینرهای ویندوز استفاده می کنید کمی پیچیده تر است. ساده ترین گزینه این است که ابتدا یک مخزن گره کانتینری به خوشه AKS موجود خود اضافه کنید. شما باید به صراحت یک هدر سفارشی را به تعریف node pool اضافه کنید که مقدار WindowsContainerRuntime را روی Containerd تنظیم کند. سپس می توانید کانتینرهای متحرک را آزمایش کنید یا کانتینرهای جدید را به استخر گره جدید اضافه کنید. همچنین می‌توان با استفاده از Azure CLI، یک Node Pool یا کل کلاستر را به Container ارتقا داد. با این کار کد شما روی کانتینر اجرا می‌شود، اما مگر اینکه یادتان باشد که به صراحت مجموعه‌های گره‌پول‌های جدیدی ایجاد کنید، آن‌ها بر اساس Docker خواهند بود.

با انتشار عمومی Kubernetes 1.23 در AKS، containerd پیش‌فرض برای کانتینرهای جدید ویندوز و همچنین برای لینوکس خواهد بود. این کار تکمیل انتقال خود را قبل از عرضه Kubernetes 1.24 بعداً در سال ۲۰۲۲ آسان‌تر می‌کند.

برخی توصیه‌های اضافی وجود دارد از آنجایی که Docker CLI در Kubernetes پشتیبانی نمی‌شود، باید از CLI دیگری برای عیب‌یابی پادهای در حال اجرا استفاده کنید. مایکروسافت استفاده از crictl را توصیه می‌کند که روشی مبتنی بر Kubernetes دارد. این منحنی یادگیری کمی دارد، اما خیلی سخت نیست. تغییراتی در نحوه نگارش گزارش‌های کانتینر وجود دارد و ممکن است لازم باشد پلتفرم گزارش خود را به یکی تغییر دهید که از فرمت‌های گزارش Kubernetes CRI پشتیبانی می‌کند. ابزارهای نظارتی خود Azure در حال حاضر از این قالب پشتیبانی می کنند. آنها به عنوان جایگزینی برای کار با موتور Docker توصیه می شوند که دیگر در دسترس نیست.

هم توسعه دهندگان Kubernetes و هم تیم Azure مایکروسافت راه طولانی را برای حذف ریسک از انتقال Dockershim طی کرده اند. اگر از Dockershim در AKS استفاده می کنید، اکنون زمان آن رسیده است که به کانتینر بروید. نباید هیچ مشکلی به جز تغییر به فرمت گزارش جدید و یادگیری نحوه استفاده از ابزارهای عیب یابی جدید وجود داشته باشد. اگرچه این نیاز به تغییراتی در نحوه کار با AKS دارد، اما آنها نسبتاً جزئی هستند. نتیجه مثال خوبی است از اینکه چگونه تیم‌های توسعه مانند Kubernetes و پلتفرم‌هایی مانند Azure می‌توانند تغییرات اساسی فناوری را مدیریت کنند و برنامه‌های شما را با کمترین کار از سوی شما اجرا کنند.