ما المكوّنات الرئيسية لبنية Kubernetes وما مسؤولية كلٍّ منها؟

تتكوّن مجموعة Kubernetes من مستوى تحكم بالإضافة إلى مجموعة من الأجهزة العاملة، تُسمّى العُقد، التي تشغّل التطبيقات المحوَّنة داخل Pods. تحتاج كل مجموعة إلى عقدة عاملة واحدة على الأقل لتشغيل Pods.

مفهوميًا، Kubernetes تصريحي: أنت ترسل الحالة المرغوبة إلى خادم API (وتُخزَّن في etcd)، ثم تشغّل وحدات التحكم حلقات مواءمة مستمرة تراقب الفروق وتتصرف لدفع الحالة الفعلية نحو الحالة المرغوبة.

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

يتخذ مستوى التحكم القرارات العامة بشأن المجموعة (مثل الجدولة) ويستجيب لأحداثها. وفي بيئات الإنتاج يعمل عادة عبر عدة آلات لتحقيق التوافر العالي.

• kube-apiserver — المكوّن الأساسي الذي يوفّر واجهة Kubernetes HTTP API. وهو الواجهة الأمامية لمستوى التحكم ونقطة الاتصال الوحيدة: تمر عبره جميع عمليات المصادقة والتفويض والتحقق من الطلبات وقراءة/كتابة حالة المجموعة. وهو قابل للتوسّع أفقيًا. وفي النشر المعتاد، يكون هو مكوّن Kubernetes الوحيد الذي يقرأ ويكتب حالة المجموعة مباشرةً في etcd؛ أمّا بقية المكوّنات فتتفاعل مع الحالة عبر خادم API.
• etcd — مخزن مفاتيح/قيم متّسق وعالي التوافر يُستخدم بوصفه مخزنًا خلفيًا لـ Kubernetes لجميع بيانات المجموعة: الإعدادات والحالة والبيانات الوصفية. etcd إلزامي وهو مصدر الحقيقة الوحيد — فقدانه يعني فقدان كل حالة المجموعة، لذا يجب أن يعمل مع quorum (عدد فردي من الأعضاء) وأن يُنسخ احتياطيًا بانتظام.
• kube-scheduler — يراقب الـ Pods التي لم تُربط بعد بعقدة، ويُسنِد كل Pod إلى عقدة مناسبة، مع مراعاة الموارد والقيود والسياسات.
• kube-controller-manager — يشغّل وحدات تحكم تنفّذ سلوك واجهة Kubernetes API (مثل Node controller وJob controller وEndpointSlice controller). تراقب كل وحدة تحكم الحالة المرغوبة وتُقارب الحالة الفعلية نحوها.
• cloud-controller-manager (اختياري) — يتكامل مع مزوّد السحابة الأساسي، مع عزل المنطق الخاص بالسحابة عن مكوّنات Kubernetes الأساسية.

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

تعمل هذه على كل عقدة، وتحافظ على تشغيل Pods وتوفّر بيئة التشغيل.

• kubelet — الوكيل الذي يضمن أن Pods تعمل، بما في ذلك حاوياتها. يراقب خادم API لتعيينات Pods، ويبدأ الحاويات عبر وقت التشغيل، ويُركّب وحدات التخزين، ويشغّل فحوصات الحيوية/الجاهزية، ويُبلّغ حالة العقدة.
• kube-proxy — يطبّق شبكات Service عبر برمجة قواعد iptables أو IPVS على العقد بحيث يُعاد توجيه الحركة إلى Service إلى عناوين IP الصحيحة للـ Pod. ويُوسَم بأنه اختياري لأن بعض إضافات CNI (مثل Cilium في وضع eBPF) تتولى مهمته، لكنه في مجموعة قياسية مطلوب.
• Container runtime — البرنامج المسؤول عن تشغيل الحاويات (مثل containerd وCRI-O، عبر واجهة CRI).

الإضافات

توسّع الإضافات وظائف المجموعة: DNS الخاص بالمجموعة (CoreDNS افتراضيًا)، واجهة Dashboard الويب، ومراقبة موارد الحاويات، والتسجيل على مستوى المجموعة.

متابعة شائعة: كل الاتصالات تمر عبر خادم API — فالمجدول ووحدات التحكم وkubelets تراقبه فقط وتتفاعل معه — مما يجعل خادم API المحور الحاسم في المجموعة.