تخطَّ إلى المحتوى

☸️ شرح Kubernetes

معمارية Kubernetes: مستوى التحكّم والعُقد

الدرس 2 من 35· ⏱ 2 دقائق قراءة

لفهم كيف يحقّق Kubernetes وعوده — الجدولة والشفاء الذاتي والتوسيع — نحتاج إلى معرفة مكوّناته الداخلية. تبني هذه الصفحة على ما هو Kubernetes؟، وتشرح المعمارية التي تجعل كل ذلك ممكنًا.

الصورة الكبيرة: مستوى التحكّم + عُقد العمل

يتكوّن أي عنقود (Cluster) من جزأين:

  • مستوى التحكّم (Control Plane): «الدماغ» الذي يتّخذ القرارات — أين تعمل الحاويات، ومتى تتوسّع، وكيف تتعافى.
  • عُقد العمل (Worker Nodes): الخوادم التي تعمل عليها حاوياتك فعليًا.

يعمل الجزءان معًا في حلقة مستمرّة: مستوى التحكّم يقارن الحالة المطلوبة (ما طلبتَه) بـالحالة الفعليّة (ما يجري حقًّا)، ويصلح الفارق باستمرار. تُسمّى هذه الفكرة حلقة المطابقة (Reconciliation Loop)، وهي جوهر Kubernetes.

مكوّنات مستوى التحكّم

  • kube-apiserver: الباب الأمامي للعنقود. كل أمر (منك أو من مكوّن داخلي) يمرّ عبره. حين تنفّذ kubectl apply، فأنت تخاطب هذا المكوّن.
  • etcd: مخزن بيانات من نوع مفتاح-قيمة، يحفظ حالة العنقود كاملةً. إنه المصدر الوحيد للحقيقة؛ فقدانه يعني فقدان معرفة العنقود بنفسه، لذا يُنسخ احتياطيًا بعناية.
  • kube-scheduler: يقرّر على أي عقدة تُشغَّل كل Pod جديد، بناءً على الموارد المتاحة والقيود.
  • kube-controller-manager: يشغّل «المتحكّمات» — حلقات تراقب الحالة وتصلحها (مثلًا: إن طلبت 3 نسخ وبقيت نسختان، ينشئ المتحكّم نسخةً ثالثة).
  • cloud-controller-manager (اختياري): يربط العنقود بخدمات مزوّد السحابة (موازنات الأحمال، الأقراص...).

مكوّنات عُقد العمل

على كل عقدة عمل تعمل ثلاثة مكوّنات أساسية:

  • kubelet: الوكيل الذي يتلقّى الأوامر من مستوى التحكّم، ويتأكّد أن الحاويات المطلوبة تعمل فعلًا على هذه العقدة وبصحّة جيّدة.
  • kube-proxy: يدير قواعد الشبكة على العقدة ليتمكّن الترافيك من الوصول إلى الحاويات الصحيحة.
  • زمن تشغيل الحاويات (Container Runtime): البرنامج الذي يشغّل الحاويات فعليًا، والمعيار اليوم هو containerd.

كيف يتدفّق النشر خطوةً بخطوة

لنتتبّع ما يحدث حين تطلب تشغيل تطبيق:

  1. تنفّذ kubectl apply -f deployment.yaml واصفًا الحالة المطلوبة.
  2. يستقبل kube-apiserver الطلب ويحفظه في etcd.
  3. يلاحظ المتحكّم وجود نسخ مطلوبة غير موجودة بعد، فيطلب إنشاء Pods.
  4. يختار kube-scheduler عقدةً مناسبة لكل Pod.
  5. يتلقّى kubelet على تلك العقدة الأمر، ويطلب من زمن التشغيل تشغيل الحاوية.
  6. تستمرّ حلقة المطابقة: إن تعطّلت حاوية لاحقًا، يكتشف المتحكّم الفارق ويعيد الحالة إلى ما طلبتَه — دون تدخّل منك.
# أنت تصف "ماذا تريد" فقط؛ المعمارية أعلاه تتكفّل بالباقي
kubectl apply -f deployment.yaml

لماذا تهمّك هذه المعمارية؟

فهم هذه المكوّنات يجعل تشخيص المشكلات منطقيًا لا سحريًا: إن لم يُجدوَل Pod، تنظر إلى الـ scheduler والموارد؛ وإن تعذّر الوصول إلى العنقود، تنظر إلى الـ apiserver؛ وإن ضاعت الحالة، تفكّر في etcd. المعمارية خريطتك عند حلّ المشكلات.

الخطوات التالية

بعد استيعاب المعمارية، ستنتقل إلى أصغر وحدة نشر — الـ Pod — ثم الـ Deployments التي تديرها، والخدمات (Services) التي تكشفها للشبكة. راجع دائمًا الأساس المفاهيمي في ما هو Kubernetes؟.

شرح معمارية Kubernetes: مستوى التحكّم والعُقد — Kubernetes بالعربي
معمارية Kubernetes: مستوى التحكّم والعُقدKubernetes بالعربي · The Code Fix

هل كان هذا الدرس مفيدًا؟