ميزات الذكاء الاصطناعي

أكبر ميزة تنافسية لـ Kudashai هي إمكانياته المدعومة بالذكاء الاصطناعي. نحن ندمج نماذج اللغات الكبيرة (LLMs) في إدارة Kubernetes اليومية الخاصة بك.

المزودون المدعومون

يتوافق Kudashai بمرونة مع مختلف مزودي الذكاء الاصطناعي:

• OpenAI (GPT-4)
• Anthropic (Claude)
• Google (Gemini)
• DeepSeek
• Ollama (Local AI)
• LMStudio
• OpenRouter

النماذج المختبرة

يتم التحقق من وكيل KudashAI عبر مجموعة سيناريوهات آلية (التشخيص من السجلات، وأعطال سحب الصور وConfigMap، والسياق متعدد الأدوار، والرفض لأسباب أمنية، وعرض الموارد على مستوى العنقود). اجتازت النماذج أدناه جميع السيناريوهات في الإصدار الحالي وهي التي نوصي بها.

النموذج	المزود	طريقة التشغيل	ملاحظات
Gemini 3.8 Flash	Google	واجهة سحابية	الأسرع؛ أقل من دقيقتين للمجموعة كاملة
DeepSeek V4 Pro	DeepSeek أو بوابة متوافقة مع OpenAI	واجهة سحابية	دقة مماثلة لـ Gemini مع بطء طفيف
MiniMax M2.7	بوابة متوافقة مع OpenAI	واجهة سحابية	تم التحقق منه مع حواجز المخرجات المدمجة
Qwen3 8B	Ollama	محلي، نحو 10 دقائق للمجموعة على Apple Silicon	أفضل نموذج محلي صغير؛ يحصل تلقائياً على موجّه النماذج الصغيرة
Gemma 4 12B	Ollama	محلي، نحو 10 دقائق للمجموعة على Apple Silicon	يجتاز المجموعة؛ أبطأ في كل دور من Qwen3

النماذج الأخرى على المزودين المدعومين تعمل، لكن سلوكها غير مضمون. تُعامل النماذج المحلية الأصغر من 14B كنماذج صغيرة: يختصر KudashAI موجّه النظام ويضيف قواعد أكثر صرامة لها. شغّل Assess على المزود بعد إضافته لحفظ الفئة الصحيحة.

إمكانيات الذكاء الاصطناعي

في صفحة الموارد (Resource)، يمكنك الاستعانة بالذكاء الاصطناعي لتنفيذ:

1. استكشاف الأخطاء وإصلاحها تلقائياً: إذا فشل Pod (مثل CrashLoopBackOff أو OOMKilled)، فسيقوم الذكاء الاصطناعي بقراءة السجلات، وتحليل الحالة، واقتراح الحلول، بل وحتى توفير كود التهيئة المكتمل والمصحح.
2. تحسين التهيئة (Config Optimization): يمكنك طلب مراجعة إعدادات Security Context، وحدود الموارد الموصى بها (Resource CPU/الذاكرة)، وأفضل الممارسات (Best Practices) في مواصفات النشر الخاصة بك من الذكاء الاصطناعي.
3. فحص تشخيصي متعدد العناقيد: من خلال AI Console، يمكنك طلب فحص المقاييس وتلخيص الحالة الصحية العامة لجميع العناقيد الخاصة بك في وقت واحد من الذكاء الاصطناعي. مثال للأمر: "تقديم ملخص لـ pods التي تحتوي على أخطاء عبر جميع العناقيد". سيقوم الذكاء الاصطناعي باستخراج المعلومات وتقديم ملخص مجمع بشكل منظم.

التفويض والأمان

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

كلا الإعدادين أدناه متاحان من صفحة Kube configurations: تفتح أيقونة الدرع على بطاقة العنقود مربع حوار وصول وكيل KudashAI (للمستخدمين الحاصلين على clusters:manage). تتحول الأيقونة إلى اللون الأخضر ما دام هناك قيد فعّال.

