تخطّى Kubernetes عتبة لا تصل إليها معظم تقنيات البنية التحتية: أصبح القاعدة الافتراضية التي يعمل عليها استدلال الذكاء الاصطناعي. تضع بيانات CNCF استخدام Kubernetes عند 82% بين معتمدي الحاويات. وأمضى KubeCon + CloudNativeCon Europe 2026 في Amsterdam معظم جلساته الرئيسية على أحمال الذكاء الاصطناعي بدل الخدمات المصغرة التقليدية. ويستخدم متحكّما GitOps، Argo CD وFlux، 42% من مستخدمي K8s للتسليم الإنتاجي. السؤال لدى فرق المنصات في 2026 لم يعد هل نستخدم Kubernetes — بل كيف نُطوّر المنصة لتستضيف الاستدلال وتقديم النماذج والوكلاء المستقلين إلى جانب الخدمات التقليدية.
لماذا فاز Kubernetes بطبقة استدلال الذكاء الاصطناعي
أربعة أسباب تفسّر وضع الافتراضية:
تغاير الموارد. تحتاج أحمال الذكاء الاصطناعي إلى مزيج من CPU وGPU وذاكرة وأحياناً مسرّعات خاصة. يتعامل مُجدوِل Kubernetes مع node selectors وtaints وtolerations وdevice plugins (NVIDIA GPU operator، AMD GPU operator) بطرق لا تغطيها أُطر الخدمة الخاصة.
قياس تلقائي يطابق أشكال حركة المرور. يوفر HPA وCluster Autoscaler وKarpenter وKEDA معاً طرقاً لقياس منصات الاستدلال من صفر إلى آلاف النسخ حسب عمق الطابور أو استخدام GPU أو مقاييس مخصصة.
Multi-tenancy. تتيح Namespaces وحصص الموارد وسياسات الشبكة وحوكمة OPA/Kyverno لعنقود واحد استضافة البحث والـstaging والإنتاج بحدود نظيفة — حاسم عند ندرة الـGPU.
جاذبية المنظومة. يستهدف KServe وRay وKubeflow وvLLM Production Stack وNVIDIA Triton وHugging Face TGI كلها Kubernetes. اختيار K8s يعني الوصول إلى أغنى مجموعة بدائية جاهزة.
كيف يبدو “الاستدلال على مستوى العنقود” في 2026
تشترك منصات الذكاء الاصطناعي الحديثة على Kubernetes في أنماط متكررة:
- توجيه النماذج. بوابة مركزية (Istio أو Envoy Gateway أو طبقة مخصصة) توجّه الطلبات إلى الإصدار الصحيح وتعالج تقسيمات A/B وتطبّق حدود المعدل لكل مستأجر.
- تقاسم الـGPU. MIG على NVIDIA وtime-slicing يسمحان لعدة pods بتقاسم مسرّع واحد.
- الخدمة على دفعات. vLLM وTriton يجمعان الطلبات الواردة ديناميكياً لتحسين الإنتاجية.
- تدرّج ذاكرة KV cache. يُرقَّى/يُنزَّل كاش توليد الرموز بين HBM GPU وذاكرة المضيف وNVMe.
- GitOps لكل شيء. إصدارات النماذج وإعدادات الخدمة وقواعد التوجيه والحصص تعيش في Git. يُعايرها Argo CD أو Flux.
خلاصات KubeCon EU Amsterdam
أبرزت تغطية CNCF لـKubeCon 2026 ثلاثة خيوط:
- Platform engineering يتوحّد. تتبنى المنظمات منصات قابلة لإعادة الاستخدام مبنية على Backstage وCrossplane وأدوات Kubernetes الأصلية.
- زخم المشاريع مستمر. تُظهر بيانات CNCF نمواً مستداماً في المشاريع الأساسية (Kubernetes وIstio وPrometheus) وتبنياً قوياً للمشاريع المُتخرّجة حديثاً (Argo وCilium).
- الأمان يتحرك يساراً. أمن وقت التشغيل المبني على eBPF (Cilium Tetragon وFalco) وسياسة وقت القبول (Kyverno) وضوابط سلسلة التوريد (Sigstore وin-toto) أصبحت بدائية قياسية.
موارد ينبغي للفرق متابعتها
يُبرز “Top 28 Kubernetes Resources for 2026” من CNCF:
- Kubernetes the Hard Way وkind/minikube للأساسيات
- أرشيفات جلسات KubeCon للأنماط المُثبَتة
- Argo Rollouts وFlagger للتسليم التدريجي
- Kueue لتصفيف المهام الدفعية وأحمال الذكاء الاصطناعي
- Kyverno وOPA Gatekeeper لسياسة-ككود
إعلان
ما ينبغي لقادة platform engineering تبنّيه هذا العام
تضع بيانات CNCF لعام 2026 استخدام Kubernetes عند 82% بين معتمدي الحاويات، وأمضى KubeCon EU Amsterdam معظم وقت المنصة الرئيسية على أحمال الذكاء الاصطناعي. السؤال لم يعد ما إذا كنت ستُعيّر معايير Kubernetes — بل أي الإضافات والممارسات تُفرّق بين المنصات الجاهزة للاستدلال وعناقيد pods عاديّة. هذه الأولويات الثلاث تُعالج الثغرات التي تُعيق تسليم الذكاء الاصطناعي أكثر.
1. إضافة الجدولة الواعية بالـGPU والرصد قبل استقبال أول فريق ML
الخطأ الأكثر شيوعاً عند إضافة أحمال الذكاء الاصطناعي إلى عنقود Kubernetes قائم هو استقبال فرق ML قبل جهوزية طبقة الجدولة والرصد. بدون NVIDIA GPU Operator (أو ما يعادله من AMD) مُثبَّت ومُختبَر، لا يمكن جدولة عقد GPU بشكل موثوق. وبدون Prometheus ومُصدِّر DCGM، يكون استخدام GPU غير مرئي، ولا تستطيع فرق المنصات تشخيص ما إذا كان النموذج محدوداً بالذاكرة أو الحوسبة أو ينتظر في الطابور. تثبيت هاتين الطبقتين واعتمادهما يستغرق يومين إلى أربعة ويجب أن يتم قبل أن تكتب أي فريق ML أي deployment manifest. يُضيف Kueue — متحكّم الطابور العادل المستضاف من CNCF — إمكانية إدارة مهام batch-training المتنافسة بين الفرق التي تتشارك طاقة GPU مكلفة، مانعاً أي فريق من استهلاك الحصة الكاملة للعنقود.
2. وضع معايير GitOps لإصدارات النماذج وإعدادات الخدمة
يُظهر مسح CNCF أن Argo CD وFlux معاً مُعتمَدان من 42% من مستخدمي Kubernetes للتسليم الإنتاجي. لأحمال الاستدلال، GitOps ليس ممارسة جيدة — إنه متطلب حوكمة. إصدارات النماذج وإعدادات الخدمة وقواعد التوجيه وحصص الموارد كلها تحتاج مصدر حقيقة واحداً يُنتج مسار تدقيق لمن غيّر ماذا ومتى. أكّدت جلسات platform engineering في KubeCon EU Amsterdam أن المنظمات التي تتوحّد على منصات مطورين داخلية مبنية على Backstage تستخدم GitOps باستمرار كطبقة تعايير تحتها. فريق يُسلّم تحديثات النماذج بتعديل مباشر لـmanifests Kubernetes — بدون commit في Git في فرع مُسمَّى — لا يستطيع إعادة إنتاج إعدادات الخدمة الماضية، ولا التراجع الآمن، ولا تلبية متطلبات تدقيق التحكم بالوصول التي يطلبها بشكل متزايد العملاء المؤسسيون في استبيانات مشتريات الذكاء الاصطناعي.
3. نشر KServe أو vLLM Production Stack كطبقة استدلال لا خادم مخصص
أكثر إطاري خدمة استدلال تبنياً في 2026 — KServe وvLLM Production Stack — يُغطيان أنماط الخدمة المهمة: autoscaling من الصفر، ونشر canary لانتقالات إصدار النموذج، وخدمة متعددة النماذج على hardware GPU مشترك، والخدمة على دفعات الديناميكية لرفع الإنتاجية. بناء خادم نموذج مخصص فوق FastAPI أو Flask خام هو النمط الذي يُسبّب أكبر قدر من إعادة الهندسة عندما يَنمو حجم حركة الاستدلال أو تزداد وتيرة تحديثات النماذج. لاحظت بيانات McKinsey 2026 عن القوى العاملة في مراكز البيانات أن توفر مهندسي البنية التحتية للذكاء الاصطناعي هو ثاني أكبر عائق في نشر الذكاء الاصطناعي المؤسسي عالمياً — وهذا يعني أن تكلفة إعادة هندسة طبقة خدمة مخصصة أعلى من تكلفة تعلّم سطح تكوين KServe أو vLLM. عيّر المعايير مرة واحدة واستثمر في المنظومة، لا في تجريد خاص يحتاج صيانة إلى أجل غير مسمى.
إضافات لفرق المنصات لأحمال الاستدلال
للفرق التي تشغّل Kubernetes لكنها لم تستضف الاستدلال بعد، أسرع الإضافات:
- Kueue — تصفيف عادل للتدريب والاستدلال الدفعي
- KServe أو vLLM Production Stack — خدمة النماذج مع autoscaling وcanary
- NVIDIA GPU Operator / AMD GPU Operator
- Prometheus + DCGM exporter — رصد واعٍ بالـGPU
- Karpenter أو Cluster Autoscaler
- جامعات OpenTelemetry — لتتبع مسارات طلبات الاستدلال
ما ينبغي مراقبته خلال 12 شهراً
- WASM على Kubernetes لدوال استدلال خفيفة على عقد الـedge
- Confidential computing (TDX، SEV-SNP) لأحمال منظَّمة
- اتحاد العناقيد للاستدلال متعدد المناطق ضمن قيود سيادية
- بدائية موجّهة للوكلاء لأن الوكلاء المستقلّين يحتاجون أنماط تنسيق لا تغطيها تجريدات pod-and-deployment الحالية بالكامل
الخلاصة
Kubernetes هو الافتراضي الآمن لاستدلال الذكاء الاصطناعي في 2026. فرق المنصات التي تستثمر في الجدولة الواعية بالـGPU وGitOps وإضافات الاستدلال ستنفق أقل على تكاليف السحابة وستطلق نماذجها أسرع.
الأسئلة الشائعة
هل تحتاج الفرق الصغيرة Kubernetes فعلاً؟
للأحمال الصغيرة، خدمات الحاويات المُدارة (ECS وCloud Run وFly.io) قد تكون أبسط. عندما تحتاج جدولة GPU أو عزل multi-tenant أو قياس تلقائي غني، يستحق Kubernetes الاستثمار.
Argo CD أم Flux؟
كلاهما متخرّج من CNCF ومُثبَت إنتاجياً. لـArgo CD واجهة أقوى؛ Flux أخف وأكثر توجهاً لـGit. اختر واحداً ووحّد عليه.
كيف يدير Kubernetes تقاسم GPU؟
عبر NVIDIA GPU Operator وMIG وtime-slicing أو المحاكاة الافتراضية. يضيف KServe وvLLM الـbatching لرفع الاستخدام أكثر.
