موفر Kubernetes (Kubernetes Provisioner)

يتيح لك موفر Kubernetes إنشاء عنقود Kubernetes جاهز للاستخدام من Cockpit في خطوات إرشادية قليلة. يبني Cockpit الأجهزة الافتراضية، ويثبت توزيعة Kubernetes خفيفة الوزن ومتوافقة بالكامل (k3s)، ويوصل الشبكات والتخزين، ويسلمك عنقودًا يمكنك الاتصال به باستخدام أداة kubectl القياسية.

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

لمن يُوجه هذا الدليل

هذا الدليل مخصص للأشخاص الذين يرغبون في تشغيل عنقود Kubernetes — فرق التطبيقات، وموجهو المنصات، والمسؤولون. ويركز على ما تفعله في واجهة Cockpit وكيفية استخدام العنقود بعد ذلك.

الترخيص

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

---

قبل أن تبدأ

يجب توفر أمرين قبل إنشاء عنقودك الأول. إذا كان المسؤول قد أعد البيئة بالفعل، يمكنك الانتقال مباشرة إلى إنشاء عنقود.

• قالب عنقود. يستنسخ Cockpit كل عقدة من صورة قالب Ubuntu معدة مسبقًا. يحمل القالب مكونات Kubernetes للإصدارات التي بُني معها، بحيث تُثبت العقد بسرعة ودون الحاجة لتنزيل أي شيء عند الإقلاع. يظهر تلقائيًا كخيار في المعالج.
• شبكة مناسبة. يجب أن تكون كل عقدة على شبكة موزعة (Distributed network) — تمتد عبر المضيفين الفيزيائيين في عنقود الحوسبة الخاص بك — حتى تتمكن العقد الموضوعة على مضيفين مختلفين من الوصول إلى بعضها البعض. انظر اختيار شبكة.

---

إنشاء عنقود

1. في شجرة المخزون اليسرى، انقر بزر الفأرة الأيمن على Cluster الحوسبة (أو Datacenter الذي ينتمي إليه).
2. اختر Kubernetes ← New Cluster.
3. يفتح معالج توفير Kubernetes في خمس خطوات قصيرة.

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

عند الانتهاء من المعالج، يبدأ Cockpit بناء العنقود في الخلفية. يمكنك إغلاق المعالج ومتابعة التقدم في لوحة Tasks. يظهر العنقود في المخزون وينتقل من provisioning إلى active عندما يكون جاهزًا للاستخدام.

الخطوة 1 — الأساسيات (Basics)

الحقل	ما يفعله
Cluster Name	اسم صديق للعنقود. يُستخدم في المخزون، وفي أسماء العقد، وفي ملف الإعداد المنزل.
Target Network	الشبكة الموزعة التي تتصل بها العقد. تُعرض الشبكات الموزعة فقط. انظر اختيار شبكة.
Node IP Addressing	DHCP (افتراضي) يتيح للشبكة توزيع العناوين. Static يتيح لك حجز نطاق ثابت للعنقود — انظر عناوين العقد الثابتة.
Kubernetes Version	إصدار k3s المراد تثبيته. تُثبت الإصدارات المدمجة في القالب بأقصى سرعة؛ اختر الأحدث ما لم يكن لديك سبب لعدم القيام بذلك.
Network Plugin (CNI)	كيف تتحدث الكبسولات مع بعضها البعض. انظر ملحقات الشبكة (CNI). اتركه على Flannel إذا لم تكن متأكدًا.

الخطوة 2 — لوحة التحكم (Control Plane)

لوحة التحكم هي "عقل" العنقود. اختر مدى مرونتها:

• Single (عقدة واحدة) — الأبسط والأخف وزنًا. مناسبة للتطوير والاختبار. إذا فُقدت تلك العقدة، يصبح العنقود غير متاح حتى يتعافى.
• High Availability (3 عقد) — يوصى بها لبيئات الإنتاج. يستمر العنقود في العمل حتى لو تعطلت عقدة واحدة من لوحة التحكم.