1. دور Kudashai. المستخدم الذي يفتقر دوره إلى k8s:write (دور Viewer) تُرفض له جميع أوامر التعديل مهما اقترح النموذج.
2. RBAC في Kubernetes. قبل عرض التأكيد، يسأل KudashAI خادم الـ API عبر SelfSubjectAccessReview عمّا إذا كانت الهوية المستخدمة تستطيع حذف المورد أو تغيير حجمه أو تعديله أو إنشاءه. لذلك لا يُظهر kubeconfig للقراءة فقط بطاقة تأكيد لتغيير لا يمكنه إجراؤه، ويقتبس الرفض سبب الخادم.
3. انتحال هوية الوكيل (اختياري، لكل بيانات اعتماد عنقود). عند تفعيله، يحمل كل طلب من الوكيل Impersonate-User: kudashai:<username> وImpersonate-Group: kudashai:<role>. عندها يكفي أن يملك kubeconfig المسجّل في Kudashai صلاحية impersonate، ويقرر RBAC العنقود نفسه ما يجوز لكل مستخدم Kudashai فعله عبر الوكيل. فعّله عبر PATCH /api/v1/app/config/kubeconfigs/<id>/agent-impersonate مع الجسم {"enabled": true}، ثم اربط الأدوار في العنقود، مثلاً:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kudashai-viewers
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: Group
  name: kudashai:viewer
  apiGroup: rbac.authorization.k8s.io

وبمعزل عن ذلك، ترفض سياسة الأمان المدمجة حذف مساحات الأسماء المحمية (kube-system وkube-public وkube-node-lease وdefault) والعُقد، والحذف الشامل بـ --all داخل مساحات الأسماء المحمية، حتى بعد موافقة المستخدم.

سياسة الموافقة لكل عنقود

يمكن للمسؤولين تقييد ما يجوز للوكيل تغييره في عنقود ما، بغض النظر عمّن يطلب وعن RBAC، عبر PATCH /api/v1/app/config/kubeconfigs/<id>/agent-policy:

{
  "mode": "confirm",
  "disableAutoApprove": true,
  "denyVerbs": ["delete", "apply"],
  "readOnlyNamespaces": ["prod", "payments"]
}

• mode: read_only يجعل العنقود بأكمله للقراءة فقط بالنسبة للوكيل.
• disableAutoApprove يزيل "Approve All" والخطط المعتمدة تلقائياً، فيُؤكَّد كل تغيير على حدة. يُنصح به لعناقيد الإنتاج.
• denyVerbs يسرد أفعال kubectl التي لا يجوز للوكيل تنفيذها هنا أبداً.
• readOnlyNamespaces يسرد مساحات الأسماء التي يمكن للوكيل فحصها لكن لا يغيّرها، بما في ذلك حذف مساحة الاسم نفسها.

الأمر المرفوض لا يصل إلى بطاقة التأكيد أبداً؛ يرى المستخدم سبب السياسة بدلاً من ذلك. أرسل {} لإعادة العنقود إلى الوضع الافتراضي (تأكيد كل تعديل، والسماح بـ Approve All).

الميزانيات: حدود صارمة لكل جلسة ولكل ساعة

لكل عنقود ميزانية تُفرض في الكود قبل كل استدعاء للنموذج وقبل كل تغيير: الرموز واستدعاءات النموذج والتغييرات المنفَّذة لكل جلسة، واستدعاءات النموذج والتغييرات لكل مستخدم في الساعة على ذلك العنقود. يمكن خفض القيم الافتراضية (400,000 رمز و80 استدعاءً و25 تغييرًا لكل جلسة؛ و400 استدعاء و80 تغييرًا في الساعة) أو رفعها لكل عنقود من مربع حوار وصول الوكيل، أو ضبطها على مستوى الخادم بمتغيرات البيئة KUDASHAI_AGENT_BUDGET_*. عندما تستنفد جلسة ميزانيتها، يتوقف الوكيل برسالة تبيّن أي حدّ تم بلوغه؛ ويُرفض التغيير الذي يتجاوز الميزانية كأي رفض سياسة آخر ولا يصل أبدًا إلى بطاقة التأكيد. تُؤخذ الأعداد من سجل تتبّع الوكيل، فتصمد أمام إعادة التشغيل وتغطي جميع نقاط الدخول. توجد الميزانيات لليوم الذي يبدأ فيه تنبيه، لا شخص، جلسةً: لا يجوز أن تتحوّل عاصفة تنبيهات إلى عاصفة استدعاءات نموذج أو تغييرات.

بيانات العنقود ليست تعليمات

تُكتب السجلات والأحداث والتعليقات التوضيحية وأسماء الموارد بواسطة أحمال العمل والمستأجرين، لذا يعامل KudashAI كل ما يعيده أي أمر كبيانات غير موثوقة. تُسيَّج النتائج وتُوسم قبل أن يراها النموذج؛ ويُعلَّم النص الذي يبدو كتعليمات (مثل "ignore previous instructions" أو "system override" أو kubectl delete مدسوس في سطر سجل) ويُبلَّغ إليك؛ ويُرفض قبل أي تأكيد أي تعديل لم يظهر هدفه إلا داخل هذا المخرج الموسوم دون أن تطلب أنت تغييراً. تُسجَّل كل خطوة، بما فيها حالات الرفض، في أثر الوكيل لأغراض التدقيق.

