آمازون اخیراً پشتیبانی از بازگردانی نسخه کوبرنیتیس را در سرویس EKS معرفی کرد. این ویژگی به تیمهای فنی اجازه میدهد تا در صورت بروز مشکل پس از ارتقا، کنترلپلن (Control Plane) کلاستر را ظرف ۷ روز به نسخه قبلی برگردانند. وجود این تور ایمنی، ریسک ارتقای درجا (in-place) کلاسترها را بهشدت کاهش میدهد و راهحلی برای بازیابی سریع ارائه میکند.
مکانیزم عملکرد بازگردانی در EKS
در فرآیند بازگردانی، EKS سرور API و اجزای کنترلپلن را به نسخه پیشین برمیگرداند، اما تمام دادههای etcd، پردازشها (workloads) و حجمهای پایدار (persistent volumes) دستنخورده باقی میمانند. برای کلاسترهایی که با EKS Auto Mode اجرا میشوند، سرویس آمازون ابتدا بهطور خودکار وُرکر نُدهای (worker nodes) حالت خودکار را عقبگرد میدهد و سپس به سراغ کنترلپلن میرود. کاربران میتوانند این فرآیند را تسریع کنند یا در میانه راه آن را لغو کنند.
درب یکطرفه ارتقای کوبرنیتیس
میکا والتر، معمار ارشد راهکارها در AWS، با اشاره به اینکه «ارتقای کنترلپلن کوبرنیتیس مدتهاست که یک درب یکطرفه محسوب میشود»، مینویسد: کوبرنیتیس هر سال سه نسخه مینور عرضه میکند و تیمهایی که مدیریت صدها کلاستر را بر عهده دارند، بهویژه در محیطهای قانونمند، اغلب از ترس عدم توانایی در بازیابی، ارتقاها را به تأخیر میاندازند. این موضوع باعث میشود کلاسترها روی نسخههای قدیمی متوقف شوند، پچهای امنیتی را از دست بدهند و با محدودیتهای پشتیبانی تمدیدشده مواجه شوند.
برخلاف Amazon ECS که یک ارکستراتور کانتینر اختصاصی است، EKS یک سرویس مدیریتشده است که نگهداری کنترلپلن را بر عهده میگیرد. فرآیند بازگردانی در EKS دقیقاً مانند مسیر ارتقا، گامبهگام و تنها برای یک نسخه مینور انجام میشود. پیش از اجرای عملیات، EKS ابزار Cluster Insights را برای بررسی آمادگی سیستم به کار میگیرد و مشکلاتی نظیر عدم تطابق نسخه نُدها یا وابستگیهای افزونهها (add-ons) را شناسایی میکند. البته کاربران میتوانند با استفاده از پرچم --force این بررسیها را نادیده بگیرند.
پایان دوران راهحلهای جایگزین پرهزینه
نسخه متنباز کوبرنیتیس تا پیش از این فاقد قابلیت بازگردانی کنترلپلن بود و با پیشنهاد KEP-4330 این محدودیت تا حدودی برطرف شد. این ضعف باعث شده بود سازمانها به روشهای جایگزین و پرهزینهای روی بیاورند. اسمعیل بیگ، رهبر ارشد کلود و DevOps در شرکت Uniphore، در این باره میگوید: آمازون سرانجام چیزی را به تیمهای EKS داد که سالها برایش درخواست میکردیم: بازگردانی بومی کوبرنیتیس. پیش از این، ما تنها دو راهحل پرهزینه داشتیم: استقرارهای Blue/Green که هزینه زیرساخت را در زمان ارتقا دو برابر میکرد، و اسنپشاتهای دستی که ساعات مهندسی را میبلعیدند و حتی تضمینی برای موفقیت آنها وجود نداشت.
رقابت در میان ارائهدهندگان سرویسهای ابری
آمازون نخستین ارائهدهنده سرویسهای ابری نیست که چنین ویژگیای را ارائه میکند. اگرچه Azure AKS تنها از پشتیبانی جزئی و محدود به نود پول (node pool) بهره میبرد، گوگل پیشتر با عرضه GKE 1.33 بازگردانی نسخه مینور کنترلپلن را معرفی کرده بود. والتر در توضیح میزان کنترل کاربران میافزاید: برای اینکه مدیریت این فرآیند در دست شما باشد، یک API لغو ارائه کردهایم تا بتوانید بازگردانی نود را در هر نقطهای متوقف کنید. اگر زمان خیلی طولانی شد یا قصد تغییر رویکرد داشتید، میتوانید آن را لغو کرده و بودجههای اختلال (disruption budgets) را برای تسریع کار تنظیم کنید.
کوری کوین، اقتصاددان ارشد کلود در گروه Duckbill، در خبرنامه خود این ویژگی را «یک دکمه undo برای ارتقاهای کوبرنیتیس» توصیف میکند که تنها پس از سالها تلاش تیمهای عملیاتی برای ساخت دورههای تثبیت و تشریفات طولانی برای اجتناب از درب یکطرفه میرسد. اشرف گامودی، مهندس DevOps در Tnker نیز معتقد است آمازون بهتازگی یکی از بزرگترین ترسهای هر مهندس کوبرنیتیس را برطرف کرده است.
بازگردانی نسخه کوبرنیتیس هماکنون در تمام مناطق در دسترس EKS بدون هزینه اضافی ارائه میشود. این قابلیت برای تمام کلاسترهای EKS در سطح کنترلپلن کاربرد دارد، اما بازگردانی نودها به کلاسترهای مبتنی بر EKS Auto Mode محدود است و از هر دو نسخه استاندارد و پشتیبانی تمدیدشده کوبرنیتیس پشتیبانی میکند. این تغییر کوچک اما حیاتی، مسیر را برای بهروزرسانیهای بیخطرتر در زیرساختهای ابری هموار میکند.