تحدد أيضًا المعالج (CPU)، والذاكرة، ومستودع التخزين (Datastore)، وحجم القرص لكل عقدة من لوحة التحكم، واختيار التوزيع (Placement):

• Auto-Distribute (موصى به) — ينشر Cockpit عقد HA الثلاث عبر ثلاثة مضيفين فيزيائيين مختلفين تلقائيًا، حتى لا يتسبب انقطاع مضيف واحد في إسقاط لوحة التحكم بأكملها.
• Manual — تختار بالضبط المضيف الذي تعمل عليه كل عقدة، من بين مضيفي عنقود الحوسبة لديك.

يوجد قسمان متقدمان مطويان افتراضيًا ويمكن تركهما كما هما لمعظم العناقيد:

• وضع وبنية المعالج (CPU Mode & Topology) — كيف يُقدم المعالج الافتراضي للعقدة. انظر وضع وبنية المعالج.
• ملصقات ووسوم العقد (Node Labels & Taints) — بيانات وصفية من Kubernetes تُطبق على عقد لوحة التحكم. انظر ملصقات ووسوم العقد. والاستخدام الشائع هو إضافة وسم NoSchedule هنا حتى تبقى كبسولات التطبيقات العادية بعيدة عن لوحة التحكم.

الخطوة 3 — عقد العمل (Workers)

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

لكل مجمع تحدد ما يلي:

الحقل	ما يفعله
Pool Name	اسم قصير للمجمع. تُبنى أسماء العقد منه: العنقود prod، المجمع gpu ← العقد prod-gpu-1، prod-gpu-2، وهكذا. انظر قواعد التسمية.
Node Count	عدد العقد التي ستبدأ بها. يمكنك تغيير هذا في أي وقت لاحقًا.
CPU, Memory, Datastore, Disk size	الموارد المخصصة لكل عقدة في هذا المجمع.
Placement	Auto-Distribute يوزع العقد بتوازن عبر مضيفي عنقود الحوسبة، أو استخدم Manual لتثبيتها على مضيفين محددين (مفيد عندما تحتوي بعض الأجهزة على عتاد خاص مثل وحدات معالجة الرسوميات GPUs).
CPU Mode & Topology (متقدم)	انظر وضع وبنية المعالج.
Node Labels & Taints (متقدم)	انظر ملصقات ووسوم العقد.

انقر فوق Add Node Pool لتحديد مجمع آخر بإعدادات مختلفة. يُسمى المجمع الأول workers ما لم تقم بتغيير اسمه.

الخطوة 4 — بيانات الاعتماد و CSI (Credentials & CSI)

• SSH Public Key — اختياري. الصق مفتاحًا عامًا هنا إذا كنت تريد وصول SSH مباشرًا إلى الأجهزة الافتراضية للعقد لاستكشاف الأخطاء وإصلاحها. هذا ليس مطلوبًا لاستخدام العنقود؛ حيث ينشئ Cockpit أيضًا زوج مفاتيح خاصًا به للعنقود، يمكنك تنزيله من صفحة العنقود.
• Storage Tiers (CSI) — اختر كيف تحصل التطبيقات على التخزين الدائم. يمكنك تمكين أكثر من مستوى. انظر التخزين لتطبيقاتك.

الخطوة 5 — المراجعة (Review)

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

---

اختيار شبكة

تتمتع الشبكة التي تختارها في الخطوة 1 بالتأثير الأكبر على نجاح إنشاء عنقودك، لذا يجدر التفكير فيها جيدًا.

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

WARNING

يجب أن توفر بوابة الشبكة وصولاً فعليًا إلى الإنترنت للعقد، وليس مجرد إعادة توجيه لحركة مرورها. فالبوابة التي توجه المسارات دون ترجمة العناوين (NAT) تجعل العقد تقلع وتستجيب لـ ping بينما تفشل كل عملية تنزيل في صمت، ولا ينتهي العنقود من التوفير أبدًا. إذا لم تكن متأكدًا من الشبكة المخصصة لـ Kubernetes، فاسأل المسؤول لديك.

