الدرس 7: التحديثات المتدرّجة والتراجع (rollback)
لدينا بالفعل Deployment يُبقي عدّة نسخ (Pods) من التطبيق قيد التشغيل. لكن ماذا يحدث عندما تريد إطلاق إصدار جديد — مثلاً استبدال الـ image من nginx:1.27 إلى nginx:1.28؟ الطريقة الساذجة هي إسقاط كل شيء وإعادة بنائه، لكن عندئذٍ تتوقّف الخدمة لبضع ثوانٍ ويشعر بذلك كل مستخدم. يحلّ Kubernetes هذه المشكلة
إنه أشبه بتبديل عجلات سيارة متحرّكة دون إيقافها — تستبدل عجلة واحدة في كل مرة، فتواصل السيارة سيرها. وإذا كانت العجلة الجديدة معوجّة، فما عليك سوى إعادة القديمة.
- التحديث المتدرّج
- طريقة لتحديث Deployment دون أيّ توقّف: يستبدل Kubernetes الـ Pods القديمة بأخرى جديدة تدريجياً، بضعة في كل مرة، بحيث تبقى دائماً نسخ حيّة كافية لخدمة الطلبات.
- التراجع
- إعادة الـ Deployment إلى الإصدار (revision) السابق الذي كان يعمل عندما يتبيّن أنّ الإصدار الجديد معطوب. الأمر kubectl rollout undo يفعل ذلك في خطوة واحدة.
- حالة الـ rollout
- متابعة حيّة لتقدّم التحديث: كم عدد الـ Pods التي جرى تحديثها بالفعل من الإجمالي، حتى تؤكّد رسالةٌ أنّ الـ rollout اكتمل بنجاح.
- maxUnavailable
- كم عدد الـ Pods المسموح بأن تكون غير متاحة في آنٍ واحد أثناء التحديث المتدرّج. القيمة المنخفضة تُبقي عدداً أكبر من النسخ حيّاً في كل لحظة لكنها تُبطئ التحديث.
- maxSurge
- كم عدد الـ Pods الإضافية المسموح بإنشائها مؤقتاً بما يتجاوز العدد المستهدف أثناء التحديث، بحيث تكون النسخ الجديدة جاهزة قبل إزالة القديمة.
- مراجعة (revision)
- نسخة محفوظة من الـ Deployment. كل تحديث يُنشئ مراجعة (revision) جديدة، ويتذكّر Kubernetes المراجعات السابقة لتتمكّن من العودة إليها.
