ترقيات Kubernetes

تنقل الترقية المجموعة إلى إصدار أحدث من Kubernetes في مكانها: تحتفظ عُقدها بأسمائها وعناوينها ووحدات تخزينها. تأخذ المنصّة أولًا لقطة من حالة المجموعة، ثم ترقّي مستوى التحكم، ثم العُقد العاملة، عقدة واحدة في كل مرة. وتنتقل إضافات النظام في المجموعة مع Kubernetes في الترقية نفسها، وقد اختُبرت معًا: خدمة DNS للمجموعة، ووكيل الخدمات، وشبكة الـ Pods وسياسات الشبكة، وإضافات الشبكة، والصلة بمستوى التحكم، وواجهة المقاييس، وموزّع الحمل على العُقد، وصورة بيئة تشغيل الـ Pod (pod sandbox).

أنت تقرّر موعد الترقية: الآن، أو في وقت تجدوله. وحين نعرض إصدارًا على المجموعة تحصل على فترة سماح لتنفيذها خلالها، وبعدها نرقّي المجموعة خلال نافذة الصيانة الخاصة بها.

الإصدارات التي تنتقل إليها المجموعة

• أحدث إصدار تصحيحي ضمن إصدارها الثانوي، مثل الانتقال من 1.36.4 إلى 1.36.5، بعلامة إصدار تصحيحي. ويحمل الإصدار التصحيحي إصلاحات للأخطاء وإصلاحات أمنية للإصدار الثانوي نفسه.
• الإصدار الثانوي التالي، مثل الانتقال من 1.36 إلى 1.37، بعلامة إصدار ثانوي. ويحمل الإصدار الثانوي ميزات جديدة وقد يزيل واجهات API أُعلن من قبل عن إيقافها (deprecated)، فافحص ما تستخدمه ملفات التعريف (manifests) ومخططات Helm وأدواتك قبل أن تنتقل إليه.

تجري الترقيات إصدارًا ثانويًا واحدًا في كل مرة، ولا تعود إلى إصدار أقدم أبدًا: للانتقال من 1.36 إلى 1.38 انتقل إلى 1.37 أولًا. ولا نعرض إلا إصدارات اختبرناها واعتمدناها. وتعرض صفحة المجموعة الإصدار الدقيق الذي تعمل به، مثل Kubernetes 1.36.4.

وبعد الترقية إلى إصدار ثانوي جديد، استخدم kubectl لا يبعد عن إصدار المجموعة بأكثر من إصدار ثانوي واحد، مثل kubectl من 1.36 إلى 1.38 للإصدار 1.37: فالإصدارات الأقدم قد لا تعمل معها.

الترقية الآن أو جدولتها

في نظرة عامة للمجموعة، تسرد بطاقة تتوفّر ترقية كل إصدار تستطيع المجموعة الانتقال إليه، مع ما الذي يحدث أثناء الترقية وما الذي يتغيّر: إصدار Kubernetes وكل إضافة، من أي إصدار وإلى أي إصدار، مع رابط إلى ملاحظات الإصدار. واختر للإصدار الذي تريده:

• ترقية الآن لتبدأ فورًا.
• جدولة لتختار تاريخًا ووقتًا، بحسب منطقتك الزمنية، في غضون 30 يومًا. ولإصدار عرضناه يجب أن يقع أيضًا قبل نهاية فترة السماح الخاصة به.

وقبل أن تبدأ الترقية، تذكر نافذة تأكيدها أيضًا ما وجدته الرؤى في المجموعة مما يعيقها أو ما ستعطّله. وتنتظر الترقية إلى إصدار ثانوي كل نتيجة تعيقها حتى تصلحها أو تقبلها، مع ذكر السبب، في قسم الرؤى للمجموعة.