عناوين العقد الثابتة

تحصل العقد افتراضيًا على عناوينها من خادم DHCP. إذا لم يكن لشبكتك خادم DHCP، أو كنت تريد أن تكون عناوين العنقود ثابتة ويمكن التنبؤ بها، فاختر Static في الخطوة 1 واملأ:

الحقل	مثال
Subnet	192.168.1.0/24
Gateway	192.168.1.1
Nameservers	8.8.8.8, 1.1.1.1
IP Range	192.168.1.100 – 192.168.1.120

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

---

ملحقات الشبكة (CNI)

يتحكم ملحق الشبكة في كيفية تواصل الكبسولات (pods) وما إذا كان يمكنك فرض سياسات أمان الشبكة. تختار ذلك مرة واحدة، في الخطوة 1.

الملحق	الأنسب لـ	ملاحظات
Flannel (افتراضي)	معظم العناقيد، التطوير، الإعدادات البسيطة	خفيف وموثوق. لا يدعم سياسات الشبكة.
Calico	الإنتاج مع عزل المستأجرين	يضيف دعم NetworkPolicy في Kubernetes للتحكم في حركة المرور بين الكبسولات.
Cilium	شبكات متقدمة عالية الأداء	معتمد على eBPF، مع سياسات L3–L7 غنية ورؤية واضحة لحركة المرور.

إذا لم تكن لديك متطلبات محددة، فإن Flannel هو الخيار الآمن.

---

مجمعات عقد العمل (Worker node pools)

مجمع العقد (Node pool) هو مجموعة من عقد العمل التي تشترك في نفس التكوين. تحتاج معظم العناقيد الصغيرة إلى مجمع واحد فقط. وتحتاج إلى أكثر من مجمع عندما تتطلب أحمال العمل المختلفة أجهزة ذات مواصفات مختلفة:

• مجمع database بذاكرة أكبر ومستودع تخزين أسرع، إلى جانب مجمع workers العام.
• مجمع gpu مثبت على المضيفين الذين يمتلكون وحدات معالجة الرسوميات، مع وسم (taint) لضمان اقتصار تشغيل أحمال عمل GPU عليه فقط.
• مجمع ingress بملصق يختاره متحكم الدخول (ingress controller) الخاص بك، بحيث يظل صغيرًا ومستقرًا بينما تتوسع بقية أجزاء العنقود.

يمتلك كل مجمع اسمه، وعدد عقده، والمعالج / الذاكرة / القرص / مستودع التخزين، وتوزيعه، ووضع وبنية المعالج، وملصقاته ووسومه. تُدار المجمعات من تبويب Node Pool الخاص بالعنقود بعد الإنشاء — انظر إدارة مجمعات العقد.

قواعد التسمية

تصبح أسماء المجمعات جزءًا من اسم كل عقدة، لذا فهي تتبع نفس قواعد أسماء مضيفي Kubernetes:

• أحرف صغيرة، وأرقام، والرمز -؛ ويجب أن تبدأ وتنتهي بحرف أو رقم؛ بحد أقصى 40 حرفًا.
• يجب أن تكون فريدة داخل العنقود.
• تُعد الأسماء worker، وmaster، وcontrol-plane محجوزة، لأن تسمية العقد بها ستتعارض مع مجمع العمل الافتراضي أو لوحة التحكم. استخدم workers للمجمع الافتراضي، أو اسمًا مميزًا مثل infra أو compute.

---

وضع وبنية المعالج (CPU mode and topology)

تحصل كل عقدة افتراضيًا على معالج افتراضي للأغراض العامة. يتيح لك قسم CPU Mode & Topology في كل مجمع تغيير كيفية تقديم المعالج، وهو أمر مهم لأحمال العمل التي تفحص المعالج أو البرامج المرخصة حسب المقبس (socket).

