ما هو Kubernetes؟

خلاصة سريعة: Kubernetes منصة مفتوحة المصدر لتنسيق الحاويات عبر مجموعة خوادم، تنشرها وفق الحالة المطلوبة وتبقيها تعمل. ويضم وحدته الأساسية Pod، ويوزع الحركة عبر Services، ويوسع النسخ ويستبدل المتعطل. قوي ومرن، لكنه يضيف تعقيدًا تشغيليًا حقيقيًا لا يناسب كل فريق.

ما هو Kubernetes؟

Kubernetes منصة لتنسيق الحاويات (Container Orchestration)، أي إدارة تشغيلها على مجموعة خوادم بدل خادم واحد. وقد طورته Google وأطلقته مصدرًا مفتوحًا عام 2014، ثم تبنته مؤسسة CNCF التي تشرف عليه اليوم. والاسم يوناني الأصل، ويعني قائد الدفة، ويُختصر غالبًا إلى K8s.

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

وهو ليس بديلًا عن Docker، بل يعمل معه ومع أي وقت تشغيل متوافق مع معايير الحاويات. Docker يبني الصورة ويشغلها على مضيف واحد، بينما يتولى Kubernetes توزيعها على عدة مضيفات وتنسيقها. ولهذا يبقى فهم الحاويات شرطًا لفهم Kubernetes.

كيف يعمل Kubernetes؟

ينقسم العنقود (Cluster) إلى طبقة تحكم (Control Plane) وعقد عمل (Worker Nodes). في طبقة التحكم يعمل خادم الواجهة (API Server) الذي يستقبل الأوامر، ومخزن الحالة (etcd) الذي يحفظ رغبات النظام، والمجدول (Scheduler) الذي يختار العقدة المناسبة، ومديرو التحكم الذين يعيدون الحالة إلى ما طُلب.

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

والنمط الأساسي هو الحالة المطلوبة (Desired State). يكتب الفريق ملفًا يصف ما يريد، ويطبقه على العنقود، ثم تبدأ حلقة المراقبة بمقارنة الواقع بالمطلوب ومعالجة الفرق. وهذا ما يجعل النظام قادرًا على التعافي من الأعطال دون تدخل يدوي في كل مرة.

ما هي Pods؟

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

وPod مؤقت بطبيعته: لا يُصلح في مكانه، بل يُستبدل بآخر عند تعطله أو عند تحديث الإصدار. ولذلك لا تُدار Pods مباشرة في الإنتاج غالبًا، بل عبر كائنات أعلى مثل Deployment، وهو يضمن العدد المطلوب من النسخ وينفذ التحديث التدريجي (Rolling Update).

كيف تُدار الشبكات والخدمات؟

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

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

كيف يتوسع Kubernetes ويستشفي؟

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

كيف تُنظم الموارد والصلاحيات؟

تُقسَّم موارد العنقود عادة بمساحات الأسماء (Namespaces)، وهي نطاقات منطقية تفصل الفرق أو البيئات. وتُضبط فيها حصص الموارد (Resource Quotas) وحدود الاستهلاك، فيُمنع فريق من استهلاك كل السعة، ويبقى لكل بيئة نصيبها المحدد.

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

ما التعقيد الذي يضيفه Kubernetes؟

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

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

متى لا تحتاج Kubernetes؟

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

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

أسئلة شائعة

مقالات ذات صلة

• ما هي الخدمات المصغرة (Microservices)؟
• ما هي المحاكاة الافتراضية (Virtualization)؟
• ما هو DevOps؟
• ما هو التكامل المستمر والتسليم المستمر (CI/CD)؟

المصادر

• Kubernetes Documentation, Overview — تحديث 30 مايو 2026
• Kubernetes Documentation, Pods — تحديث 11 أكتوبر 2026
• IBM Think, What is Kubernetes? — 11 مارس 2024
• CNCF, Kubernetes project — 2026

صورة الغلاف: Guillaume Paumier / Wikimedia Commons، بموجب رخصة CC BY.