والترقيات التي تبدؤها أو تجدولها بنفسك تجري في الوقت الذي تختاره، داخل نافذة الصيانة أو خارجها. ويمكنك بدء ترقية ما دامت المجموعة جاهزة، ولا تُفتح في المجموعة إلا ترقية واحدة في كل مرة، والعرض من بينها: فما دمنا نعرض عليها إصدارًا، فابدأ بالترقية إليه.

وتبدأ الترقية حين تستقر المجموعة: كل عُقدها جاهزة، ولا تغيير في مجمّعات العُقد ولا نسخ احتياطي أو استعادة قيد التنفيذ. وإن بقيت المجموعة مشغولة بعد 30 دقيقة من موعد الترقية، فلا تبدأ الترقية، وتبيّن لوحة التحكم ذلك.

يستطيع المالكون والمسؤولون والمطوّرون ترقية المجموعة، وجدولة الترقية أو إلغاءها، وضبط نافذة الصيانة. ويستطيع المشاهدون رؤيتها.

العروض وفترة السماح

نعرض الإصدار الجديد على المجموعات التي يرقّيها. وتحصل كل مجموعة نعرضه عليها على فترة سماح:

• إلى أن تنتهي فترة السماح، اختر ترقية الآن، أو جدولة وقت قبل نهايتها.
• وحين تنتهي يحين موعد ترقية المجموعة، فنرقّيها خلال نافذة الصيانة الخاصة بها. وإلى أن نفعل، يبقى بإمكانك اختيار ترقية الآن.
• لا يمكن تأجيل نهاية فترة السماح من لوحة التحكم. وإن احتجت إلى وقت أطول، فتواصل مع فريق الدعم، فهو يستطيع تمديدها.
• لا تُرقّى أي مجموعة بمؤقّت تلقائي: بعد فترة السماح يبدأ فريقنا الترقيات، وتبدأ كل منها في نافذة صيانة مجموعتها. ولا نرقّي مجموعة قبل نهاية فترة السماح أو خارج نافذتها إلا في حالة طارئة، كإصلاح أمني لا يحتمل الانتظار.

وتجد نهاية دعم كل إصدار ثانوي في مرجع Kubernetes، ويُبلَّغ مالكو مساحة العمل ومديروها بالبريد الإلكتروني قبلها بـ 30 يومًا و7 أيام.

نافذة الصيانة

نافذة الصيانة هي الوقت الذي يجوز لنا فيه ترقية المجموعة بعد انتهاء فترة السماح. وهي افتراضيًا أيام الثلاثاء والأربعاء والخميس من الساعة 23:00 بتوقيت UTC، لمدة 4 ساعات: من 02:00 إلى 06:00 بتوقيت عمّان.

لتغييرها، افتح الإعدادات في المجموعة وانتقل إلى نافذة الصيانة:

وفيما عدا الافتراضية، تكون الأيام ووقت البدء بحسب منطقة زمنية، هي في البداية منطقتك أنت؛ واختر غيرها من المنطقة الزمنية. ومع التوقيت الصيفي يتبع وقت البدء الساعة المحلية، ولا تقصر النافذة أبدًا. وتعرض البطاقة موعد فتح النافذة التالي، بمنطقتك الزمنية وبمنطقة النافذة. واختر حفظ النافذة لتحفظها.

• لا تبدأ الترقيات التي نبدؤها نحن إلا داخل النافذة، ولا يبدأ مستوى التحكم فيها بالانتقال إلا إذا بقيت من النافذة ساعة على الأقل. والعقدة العاملة التي تكون قيد الترقية حين تُغلق النافذة تكمل ترقيتها، وتنتظر التالية النافذة التالية.
• أما الترقيات التي تبدؤها أو تجدولها بنفسك فلا تتقيد بها.

ما يجري أثناء الترقية