وضع المعالج (CPU Mode)

الوضع	ما تراه العقدة	متى يُستخدم
Host Model	معالج يطابق طراز المضيف الفيزيائي	توازن ممتاز بين الأداء وقابلية النقل.
Host Passthrough	معالج المضيف الفيزيائي بدقة متناهية، مع كل الميزات	أقصى أداء؛ أحمال العمل التي تحتاج إلى تعليمات معالج محددة. يجب أن تبقى العقد على مضيفين يمتلكون معالجات متطابقة.
Custom Named Model	طراز معالج محدد تسميه بنفسك (مثل Broadwell-IBRS)	عندما تحتاج إلى ميزات معالج متطابقة عبر مضيفين يمتلكون معالجات فيزيائية مختلفة.

تتيح لك البنية (Topology) تشكيل المعالجات الافتراضية إلى مقابس × قوالب × نوى × خيوط (sockets × dies × cores × threads). ويجب أن يساوي حاصل الضرب عدد المعالجات الافتراضية (vCPU) للمجمع — يعرض المعالج العملية الحسابية أثناء الكتابة ولن يسمح لك بالمتابعة في حال عدم التطابق. على سبيل المثال، يمكن تكوين 4 معالجات vCPU كـ 1 × 1 × 4 × 1 (مقبس واحد، أربع نوى) أو 2 × 1 × 2 × 1 (مقبسان، نواتان لكل منهما)، مما يغير عدد التراخيص للبرامج المرخصة حسب المقبس.

اترك القسم مطويًا لقبول الإعدادات الافتراضية. ويُعرض الوضع والبنية المحددة لكل مجمع في تبويب Node Pool بعد الإنشاء.

---

ملصقات ووسوم العقد (Node labels and taints)

الملصقات (Labels) هي وسوم مفتاح-قيمة تتيح لك توجيه أحمال العمل نحو عقد محددة باستخدام nodeSelector أو تقارب العقد (node affinity). وتفعل الوسوم (Taints) العكس: فهي تبقي أحمال العمل بعيدة عن العقدة ما لم يتحمل حمل العمل الوسم صراحة (toleration). ويشكل كلاهما معًا الطريقة التي يحول بها Kubernetes "مجمع أجهزة GPU" إلى شيء يفهمه المجدول (scheduler) فعليًا.

قم بتعيينها لكل مجمع في قسم Node Labels & Taints:

الإعداد	التنسيق	مثال
Label	المفتاح = القيمة	tier = database
Taint	المفتاح=القيمة:التأثير، حيث التأثير هو NoSchedule، أو PreferNoSchedule، أو NoExecute	dedicated=gpu:NoSchedule

يتحقق المعالج من صحة التنسيق أثناء الكتابة — ويتم رفض التأثير الخاطئ أو المفتاح غير الصالح قبل بناء أي شيء، بدلاً من إنشاء عقدة تفتقر إلى وسمها بصمت.

تُطبق عند الإنشاء

تُمنح الملصقات والوسوم لكل عقدة عندما تنضم إلى العنقود لأول مرة، وكل عقدة تُضاف لاحقًا عن طريق التوسيع أو عبر مجمع جديد تحصل على ملصقات ووسوم مجمعها بالطريقة نفسها. ولا يمكن تغييرها لمجمع موجود من Cockpit — لتغييرها للعقد الموجودة بالفعل، استخدم kubectl label و kubectl taint، أو أنشئ مجمعًا جديدًا بالإعدادات المطلوبة واحذف المجمع القديم.

يستهدف حمل العمل المجمع بعد ذلك بهذه الطريقة:

spec:
  nodeSelector:
    tier: database
  tolerations:
    - key: dedicated
      operator: Equal
      value: gpu
      effect: NoSchedule

إبقاء التطبيقات بعيدة عن لوحة التحكم

