مدیریت داخلی ارتقا کوبرنتیز چه هزینه‌ای دارد؟ بررسی نقش کوبرنتیز مدیریت‌شده

ارتقا کوبرنتیز فقط به تغییر شماره نسخه محدود نمی‌شود. هر ارتقا می‌تواند مجموعه‌ای از فعالیت‌های فنی مانند نصب Patchها، بررسی APIهای منسوخ‌شده، رفع ناسازگاری Add-onها و اطمینان از سازگاری وابستگی‌های مختلف پلتفرم را به همراه داشته باشد. در پلتفرم‌هایی که بر پایه چند پروژه متن‌باز ساخته شده‌اند، دنبال کردن تغییرات پروژه‌های Upstream هم به بخشی از فرایند نگهداری تبدیل می‌شود.

انجام این فعالیت‌ها به زمان و ظرفیت مهندسی نیاز دارد؛ ظرفیتی که می‌تواند صرف توسعه قابلیت‌های جدید یا سایر اولویت‌های محصول شود. به همین دلیل، نگهداری کوبرنتیز در بسیاری از تیم‌ها، با برنامه توسعه محصول برای استفاده از زمان مهندسی رقابت می‌کند. در این مطلب، فرایندهای اصلی نگهداری و ارتقا کوبرنتیز، عوامل مؤثر بر پیچیدگی این فرایند و راهکارهای مدیریت آن را بررسی می‌کنیم.

نگهداری کوبرنتیز زمان تیم را صرف چه کارهایی می‌کند؟

نگهداری کوبرنتیز مجموعه‌ای از فعالیت‌های مستمر است که فقط به زمان اجرای ارتقا محدود نمی‌شود. تیم پلتفرم باید تغییرات خود کوبرنتیز و اجزای وابسته را دنبال کند، سازگاری آن‌ها را بررسی کند و پس از هر تغییر، از عملکرد درست پلتفرم مطمئن شود. مهم‌ترین بخش‌های این فرایند عبارت‌اند از:

• ارتقا نسخه و نصب اصلاحیه‌ها (Patch): تیم باید نسخه‌ها و اصلاحیه‌های جدید، از جمله اصلاحیه‌های امنیتی را دنبال و برای اعمال آن‌ها روی کلاسترها برنامه‌ریزی کند.
• رسیدگی به APIهای منسوخ‌شده: نسخه‌های قدیمی API ابتدا منسوخ می‌شوند و ممکن است در نسخه‌های بعدی دیگر ارائه نشوند. به همین دلیل، تیم باید وابستگی فایل‌های YAML، کلاینت‌های API، کنترل‌کننده‌ها و یکپارچه‌سازی‌ها به این APIها را شناسایی کند و در صورت نیاز، آن‌ها را به نسخه‌های جدیدتر انتقال دهد.
• رفع ناسازگاری افزونه‌ها (Add-on): ابزارها و افزونه‌های نصب‌شده روی کلاستر ممکن است با نسخه جدید کوبرنتیز سازگار نباشند، بنابراین تیم باید سازگاری آن‌ها را بررسی کند و در صورت نیاز، نسخه مناسب‌تری از آن‌ها را به کار بگیرد.
• ارتقا هلم چارت‌ها (Helm Chart): نسخه‌های جدید هلم چارت‌ها باید از نظر تغییر مانیفست‌ها (Manifest)، وابستگی‌ها و سازگاری با کلاستر بررسی شوند. حتی اگر بررسی مانیفست‌ها بدون خطا انجام شود، ممکن است برخی ناسازگاری‌ها فقط هنگام اجرای واقعی سیستم آشکار شوند.
• دنبال‌کردن تغییرات پروژه‌های بالادستی (Upstream): پلتفرم‌های مبتنی بر کوبرنتیز معمولا از چند پروژه متن‌باز تشکیل شده‌اند. تغییراتی مانند انتشار نسخه‌های جدید، ارائه اصلاحیه‌های امنیتی یا پایان پشتیبانی هر یک از این پروژه‌ها می‌تواند تیم را به ارتقا یکی از اجزای پلتفرم ملزم کند.
• آزمایش و پایش پس از تغییرات: تغییرات باید پیش از استقرار بررسی شوند و پس از اجرا هم عملکرد سرویس‌ها در محیط واقعی پایش شود؛ زیرا برخی ناسازگاری‌ها فقط هنگام اجرا یا پس از گذشت زمان آشکار می‌شوند.