1. التجهيز. تنزّل كل عقدة الإصدار الجديد وتتحقق منه، وتحمّل العُقد العاملة الصور الجديدة للإضافات. ولا يُعاد تشغيل شيء بعد.
2. اللقطة. تأخذ المنصّة لقطة من حالة المجموعة، مثل النسخ الاحتياطية لحالة المجموعة التي تُؤخذ كل ساعة. ويبدأ مستوى التحكم خلال 15 دقيقة منها، وإلا فتُؤخذ لقطة أخرى.
3. مستوى التحكم. تُرقّى عُقده واحدة تلو الأخرى. ومن دون التوافر العالي تتوقف واجهة المجموعة نحو دقيقة أثناء إعادة تشغيل مستوى التحكم، وتواصل أحمال عملك العمل. ومع التوافر العالي تبقى الواجهة تجيب. ثم تنتقل الإضافات إلى إصداراتها الجديدة، وتنتظر العُقد العاملة حتى تعمل كلها وتجهز.
4. العُقد العاملة، مجمّعًا بعد مجمّع، واحدة في كل مرة. وتُفحص كل منها قبل أن تبدأ التالية: يجب أن تكون Pods النظام عليها جاهزة بإصداراتها الجديدة.
   • الإصدار التصحيحي يرقّي كل عقدة عاملة في مكانها دون تفريغها، فتواصل الـ Pods عليها العمل.
   • الإصدار الثانوي يفرّغ العقدة العاملة أولًا حين يكون في مجمّع عُقدها عقدة عاملة جاهزة أخرى تستقبل الـ Pods، ثم يرقّيها. ويحترم التفريغ ميزانيات تعطّل الـ Pods لديك ولا يُخرج أي Pod بالقوة: فحين لا تسمح ميزانية بخروج Pod، ينتظر ويعرض الـ Pods التي توقفه. أما العقدة العاملة الوحيدة في مجمّعها، كالعقدة العاملة الوحيدة في المجموعة، فتُرقّى في مكانها والـ Pods عليها تعمل.
5. الاكتمال. تعمل كل العُقد بالإصدار الجديد، وقد انتقلت الإضافات معه. والعُقد العاملة التي تُضاف لاحقًا، أو التي تحلّ محل عقدة متعطّلة، تنضم بالإصدار الجديد.

والعقدة التي لا تعود سليمة على الإصدار الجديد تعود إلى الإصدار الذي كانت تعمل به، وتتوقف الترقية عندها، وتبيّن لوحة التحكم ما حدث. ويُنبَّه فريقنا، ويستطيع متابعة الترقية من تلك العقدة أو إعادة العُقد التي رُقّيت إلى إصدارها السابق. وإن توقفت الترقية قبل أن يبدأ مستوى التحكم بالانتقال، فلم يتغيّر شيء في المجموعة.

أثناء سير الترقية

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

ميزانيات تعطّل الـ Pods

تفرّغ الترقية إلى إصدار ثانوي العُقدَ العاملة بإخلاء الـ Pods التي عليها (eviction)، مع مهلة الإنهاء الكاملة لكل منها، لذا تحدّد ميزانية تعطّل الـ Pods (PodDisruptionBudget) عدد Pods حمل العمل التي يجوز أن تغيب في وقت واحد. شغّل نسختين (replicas) على الأقل من كل ما يجب أن يبقى عاملًا، وامنحه ميزانية تسمح بخروج واحدة في كل مرة:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: web

kubectl apply -f web-pdb.yaml
kubectl get pdb web

يعرض ALLOWED DISRUPTIONS عدد الـ Pods التي يجوز خروجها الآن. والميزانية التي لا تسمح بأي خروج، مثل maxUnavailable: 0 أو minAvailable يساوي عدد النسخ، توقف التفريغ: فتبقى العقدة العاملة على نقل الـ Pods وتسرد الـ Pods التي تنتظرها. أضف نسخة أو خفّف الميزانية، فيتابع التفريغ من تلقاء نفسه.

