أعلنت Google Cloud أن خدمة GKE الخاصة بها توفر الآن ترقيات لمستوى التحكم (control-plane) بخطوتين متاحة بشكل عام، مما يتيح للعملاء فصل ترقية الملفات الثنائية (software binary upgrade) عن ترحيل تنسيق البيانات (data-format migration) وإبقاء نافذة التراجع (rollback window) مفتوحة أثناء تغييرات الإصدارات الفرعية.

لماذا احتاجت GKE إلى مسار أكثر أماناً

لطالما انطوت عملية ترقية مستوى التحكم في Kubernetes من إصدار فرعي إلى الإصدار الذي يليه على مخاطر. فالمرحلة من 1.33 إلى 1.34 لا تستبدل الملفات الثنائية فحسب، بل تعيد أيضاً كتابة هياكل البيانات الأساسية. وإذا احتوى الإصدار الجديد على خطأ برمجِيّ، فلا يمكن ببساطة التراجع عن العنقود (cluster)؛ بل يجب على المسؤولين استعادة لقطات (snapshots) قديمة لقاعدة البيانات أو إعادة بناء العنقود بالكامل، وهي عملية تستغرق وقتاً طويلاً وعرضة للأخطاء.

كيف تعمل الترقية المكونة من خطوتين

يقسم التدفق الجديد الترقية إلى مرحلتين متميزتين:

  • الخطوة 1 – ترقية الملفات الثنائية (وضع المحاكاة). تقوم GKE باستبدال الملفات الثنائية لمستوى التحكم بالإصدار المستهدف مع الحفاظ على تنسيق البيانات القديم. ولأنه لا يتم كتابة هياكل بيانات جديدة، يظل العنقود آمناً للتراجع (rollback-safe) طوال هذه المرحلة.
  • الخطوة 2 – الإنهاء (Finalization). بعد فترة انتظار قابلة للتهيئة، تقوم GKE بتحويل البيانات المخزنة إلى التنسيق الجديد. وبمجرد انتهاء عملية التحويل هذه، سيتطلب التراجع نفس مجهود استعادة اللقطات (snapshot-restore) الذي صُممت عملية الخطوتين لتجنبه.

يخلق هذا الفصل "نافذة اختبار" (soak window) حيث يمكن للمشغلين مراقبة الملفات الثنائية التي تمت ترقيتها في بيئة الإنتاج دون الالتزام بعملية ترحيل البيانات غير القابلة للتراجع.

نافذة الاختبار في الممارسة العملية

تقوم GKE تلقائياً بمراقبة مقاييس الصحة الرئيسية خلال فترة الاختبار — مثل زمن استجابة API، ومعدلات الخطأ، وصحة الـ pods. وإذا اكتشفت الخدمة أي حالات شاذة، فإنها توقف عملية النشر، مما يترك العنقود في حالة "الملفات الثنائية فقط" حيث لا يزال التراجع ممكناً. وتذكر Google أن نسبة النجاح في الترقيات التي تتبع هذا النمط تصل إلى 99.999%.

بالنسبة للعناقيد التي تستخدم ميزة الترقية التلقائية (auto-upgrade) في GKE، تقوم المنصة بتنسيق تسلسل الخطوتين بالكامل دون تدخل يدوي. أما المستخدمون الذين يفضلون التحكم الكامل، فيمكنهم استدعاء العملية من خلال Cloud CLI أو Terraform.

تشغيل ترقية يدوية مكونة من خطوتين

تبدو الترقية اليدوية النموذجية مع نافذة أمان مدتها 48 ساعة كما يلي:

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 التي تعمل بالإصدار 1.33 أو أحدث.
  • يمكن ترقية إصدار فرعي واحد فقط في كل مرة؛ ولا يتم دعم تخطي الإصدارات.
  • تظل كل من Autopilot والعناقيد الإقليمية (regional clusters) متاحة طوال عملية الخطوتين.

السلبيات المحتملة

يضيف فصل ترقيات الملفات الثنائية عن ترقيات البيانات خطوة إضافية إلى الجدول الزمني للترقية، مما قد يطيل النافذة الإجمالية للمؤسسات التي تحتاج إلى تغييرات سريعة في الإصدارات. كما تعتمد فترة الاختبار على فحوصات الصحة الآلية؛ لذا قد تحتاج الفرق التي تشغل أعباء عمل مخصصة للغاية إلى تعزيز مراقبة GKE بأدوات المراقبة والتحليل (observability tooling) الخاصة بها لالتقاط أي تراجعات في الحالات الاستثنائية.

ما يجب مراقبته لاحقاً

لم تكشف Google عن خارطة طريق لتوسيع نموذج الخطوتين ليشمل ترقيات الإصدارات الرئيسية (major version upgrades)، والتي لا تزال تتطلب إعادة إنشاء العنقود بالكامل في كثير من الحالات. وسينتظر المراقبون إعلانات حول شبكات أمان مماثلة لترقيات مجموعات العقد (node-pool upgrades) وأي تكامل مع خطوط أنابيب CI/CD التابعة لجهات خارجية والتي يمكن أن تؤتمت فحوصات نافذة الاختبار.

الخلاصة: من خلال فصل ترقيات الملفات الثنائية عن عمليات ترحيل البيانات، تمنح GKE مهندسي المنصات نافذة تراجع عملية لتغييرات الإصدارات الفرعية، مما يقلل التكلفة التشغيلية لصيانة العنقود مع إبقاء وقت التوقف عن العمل في حده الأدنى.