كل تغيير يُجرَّب تجريبيًا (dry-run) قبل موافقتك

لا تعرض بطاقة التأكيد أمرًا مجردًا أبدًا. قبل ظهورها، يُجري KudashAI تجربة جافة (dry-run) للتعديل على العنقود ويضع النتيجة على البطاقة: ما الذي سيحدث بلغة المشغّل ("deployment web في shop: replicas 3 → 0"، "ستُنهى حاويات pod الثلاث ولن يُعاد إنشاؤها"، "يديره ReplicaSet api-7d9 لذا سيُنشأ pod بديل")، وبالنسبة إلى patch وlabel وannotate وkubectl apply، فرقًا موحّدًا (unified diff) للكائن قبل التغيير وبعده. يُتحقّق من الحذف بقراءة الهدف؛ أما الإنشاء وpatch وapply فتستخدم التجربة الجافة من جهة خادم API، فتظهر أخطاء التحقق والحصص والقبول (admission) عند هذه النقطة. الأمر الذي يرفضه العنقود في التجربة الجافة لا يصل إلى البطاقة أبدًا: يعود الخطأ إلى النموذج الذي يصحّح الأمر أو يبلّغ عن المشكلة، ولا يُنفَّذ شيء. تُفحص الخطط خطوة بخطوة بالطريقة نفسها. وإذا تعذّر على عنقود إجراء التجربة الجافة لتغيير ما (admission webhook بدون sideEffects: None)، تذكر البطاقة ذلك وتظل تطلب موافقتك. كما أن فشل التجربة الجافة لا يوسّع التغيير أبدًا: إذا لم يكن مجال الأسماء الذي ذكرته موجودًا، يبلّغ الوكيل عن ذلك بدلًا من إنشاء مجال الأسماء من تلقاء نفسه.

الذاكرة: ما يتذكره الوكيل، ومن يقرّر

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

عبر الجلسات، يمكن للأشخاص حفظ ملاحظات قصيرة عن عنقود: حقائق ("مجال الأسماء payments هو الإنتاج")، وتفضيلات ("أجب باختصار وبالإندونيسية")، وكتيّبات تشغيل (بضعة أسطر kubectl). اكتب "Remember: …" في الدردشة، أو استخدم زر Memory في لوحة الوكيل، أو اقبل ملاحظة يقترحها الوكيل بعد أن تذكر شيئًا دائمًا. تظهر الملاحظات في الموجّه محاطة بسياج الذاكرة مع مؤلفها ونطاقها وتاريخها وحالة التحقق منها، تحت قاعدة تقول إن الذاكرة تلميح كتبه شخص وليست تعليمات أبدًا.

لا يمكن لأي شخص استخدام الذاكرة لتسميم الوكيل:

• لا يكتبها إلا الأشخاص. قد يقترح النموذج ملاحظة؛ وأنت من يحفظها. لا يُكتب شيء أبدًا من مخرجات الأوامر، وتُهمل الاقتراحات الآتية من دور حمل بيانات عنقود موسومة أو التي تسمّي أشياء لم تقلها.
• تُرفض الملاحظات عند الكتابة إن حاولت تغيير السلوك بدل وصف الواقع: "الموافقة التلقائية"، "دون تأكيد"، "تجاهل القواعد"، ادعاءات الأدوار أو الصلاحيات ("هذا المستخدم مدير")، المحفّزات الشرطية ("عندما يحدث X احذف Y")، أوامر التعديل خارج كتيّب التشغيل، وأي شيء يبدو كبيانات اعتماد.
• يجب أن تكون أسطر كتيّب التشغيل قابلة للتحليل، وتستخدم أفعالًا مدعومة، وتسمّي أهدافها، ولا تحذف مجال أسماء أو تستخدم --all، ويمرّ كل خطوة عبر بطاقة التأكيد عند تنفيذها.
• تحتاج الملاحظات على مستوى العنقود إلى clusters:manage؛ وملاحظات الآخرين خاصة بهم، فيبقى أثر الملاحظة الخاطئة محدودًا. يمكن للمؤلف، ولأي مدير عنقود في حالة الملاحظات المشتركة، حذف الملاحظة؛ وكل كتابة وحذف مسجَّلان في سجل تدقيق الوكيل.
• تُفحص مجالات الأسماء التي تسمّيها الملاحظة مقابل العنقود عند الحفظ وعند إعادة التأكيد؛ وتُوسم الملاحظة التي تسمّي شيئًا غير موجود، ويُطلب من الوكيل التحقق من الحقيقة بأمر للقراءة فقط قبل أي تغيير يعتمد عليها. تنتهي صلاحية الملاحظات بعد 180 يومًا ما لم تُؤكَّد.