لا يضع k3s وسومًا على عقد لوحة التحكم الخاصة به، لذا يمكن افتراضيًا جدولة الكبسولات العادية عليها. بالنسبة لعناقيد الإنتاج، أضف وسمًا مثل dedicated=control-plane:NoSchedule إلى لوحة التحكم في الخطوة 2. تعمل مكونات نظام العنقود بالفعل في الأماكن المطلوبة؛ وستبقى تطبيقاتك على عقد العمل فقط.

المفاتيح الواقعة تحت البادئات kubernetes.io/ و k8s.io/ (بما في ذلك node-role.kubernetes.io/) محجوزة لـ Kubernetes نفسه ولا يمكن تعيينها هنا — اختر مفتاحك الخاص بدلاً من ذلك.

---

التخزين لتطبيقاتك (Storage for your applications)

تطلب التطبيقات التي تحتاج إلى الاحتفاظ بالبيانات (قواعد البيانات، وتحميلات الملفات، وما إلى ذلك) التخزين من خلال مستوى التخزين (Storage tier). قم بتمكين المستويات التي تحتاجها في الخطوة 4؛ يمكنك تشغيل أكثر من مستوى واختيار المستوى المناسب لكل تطبيق.

المستوى	ما يوفره لك	متى يُستخدم
Local Path (مفعل افتراضيًا)	تخزين سريع على العقدة التي تعمل عليها الكبسولة	تخزين بسيط وفائق السرعة. تبقى البيانات على عقدة واحدة، لذا لا تكون متاحة إذا انتقلت الكبسولة إلى عقدة أخرى.
مشترك (NFS)	تخزين يمكن لعدة كبسولات مشاركته في وقت واحد، ومتاح عبر العقد	عندما تحتاج الكبسولات إلى مشاركة الملفات (ReadWriteMany)، أو الاحتفاظ ببياناتها عند انتقالها بين العقد.
متماثل (Longhorn)	تخزين كتل عالي التوفر، يُنسخ احتياطيًا عبر العقد	أحمال العمل ذات الحالة (Stateful) مثل قواعد البيانات التي يجب أن تنجو من تعطل العقدة.

مشترك (NFS). اختر مستودع تخزين NFS مسجلاً بالفعل في Cockpit وسيتم ملء عنوان الخادم ومسار التصدير نيابة عنك، أو أدخل عنوان خادم NFS خارجي يدويًا. يتحقق Cockpit من إمكانية الوصول إلى الخادم من شبكة العنقود نفسها — وهو الأمر الحاسم، نظرًا لأن عمليات التثبيت تتم من هناك — قبل تثبيت برنامج التشغيل، ويؤكد تشغيل برنامج التشغيل على كل عقدة قبل إعلان العنقود نشطًا.

متماثل (Longhorn). حدد عدد النسخ المتماثلة (Replica count) — كم عدد النسخ التي يحتفظ بها Longhorn من كل وحدة تخزين، كل منها على عقدة عمل مختلفة. القيمة الافتراضية 3 تنجو من فقدان عقدتي عمل. لا يمكن أن يتجاوز العدد عدد عقد العمل الإجمالي؛ ويرفض المعالج العدد الذي لا يمكن للعنقود تلبيته أبدًا، لأن Longhorn سيترك وحدات التخزين متدهورة بشكل دائم. تم تكوين Longhorn للاحتفاظ بالنسخ على عقد العمل فقط، وتجنب لوحة التحكم دائمًا.

إضافة التخزين لاحقًا

يتم اختيار مستويات التخزين عند الإنشاء. وإذا قمت بتقليل عدد عقد العمل إلى أقل من عدد نسخ Longhorn المتماثلة لاحقًا، تصبح وحدات التخزين متدهورة (Degraded) حتى يتوفر عدد كافٍ من العمال مرة أخرى — قم بالتوسيع لاستعادة التكرار الكامل.

---

الاتصال بالعنقود

بمجرد أن تصبح حالة العنقود active، يمكنك الاتصال باستخدام kubectl، أداة سطر أوامر Kubernetes القياسية.

