رؤى المجموعة

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

كيف تعمل

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

تُرتَّب الملاحظات من الأخطر إلى الأخف، في ثلاثة أقسام: جاهزية الترقية والاعتمادية والكفاءة.

الخطورة والترقيات

وتذكر كل ملاحظة أيضًا ما تعنيه لترقية Kubernetes التالية للمجموعة:

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

لا تنقل الترقية إلى إصدار تصحيحي (patch)، مثل الانتقال من 1.36.1 إلى 1.36.2، أي Pod، فلا يمنعها إلا خلل في سلامة المجموعة: عُقد عاملة على إصدار آخر أو غير جاهزة، وPods نظام متعثّرة، ومطالبات تخزين غير مربوطة. أما الترقية إلى إصدار ثانوي (minor)، مثل الانتقال من 1.36 إلى 1.37، فتفرّغ العُقد العاملة واحدة تلو الأخرى، فيمنعها أيضًا كلٌّ من الواجهات المُزالة التي استُدعيت خلال آخر 30 يومًا، وإصدارات Helm التي يستخدم ملف تعريفها المحفوظ واجهات مُزالة، وميزانيات التعطّل التي لا تسمح بشيء؛ ويتعطّل أثناءها كلٌّ من أحمال العمل ذات النسخة الواحدة، والـ Pods التي لا يديرها متحكّم، والـ Pods التي تحفظ بياناتها على عقدتها، وخطافات القبول التي ترفض الطلبات عند تعطّلها.

وقبل أن تبدأ الترقية، يذكر تأكيدها عدد الملاحظات التي ما زالت تمنعها، وعدد العوائق المقبولة، وعدد الملاحظات التي تبيّن أين ستتعطّل أحمال عملك. وتشرح صفحة ترقيات Kubernetes ما يجري أثناء الترقية، وتعيد الواجهة البرمجية المعلومات نفسها لأيٍّ من نوعَي الترقية: انظر الواجهة البرمجية وMCP.

جاهزية الترقية

استدعاءات الواجهات المُهمَلة

deprecated_api · تحذير حين يزيلها الإصدار الثانوي التالي، وللعلم حين يزيلها إصدار لاحق · التحذير يمنع الترقية إلى إصدار ثانوي

استدعى شيء ما إصدارًا مُهمَلًا من واجهة سيتوقّف إصدار قادم من Kubernetes عن تقديمه، بحسب ما يعدّه خادم الـ API في المجموعة نفسه. ولا تظهر الإصدارات المُهمَلة التي لم يُعلَن موعد لإزالتها، إذ لا شيء يستدعي إجراءً بعد. وتذكر الملاحظة مجموعة الواجهة (group) وإصدارها ومورِدها، والإصدار الذي يزيلها، وبديلها. وتُغلق بعد أن تمرّ 30 يومًا دون أن يستدعي أحد ذلك الإصدار، فمهمة ليلية ما زالت تستخدمه تُبقيها مفتوحة.

الإصلاح: اعثر على ملفات التعريف (manifests) التي تستخدم الإصدار القديم، وحوّلها إلى البديل بإضافة kubectl convert، ثم حدّث الأداة أو مخطط Helm أو المتحكّم الذي يرسل الطلبات:

grep -rln "apiVersion: flowcontrol.apiserver.k8s.io/v1beta3" .
kubectl convert -f <file> --output-version flowcontrol.apiserver.k8s.io/v1

وفي المورد المخصّص الذي لا يُعرف له بديل، يعرض المقتطف بدلًا من ذلك الإصدار الذي يحفظ به تعريفُ المورد المخصّص (CustomResourceDefinition) بياناته، وهو الإصدار الذي تنتقل إليه.

إصدارات Helm التي تستخدم واجهات مُزالة

helm_removed_api · حرجة حين لم تعد المجموعة تقدّم إحدى واجهاتها، وتحذير حين يزيل الإصدار الثانوي التالي إحداها · تمنع الترقية إلى إصدار ثانوي

إصدار Helm (release) يستخدم ملف تعريفه المحفوظ، أي ملف تعريف مراجعته المنشورة، إصدارات واجهات لم تعد المجموعة تقدّمها أو سيزيلها الإصدار الثانوي التالي. ويفشل أمر helm upgrade التالي لهذا الإصدار إلى أن يُصلَح ملف التعريف المحفوظ. وتسرد الملاحظة كل إصدار واجهة ونوعه وبديله.

الإصلاح: أعد كتابة ملف التعريف المحفوظ بإضافة mapkubeapis الخاصة بـ Helm، ثم حدّث الإصدار بنسخة من المخطط تستخدم الواجهات الحالية:

helm mapkubeapis <release> --namespace <namespace>
helm upgrade <release> <chart> --namespace <namespace>

ميزانيات التعطّل التي لا تسمح بشيء

disruption_budget_blocks_drain · تحذير · تمنع الترقية إلى إصدار ثانوي

ميزانية تعطّل (PodDisruptionBudget) لا تسمح بإيقاف أي Pod مع أن كل الـ Pods التابعة لها سليمة، مثل minAvailable: 100% أو maxUnavailable: 0. وتفريغ العقدة العاملة ينتظرها.