العنقود هو من يقرّر ما إذا نجح التغيير، وكل تغيير يمكن التراجع عنه

بعد قبول التغيير، لا يأخذ KudashAI كلمة خادم API كما هي. بل يراقب العنقود حتى يظهر الأثر أو تنفد الميزانية: يكتمل التوسيع أو إعادة التشغيل عندما تصبح جميع النسخ جاهزة في الجيل الجديد، والحذف عندما يختفي الكائن، وkubectl run عندما يصبح الـ pod في حالة Running وReady، وapply عندما يستوفي كل كائن في الملف المعيار نفسه. تظهر النتيجة كسطر فحص لاحق ("ok, 8s: deployment web in shop: 3/3 replicas ready" أو "timeout, 45s: 1/3 ready; pods needing attention: web-x (ImagePullBackOff)") في الدردشة وفي النتيجة التي يراها النموذج، فيبلّغ النموذج عن الحالة الملاحَظة. وأي إجابة تدّعي النجاح بعد فحص لاحق فاشل تحصل على ملاحظة نظام ظاهرة.

قبل تنفيذ التغيير، يسجّل الوكيل ما هو على وشك تعديله: الكائن كما كان، أو حقيقة أن كائنًا يُنشأ أو يُحذف. يصبح هذا السجل عرض تراجع (Undo) أسفل النتيجة. يعرض التراجع أولًا تجربة جافة لما سيُستعاد أو يُعاد إنشاؤه أو يُزال، ثم يطبّقه عند التأكيد، ويتحقق من الأثر بالطريقة نفسها، ويُسجَّل في التدقيق. ويخضع للقواعد نفسها التي خضع لها التغيير الأصلي: دورك، وسياسة موافقة العنقود، والأفعال الممنوعة، ومجالات الأسماء للقراءة فقط. التراجع يُستخدم مرة واحدة وتنتهي صلاحيته بعد 24 ساعة؛ ولا تراجع لمجالات الأسماء ولا للـ pods المملوكة لمتحكّم، لأن إعادة إنشائها لن تعيد ما كان بداخلها أو لأن المتحكّم سيلغيها على أي حال.

سطح المكتب: صدفة (shell) تتبع العنقود

في Kudashai Desktop تحتوي لوحة الوكيل على زر Terminal. يفتح صدفة على جهازك أنت، في لوحة الطرفية أسفل الشاشة، مع KUBECONFIG يشير إلى نسخة خاصة من بيانات اعتماد العنقود المعروض والسياق محدد مسبقًا. تعمل الاختصارات والإضافات وأدوات سطر الأوامر السحابية كما في طرفيتك المعتادة؛ وتُحذف النسخة عند إغلاق الصدفة.

يربط الصدفة بالوكيل أمران:

• Attach terminal. بعد فتح الصدفة، يبدّل الزر نفسه ما إذا كانت الأسطر الأخيرة من مخرجاتها تُرفق بطلبك التالي، فيمكن لسؤال «ماذا يعني هذا الخطأ؟» أن يشير إلى ما نفّذته للتو. تُسلَّم المخرجات إلى النموذج كبيانات غير موثوقة، مثل أي مخرجات أوامر أخرى.
• Run in my terminal. تحصل كل بطاقة تأكيد على خيار رابع بجانب Approve وReject: يُكتب الأمر عند موجّه الصدفة ولا يعمل شيء حتى تضغط Enter. لا ينفّذه الوكيل ولا يعيد محاولته. بعد ذلك تراقب المحادثة صدفتك؛ وبمجرد انتهاء الأمر وعودة الموجّه تظهر بطاقة تعرض مخرجاته مع زر Show me the result الذي يسلّم تلك المخرجات إلى الوكيل كرسالتك التالية. وإذا كانت البطاقة قادمة من خطة مهام، تعود الخطوات المتبقية كبطاقة Task Plan لتشغيلها متى كنت جاهزًا.

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

أوضاع الجلسة: Plan وConfirm وAuto

اختر مقدار ما يفعله الوكيل من تلقاء نفسه في الجلسة الحالية من قائمة Mode بجانب مُحدِّد النموذج (المفاتيح 1–3 أثناء فتح القائمة):

