دليل للتزويد التلقائي للعقد السحابية

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
تتطلب أعباء العمل المختلفة مواصفات أجهزة متنوعة مثل نوع الجهاز وحجمه وموقعه الجغرافي. مع صعود نماذج تعلم الآلة/النماذج اللغوية الكبيرة (ML/LLMs)، أصبح اختيار الأجهزة المناسبة أمرًا بالغ الأهمية. نحتاج إلى اتخاذ خيارات بناءً على مواصفات الأجهزة مثل نوع نظام التشغيل، والبنية، والمعالج، ونوع وحدة معالجة الرسوميات (GPU)، والتخزين. يساعد Kubernetes في تنسيق وتوزيع الموارد بين أعباء العمل المتشابهة، ولكن التزويد الديناميكي لهذه الموارد عند الطلب لا يزال يمثل تحديًا.
A Kubernetes (K8s) هي مجموعة من العقد التي تشغل التطبيقات المُحاوية بطريقة فعالة ومؤتمتة وموزعة وقابلة للتوسع. كل عقدة داخل مجموعة Kubernetes لها سمات محددة مثل نوع الجهاز وحجمه وموقعه.
تستكشف هذه المدونة ضرورة أدوات التزويد التلقائي للعقد السحابية لإدارة متطلبات أعباء العمل المتنوعة داخل مجموعات Kubernetes تلقائيًا. كما نقدم رؤى حول الحلول التي يقدمها مزودو الخدمات السحابية الرئيسيون مثل AWS و GCP و Azure. أخيرًا، نتعمق في كيفية معالجة TrueFoundry لهذه التحديات كمنصة.
مقدمة
يعمل التزويد التلقائي للعقد على أتمتة توفير مجموعة العقد المناسبة بناءً على قيود الحاويات (pods) غير المجدولة لتحسين تكاليف البنية التحتية. أدوات التزويد التلقائي للعقد في مجموعة Kubernetes مسؤولة عن الإجراءات التالية:
- الجدولة: إطلاق العقد استجابةً للحاويات (pods) غير المجدولة بعد حل قيود الجدولة عن طريق تحديد أفضل نوع وحجم ممكن للجهاز بشكل أمثل.
- الإنهاء: حذف العقد عندما لا تكون قيد الاستخدام بسبب انتهاء الصلاحية، الدمج، أو الانجراف أو الانقطاع
لماذا التزويد التلقائي للعقد؟
لدى Kubernetes عقد تعمل كأجهزة عاملة ذات تكوينات أجهزة محددة مثل نوع الجهاز وحجمه ونوع السعة، وتشير مجموعات العقد إلى مجموعات من هذه الأجهزة العاملة المشتركة. في غياب أداة التزويد التلقائي للعقد، كانت الطريقة الوحيدة لتخصيص تكوين أجهزة محدد لعبء عملك هي من خلال اختيار مجموعة العقد. يتطلب هذا من المستخدم إنشاء مجموعة عقد بالتكوين المطلوب في سحابتهم ثم إضافة تقارب العقد تقارب لمجموعة العقد المحددة في مواصفات Pod.

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

يمكن أن تكون مجموعات متطلبات تجمعات العقد عديدة، خاصة خلال مرحلة التجريب لأعباء عمل تعلم الآلة/النماذج اللغوية الكبيرة (ML/LLM). يمكن أن يستغرق التنسيق بين فرق DevOps والمنصة المنفصلة وقتًا طويلاً خلال مرحلة التطوير. لذلك، يصبح المتحكم الذي يقيم المتطلبات ديناميكيًا ويوفر البنية التحتية تلقائيًا أمرًا بالغ الأهمية.
كيف يعمل التوفير التلقائي للعقد؟
يلغي التوفير التلقائي للعقد الخطوة اليدوية لإنشاء مجموعات العقد مسبقًا عن طريق السماح للمستخدمين بإضافة متطلبات عالية المستوى كقيود. يحدد تلقائيًا أفضل نوع جهاز أو عقدة متاحة لعبء العمل.

بعض القيود الشائعة الاستخدام:
- cpu: وحدة المعالجة المركزية المطلوبة مثل
2 - memory: الذاكرة المطلوبة لعبء العمل مثل
1000 - gpu-type: نوع وحدة معالجة الرسوميات المطلوبة مثل
t4, a100 - نوع السعة: خيار الشراء مثل
on-demandأوفوري - مناطق: مواقع جغرافية، مثل
us-east-1a - نظام التشغيل: نظام تشغيل الجهاز، مثل
linuxأوwindows - المعمارية: معمارية الجهاز، مثل
arm64أوamd64

