گوگل کلاود اعلام کرد که سرویس GKE اکنون ارتقای کنترلپلین (control-plane) دو مرحلهای را بهصورت عمومی (generally-available) ارائه میدهد؛ این قابلیت به مشتریان اجازه میدهد ارتقای باینری نرمافزار را از مهاجرت فرمت دادهها جدا کرده و در طول تغییرات نسخههای فرعی (minor version)، یک بازه بازگشت (rollback window) باز نگه دارند.
چرا GKE به یک مسیر امنتر نیاز داشت
ارتقای کنترلپلین کوبرنتیز از یک نسخه فرعی به نسخه بعدی همیشه با ریسک همراه بوده است. انتقال از نسخه ۱.۳۳ به ۱.۳۴ نه تنها باینریها را جایگزین میکند، بلکه ساختارهای داده زیربنایی را نیز بازنویسی میکند. اگر نسخه جدید حاوی یک باگ باشد، کلاستر را نمیتوان بهسادگی به حالت قبل بازگرداند؛ مدیران باید اسنپشاتهای قدیمی پایگاه داده را بازیابی کنند یا کل کلاستر را از نو بسازند، که فرآیندی زمانبر و مستعد خطا است.
فرآیند ارتقای دو مرحلهای چگونه کار میکند
جریان جدید، ارتقا را به دو مرحله مجزا تقسیم میکند:
- مرحله ۱ – ارتقای باینری (حالت شبیهسازی شده). GKE باینریهای کنترلپلین را به نسخه هدف تغییر میدهد در حالی که فرمت دادههای قدیمی را حفظ میکند. از آنجایی که هیچ ساختار داده جدیدی نوشته نمیشود، کلاستر در طول این مرحله از نظر قابلیت بازگشت (rollback) ایمن باقی میماند.
- مرحله ۲ – نهاییسازی. پس از یک دوره انتظار قابل تنظیم، GKE دادههای ذخیرهشده را به فرمت جدید تبدیل میکند. پس از اتمام این تبدیل، بازگشت به حالت قبل مستلزم همان تلاش برای بازیابی اسنپشات خواهد بود که فرآیند دو مرحلهای برای جلوگیری از آن طراحی شده است.
این جداسازی یک «بازه پایداری» (soak window) ایجاد میکند که در آن اپراتورها میتوانند باینریهای ارتقایافته را در محیط عملیاتی مشاهده کنند، بدون اینکه خود را متعهد به مهاجرت غیرقابل بازگشت دادهها کنند.
بازه پایداری (soak window) در عمل
GKE بهطور خودکار معیارهای کلیدی سلامت را در طول دوره پایداری نظارت میکند؛ از جمله تأخیر API، نرخ خطا و سلامت پادها (pods). اگر سرویس متوجه ناهنجاری شود، فرآیند انتشار را متوقف میکند و کلاستر را در حالت «فقط باینری» باقی میگذارد که در آن بازگشت به حالت قبل همچنان امکانپذیر است. گوگل نرخ موفقیت ۹۹.۹۹۹ درصدی را برای ارتقاهایی که از این الگو پیروی میکنند، ذکر کرده است.
برای کلاسترهایی که از قابلیت ارتقای خودکار (auto-upgrade) در GKE استفاده میکنند، پلتفرم کل توالی دو مرحلهای را بدون دخالت دستی مدیریت میکند. کاربرانی که کنترل کامل را ترجیح میدهند، میتوانند این فرآیند را از طریق Cloud CLI یا Terraform اجرا کنند.
اجرای دستی ارتقای دو مرحلهای
یک ارتقای دستی معمولی با بازه ایمنی ۴۸ ساعته به این صورت است:
gcloud beta container clusters upgrade my-cluster \
--location=us-central1 \
--cluster-version=1.34.1-gke.1829001 \
--control-plane-soak-duration=48h \
--master
برای بررسی وضعیت فعلی:
gcloud container clusters describe my-cluster \
--location=us-central1 \
--format="yaml(rollbackSafeUpgradeStatus)"
اگر در طول دوره پایداری مشکلی بروز کند، مدیر میتواند دستور بازگشت (rollback) را صادر کرده و بدون از دست رفتن دادهها به نسخه قبلی برگردد. هنگامی که پایداری کلاستر تأیید شد، ارتقا را میتوان زودتر با دستور complete-control-plane-upgrade تکمیل کرد.
محدودیتها و الزامات
- این ویژگی برای کلاسترهای GKE که نسخه ۱.۳۳ یا بالاتر را اجرا میکنند، اعمال میشود.
- در هر بار فقط میتوان یک نسخه فرعی را ارتقا داد؛ پرش از نسخهها پشتیبانی نمیشود.
- هر دو حالت Autopilot و کلاسترهای منطقهای (regional) در طول فرآیند دو مرحلهای در دسترس باقی میمانند.
معایب احتمالی
جداسازی ارتقای باینری و داده، یک مرحله اضافی به زمانبندی ارتقا اضافه میکند که ممکن است برای سازمانهایی که نیاز به تغییرات سریع نسخه دارند، بازه زمانی کلی را طولانیتر کند. همچنین دوره پایداری به بررسیهای سلامت خودکار متکی است؛ تیمهایی که از بارهای کاری بسیار سفارشی استفاده میکنند، ممکن است نیاز داشته باشند نظارت GKE را با ابزارهای مشاهدهپذیری (observability) خود تکمیل کنند تا عقبگردهای (regressions) موارد خاص را شناسایی کنند.
آنچه باید در آینده دنبال کرد
گوگل نقشه راهی برای گسترش مدل دو مرحلهای به ارتقای نسخههای اصلی (major version) منتشر نکرده است، که در بسیاری از موارد همچنان نیازمند بازسازی کامل کلاستر است. ناظران منتظر اعلام خبرهایی درباره شبکههای ایمنی مشابه برای ارتقای نود-پولها (node-pool) و همچنین هرگونه ادغام با خط لولههای CI/CD شخص ثالث خواهند بود که میتواند بررسیهای بازه پایداری را خودکار کند.
نتیجهگیری: GKE با جداسازی ارتقای باینری از مهاجرت دادهها، به مهندسان پلتفرم یک بازه بازگشت کاربردی برای تغییرات نسخه فرعی میدهد و در عین حال که زمان خرابی (downtime) را به حداقل میرساند، هزینه عملیاتی نگهداری کلاستر را کاهش میدهد.