حجم بار نگهداری چقدر است؟

میزان زمانی که نگهداری کوبرنتیز از تیم مهندسی می‌گیرد، به عواملی مانند تعداد کلاسترها، اندازه محیط، معماری پلتفرم و میزان خودکارسازی فرایندها بستگی دارد. بنابراین، نمی‌توان عدد ثابتی را برای همه محیط‌های مبتنی بر کوبرنتیز در نظر گرفت. بااین‌حال، تجربه‌های منتشرشده نشان می‌دهند که حجم این بار نگهداری در محیط‌های مختلف یکسان نیست.

Munib Ali، مدیر مهندسی SRE در Fairwinds، می‌گوید در بسیاری از استقرارهای متوسط EKS (مخفف Amazon Elastic Kubernetes Service، سرویس مدیریت‌شده کوبرنتیز در زیرساخت ابری AWS)، انجام یک ارتقا Minor در سه منطقه (Region) می‌تواند چهار تا شش هفته تلاش مهندسی مصرف کند و توسعه دو تا سه قابلیت در سطح نقشه راه را به تعویق اندازد. این عدد که یک مشاهده تجربی از سوی Fairwinds است، به شرایط محیط بستگی دارد و نباید به همه کلاسترهای کوبرنتیز تعمیم داده شود

همچنین Jehoszafat Zimnowoda و Matthias Erll، مهندسان ارشد نرم‌افزار در Akamai، انتشارهای سه سال گذشته ۱۴ پروژه متن‌باز را بررسی کرده‌اند. بر اساس تجربه و تحلیل آن‌ها، یک پلتفرم متکی به این مجموعه پروژه‌ها ممکن است در هر سال با ۲ تا ۵ ارتقا اصلی، ۴۳ تا ۵۲ ارتقا فرعی و ۲۷۶ تا ۳۲۷ اصلاحیه روبه‌رو شود. این داده هم به همان پروژه‌های بررسی‌شده مربوط است و معیار عمومی همه پلتفرم‌های کوبرنتیز نیست.

چرا ارتقا کوبرنتیز پیچیده‌تر از یک ارتقا نسخه (Version Bump) است؟

چند عامل فنی مانند تغییر APIها، وابستگی میان نسخه اجزای مختلف کلاستر و بررسی سازگاری افزونه‌ها (Add-on) و چارت‌های Helm باعث می‌شوند فرایند ارتقا کلاستر کوبرنتیز، پیچیده‌تر از یک به‌روزرسانی ساده باشد. 

تغییر و حذف APIها

با تکامل API کوبرنتیز، نسخه‌های قدیمی ابتدا منسوخ و در نهایت حذف می‌شوند. پس از حذف یک نسخه API، آن نسخه دیگر توسط kube-apiserver ارائه نمی‌شود و مانیفست‌ها یا کلاینت‌هایی که همچنان به آن وابسته‌اند باید به نسخه‌ای پشتیبانی‌شده مهاجرت کنند.

مهاجرت APIهای منسوخ‌شده کوبرنتیز ممکن است به تغییر فایل‌های YAML، کلاینت‌های API، کنترل‌کننده‌ها و یکپارچه‌سازی‌های سفارشی نیاز داشته باشد. مستندات رسمی، ابزار kubectl convert را نیز برای تبدیل خودکار بعضی منابع معرفی می‌کنند؛ بااین‌حال، این تبدیل ممکن است از مقادیر پیش‌فرض نامناسب استفاده کند و نتیجه آن باید با مراجعه به مستندات API همان منبع بررسی شود.

وابستگی میان نسخه اجزا

پروژه کوبرنتیز شاخه‌های سه نسخه Minor اخیر را نگهداری می‌کند و نسخه‌های ۱.۱۹ به بعد تقریباً یک سال پشتیبانی از Patch دریافت می‌کنند. بنابراین، باقی‌ماندن روی نسخه‌های قدیمی نمی‌تواند برای مدتی نامحدود ادامه پیدا کند و برنامه ارتقا باید چرخه پشتیبانی کوبرنتیز را در نظر بگیرد.