موفرو الخدمات السحابية الذين يقدمون التزويد التلقائي للعقد
يقدم كل موفر خدمة سحابية آلياته الخاصة للتزويد التلقائي. تتطلب AWS تثبيت أدوات مثل Karpenter، بينما توفر GCP حلاً مدمجًا. وقد قدمت Azure مؤخرًا مشروعها للتزويد التلقائي، وهو حاليًا في وضع المعاينة.
AWS Karpenter
Karpenter، وهو مشروع مفتوح المصدر لإدارة دورة حياة العقد مصمم لـ Kubernetes، يعزز بشكل كبير كفاءة وفعالية تكلفة تشغيل أعباء العمل على المجموعات. من خلال مراعاة قيود الجدولة مثل طلبات الموارد، ومحددات العقد، والتفضيلات، والتسامحات، وقيود انتشار الطوبولوجيا، يقوم Karpenter بتوفير العقد وإلغاء توفيرها بذكاء حسب الحاجة.
التزويد التلقائي للعقد في GCP
التزويد التلقائي للعقد، المدمج في أداة التحجيم التلقائي للمجموعات، يقوم بتحجيم مجموعات العقد الحالية بناءً على مواصفات الـ Pods غير القابلة للجدولة. تضمن ميزة التزويد التلقائي من GCP الاستخدام الأمثل للموارد من خلال مراعاة وحدة المعالجة المركزية (CPU)، والذاكرة (memory)، والتخزين المؤقت (ephemeral storage)، وطلبات وحدات معالجة الرسوميات (GPU)، وتفضيلات العقد (node affinities)، ومحددات التسميات (label selectors).
التزويد التلقائي للعقد في Azure
ميزة Azure مشروع التزويد التلقائي للعقد (NAP)، المتوفر حاليًا في وضع المعاينة، يستفيد من مشروع Karpenter مفتوح المصدر لتحديد التكوين الأمثل للأجهزة الافتراضية (VM) لتشغيل أعباء العمل بكفاءة وفعالية من حيث التكلفة. يقوم NAP تلقائيًا بنشر وإدارة Karpenter على مجموعات AKS، مما يوفر للمستخدمين تجربة سلسة.
💡
التزويد التلقائي للعقد (NAP) لـ AKS متوفر حاليًا في وضع المعاينة. نحن متحمسون جدًا لهذا المشروع الجديد ونتطلع إلى استخدامه لعملائنا. اعرف المزيد
TrueFoundry - احصل على تجربة التزويد التلقائي للعقد
تقدم TrueFoundry إمكانيات تصفية متقدمة لمجموعات العقد، محاكيةً تجربة التزويد التلقائي للعقد.

لتحقيق ذلك، اتبعنا بضع خطوات بسيطة:
- إنشاء مجموعات عقد برمجيًا بجميع تركيبات أنواع الأجهزة وأنواع السعة، مع تمكين التحجيم التلقائي وتقليلها إلى الصفر.
- ربط مجموعة العقد بنوع جهازها، ووحدة المعالجة المركزية (CPU)، والذاكرة (memory)، ونوع وعدد وحدات معالجة الرسوميات (GPU).
- ثم نقوم بتصفية مجموعات العقد هذه بناءً على المتطلبات، مما يسهل على المستخدم النهائي اختيار البنية التحتية الصحيحة.
يتيح هذا النهج للمطورين/علماء البيانات اختيار أفضل مجموعة عقد لأعباء عملهم من خلال تحليل متطلباتهم. تتيح لنا هذه الآلية البسيطة توفير نفس التجربة لأي سحابة لا تزال تفتقر إلى الدعم المدمج لمزودي التزويد التلقائي.
الخلاصة
مع استمرار تطور متطلبات البنية التحتية، يلتزم موفرو الخدمات السحابية بتبسيط عملية اختيار البنية التحتية المثلى لأعباء العمل المتنوعة. في ترو فاوندري، نشارك هذا الالتزام من خلال سعينا لتمكين المطورين بالأدوات والمعرفة التي يحتاجونها لنشر أعباء عملهم بسلاسة.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI






















.png)
.webp)










.webp)