1. افتح صفحة تفاصيل العنقود وانقر فوق Download Kubeconfig. يقدم لك Cockpit ملفًا جاهزًا للاستخدام مع عنوان الخادم الصحيح مملوءًا بالفعل.

2. احفظه وقم بتوجيه kubectl إليه:

   mkdir -p ~/.kube
   mv ~/Downloads/kubeconfig-my-cluster.yaml ~/.kube/config-my-cluster
   chmod 600 ~/.kube/config-my-cluster
   export KUBECONFIG=~/.kube/config-my-cluster

3. تأكد من عمله:

   kubectl get nodes --show-labels

   يجب أن تشاهد عقد لوحة التحكم وعقد العمل مدرجة بحالة Ready، ويحمل كل منها ملصقات المجمع الخاص به.

TIP

لتجنب تعيين KUBECONFIG في كل مرة، أضف سطر export إلى ملف تعريف الصدفة الخاص بك (~/.bashrc أو ~/.zshrc).

---

إدارة مجمعات العقد (Manage node pools)

افتح العنقود واختر تبويب Node Pool. يمثل كل مجمع صفًا في جدول يوضح اسمه، ودوره، وعدد عقده مع عدد العقد الجاهزة (Ready)، وموارد المعالج / الذاكرة / القرص / مستودع التخزين لعقده، وتكوين المعالج، والملصقات والوسوم. يُسرد مجمع لوحة التحكم كمرجع ويُعلم بـ Locked — حيث لا يمكن توسيعه أو حذفه هنا.

يحتوي كل مجمع عمل على إجراءي Scale و Remove في صفه، ويحتوي التبويب على زر Add Pool. وتتوفر هذه الإجراءات الثلاثة فقط أثناء كون العنقود بحالة active؛ وأثناء أي تغيير يتم تعطيلها حتى لا تتعارض عمليتان. ويظهر كل تغيير في تبويب Tasks الخاص بالعنقود وفي لوحة Tasks.

توسيع مجمع

1. انقر فوق Scale في صف المجمع.
2. اضبط عدد العقد المطلوب الجديد ثم أكد العملية.

تؤدي عملية التوسيع (Scale up) إلى إضافة أجهزة افتراضية جديدة للعقد بنفس تكوين المجمع تمامًا — الموارد، ووضع المعالج، والملصقات والوسوم — وضمها إلى العنقود تلقائيًا. وعندما تظهر العقد الجديدة بحالة Ready، تبدأ في استقبال أحمال العمل.

تتم عملية تقليص الحجم (Scale down) بلباقة وأمان. فقبل إزالة العقدة، ينقل Cockpit أولاً أي نسخ متماثلة لـ Longhorn بعيدًا عنها حتى تحافظ وحدات التخزين على تكرارها، ثم يقوم بـ تفريغها (drain) — بنقل أحمال العمل التي تعمل عليها إلى العقد المتبقية — وبعد ذلك فقط يزيل الجهاز الافتراضي ويحرر موارده.

في حال فشل إضافة عقدة

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

إضافة مجمع إلى عنقود قيد التشغيل

لا تحتاج إلى إعادة بناء العنقود لمنحه فئة جديدة من العقد.

1. انقر فوق Add Pool في تبويب Node Pool.
2. املأ نفس الإعدادات كما في الخطوة 3 من المعالج — الاسم، والعدد، والموارد، ومستودع التخزين، والتوزيع، واختياريًا وضع المعالج والملصقات/الوسوم.
3. أكد العملية. يتم توفير العقد الجديدة وضمها، ويظهر المجمع كصف جديد في الجدول.

تنطبق نفس القواعد المتبعة عند الإنشاء: يجب أن يتبع الاسم قواعد التسمية، وألا يكون قيد الاستخدام بالفعل، وفي العناقيد ذات العناوين الثابتة يجب أن تتوفر عناوين حرة كافية للعقد الجديدة. يتحقق Cockpit من كل هذا قبل إنشاء أي شيء.