اجزای مختلف کلاستر همچنین باید از قواعد اختلاف نسخه (Version Skew؛ محدوده مجاز تفاوت نسخه میان اجزای مختلف کوبرنتیز) پیروی کنند. برای مثال، kubelet نباید از kube-apiserver جدیدتر باشد و می‌تواند حداکثر سه نسخه Minor از آن قدیمی‌تر باشد. kube-proxy نیز نباید از kube-apiserver جدیدتر باشد و باید محدودیت اختلاف نسخه با kube-apiserver و kubelet را رعایت کند.

این محدودیت‌ها بر ترتیب ارتقا اثر می‌گذارند. ابتدا kube-apiserver ارتقا پیدا می‌کند. در کلاسترهای دارای دسترس‌پذیری بالا، تمام نمونه‌های kube-apiserver که سایر اجزای Control Plane ممکن است با آن‌ها ارتباط برقرار کنند، باید پیش از ارتقا kube-controller-manager، ‏kube-scheduler و cloud-controller-manager ارتقا یافته باشند. پس از آن، kubelet و kube-proxy را می‌توان با رعایت محدوده مجاز اختلاف نسخه ارتقا داد.

ناسازگاری Add-onها و Helm Chartها

ارتقا افزونه‌ها و هلم چارت‌ها هم می‌تواند با چالش‌هایی همراه باشد. برخی نسخه‌های جدید هلم چارت تغییراتی در فیلدهای تغییرناپذیر (Immutable Fields) منابع کوبرنتیز ایجاد می‌کنند که می‌تواند فرایند ارتقا را با مشکل مواجه کند.

همه مشکلات در مرحله بررسی مانیفست‌ها مشخص نمی‌شوند و بعضی ناسازگاری‌ها فقط هنگام اجرای واقعی سامانه آشکار می‌شوند. پیش از اعمال تغییرات، می‌توان مانیفست‌های رندرشده نسخه فعلی و نسخه جدید را با یکدیگر مقایسه کرد، آن‌ها را با طرح‌واره OpenAPI (همان OpenAPI schema) کوبرنتیز و CRDهای اضافه‌شده سنجید و تغییرات را به‌صورت Dry Run (بررسی آزمایشی یک تغییر، بدون اعمال و ذخیره‌کردن واقعی آن در کلاستر) در برابر کلاستر در حال اجرا بررسی کرد.

بااین‌حال، استقرار بدون خطا تضمین نمی‌کند که برنامه همچنان مطابق انتظار کار می‌کند. به همین دلیل، تست‌های یکپارچگی باید روی کلاستر در حال اجرا انجام شوند تا ارتباط سرویس‌ها با وابستگی‌ها و در دسترس بودن Endpointها بررسی شود. پایش بلندمدت نیز ضروری است؛ زیرا مشکلاتی مانند کمبود حافظه، محدودشدن CPU یا تمام‌شدن فضای دیسک ممکن است چند روز یا چند هفته پس از تغییر آشکار شوند.

چگونه بار نگهداری را ساختاریافته‌تر کنیم؟

اگرچه مدیریت چرخه عمر کوبرنتیز همواره به فعالیت‌های نگهداری نیاز دارد، اما می‌توان بخشی از این فرایند را با برنامه‌ریزی و خودکارسازی ساختاریافته‌تر کرد. در ادامه، برخی اقدام‌های پیشنهادی برای ساختاریافته‌ترکردن این فرایند را بررسی می‌کنیم:

• خودکارسازی شناسایی نسخه‌های جدید و ایجاد درخواست تغییر (Pull Request): بخشی از فرایند شناسایی نسخه‌های جدید پروژه‌های متن‌باز و هلم چارت‌ها را می‌توان خودکار کرد تا پس از انتشار نسخه جدید، یک درخواست تغییر برای بررسی و اعمال به‌روزرسانی ایجاد شود.
• شناسایی APIهای منسوخ‌شده: مستندات رسمی کوبرنتیز استفاده از هشدارهای کلاینت، معیارها و اطلاعات Audit را برای یافتن وابستگی به APIهای منسوخ‌شده پیشنهاد می‌کنند. پس از شناسایی این وابستگی‌ها، فایل‌های YAML، کلاینت‌های API، کنترل‌کننده‌ها و یکپارچه‌سازی‌های سفارشی باید پیش از حذف نسخه قدیمی به APIهای منسوخ‌نشده مهاجرت کنند.
• اعتبارسنجی مانیفست‌های رندرشده پیش از اعمال تغییرات: می‌توان تمام مانیفست‌هایی را که پلتفرم مستقر می‌کند با طرح‌واره OpenAPI کوبرنتیز و CRDهای اضافه‌شده اعتبارسنجی کرد. مقایسه مانیفست‌های نسخه فعلی و نسخه جدید و اجرای Dry Run در برابر کلاستر در حال اجرا نیز می‌تواند تغییرات مخرب احتمالی را پیش از اعمال آن‌ها آشکار کند
• اجرای تست‌های یکپارچگی و پایش پس از ارتقا: اجرای موفق فرایند استقرار، به‌تنهایی تضمین نمی‌کند که سامانه همچنان مطابق انتظار عمل می‌کند. به همین دلیل، اجرای تست‌های یکپارچگی روی کلاسترِ در حال اجرا و پایش مداوم سامانه پس از ارتقا، بخشی از فرایند نگهداری محسوب می‌شود.

