kubectl rollout
متابعة النشر والتراجع عنه kubectl rollout
kubectl rollout يتابع تقدّم تحديث Deployment ويتيح التراجع الفوري للإصدار السابق عند فشل النشر، وهو الأداة الأساسية لأتمتة النشر الآمن في CI/CD.
بعد kubectl apply أو kubectl set image، يبدأ Kubernetes بتحديث النسخ (Pods) وفق استراتيجية Rolling Update تدريجياً. kubectl rollout status deployment/<اسم> يبقى منتظراً حتى اكتمال التحديث بنجاح، وهو ما يجعله مثالياً كخطوة CI تتحقق فعلياً من نجاح النشر بدل الاكتفاء بنجاح أمر apply نفسه.
كل تحديث لـ Deployment يُخزَّن كنسخة (revision) في تاريخ الطرح، فـ kubectl rollout undo يتراجع فوراً لآخر نسخة مستقرة معروفة دون الحاجة لإعادة تطبيق ملف YAML قديم يدوياً. kubectl rollout history يعرض قائمة كل النسخ السابقة لاختيار نسخة محددة للتراجع إليها إذا لزم.
الصياغة
kubectl rollout status deployment/<اسم> kubectl rollout undo deployment/<اسم> kubectl rollout history deployment/<اسم>
📄 مثال
# داخل خطوة نشر CI/CD:
kubectl set image deployment/my-app my-app=ghcr.io/org/my-app:${GITHUB_SHA}
kubectl rollout status deployment/my-app
# عند فشل الفحص الصحي بعد النشر:
kubectl rollout undo deployment/my-appأهم النقاط
| العنصر | الوظيفة |
|---|---|
| kubectl rollout status | ينتظر ويعرض تقدّم التحديث حتى اكتماله أو فشله |
| kubectl rollout undo | يتراجع فوراً لآخر نسخة مستقرة معروفة |
| kubectl rollout history | يعرض قائمة النسخ (revisions) السابقة للتحديثات |
| --to-revision | يحدد نسخة معينة بالضبط للتراجع إليها بدل آخر نسخة فقط |
💡 نصائح عملية
- اجعل kubectl rollout status جزءاً إلزامياً من pipeline النشر — بدونه لا تعرف فعلياً هل نجح التحديث أم لا يزال قيد التنفيذ
- أضف خطوة rollout undo تلقائية في CI عند فشل فحص صحي بعد النشر مباشرة بدل التدخل اليدوي
⚠️ أخطاء شائعة
- اعتبار نجاح kubectl apply دليلاً كافياً على نجاح النشر — apply قد ينجح بينما التحديث الفعلي لا يزال يفشل أو عالقاً
- تشغيل rollout undo متكرراً دون فهم السبب الجذري للفشل — يعالج العرض لا المشكلة
خصائص ذات صلة
🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار DEVOPS الكامل بالعربي.
📚 للتعمق التقني الكامل بالإنجليزية: MDN Web Docs