إزالة مجمع

1. انقر فوق Remove في صف المجمع وأكد — يؤدي الحذف إلى تدمير عقد المجمع ولا يمكن التراجع عنه.
2. يتم التعامل مع كل عقدة بالطريقة التي يتعامل بها تقليص الحجم: تُنقل نسخ Longhorn المتماثلة أولاً، وتُفرغ أحمال العمل، وبعد ذلك فقط يُدمر الجهاز الافتراضي. وعند رحيل آخر عقدة يختفي المجمع من الجدول.

بقاء مجمع العمل الأخير

يحتفظ العنقود دائمًا بمجمع عمل واحد على الأقل. ولا يتوفر إجراء Remove على المجمع الوحيد المتبقي، وترفض واجهة برمجة التطبيقات الطلب. وإذا كنت تريد ألا يحتوي العنقود على أي عمال، فقلص ذلك المجمع؛ وإذا كنت تريد التخلص من العنقود بالكامل، فاحذف العنقود.

---

ترقية العنقود

يقوم Cockpit بإجراء ترقية متتابعة (Rolling upgrade)، بنقل العنقود إلى إصدار Kubernetes أحدث عقدة تلو الأخرى حتى تظل تطبيقاتك متاحة دون انقطاع.

1. افتح العنقود واختر Upgrade.
2. اختر الإصدار المستهدف من القائمة.
3. أكد العملية. يقوم Cockpit بترقية لوحة التحكم أولاً، ثم عمال العنقود، عقدة واحدة في كل مرة.

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

يظهر التقدم في تبويب Tasks الخاص بالعنقود. وتحت المهمة، تعرض قائمة Node Upgrade Jobs مدخلاً واحدًا لكل عقدة أثناء عمل متحكم الترقية الداخلي؛ انقر فوق View log على أي عقدة لقراءة ما حدث عليها بدقة. هذا السجل هو المكان المناسب للبحث إذا توقفت عقدة واحدة — فقد تفيد المهمة باكتمال عقدة، لكن السجل وحده هو الذي يوضح ما قامت به.

---

مراقبة صحة العنقود

بعد أن تصبح حالة العنقود active، يواصل Cockpit مراقبته ويعرض حالة الصحة في صفحة العنقود:

• Healthy (سليم) — جميع العقد موجودة وجاهزة (Ready).
• Degraded (متدهور) — عقدة واحدة أو أكثر ليست جاهزة (على سبيل المثال، توقفت عقدة أو فقدت الاتصال بالشبكة). لا يزال العنقود قيد التشغيل ولكن بسعة أو قدرة صمود منخفضة.

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

---

استكشاف الأخطاء وإصلاحها

العنقود عالق في حالة "provisioning" ولا يصبح نشطًا أبدًا. السبب الأكثر شيوعًا هو الشبكة. تأكد من أن الشبكة التي اخترتها تمتد عبر المضيفين في عنقود الحوسبة لديك وأن بوابتها تمنح العقد وصولاً فعليًا إلى الإنترنت — وليس مجرد إعادة توجيه. العقد التي تقلع وتستجيب لـ ping ولكن لا تكمل التثبيت أبدًا تفتقر دائمًا إلى مسار خروج فعال. انظر اختيار شبكة.

يرفض المعالج اسم المجمع الخاص بي. يجب أن تكون الأسماء أحرفًا صغيرة وأرقامًا والرمز -، وتُعد الأسماء worker و master و control-plane محجوزة. انظر قواعد التسمية.

تُرفض إضافة مجمع أو التوسيع مع رسالة "static IP pool is exhausted". نفدت العناوين الحرة المتبقية في نطاق العناوين الثابتة للعنقود للعقد الجديدة. توضح الرسالة عدد العناوين المتاحة والعدد المطلوب. قلص شيئًا آخر أولاً، أو أنشئ عنقودًا جديدًا بنطاق أوسع — فلا يمكن توسيع النطاق في عنقود موجود بالفعل.

