توالی انتشار GKE با استفاده از مراحل سفارشی
سرویس GKE در گوگل کلاود اکنون به شما اجازه میدهد ترتیب دقیق ارتقای کلاسترها را تعیین کنید. این کار از طریق توالی انتشار با مراحل سفارشی انجام میشود که به جای برنامه زمانی منطقهای پیشفرض، از منطق کسبوکار شما پیروی میکند.
ارتقای کلاسترهای Kubernetes در دهها یا صدها محیط مختلف، کار دشواری است. وصلههای امنیتی بهطور منظم منتشر میشوند، اما شما باید سرویسهای عملیاتی (production) را نیز فعال نگه دارید. مدل قدیمی ارتقای منطقهای ممکن بود نسخه جدید control-plane را پیش از اتمام فرآیند اعتبارسنجی در محیط staging به یک کلاستر production اعمال کند و کل ناوگان (fleet) را در معرض تغییرات آزمایشنشده قرار دهد.
چرا مدل قدیمی ناکافی بود
یک انتشار منطقهای با هر کلاستر در آن منطقه به عنوان یک گروه واحد برخورد میکند. وقتی بازه زمانی ارتقا باز میشود، control plane و nodeها بهصورت موازی ارتقا مییابند، بدون توجه به اینکه کلاستر در کجای خط لوله انتشار (release pipeline) قرار دارد. تیمهایی که بر جریان سختگیرانه «ابتدا canary و سپس production» تکیه میکنند، با ارتقاهای «خارج از ترتیب» مواجه میشوند که میتواند باعث بروز پسرفتهایی (regressions) شود که ردیابی آنها تا یک تغییر خاص دشوار است. هزینه این کار فقط از دست رفتن زمان فعالیت (downtime) نیست؛ بلکه زمان مهندسی است که صرف عیبیابی مشکلی میشود که میتوانست زودتر شناسایی شود.
آنچه توالی انتشار GKE اضافه میکند
این قابلیت جدید یک شیء RolloutSequence معرفی میکند که مجموعهای از مراحل را تعریف میکند. هر مرحله، یک بخش منطقی از ناوگان شماست که توسط label selectorها شناسایی میشود. سیستم یک مسیر قطعی (deterministic) را دنبال میکند:
- ابتدا ارتقای control-plane. GKE پیش از دست زدن به هر یک از nodeها، مؤلفه مدیریت مرکزی را به نسخه هدف منتقل میکند.
- شروع تایمر Soak. پس از اینکه control plane به نسخه هدف رسید، یک تأخیر قابل تنظیم اجرا میشود که به شما فرصتی برای اجرای بررسیهای سلامت (health checks) میدهد.
- ارتقای nodeها بهصورت موازی. در حالی که تایمر soak در حال شمارش معکوس است، GKE nodeها را ارتقا میدهد تا کلاستر بهسرعت به نسخه جدید همگرا شود.
- شروع مرحله بعد تنها پس از تکمیل مرحله فعلی. وقتی تمام nodeها و control plane در مرحله فعلی کارشان تمام شد و تایمر soak به پایان رسید، GKE به مرحله بعد میرود.
با تقسیم یک ناوگان به گروههای کوچکتر و برچسبدار، میتوانید ابتدا تعدادی از کلاسترهای canary را ارتقا دهید، بررسی کنید که قوانین مانیتورینگ و مسیریابی ترافیک (traffic-routing) طبق انتظار عمل میکنند، و سپس همان نسخه را برای بقیه محیط production منتشر کنید.
قوانینی برای حفظ نظم در توالی
- مرحله Catch-all: مرحله نهایی فاقد label selector است که تضمین میکند هر کلاستر دیگری که در مراحل قبل مطابقت نداشته، همچنان ارتقا را دریافت کند.
- حل تداخل: اگر برچسبهای یک کلاستر با بیش از یک مرحله مطابقت داشته باشد، GKE آن را در اولین مرحله مطابقتیافته قرار میدهد تا از ارتقای دوگانه تصادفی جلوگیری شود.
اهرمهای کنترل در لحظه
در طول یک انتشار فعال، شما کنترل را در دست دارید:
- Pause (توقف موقت): هرگونه ارتقای بیشتر را متوقف میکند و به شما اجازه میدهد بدون گسترش مشکل، یک شکست در مرحله canary را بررسی کنید.
- Force-complete (تکمیل اجباری): زمانی که اسکریپتهای اعتبارسنجی شما زودتر از موعد موفقیت را گزارش میدهند، زمان باقیمانده soak را حذف کرده و سرعت انتشار را بالا میبرد.
- Cancel (لغو): اگر نسخه جدید منتشر شده دارای یک باگ بحرانی باشد، کل توالی را متوقف میکند و به شما اجازه میدهد نسخه را بازگردانی (revert) کنید یا منتظر یک hotfix بمانید.
چه کسانی بهره میبرند و مزایا و معایب چیست
آنچه باید در ادامه دنبال کرد
نتیجهگیری
توالی انتشار با مراحل سفارشی، به اپراتورهای GKE این امکان را میدهد که کلاسترها را به ترتیبی که کسبوکارشان میطلبد ارتقا دهند، نه به ترتیبی که پلتفرم دیکته میکند. این قابلیت با جداسازی ارتقای control-plane و nodeها، افزودن دوره soak قابل تنظیم و ارائه عملکردهای pause/force-complete/cancel، ریسک ارتقا را کاهش داده و در عین حال سرعت مورد نیاز تیمهای cloud-native را حفظ میکند. برای هر کسی که با آشفتگی ارتقای Kubernetes در سطح کل ناوگان دستوپنجه نرم میکند، مدل توالی جدید گامی ملموس به سوی اتوماسیون ایمنتر و همسو با کسبوکار است.