بااین‌حال، خودکارسازی، فقط بخشی از فعالیت‌های نگهداری را ساده‌تر می‌کند و همچنان مسئولیت‌هایی مانند برنامه‌ریزی ارتقا، بررسی سازگاری وابستگی‌ها و تصمیم‌گیری درباره نگهداری مستمر بر عهده تیم فنی باقی می‌ماند. به بیان دیگر، خودکارسازی می‌تواند بخشی از بار عملیاتی را کاهش دهد، اما مسئولیت مدیریت چرخه عمر کوبرنتیز را حذف نمی‌کند.

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

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

نمونه دیگر، سازمان‌هایی هستند که می‌توانند تشکیل و نگهداری یک تیم پلتفرم بسیار تخصصی را از نظر عملیاتی و اقتصادی توجیه کنند. این نمونه‌ها تنها بخشی از موقعیت‌هایی هستند که مدیریت داخلی کوبرنتیز می‌تواند در آن‌ها ارزش ایجاد کند و نباید آن‌ها را به‌عنوان فهرست کامل معیارهای تصمیم‌گیری برای همه سازمان‌ها در نظر گرفت.

چگونه واگذاری نگهداری کوبرنتیز ظرفیت تیم داخلی را آزاد می‌کند؟

Fairwinds بر اساس تجربه خود گزارش می‌کند که انتقال مسئولیت انجام ارتقا، اعمال اصلاحیه‌ها و مدیریت افزونه‌ها از برنامه کاری داخلی به یک تیم تخصصی Kubernetes SRE، می‌تواند بخشی از زمان مهندسان ارشد را آزاد کند. البته این نتیجه، تجربه Fairwinds است و نباید به‌عنوان پیامد قطعی این الگو برای همه سازمان‌ها در نظر گرفته شود. همچنین زمان آزادشده می‌تواند صرف توسعه قابلیت‌های جدید، بهبود قابلیت اطمینان، بهینه‌سازی عملکرد و ارتقا تجربه توسعه‌دهندگان شود. به این ترتیب، بخشی از ظرفیت مهندسی به فعالیت‌هایی اختصاص پیدا می‌کند که اثر مستقیم‌تری بر محصول و اولویت‌های مهندسی دارند.

در سازمان‌هایی که تمایلی به مدیریت مستقیم همه فعالیت‌های عملیاتی کوبرنتیز ندارند، استفاده از خدمات مدیریت‌شده کوبرنتیز (Kubernetes as a Service یا KaaS) هم می‌تواند یکی از گزینه‌های قابل بررسی باشد. البته قابلیت‌ها و مسئولیت‌های هر سرویس مدیریت‌شده به ارائه‌دهنده آن بستگی دارد و باید بر اساس مستندات رسمی همان سرویس ارزیابی شود.

جمع‌بندی: کوبرنتیز باید قابل‌پیش‌بینی باشد، نه مصرف‌کننده دائمی تمرکز تیم

مدیریت چرخه عمر کوبرنتیز فرایندی مستمر است و با پایان یک ارتقا نسخه به پایان نمی‌رسد. در این فرایند، انتشار نسخه‌های جدید، تغییر APIها، به‌روزرسانی وابستگی‌ها و ارزیابی تغییرات، همگی بخشی از فعالیت‌هایی هستند که در طول زمان ادامه پیدا می‌کنند و به برنامه‌ریزی و رسیدگی مداوم نیاز دارند.

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