الإصدار الذي علّمني احترام الـ rollouts خرج يوم جمعة في الرابعة عصرًا (أعرف). كان في الإصدار الجديد خطأ إملائي في اسم متغيّر بيئة، فلم يستطع الوصول إلى قاعدة البيانات. لم يكن في الـ Deployment أي readiness probe، وكانت إعدادات الـ rollout افتراضية، فاستبدل Kubernetes بكل سرور كل Pod يعمل بآخر يُرجع أخطاء 500. استغرق الأمر ست دقائق لنلاحظ، وأربعين ثانية لنتراجع. هذا الدرس عن جعل الجزء الأول مستحيلًا والجزء الثاني روتينيًا.
\nحين تغيّر أي شيء في قالب الـ Pod في Deployment، وعادةً الـ image، ينشئ الـ Deployment ReplicaSet جديدًا للقالب الجديد ويبدأ في نقل النسخ من القديم إلى الجديد. إعدادان يحدّدان الوتيرة:
\nspec:\n revisionHistoryLimit: 10\n minReadySeconds: 10\n progressDeadlineSeconds: 300\n strategy:\n type: RollingUpdate\n rollingUpdate:\n maxSurge: 1\n maxUnavailable: 0maxSurge: كم Pod فوق العدد المرغوب يمكن أن يوجد أثناء التحديث. مع 4 نسخ وmaxSurge: 1، يمكن أن يوجد 5 Pods في وقت واحد.maxUnavailable: كم Pod تحت العدد المرغوب يُتسامح معه. عند 0 لا تنخفض السعة أبدًا.minReadySeconds: يجب أن يبقى الـ Pod الجديد جاهزًا هذه المدة قبل أن يُعدّ متاحًا. هذا يلتقط الإصدارات التي تجتاز الـ readiness ثم تنهار بعد عشر ثوانٍ.progressDeadlineSeconds: إذا لم يحرز الـ rollout أي تقدّم طوال هذه المدة، يُبلغ الـ Deployment بأنه فشل.القيم الافتراضية هي 25% للزيادة و25% لعدم الإتاحة. أنا أضبط maxUnavailable: 0 على كل خدمة تواجه المستخدمين: لا يُزال Pod قديم إلا بعد أن يصبح Pod جديد جاهزًا. ومع الـ readiness probe من الدرس 5.1، لا يستطيع إصدار معطوب أخذ الحركة من إصدار يعمل. إنه يتوقّف مع Pod جديد واحد غير جاهز بينما تخدم الـ Pods القديمة.
الاستراتيجية الأخرى، Recreate، تحذف كل الـ Pods القديمة قبل تشغيل الجديدة. استخدمها فقط حين لا يستطيع الإصداران فعلًا العمل جنبًا إلى جنب، واقبل التوقّف.
غيّر الـ image في k8s/deployment.yaml وطبّق، ثم راقب:
kubectl apply -f k8s/deployment.yaml\nkubectl rollout status deployment/notes-api --timeout=5mالأمر rollout status ينتظر حتى يكتمل الـ rollout أو يفشل، ويخرج برمز غير صفري عند الفشل، فيستطيع الـ CI استخدامه كخطوة «هل نجح النشر؟». إذا فشل، أو صارت لوحات المتابعة حمراء بعد نجاحه:
kubectl rollout history deployment/notes-api\nkubectl rollout undo deployment/notes-api\nkubectl rollout undo deployment/notes-api --to-revision=7كل ReplicaSet قديم (حتى revisionHistoryLimit) هدف تراجع جاهز. الأمر undo يوسّع السابق من جديد باستخدام قواعد التحديث المتدرّج نفسها، فيكون التراجع آمنًا مثل التقدّم ويستغرق بضع ثوانٍ. ولتجعل history مقروءًا، سجّل سبب وجود كل revision: kubectl annotate deployment/notes-api kubernetes.io/change-cause="1.5.0: bulk export".
بعد الـ undo، يشغّل الـ cluster الإصدار 1.4.0 بينما يقول Git 1.5.0. اعكس الـ commit فورًا، وإلا فسيعيد الـ apply الروتيني التالي نشر الخلل.
\n\nصار مجلد k8s/ الخاص بـ notes-api ستة ملفات، وبيئة staging تحتاج إلى عدد نسخ وموارد وtags مختلفة عن الإنتاج. Helm يغلّف الـ manifests في chart: قوالب فيها عناصر نائبة، مع ملف values.yaml للقيم الافتراضية تتجاوزه كل بيئة.
charts/notes-api/\n Chart.yaml\n values.yaml\n templates/\n deployment.yaml\n service.yaml\n hpa.yaml\n configmap.yaml containers:\n - name: api\n image: \"{{ .Values.image.repository }}:{{ .Values.image.tag }}\"\n resources:\n {{- toYaml .Values.resources | nindent 12 }}image:\n repository: ghcr.io/skylane/notes-api\n tag: \"1.5.1\"\nresources:\n requests: { cpu: 250m, memory: 256Mi }\n limits: { memory: 512Mi }الأوامر تحاكي ما فعلته بـ kubectl:
\nhelm lint charts/notes-api\nhelm template notes-api charts/notes-api -f charts/notes-api/values-prod.yaml\nhelm upgrade --install notes-api charts/notes-api -n notes -f charts/notes-api/values-prod.yaml\nhelm history notes-api -n notes\nhelm rollback notes-api 4 -n notesالأمر helm template يولّد الـ YAML محليًا حتى تراجعه. وupgrade --install يثبّت في المرة الأولى ويرقّي بعدها، مسجّلًا release revision مرقّمة في كل مرة. وhelm rollback يعيد تطبيق المجموعة الكاملة من manifests revision سابقة، بما فيها الـ ConfigMap، وهذا أوسع من kubectl rollout undo. Helm 4، الصادر أواخر 2025، أعاد تسمية بعض الخيارات؛ فمثلًا --atomic، الذي يتراجع تلقائيًا حين تفشل الترقية، صار الآن --rollback-on-failure.
تستطيع الآن شحن إصدار ومراقبته وعكسه بثقة. الدرس الأخير يُدخل الحركة إلى الـ cluster كما يجب، ويجمع دليل التشخيص لتلك اللحظات التي يحدث فيها خلل رغم كل شيء.
\n","toc":[{"id":"sec-1","text":"كيف يعمل التحديث المتدرّج","level":2},{"id":"sec-2","text":"انشر وراقب وتراجع","level":2},{"id":"sec-3","text":"التغليف بـ Helm","level":2}],"takeaways":["التحديث المتدرّج يوسّع ReplicaSet جديدًا ويقلّص القديم، بوتيرة يضبطهاmaxSurge وmaxUnavailable، ولا يتقدّم إلا بقدر ما تسمح به الـ readiness.","مع maxUnavailable على 0، يتوقّف الإصدار الذي لا تصبح الـ Pods الخاصة به جاهزة أبدًا دون ضرر، بينما يستمر الإصدار القديم في الخدمة.","الأمر kubectl rollout undo يعود إلى الـ ReplicaSet السابق خلال ثوانٍ، لكن حدّث Git أيضًا وإلا فسيعيد الـ apply التالي نشر الإصدار السيئ.","التراجع عن الكود لا يتراجع عن قاعدة البيانات، لذا يجب أن تعمل تغييرات المخطّط مع الإصدارين القديم والجديد معًا.","Helm يغلّف الـ manifests كقوالب مع قيم؛ والأمر helm upgrade --install ينشر، وhelm rollback يعود إلى release revision سابقة."],"further":[{"title":"Deployments (rolling update and rollback)","url":"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment"},{"title":"Performing a Rolling Update","url":"https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/"},{"title":"kubectl rollout","url":"https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/"}],"quiz":[{"q":"يعمل notes-api بـ 4 نسخ مع maxSurge 1 وmaxUnavailable 0. Pods الإصدار 1.5.0 تنهار عند البدء. ماذا يلاحظ المستخدمون؟
Recreate. التحديثات المتدرّجة تُبقي الـ ReplicaSet القديم حتى يصبح الجديد جاهزًا."},{"text":"يفشل نحو ربع الطلبات حتى يتدخّل أحد.","why":"قد يحدث هذا مع maxUnavailable أكبر من صفر ودون readiness probe. أما هنا فالـ Pod الفاشل لا يستقبل أي حركة."},{"text":"يتراجع Kubernetes تلقائيًا إلى 1.4.0 بعد انتهاء المهلة.","why":"يعلّم Kubernetes الـ rollout بأنه فاشل بعد progressDeadlineSeconds، لكنه لا يتراجع من تلقاء نفسه."}],"answer":0},{"q":"شغّلت kubectl rollout undo deployment/notes-api أثناء حادث فتعافت الخدمة. ما الذي يجب أن يحدث بعد ذلك؟
kubectl apply التالي نشر الإصدار المعطوب.","why":"صحيح. يجب أن يتّفق Git والـ cluster. أصلح مصدر الحقيقة قبل أن يشغّل أحد الـ deploy التالي."}],"answer":3},{"q":"الإصدار 1.5.0 يعيد تسمية العمود body في قاعدة البيانات إلى content عبر migration. في 1.5.0 خلل فتتراجع إلى 1.4.0. ماذا يحدث؟
body، الذي لم يعد موجودًا.","why":"صحيح. لهذا يجب أن تكون تغييرات المخطّط على نمط التوسعة ثم التقليص (أضف الجديد، ورحّل، واحذف القديم لاحقًا)، حتى يعمل الإصداران المتجاوران كلاهما."},{"text":"يعيد Postgres تسمية العمود إلى اسمه القديم حين تصل الاستعلامات القديمة.","why":"قواعد البيانات لا تتراجع عن تغييرات المخطّط استجابة للاستعلامات."},{"text":"لا شيء ينكسر، لأن image الإصدار 1.4.0 تتضمّن مخطّطها الخاص.","why":"الـ images تحمل الكود، لا حالة قاعدة البيانات. المخطّط يعيش في Postgres."}],"answer":1},{"q":"تريد رؤية YAML Kubernetes الدقيق الذي سينتجه Helm chart للإنتاج قبل تثبيته. أي أمر تستخدم؟
","options":[{"text":"helm history notes-api","why":"هذا يسرد الإصدارات السابقة لـ chart مثبّت، لا الـ manifests المولّدة."},{"text":"helm rollback notes-api 0","why":"هذا يغيّر الـ cluster؛ ولا يعاين أي شيء."},{"text":"helm template notes-api ./charts/notes-api -f values-prod.yaml","why":"صحيح. يولّد القوالب بقيمك محليًا ويطبع الـ YAML، فتستطيع قراءته أو مقارنته."},{"text":"kubectl get all -n notes","why":"هذا يعرض ما يعمل أصلًا، لا ما سينشئه الـ chart."}],"answer":2}],"exercise":{"kind":"fill","language":"bash","template":"# Wait for the 1.5.0 rollout to finish (fails after 5 minutes)\nkubectl rollout {{0}} deployment/notes-api --timeout=5m\n\n# It's failing in production: list revisions, then go back one\nkubectl rollout {{1}} deployment/notes-api\nkubectl rollout {{2}} deployment/notes-api\n\n# On the Helm-managed staging cluster, return to release revision 4\nhelm {{3}} notes-api 4 -n notes","blanks":[{"answers":["status"]},{"answers":["history"]},{"answers":["undo"]},{"answers":["rollback"]}],"title":"راقبه، ثم استرجعه","prompt":"الإصدار 1.5.0 قيد النشر (rollout). املأ الفراغات لانتظار الـ rollout، وسرد revisions الـ Deployment، والتراجع إلى السابقة، وإعادة release staging الذي يديره Helm إلى الـ revision رقم 4.
\n","hints":["الأوامر الفرعية الثلاثة لـkubectl rollout كلمة واحدة لكل منها: واحد ينتظر، وواحد يسرد، وواحد يعكس.","أمر Helm للعودة إلى release سابق يحمل اسم المفهوم نفسه."],"explanation":"kubectl rollout status deployment/notes-api --timeout=5m\nkubectl rollout history deployment/notes-api\nkubectl rollout undo deployment/notes-api\nhelm rollback notes-api 4 -n notesالأمر status ينتظر حتى ينتهي الـ rollout ويخرج برمز غير صفري إن فشل، وهذا يجعله بوّابة جيدة في الـ CI. وundo يوسّع الـ ReplicaSet السابق من جديد بقواعد التحديث المتدرّج نفسها. وhelm rollback يعيد تطبيق كل الـ manifests من release revision رقم 4. بعد ذلك، اعكس التغيير في Git حتى لا يعيد الـ deploy التالي الإصدار 1.5.0.