الإصلاح: اسمح بإيقاف Pod واحد في كل مرة، أو شغّل نسخًا أكثر مما يطلبه minAvailable:

kubectl -n <namespace> patch poddisruptionbudget <name> --type=merge -p '{"spec":{"minAvailable":null,"maxUnavailable":1}}'

أحمال العمل ذات النسخة الواحدة

single_replica · تحذير · يتعطّل أثناء الترقية إلى إصدار ثانوي

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

الإصلاح: شغّل نسختين، أو ارفع minReplicas في التوسّع التلقائي إلى 2:

kubectl -n <namespace> scale deployment/<name> --replicas=2

الـ Pods التي لا يديرها متحكّم

pod_without_controller · تحذير · يتعطّل أثناء الترقية إلى إصدار ثانوي

Pod يعمل ولا يملكه Deployment ولا StatefulSet ولا DaemonSet ولا Job ولا أي متحكّم آخر. ولن يعيد تشغيله شيء على عقدة عاملة أخرى، لذا ينتظره تفريغ عقدته العاملة أثناء الترقية إلى إصدار ثانوي حتى تحذفه.

الإصلاح: شغّله من Deployment، ثم احذف الـ Pod المنفرد:

kubectl -n <namespace> create deployment <name> --image=<image> --replicas=2
kubectl -n <namespace> rollout status deployment/<name>
kubectl -n <namespace> delete pod <name>

بيانات محفوظة على العقدة

local_data · تحذير مع وحدة تخزين hostPath أو وحدة محلية، وللعلم مع emptyDir وحدها · التحذير يتعطّل أثناء الترقية إلى إصدار ثانوي

حمل عمل تحفظ الـ Pods التابعة له بياناتها على عقدتها العاملة: في وحدة تخزين emptyDir أو hostPath، أو على مطالبة تخزين مربوطة بوحدة تخزين محلية. وتبقى تلك البيانات خلفها حين تنتقل الـ Pods إلى عقدة عاملة أخرى. ووحدة emptyDir مساحة مؤقتة يبدأ بها الـ Pod فارغة من جديد، فهي وحدها من باب العلم فقط. ولا تشمل الملاحظة DaemonSet، لأن الـ Pods التابعة له لا تنتقل.

الإصلاح: احفظ البيانات على مطالبة تخزين دائمة بدلًا من ذلك. ومقتطف لوحة التحكم مطالبة يمكنك البدء منها، وتشرح صفحة وحدات تخزين Kubernetes فئات التخزين.

خطافات القبول التي ترفض الطلبات عند تعطّلها

webhook_fail_closed · حرجة بلا أي نقطة نهاية جاهزة، وتحذير مع نقطة واحدة · الحرجة تتعطّل أثناء كل ترقية، والتحذير أثناء الترقية إلى إصدار ثانوي

خطاف قبول (admission webhook) مضبوط على failurePolicy: Fail لدى خدمته أقل من نقطتَي نهاية جاهزتين. وما دامت خدمته بلا أي نقطة نهاية جاهزة، ترفض المجموعة كل طلب يغطّيه الخطاف، وقد يوقف ذلك خدمات المجموعة نفسها أثناء الترقية.

الإصلاح: شغّل حمل عمل الخطاف بنسختين، أو اضبط failurePolicy على Ignore إن كانت السياسة التي يفرضها تحتمل أن تتوقّف لحظة:

kubectl -n <namespace> get endpointslices -l kubernetes.io/service-name=<service>
kubectl -n <namespace> scale deployment/<name> --replicas=2

إصدار ثانوي لم يُتَح بعد

addon_compatibility · للعلم · لا أثر لها على الترقيات

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

سلامة المجموعة

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

الاعتمادية

نفاد الذاكرة

oom_killed · تحذير · لا أثر لها على الترقيات

حاوية أُوقفت لنفاد ذاكرتها خلال آخر 24 ساعة، مع عدد الـ Pods التي أصابها ذلك ومرات إعادة تشغيلها، ووقت آخر مرة، وحدّ ذاكرة الحاوية.

الإصلاح: امنحها ذاكرة أكبر. يضبط مقتطف لوحة التحكم طلبها وحدّها على مرة ونصف من الحدّ الذي أُوقفت عنده، مقرَّبًا إلى الأعلى بخطوات من 64 ميبيبايت:

kubectl -n <namespace> set resources deployment/<name> -c <container> --requests=memory=384Mi --limits=memory=384Mi

الكفاءة

أحمال العمل التي لا تطلب موارد

no_requests · تحذير · لا أثر لها على الترقيات

حمل عمل لا تطلب أيٌّ من حاوياته معالجًا ولا ذاكرة. فلا يستطيع المجدول أن يخطّط له، وقد يزاحم غيره على العقدة العاملة، وهو أول ما يُخلى حين تنقص ذاكرة العقدة.

الإصلاح: قِس ما يستهلكه، ثم اطلب نحو ذلك:

kubectl -n <namespace> top pods
kubectl -n <namespace> set resources deployment/<name> --requests=cpu=100m,memory=128Mi

حجم مجمّعات العُقد

pool_underused · للعلم · pool_overloaded · تحذير · لا أثر لها على الترقيات

لكل مجمّع عُقد، تأخذ المنصّة استهلاك عُقده العاملة للمعالج والذاكرة خلال آخر 7 أيام، وتحسب المئين 95: الاستهلاك الذي يبقى المجمّع دونه 95٪ من الوقت.

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

التجاهل والتأجيل والقبول

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

• أجّل الملاحظة يومًا أو 7 أيام أو 30 يومًا: تعود بعد ذلك.
• تجاهلها لتخفيها إلى أن تستعيدها.
• استعد ملاحظة متجاهَلة أو مؤجّلة لتظهر من جديد.

يستمر فحص الملاحظة المخفية، وتُغلق حين تُصلَح. وإن أُغلقت ثم عادت خلال 30 يومًا بقي تجاهلها قائمًا. وتعرض كل ملاحظة من تجاهلها أو أجّلها، وإلى متى، ولماذا.

قبول ملاحظة تمنع الترقية

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

ويُسجَّل كلٌّ من التجاهل والتأجيل والقبول والاستعادة في سجل التدقيق، ولا تتجاوز هذه التغييرات 60 تغييرًا في الدقيقة لكل مجموعة.

من يستطيع ماذا

ولا أثر هنا لدورك في المجموعة نفسها، أي الدور الذي يستخدمه ملف kubeconfig الخاص بك: فالفحوص تعمل بصفة المنصّة لا بصفتك.

الواجهة البرمجية وMCP

وبدء ترقية إلى إصدار ثانوي عبر POST /v1/kubernetes/clusters/{id}/upgrades بينما تمنعها ملاحظة يُرَدّ عليه بـ 409 K8S_UPGRADE_BLOCKED.

تكون state بقيمة pending قبل أول فحص، وfailed حين يتعذّر على آخر فحص الوصول إلى المجموعة (والملاحظات حينها ملاحظات checkedAt)، وpartial حين يتعذّر تشغيل أجزاء منه (تسردها unchecked)، وok فيما عدا ذلك. وتبدو كل ملاحظة هكذا:

{
  "id": "kin_3f9a1c0b7d2e4a6f8b10",
  "kind": "single_replica",
  "category": "readiness",
  "severity": "warning",
  "upgradeImpact": "disrupts",
  "details": { "namespace": "shop", "kind": "Deployment", "name": "web", "autoscaler": null },
  "fix": { "language": "shell", "code": "kubectl -n shop scale deployment/web --replicas=2" },
  "cost": null,
  "firstSeenAt": "2026-10-10T09:00:00.000Z",
  "lastSeenAt": "2026-10-16T11:00:00.000Z",
  "dismissed": null,
  "dismissedUntil": null,
  "dismissedBy": null,
  "dismissReason": null
}

وupgradeImpact أثر الملاحظة في الترقية إلى إصدار ثانوي، وهي الحالة الأوسع. وcost، في مجمّع العُقد، هي { "kind": "saving", "monthlyUsd": 10.22 } أو { "kind": "cost", … }، والحجم المقترح في details.suggestion. وقيمة dismissed هي snoozed أو forever أو null.

يقرأ وكلاء الذكاء الاصطناعي المتصلون عبر MCP الملاحظات نفسها بالأداة list_kubernetes_cluster_insights، ويمكنهم تنفيذ اقتراح المجمّع بالأداة scale_kubernetes_node_pool. والأداة للقراءة فقط: يبقى التجاهل والقبول للأشخاص في لوحة التحكم ولمفاتيح API.

ما تقرؤه الفحوص

• قراءة فقط. تعمل الفحوص على مستوى التحكم في المجموعة، ولا تفعل سوى سرد الكائنات وقراءتها كما يفعل kubectl get. ولا تغيّر شيئًا في المجموعة.
• أسماء لا قيم. تحتفظ الملاحظة بالأسماء والأعداد والإصدارات والحالات: مساحات الأسماء، وأسماء الكائنات والحاويات، والصور، وأعداد النسخ ومرات إعادة التشغيل، وإصدارات الواجهات. ولا تُجمَع قيمة أي Secret أو متغيّر بيئة أبدًا.
• إصدارات Helm تُحفظ في المجموعة على هيئة Secrets. ويفتح الفحص المراجعة المنشورة لكل إصدار على مستوى التحكم، ولا يحتفظ إلا بإصدار الواجهة ونوع كل كائن في ملف تعريفه، لا بقيمه أبدًا.
• مساحات أسماء المجموعة نفسها، مثل kube-system ومساحة البوابة المُدارة، مستثناة، إلا لمعرفة ما إذا كانت خدمات المجموعة نفسها تعمل.
• ملاحظات مساحة عملك لا تُعرض إلا لأعضائها ومفاتيحها ووكلائها كما سبق. ويستطيع فريق الدعم لدينا رؤية الملاحظات نفسها، للقراءة فقط، لمساعدتك في مجموعتك.

الحدود