• Plan — للقراءة فقط. كل تغيير كان الوكيل سيجريه يُقترح كخطة؛ لا يعمل شيء حتى تنفّذ الخطة، وعندها تظل كل خطوة تطلب التأكيد.
• Confirm — الوضع الافتراضي. كل تغيير يمر بتجربة جافة (dry-run) وينتظر في بطاقة التأكيد.
• Auto — التغييرات منخفضة المخاطر على أحمال العمل العادية (scale وrollout restart وlabel وannotate وpatch وset) تعمل من تلقاء نفسها، مع بقاء التجربة الجافة والفحص اللاحق والتراجع لكل منها. ما عدا ذلك يطلب التأكيد، وتوضح البطاقة السبب: delete وapply وأي شيء يمس RBAC أو namespace أو node أو secret أو مساحات أسماء النظام، وأي هدف تحذّر منه ملاحظة في الذاكرة. إذا فشل فحص لاحق أو جرى التراجع عن تغيير، يتوقف Auto لبقية الجلسة ويعود كل تغيير إلى طلب التأكيد.

اختيارك مقيّد بسياسة العنقود: العنقود للقراءة فقط يسمح بـ Plan وحده، و«تأكيد تغيير واحد في كل مرة» يقف عند Confirm، ويحتاج Auto إلى مزوّد معتمد من مجموعات التقييم. عندما يطبّق الخادم وضعًا مختلفًا عما اخترته، تخبرك وحدة التحكم بذلك.

تنطبق ميزانيات الخطوات والتغييرات لكل جلسة على العمل بلا إشراف فقط (Auto و«Approve All»). في Plan وConfirm أنت من يضغط إرسال ويوافق على كل تغيير، لذا لا تقيّد جلسة تصحيح الأخطاء الطويلة سوى ميزانية الرموز والحدود في الساعة.

التشخيص المُطلق بالتنبيه: الخطوة الأولى بلا إشراف

يمكن لتنبيه من العنقود (pod ينهار أو يفشل، عقدة NotReady، نشر فاشل، مقياس تلقائي بلغ حدّه) أن يبدأ جلسة KudashAI دون أن يكتب أحد شيئًا. ما يبدأ ضيّق عمدًا: تشخيص. تعمل الجلسة بمنفّذ للقراءة فقط، فيُرفض كل تعديل قد يقترحه النموذج قبل أن يصل إلى العنقود؛ والنتيجة جلسة في سجل المدير الذي فعّل المحفّزات، بعنوان [auto] …، تحوي السبب، وإن اقترح النموذج إصلاحًا، خطة يمكن لشخص فتحها والموافقة عليها. تنطبق الميزانيات وقواعد الذاكرة ودفاع الحقن وسياسة العنقود دون تغيير لأن الكود نفسه هو الذي يعمل. يحصل كل مورد على جلسة واحدة لكل فترة تهدئة (30 دقيقة افتراضيًا) وكل عنقود على بضع جلسات في الساعة على الأكثر (6 افتراضيًا). ويُرسل ملخص أيضًا إلى تكاملاتك المضبوطة كحدث مخصص.

ليس كل نموذج مسموحًا له بذلك. تسمّي المحفّزات مزودًا، ويجب أن يكون هذا المزود معتمدًا: يجب أن تكون حزم التقييم verified وmemory وoutcome قد نجحت جميعها على النموذج الذي يستخدمه المزود الآن (شغّل agenteval -certify)، خلال الثلاثين يومًا الأخيرة، وألا يكون النموذج من الفئة الصغيرة. عندها فقط يمكن للمدير تفعيل Allow unattended sessions للمزود؛ ويُلغي التشغيل الفاشل الاعتماد والمفتاح معًا. فعّل المحفّزات لكل عنقود من مربع حوار وصول الوكيل، باختيار المزود وأنواع التنبيهات.

واجهة دردشة الذكاء الاصطناعي

يتميز Kudashai أيضاً بمساحة دردشة ذكاء اصطناعي (AI Chatbot) مدمجة حيث يمكنك طلب معلومات متعلقة بالعنقود أو طلب إنشاء المانفيست بشكل طبيعي.

مثال للتفاعل:

"يرجى إنشاء NGINX Deployment مع 3 نسخ متماثلة وكشف المنفذ 80 عبر خدمة NodePort Service."

سيقوم Kudashai بإنشاء تهيئة K8s الصحيحة بناءً على طلبك.

الخصوصية افتراضياً: نظراً لدعمه لـ Local AI (مثل Ollama)، يمكنك تشغيل نماذج الذكاء الاصطناعي محلياً في الموقع (on-premise)، مما يحافظ على سرية مخطط العنقود الخاص بك مع مخطط عدم الاعتماد على السحابة.