• والـ Pod الذي لا يديره أي متحكّم (controller)، كالذي يُشغَّل بـ kubectl run، يوقف التفريغ كذلك، لأن لا شيء سيشغّله من جديد في مكان آخر: احذفه، أو شغّله من Deployment.
• وحمل العمل ذو النسخة الواحدة يتوقف ريثما يعود الـ Pod إلى العمل على عقدة عاملة أخرى.
• ولا تنتقل بيانات emptyDir مع الـ Pod: تُحذف حين يغادر العقدة العاملة.

وتمنح إزالةُ العُقد العاملة أو حذفُ مجمّع عُقد ميزانياتِك مهلة تصل إلى 15 دقيقة؛ أما الترقية فتنتظرها.

الإلغاء والتراجع

• إلغاء الترقية يوقف ترقية بدأتها أو جدولتها، ما دام مستوى التحكم لم يبدأ بالانتقال: لم يتغيّر شيء في المجموعة حتى ذلك الحين. والترقية التي بدأتها من عرض تعود عرضًا كما كانت، بالنهاية نفسها لفترة السماح.
• والترقية التي بدأها فريقنا، كالتي تأتي بعد فترة السماح، لا يمكن إلغاؤها من لوحة التحكم: تواصل مع فريق الدعم.
• الإصدار التصحيحي يستطيع فريق الدعم التراجع عنه خلال 72 ساعة من اكتمال الترقية، بالطريقة نفسها في المكان. ويعرض سجل الترقيات حتى متى يمكن ذلك.
• الإصدار الثانوي لا يمكن التراجع عنه. فإن تعطّل شيء بعده، تواصل مع فريق الدعم: يستطيع إعادة حالة المجموعة من اللقطة التي أُخذت قبل الترقية، وبذلك يضيع كل تغيير أُجري عبر واجهة المجموعة منذ ذلك الحين. انظر النسخ الاحتياطية لحالة المجموعة.

متابعة الترقية

• نظرة عامة: ما دام إصدار معروضًا، يسمّيه شريط تنبيه، مثل يتوفّر Kubernetes 1.36.5، مع الموعد الذي ترقّي قبله: رقِّ المجموعة في أي وقت قبل 30 أكتوبر 2026. بعد ذلك سنرقّي هذه المجموعة خلال نافذة الصيانة الخاصة بها. ويعدّ الأيام والساعات المتبقية، ويحمل علامة تحديث أمني للإصدار الأمني. وحين تُجدوَل الترقية، يعرض موعدها ويعدّ الوقت المتبقي حتى تبدأ.
• جارٍ الترقية إلى Kubernetes 1.36.5: أثناء سير الترقية تعرض البطاقة نفسها خطواتها: تجهيز الإصدار الجديد على كل عقدة، واللقطة، ومستوى التحكم خطوةً واحدة، وكل عقدة عاملة بحالتها.
• سجل الترقيات: كل ترقية، الأحدث أولًا، بإصداراتها وما تغيّر فيها، ونوعها ونتيجتها، ومن بدأها (مساحة عملك أو فريق الدعم أو المنصّة) ومتى.
• Kubernetes: تَسِم قائمة المجموعات كل مجموعة لديها ترقية متاحة أو مجدولة أو جارية، وتسرد صفحة الترقيات فيها كل مجموعات مساحة العمل بإصدار كل منها والترقية المعروضة لها وموعد الاختيار ونافذة الصيانة، مع ترقية الآن وجدولة.

ويُبلَّغ مالكو مساحة العمل ومديروها بالبريد الإلكتروني حين يُعرض إصدار على المجموعة، وحين تُجدوَل ترقية، وحين تبدأ، وحين تكتمل أو تفشل أو يُتراجَع عنها.

من الـ API وMCP

