عندما يكون Kubernetes هو المقايضة الخاطئة للأداء_

Kubernetes هو افتراضي جيد لمعظم منصات الويب.

يوفر للفرق القدرة على نشر التطبيقات بشكل متكرر، والعزل بين الموارد، واكتشاف الخدمات، ونموذج تشغيلي ناضج. بالنسبة لواجهة برمجة التطبيقات (API) النموذجية، أو أسطول العمال، أو النظام الداخلي، تفوق هذه الفوائد على التكاليف المرتبطة.

الخطأ هو تحويل ذلك إلى قاعدة عالمية.

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

## ما الذي يضيفه النظام الأساسي

Kubernetes لا يقوم بتشغيل عملية واحدة فحسب. بل يلفها في نموذج تنفيذي أوسع:

- شبكات الحاويات
- توجيه الخدمات
- إدارة حزم kube-proxy أو eBPF
- المجموعات (cgroups) وجدولة وحدة المعالجة المركزية
- الشبكات العامة في العديد من البيئات

بالنسبة لمعظم التطبيقات، تعتبر هذه التكاليف مقبولة.

بالنسبة للأنظمة التي تهتم باللاتنسيات الطويلة، أو تنظيم حزم البيانات، أو التفاعل المباشر مع NIC، قد لا تكون كذلك.

## القرار الحقيقي يتعلق بالتحديد

القضية عادة ليست متوسط اللاتنسي. بل هي التباين.

بعض الأحمال تهتم أكثر بكثير بالتذبذب من اهتمامها بمعدل النقل:

- معالجة الحزم
- التداول منخفض اللاتنسي
- إدخال البيانات المتخصصة
- الشبكات في مستوى المستخدم باستخدام DPDK أو أساليب مشابهة

في تلك الأنظمة، قد تكون فوائد خطة التحكم في Kubernetes أقل أهمية من:

- وضع ثابت لوحدة المعالجة المركزية
- عدد أقل من طبقات الشبكة
- ضوضاء أقل من الجدول الزمني
- وصول أكثر قابلية للتنبؤ إلى الأجهزة

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

## لا ينبغي على معظم الفرق قراءة هذا على أنه "تجنب Kubernetes"

بالنسبة للأنظمة SaaS العادية، فإن الاستنتاج المعاكس عادة ما يكون صحيحاً.

إذا كانت نقطة الاختناق في منتجك هي لاتنسي قاعدة البيانات، أو المحاولات بلا حدود، أو تخزين الكائنات البطيء، أو منطق التطبيق المكلف، فمن المحتمل ألا تكون الانتقال بعيداً عن Kubernetes هو الحل.

يجب أن يكون معيار ترك النظام الأساسي مرتفعاً.

## طريقة أفضل لتقييم ذلك

قبل أن تلوم Kubernetes، تحقق من:

- هل تقيس اللاتنسي الطويل، وليس فقط المتوسطات؟
- هل نقطة الاختناق هي الشبكة، أو جدولة وحدة المعالجة المركزية، أو شيء آخر تماماً؟
- هل ستساعد التوافق في العقد، أو تثبيت وحدة المعالجة المركزية، أو العقد المخصصة في حل جزء كافٍ من المشكلة؟
- هل تستخدم نموذج CNI وتوجيه يتوافق مع الحمل؟

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

## متى تصبح الخوادم الفعلية منطقيّة

تصبح الخوادم الفعلية أو الخوادم المخصصة أكثر دفاعاً عندما:

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

هذه شريحة ضيقة من الأنظمة. إنها حقيقية، لكنها ضيقة.

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

## المزيد من القراءة

- [Kubernetes: شبكات الكلاستر](https://kubernetes.io/docs/concepts/cluster-administration/networking/)
- [Kubernetes: سياسات إدارة وحدة المعالجة المركزية](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/)
- [DPDK](https://www.dpdk.org/)