لا يسمح لي المعالج بالمتابعة بعد بنية المعالج (CPU topology). يجب أن يساوي حاصل ضرب المقابس × القوالب × النوى × الخيوط عدد معالجات vCPU للمجمع. اضبط إما البنية أو عدد vCPU حتى تتطابق العملية الحسابية الموضحة في المعالج.

تم رفض ملصق أو وسم. يجب أن تكون الوسوم بتنسيق المفتاح=القيمة:التأثير مع كون التأثير حصريًا NoSchedule أو PreferNoSchedule أو NoExecute. تتبع مفاتيح وقيم الملصقات قواعد Kubernetes (بحد أقصى 63 حرفًا، أحرف وأرقام و - و _ و .)، والمفاتيح الواقعة تحت kubernetes.io/ أو k8s.io/ محجوزة. يوضح لك المعالج أي مدخل به خطأ.

خيار الإزالة (Remove) غير متاح ومظلل باللون الرمادي على مجمع العمل. هذا هو مجمع العمل الوحيد في العنقود، ويحتفظ العنقود دائمًا بمجمع واحد على الأقل. أضف مجمعًا آخر أولاً إذا كنت تريد استبداله، أو قلصه إذا كنت تريد عددًا أقل من العقد، أو احذف العنقود.

تظهر وحدات تخزين Longhorn بحالة "degraded". عدد عقد العمل أقل من عدد النسخ المتماثلة، لذا لا يستطيع Longhorn وضع كل نسخة على عقدة منفصلة. قم بتوسيع مجمع العمل حتى يصبح عدد العمال مساويًا لعدد النسخ المتماثلة على الأقل، وستتعافى وحدات التخزين من تلقاء نفسها.

يبلغ مستوى NFS أن الخادم غير قابل للوصول. يتم الفحص من شبكة العنقود، وليس من Cockpit، لأن عمليات التثبيت تتم من هناك. تأكد من أن خادم NFS يستمع فعليًا على عنوان يمكن للعقد الوصول إليه وأن مسار التصدير يسمح بالشبكة الفرعية للعقد — فالخادم الذي يمكن الوصول إليه من جهازك المكتبي ولكنه مرتبط فقط بواجهة إدارة سيفشل في هذا الفحص.

تظهر عقدة بحالة "NotReady" أو العنقود "Degraded". تحقق من أن الجهاز الافتراضي للعقدة قيد التشغيل (ربما تم إيقافه، أو قد يكون مضيفه معطلاً). بمجرد عودة الجهاز الافتراضي وإعادة اتصاله بالشبكة، تنضم العقدة مجددًا وتعود الحالة الصحية إلى Healthy تلقائيًا.

لا يمكن لـ kubectl الاتصال بعد تنزيل ملف kubeconfig. تأكد من أن KUBECONFIG يشير إلى الملف الذي تم تنزيله وأن جهازك يمكنه الوصول إلى عنوان عقدة لوحة التحكم عبر الشبكة. أعد تنزيل kubeconfig إذا تغير عنوان العنقود.

فقدت التطبيقات بياناتها بعد انتقال كبسولة إلى عقدة أخرى. يحدث هذا مع مستوى تخزين Local Path، الذي يحتفظ بالبيانات على عقدة واحدة. بالنسبة للبيانات التي يجب أن تتبع التطبيق، استخدم المستوى مشترك (NFS) أو متماثل (Longhorn) بدلاً من ذلك. انظر التخزين لتطبيقاتك.

---

مواضيع ذات صلة

• جدولة الموارد الموزعة (DRS) والتوفر العالي (HA) — كيف يوزع Cockpit أجهزة العقد الافتراضية ويوازنها عبر المضيفين.
• الشبكات الافتراضية — الشبكات الموزعة التي تتصل بها عقد العنقود.
• التخزين ومستودعات التخزين — مستودعات التخزين المشتركة التي تتيح للعناقيد العمل عبر المضيفين.