يُرجع GET /v1/kubernetes/clusters/{id}/upgrades الإصدار الدقيق الذي تعمل به المجموعة في version، وavailableUpgrades، ونافذة الصيانة المعمول بها في maintenanceWindow، والترقية أو العرض المفتوح في active مع حالة كل عقدة عاملة وما يتغيّر، وآخر 50 ترقية في history. ويحتاج إلى kubernetes:read. وللترقية، أرسل الإصدار بـ POST إلى المسار نفسه، مع scheduledFor، وهو وقت مع فرق توقيته، لجدولتها؛ واتركه لتبدأ الآن. ويحتاج ذلك إلى kubernetes:update:

curl -X POST "https://api.sahabti.com/v1/kubernetes/clusters/$CLUSTER_ID/upgrades" \
  -H "x-api-key: $SAHABTI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"version":"1.36.5","scheduledFor":"2026-10-20T23:00:00Z"}'

وللترقية المنتظرة، عرضًا كانت أو ترقية جدولتها بنفسك، يضبط PUT /v1/kubernetes/clusters/{id}/upgrades/{upgradeId}/schedule مع scheduledFor موعدها أو يغيّره، ويزيله DELETE على المسار نفسه (فيعود العرض إلى الانتظار مع نهاية فترة السماح نفسها، وتُلغى الترقية التي جدولتها بنفسك)، ويبدؤها POST /v1/kubernetes/clusters/{id}/upgrades/{upgradeId}/start-now الآن. ولا يعمل أيٌّ منها على ترقية جدولها فريقنا أو جولة ترقية جماعية. ويلغي POST /v1/kubernetes/clusters/{id}/upgrades/{upgradeId}/cancel الترقية. ويتلقى الإصدار الذي لا تستطيع المجموعة الانتقال إليه 400 K8S_UPGRADE_VERSION_INVALID، والوقت الذي مضى أو الذي يتجاوز 30 يومًا أو يقع بعد فترة السماح 400 K8S_UPGRADE_SCHEDULE_INVALID، ووجود ترقية أو عرض مفتوح آخر 409 K8S_UPGRADE_IN_PROGRESS، والإصدار الثانوي الذي ما زالت نتائج الرؤى تعيقه 409 K8S_UPGRADE_BLOCKED، والمجموعة غير الجاهزة 409 K8S_CLUSTER_BUSY، والإلغاء بعد أن يبدأ مستوى التحكم بالانتقال 409 K8S_UPGRADE_NOT_CANCELLABLE. ولا تُقبل أكثر من 10 طلبات ترقية في الدقيقة لكل مجموعة.

ويضبط PATCH /v1/kubernetes/clusters/{id}/settings النافذة في maintenanceWindow، مع days من mon إلى sun، ووقت البداية start، والمدة بالساعات durationHours من 2 إلى 8، والمنطقة الزمنية timeZone؛ وتعيد null الإعداد الافتراضي:

{
  "maintenanceWindow": {
    "days": ["fri", "sat"],
    "start": "02:00",
    "durationHours": 4,
    "timeZone": "Asia/Amman"
  }
}

وتحمل المجموعة نفسها، من GET /v1/kubernetes/clusters/{id}، الحقل kubernetesVersion للإصدار الدقيق (ويبقى version الإصدار الثانوي)، وavailableUpgrades، وupgrade للترقية أو العرض المفتوح فيها، وnextMaintenanceWindow لنافذتها المفتوحة الآن أو التالية، بتوقيت UTC.

وفي MCP، تقرأ list_kubernetes_cluster_upgrades ما يقرؤه GET نفسه، وتبدأ start_kubernetes_cluster_upgrade ترقية أو تجدولها، وتغيّر schedule_kubernetes_cluster_upgrade موعد ترقية منتظرة وتبدؤها start_kubernetes_cluster_upgrade_now الآن؛ وتحتاج كلها إلى kubernetes:update، وتطلب تأكيدك أولًا حين يدعم عميلك ذلك، وتضبط update_kubernetes_cluster_settings النافذة. وتُرجع get_kubernetes_cluster أيضًا version وkubernetesVersion وavailableUpgrades وupgrade.