مقارنة توزيعات كيبرنيتيس لبيئة معملية منزلية تحتوي على 3 عقد

اختيار أفضل نسخة من كيبرناتس لبيئتنا المحلية

Page content

أنا مقارنة بين نسخ Kubernetes المضيفة محليًا
التي تناسب المختبر المحلي القائم على Ubuntu مع 3 عقد (16 جيجابايت من الذاكرة، 4 نوى لكل منها)، مع التركيز على سهولة التثبيت والصيانة، والدعم لوحدات التخزين المستمرة (Persistent Volumes) والمحولات (LoadBalancers).

الموقف: لدينا ثلاث عقد من Ubuntu (16 جيجابايت من الذاكرة، 4 نوى لكل منها) في مختبر محلي. لا تُعتبر الموثوقية العالية (HA) أو دعم ARM أولوية. نريد تجميعًا (cluster) من Kubernetes سهل التثبيت ومتواضع الصيانة (إما تجميع واحد العقد أو 3 عقد) مع دعم لوحدات التخزين المستمرة (Persistent Volumes) وخدمات المحولات (LoadBalancer) (حتى تعمل التطبيقات السحابية المطلوبة للتخزين أو العناوين الخارجية بسلاسة).
سنتركّز على خيارات التجميع بثلاث عقد دون متطلبات الموثوقية العالية أو توافق مع وحدات معالجة ARM.

kubernetes homelab

فيما يلي نقارن بين التوزيعات الخفيفة الشهيرة لـ [Kubernetes(https://www.glukhov.org/ar/post/2024/10/kubernetes-cheatsheet/ “قائمة ووصف لأهم الأوامر الشائعة والمفيدة في k8s - كتيب k8s”)

  • K3s، MicroK8s، Minikube، و kubeadm (Kubernetes الأصلي) - وكيف تقارن فيما بينها حسب المعايير الرئيسية (الميزات، التثبيت/الصيانة، دعم PV/LB، متطلبات الموارد، إعداد التجميع، والأدوات). كما نقدم بعض التوصيات لاختيار ما يناسب موقف المختبر المحلي.

K3s (Kubernetes الخفيف من Rancher)

الميزات الرئيسية: K3s هو توزيع Kubernetes معتمد من CNCF تم تصميمه لاستخدام موارد قليلة (يمكنه العمل حتى على 512 ميجابايت من الذاكرة). يُعبّئ K3s كل مكونات وحدة التحكم في Kubernetes في ملف واحد وعملية واحدة، باستخدام مكونات خفيفة (مثل قاعدة بيانات SQLite كافتراضي بدلًا من etcd، وflannel للشبكات). يتضمن K3s إعدادات مُحكمة مثل متحكم الدخول (Ingress Controller) المدمج (Traefik) ومُوزع الحمل البسيط. يُزيل K3s الميزات القديمة أو التجريبيّة لخفض التضخم.

  • سهولة التثبيت والصيانة: بسيطة جدًا - يمكننا تثبيته باستخدام نص واحد (curl ... | sh) أو عبر أدوات مثل K3sup. تبدأ العقدة الرئيسية بالتشغيل مع المكونات الافتراضية دون الحاجة إلى إعدادات إضافية. إضافة العقد سهلة (تشغيل وكيل K3s مع مفتاح من العقدة الرئيسية). التحديث سهل (استبدال الملف الثنائي أو استخدام نص التثبيت لنسخة جديدة). لا حاجة لتهيئة etcd منفصلة (ما لم نختر إعداد HA متعدد الماسترز). تم تصميم K3s ليحتاج إلى تدخل قليل بعد التثبيت، مما يجعله شائعًا في IoT والمختبرات المنزلية.

  • دعم وحدات التخزين المستمرة: مدمج. بشكل افتراضي، يحتوي K3s على local-path StorageClass من Rancher، الذي يوفر وحدات تخزين PV ديناميكيًا على نظام الملفات المحلي لكل PVC. هذا يعني أن أي PVC سيُلبى تلقائيًا من خلال إنشاء حجم hostPath على العقدة. إنه حل تخزين لوحدة واحدة (كل حجم على قرص عقدة واحدة)، لكنه يعمل بشكل افتراضي لتطبيقات مُستمرة. للمخزنة المتقدمة، يمكن إضافة شيء مثل Longhorn من Rancher (تخزين كتل موزع) الذي يدعمه K3s، لكن لمعمل المختبر، فإن المُوزع local-path الافتراضي عادة كافٍ.

  • دعم المحولات: مدمج. يحتوي K3s على متحكم خفيف يُسمى ServiceLB (سابقًا “Klipper LB”) يسمح بخدمات نوع LoadBalancer للحصول على عنوان IP/منفذ على العقدة دون أي مزود سحابي خارجي. عند إنشاء خدمة LoadBalancer، يقوم K3s بتثبيت DaemonSet من صغار مكونات LB (svc-...) على كل عقدة، والتي تستخدم منافذ العقدة لتحويل البيانات إلى الخدمة. في الأساس، يستخدم K3s عنوان IP للعقدة (داخلي أو خارجي) كعنوان IP للمحول، ويستخدم iptables في مكونات المحول لتحويل البيانات إلى عنوان ClusterIP للخدمة. يعمل هذا دون أي إعدادات - الخدمات لن تبقى “معلقة” (مختلفًا عن Kubernetes الأصلي على الأجهزة المادية). التبادل هو أن عنوان IP الخارجي للمحول سيكون أحد عناوين العقد (أو جميع العقد) ويجب التأكد من أن المنفذ متوفر. لمعظم استخدامات المختبر المحلي (عرض عدد قليل من الخدمات على منافذ HTTP/HTTPS)، هذا مثالي تمامًا. إذا لزم الأمر، يمكننا تعطيل المحول المدمج وتثبيت MetalLB يدويًا، لكن معظم المستخدمين يفضلون الافتراضية المريحة.

  • متطلبات الموارد: منخفضة جدًا. يمكن لـ K3s العمل حتى على معدات منخفضة الأداء. رسميًا، 512 ميجابايت من الذاكرة وعدد قليل من الميجابايت من القرص كافٍ لعقدة خادم. عمليًا، قد يستخدم تجميع صغير بضع مئات من الميجابايت من الذاكرة لوحدة التحكم. حجم ملفه الثنائي أقل من 100 ميجابايت. تكاليف المعالج منخفضة (K3s يستخدم قليلاً أكثر من MicroK8s عند الراحة، لكنه لا يختلف بشكل كبير). عقدتنا (16 جيجابايت لكل منها) أكثر من كافية لتشغيل K3s بسلاسة.

  • تجميع واحد العقدة مقابل متعدد العقد: مناسب لكل منهما. يمكن لـ K3s العمل كتجميع واحد العقدة (كل وحدة التحكم والمهام على جهاز واحد) أو متعدد العقد. في إعداد بثلاث عقد، قد نقوم بتشغيل خادم واحد (ماستير) وعنصرين مساعدين، أو حتى جعل جميع الثلاثة خوادم لـ HA (ليس مطلوبًا هنا لأن HA ليست هدفًا). انضمام العقد سهل للغاية مع المفتاح. قاعدة بيانات SQLite الافتراضية في K3s تعمل لخادم واحد؛ لـ HA متعدد الخوادم سنقوم بتغييرها إلى etcd مدمج (K3s يمكنه القيام بذلك تلقائيًا عند تشغيل عدة عقد خوادم).

  • أدوات CLI وواجهة المستخدم: نتفاعل مع K3s تمامًا كما نفعل مع أي Kubernetes - عبر kubectl. يحتوي K3s على نسخته الخاصة من kubectl (يمكننا تشغيل k3s kubectl ... أو استخدام kubectl العادي من خلال إعداده ليشير إلى kubeconfig لـ K3s). لا توجد أداة CLI خاصّة بـ K3s سوى الأوامر المتعلقة بالتركيب؛ وهو مصمم ببساطة متعمدة. لا توجد واجهة مستخدم مدمجة (اللوحة الافتراضية لا تُثبت بشكل افتراضي). ومع ذلك، يمكننا تثبيت لوحة Kubernetes أو أدوات أخرى على K3s كما نفعل مع أي تجميع عادي. يمكن أيضًا تثبيت Rancher (أداة إدارة واجهة المستخدم من نفس الشركة) على K3s إذا أردنا واجهة مستخدم كاملة، لكنها ليست جزءًا من K3s نفسه. في الأساس، يوفر K3s واجهات API الأساسية لـ k8s، ونضيف الميزات الإضافية حسب الحاجة (مثل الدخول، التخزين، إلخ - بعضها معبأ بالفعل كما ذكرنا).

MicroK8s (Kubernetes منخفض الإعداد من Canonical)

الميزات الرئيسية: MicroK8s هو توزيع Kubernetes الخفيف من Canonical، ويُوزع كحزمة snap. يُثبيت MicroK8s تجميع Kubernetes كامل (الملفات الأصلية) بخط واحد ويتم تصميمه لسهولة الاستخدام (“منخفض الإعداد”) على جهاز واحد أو تجميع صغير. يركز على نهج “البطاريات مُضمنة” - نحصل على عدد كبير من الميزات الإضافية يمكن تمكينها عبر أوامر بسيطة. يفتقر MicroK8s إلى تجربة Kubernetes الأصلي (كل واجهات API القياسية) لكنه يحتوي على إضافات مريحة للاحتياجات الشائعة. يدعم MicroK8s التجميعات بعقدة واحدة ومتعددة العقد (يمكننا تشكيل تجميع عبر “انضمام” العقد)، ويحتوي حتى على وضع HA لوحدة التحكم (باستخدام Dqlite - SQLite موزعة - عند وجود 3 ماسترز).

  • سهولة التثبيت والصيانة: سهلة جدًا أيضًا - فقط snap install microk8s --classic على جهاز Ubuntu سيقوم بتثبيت عقدة Kubernetes. إنها حزمة واحدة تحتوي على جميع المكونات. يتم صيانة MicroK8s عبر نظام snap من Ubuntu، مما يعني أن التحديثات تتم بشكل ذري و يمكن أن تكون تلقائية (يمكننا تتبع قناة لنسخ Kubernetes). هذه القدرة على التحديث التلقائي فريدة بين هذه الخيارات - يمكننا الاشتراك لتلقي التحديثات الأمنية والصغيرة عبر تحديثات snap. يتم إدارة MicroK8s عبر أمر microk8s، الذي يحتوي على أوامر فرعية لتمكين أو تعطيل الميزات. بشكل عام، إنها منخفضة التكاليف: لا توجد حاويات أو أجهزة افتراضية لإدارتها (تُنفذ بشكل مباشر على الجهاز)، ولا توجد etcd خارجية لتكوينها (تستخدم قاعدة بيانات داخلية). الصيانة تقتصر على تحديث snap عند الحاجة واستخدام microk8s.status للرصد.

  • دعم وحدات التخزين المستمرة: متوفر عبر إضافة. بشكل افتراضي، لا يقوم MicroK8s بتوفير وحدات PV تلقائيًا حتى نتمكّن من “hostpath-storage”. تمكين هذا (باستخدام microk8s enable hostpath-storage) ينشئ StorageClass افتراضيًا يخصص وحدات تخزين من دليل على الجهاز. هذا يشبه في المفهوم مُوزع hostPath الديناميكي في K3s. بمجرد تمكينه، سيتم ربط أي PVC بـ hostpath PV على عقدة MicroK8s. (في تجميع MicroK8s متعدد العقد، سيقع hostpath PV على عقدة واحدة - مناسب للاختبار أو المختبرات المنزلية لكنه ليس تخزينًا موزعًا). يوفر MicroK8s أيضًا Mayastor وأدوات تخزين إضافية أخرى إذا أردنا تخزين متقدم عبر العقد، لكن لبساطة، تخزين hostpath يعمل بشكل جيد. ملاحظة: الإضافة ليست مفعلة افتراضيًا (لإبقاء الأمور مبسطة)، لذا سنحتاج إلى تمكينها للحصول على عمل PVCs. تشير Canonical إلى أن هذا ليس مناسبًا للاستخدام في الإنتاج مع HA (بما أنه غير مكرّر)، لكنه مثالي تمامًا للمختبرات المنزلية.

  • دعم المحولات: متوفر عبر إضافة. لا يحتوي MicroK8s على محول افتراضي، لكنه يوفر MetalLB كإضافة سهلة. تشغيل microk8s enable metallb:<start-IP>-<end-IP> يثبيت MetalLB في وضع طبقة 2 ويسمح لنا باختيار نطاق من عناوين IP من الشبكة المحلية لاستخدامها في خدمات المحولات. بمجرد تمكينه، سيتم تخصيص أي خدمة من نوع LoadBalancer تلقائيًا من هذا النطاق (وسيقوم MicroK8s بالإعلان عنها عبر ARP في الشبكة المحلية). هذا يعطي تجربة سحابية على الأجهزة المادية. (إذا لم نتمكّن من MetalLB، فستبقى خدمة LoadBalancer معلقة، لأن MicroK8s بمفرده لا يدعمها - تمامًا كما هو الحال في Kubernetes الأصلي.) في المختبرات المنزلية، MetalLB سهل الاستخدام ويسمح لنا بالوصول إلى الخدمات على شبكة محلية. سنحتاج إلى اختيار نطاق أو عنوان IP خالي في شبكة لدينا. أمر تمكين MicroK8s يجعل التكوين سهلًا، لكنه خطوة منفصلة. (بالمقارنة مع K3s، الذي يعمل بشكل افتراضي مع المحولات لكنه يحتوي على قيود استخدام عناوين IP/منافذ العقد.) يختار العديد من مستخدمي MicroK8s تمكين MetalLB كجزء من إعدادهم الأولي لمحول وظيفي.

  • متطلبات الموارد: MicroK8s خفيف نسبيًا، لكنه أعلى قليلاً من K3s من حيث الحجم. يُنفذ جميع الخدمات الأساسية (خادم API، متحكم، مخطط، kubelet، etcd أو Dqlite) بشكل مباشر. الاستخدام عند الراحة عادة ما يكون ~500–600 ميجابايت من الذاكرة للوحدة الرئيسية، حسب ما تم تمكينه من الإضافات. تشير Canonical إلى ~540 ميجابايت كحد أدنى للذاكرة. استخدام المعالج منخفض عند الراحة، وعقدتنا بـ 16 جيجابايت لديها فائض كبير. متطلبات مساحة القرص صغيرة (snap ~ 200 ميجابايت زائد بيانات etcd). في المجموع، يمكن لـ MicroK8s العمل على معدات ذات أداء معتدل (حتى يُقدّم لـ Raspberry Pis)، وفي موقفنا، تتناسب المعدات بسهولة معه. إذا تم تمكين عدة إضافات (لوحة التحكم، المراقبة، إلخ)، فسيزداد استخدام الموارد بشكل متناسب.

  • تجميع واحد العقدة مقابل متعدد العقد: يعمل MicroK8s بشكل جيد لكل منهما. يمكننا استخدامه لتجميع واحد العقدة (على سبيل المثال، على جهاز تطوير أو خادم واحد) أو إنشاء تجميع متعدد العقد عبر “انضمام” العقد. توفر وثائق MicroK8s أمرًا لإضافة عقدة (نحصل على مفتاح انضمام من العقدة الأولى ونستخدمه على العقد الأخرى). في إعداد متعدد العقد بدون HA، ستكون عقدة واحدة هي وحدة التحكم الرئيسية. مع ثلاث عقد، لدينا خيار تمكين ha-cluster (جعل وحدة التحكم HA عبر تشغيل Dqlite على ثلاث عقد)، لكن في موقفنا، HA ليست مطلوبة. سواء كان واحدًا أو ثلاث عقد، فإن التجربة هي نفسها من حيث واجهات API لـ Kubernetes. MicroK8s متعدد العقد هو أحدث قليلاً من نهج K3s، لكنه مستقر الآن. إنه خيار جيد إذا أردنا “سحابة صغيرة” من عدة أجهزة Ubuntu تعمل على k8s بجهد قليل.

  • أدوات CLI وواجهة المستخدم: يأتي MicroK8s مع أداة microk8s للسطر الأوامر، وهي مفيدة جدًا. على سبيل المثال، microk8s enable <addon> يُغير بين الخدمات المختلفة (DNS، الدخول، التخزين، metallb، لوحة التحكم، إلخ)، وmicrok8s status يعرض ما هو قيد التشغيل. كما يحتوي على kubectl مدمج: يمكننا استخدام microk8s kubectl ... (أو تعيينه) الذي يتحدث إلى التجميع - هذا مفيد لأننا لا نحتاج لتكوين kubeconfig. بالنسبة لواجهة المستخدم، يوفر MicroK8s لوحة Kubernetes Dashboard كإضافة (microk8s enable dashboard)، والتي ستقوم بتثبيت واجهة المستخدم القياسية. بمجرد تمكينها، يمكننا الوصول إليها (تُنفذ على منفذ 10443 أو عبر وكيل). لا يحتوي MicroK8s على واجهة مستخدم مخصصة له - يعتمد على لوحة Kubernetes Dashboard أو أدوات أخرى - لكن سهولة تمكينها ميزة إيجابية. في المجموع، يركز MicroK8s على تجربة “واحدة فقط” للمهام الشائعة وفلسفة “يعمل بشكل مباشر”، مما يخفف الكثير من التعقيد (على حساب إخفاء بعض التفاصيل الداخليّة). هذا يجعله جداً مناسبًا للمختبرات المنزلية لمن يرغب في تجميع Kubernetes دون إعداد كل المكون يدويًا.

  • مقارنة بين K3s و MicroK8s: كلاهما متشابهان إلى حد كبير في الأهداف والقدرات - خفيف، سهل، قابل للتوسع إلى عدة عقد. K3s يميل إلى أن يكون أكثر “يدويًا” عند إضافة الميزات الإضافية (يتم الاعتماد على مخططات Helm أو الملفات اليدوية للأشياء غير المضمنة)، بينما يوفر MicroK8s إضافات مدمجة عبر واجهته CLI. MicroK8s هو أيضًا Kubernetes أكثر “أصليًا” من الداخل (مكونات أصلية، فقط معبأة كـ snap)، بينما K3s يستخدم بعض الملفات الثنائية المخصصة وخدمة واحدة لكل شيء. كلاهما خيار جيد للمختبرات المنزلية؛ والقرار غالبًا يعتمد على الأذواق: إذا كان تفضيل Ubuntu/snaps وشعور متكامل هو الأفضل، فإن MicroK8s رائع، بينما إذا كان التفضيل هو النهج البسيط مع قليل من التحكم اليدوي، فإن K3s ممتاز. (سنتقدم ببعض التوصيات في النهاية.)

مينيكاب (مستودع كيوبس المحلي ذو العقدة الواحدة)

الميزات الرئيسية: مينيكاب هو أداة رئيسية لتشغيل كيوبس محليًا (غالبًا على جهاز الكمبيوتر أو الحاسوب المحمول للمطور) بدلًا من كластر تقليدي عبر عدة أجهزة. ينشئ مينيكاب كластر كيوبس ذو عقدة واحدة في وحدة وهمية أو حاوية على جهازنا. يُعرف مينيكاب بدعمه الواسع للبيئات – يمكنه العمل على أنظمة لينكس، ماك أو إس، ويندوز، ويدعم عدة مُعدّلات وهمية (فيريتوال بوكس، كفي إم في، هايبر-في، درايفر دوكير، إلخ). يُدار مينيكاب من قبل فرق كيوبس (SIGs) ويُستخدم غالبًا للاختبار والتعلم. على الرغم من أن مينيكاب يمكن إقناعه بتكوين متعدد العقد، إلا أنه مصمم أساسًا للكластرات ذات العقدة الواحدة (وضع “متعدد العقد” في مينيكاب يبدأ عدة عقد على نفس المضيف باستخدام مُعدّلات الحاويات – مفيد لمحاكاة كластر، لكنه لا يُستخدم لتشغيله على أجهزة مادية منفصلة).

  • سهولة التثبيت والتشغيل: يسهل استخدام مينيكاب على جهاز واحد. نقوم بتثبيت ملف ثنائي مينيكاب، نتأكد من وجود مُعدّل وهمي (أو دوكير)، ونقوم بتشغيل minikube start. سيقوم هذا بإنشاء وحدة وهمية أو حاوية محلية وتشغيل كيوبس داخلها. يمكن القول إن هذا هو أبسط طريقة للحصول على كластر كيوبس للمرة الأولى. يوفر الواجهة السطرية (minikube) الأوامر للتفاعل مع الوحدة (البدء، التوقف، الحذف) وتفعيل الإضافات. نظرًا لأن مينيكاب مصمم للاستخدام المحلي، فإنه ليس “daemon” يعمل لفترة طويلة – نبدأه عادةً عندما نحتاجه ونوقفه عندما ننتهي، على الرغم من أننا يمكننا الحفاظ على تشغيله بشكل مستمر على خادم مختبر منزلي إذا أردنا. تُسهل الصيانة والتحديثات: فقط نقوم بتحديث إصدار مينيكاب ونعيد تشغيل الكластر (يمكن لمينيكاب أيضًا تحديث إصدار كيوبس الذي يعمل به باستخدام علم). ومع ذلك، فإن أحد القيود هو أن مينيكاب مصمم ليكون ذو عقدة واحدة (إضافة عقد إضافية تعني تشغيل وحدات وهمية إضافية على نفس المضيف، وليس توصيل مضيفين منفصلين). لذا، استخدام مينيكاب على ثلاثة مضيفين ماديين منفصلين يعني في الواقع تشغيل ثلاث كластرات مستقلة ذات عقدة واحدة، وهو ما لا نريده غالبًا. يبرز مينيكاب في التطوير واختبار على جهاز واحد، لكنه لم يُصمم لإدارة كластر موزع عبر عدة خوادم مادية.

  • دعم الحجم المستمر: مدمج (hostPath). تشمل كластرات مينيكاب تلقائيًا فئة تخزين افتراضية تستخدم مُعدّل hostPath. في الواقع، يشغل مينيكاب متحكمًا صغيرًا ينشئ تلقائيًا PVs من نوع hostPath داخل الوحدة الافتراضية عند طلب PVCs. هذا يعني أننا يمكننا إنشاء PersistentVolumeClaims وستتم تلبية طلباتها باستخدام التخزين على نظام ملفات وحدة مينيكاب (عادةً تحت /tmp/hostpath-provisioner أو ما يشبهه). هذا يعمل بشكل افتراضي – لا حاجة لتكوين أي شيء لاستخدام PV الأساسي. على سبيل المثال، تُخريج الفئة الافتراضية “standard” في مينيكاب تُخريج تخزين من نوع hostPath على العقدة. ملاحظة: إذا أعادنا تشغيل أو حذف وحدة مينيكاب، فقد تُفقد هذه الحوافز hostPath (يحاول مينيكاب الحفاظ على بعض المجلدات عبر إعادة التشغيل – على سبيل المثال، /data، /var/lib/minikube، /tmp/hostpath* تُحفظ). لكن في المجمل، في بيئة غير إنتاجية هذا أمر مقبول. إذا أردنا محاكاة أكثر، فإن مينيكاب أيضًا يحتوي على إضافة قيادة hostpath CSI التي تدعم التقاط لقطات وتعمل في وضع متعدد العقد، لكنها أكثر مناسبة للتجريب. الخلاصة: يدعم مينيكاب الحوافز بشكل افتراضي عبر hostPath، وهو كافٍ لاختبار تطبيقات مُدارة في مختبر منزلي.

  • دعم LoadBalancer: مدعوم عبر التوجيه (أو إضافة MetalLB). في السحابة، يحصل خدمة LoadBalancer على مُعدّل تحميل متوازن مع عنوان IP خارجي. في مينيكاب، من الواضح أنه لا توجد مزودة سحابية، لذا يوفر مينيكاب آلية اثنتين:

    • تunnel مينيكاب: يمكننا تشغيل minikube tunnel في عملية منفصلة، والتي ستنشئ مسارًا شبكة على مضيفنا وستخصص عنوان IP لخدمة LoadBalancer. ببساطة، يستخدم مضيفنا كـ “مُعدّل تحميل خارجي”. عند إنشاء خدمة LoadBalancer، سيعرض مينيكاب “عنوان IP خارجي” (عادةً من شبكة العقدة) وستقوم عملية minikube tunnel بتوجيه ذلك إلى الخدمة. يتطلب هذا أن تظل عملية التوجيه تعمل (وعادةً صلاحية الجذر لإنشاء المسارات). إنه خطوة يدوية إلى حد ما، لكن مينيكاب يطبع تذكيرًا إذا كانت لدينا خدمة LoadBalancer دون تشغيل عملية التوجيه (“External-IP pending” حتى نبدأ التوجيه).
    • إضافة MetalLB: تحتوي إصدارات أحدث من مينيكاب أيضًا على إضافة MetalLB. يمكننا تنفيذ minikube addons enable metallb وتكوين نطاق IP (سيطلب مينيكاب ذلك منا). هذا ينشئ MetalLB داخل كластر مينيكاب، والذي سيتعامل مع خدمات LoadBalancer تمامًا كما يفعل في أي كيوبس معدّل معدني. هذا هو حل أكثر “داخل الكластر” ولا يتطلب عملية توجيه منفصلة بعد الإعداد الأولي.

    كلا الخيارين يعملان، والاختيار بينهما يعتمد علينا. لعرض خدمة واحدة بسرعة، فإن minikube tunnel سريع ومؤقت. لاستخدام دائم، يمكن تمكين إضافة MetalLB بحيث يحصل LoadBalancer على عناوين IP حقيقية (على سبيل المثال، قد نعطيه نطاقًا مثل 10.0.0.240-250 على مينيكاب مع شبكة متصلة). تذكّر أن مينيكاب عادةً ذو عقدة واحدة، لذا في الواقع “مُعدّل تحميل” لا يوزع عبر عدة عقد – إنه فقط يوفر الوصول الخارجي إلى خدمة العقدة الواحدة. هذا مناسب للتطوير. في مختبر منزلي، إذا استخدمنا واحدة فقط من عقدتنا وتشغيلنا مينيكاب عليها، يمكننا استخدام هذه الأدوات للوصول إلى تطبيقاتنا. لكن إذا أردنا الاستفادة من جميع 3 العقد، فإن طريقة مينيكاب لـ LoadBalancer ليست مناسبة لهذا السيناريو.

  • متطلبات الموارد: مينيكاب نفسه خفيف، لكنه عادةً يشغل كластر كيوبس كامل (في وحدة وهمية)، لذا فإن استخدام الموارد مماثل لمستوى كластر صغير عادي. يُنصح الحد الأدنى بـ 2 جيجابايت من الذاكرة و2 معالجًا لوحدة الافتراضية. بشكل افتراضي، يخصص مينيكاب غالبًا 2 جيجابايت من الذاكرة لوحدة الافتراضية. في حالتنا، مع 16 جيجابايت لكل جهاز، هذا أمر بسيط. مينيكاب (كيوبس) في حالة الراحة قد يستخدم ~600 ميجابايت من الذاكرة. شيء يجب مراعاته هو أن مينيكاب سيُشغل على فوق نظام تشغيلنا – إما كوحدة وهمية عبر مُعدّل وهمي أو كحاوية دوكير – مما يضيف بعض التحميل. في خادم مختبر منزلي، يمكننا تشغيل مينيكاب باستخدام “السائق none” (الذي يثبيت مكونات كيوبس مباشرة على المضيف). ومع ذلك، فإن السائق “none” (أي ما يسمى بـ “bare-metal”) يشبه في الأساس استخدام kubeadm على هذا العقد، ويحتاج إلى تنظيف يدوي، لذا ليس شائعًا. يستخدم معظم المستخدمين سائق وحدة وهمية أو دوكير. في الخلاصة، أي من عقدتنا في مختبر منزلي يمكن تشغيل مينيكاب بسهولة. المحدودة الوحيدة هي أن مينيكاب لن يستخدم موارد جميع 3 العقد – سيكون مقييدًا بالمضيف الذي يعمل عليه (ما لم نستخدم النسخة التجريبية متعددة العقد داخل نفس المضيف).

  • العقدة الواحدة مقابل العقد المتعددة: تُركز على العقدة الواحدة. مينيكاب مثالي لتشغيل كластر ذو عقدة واحدة على جهاز واحد. لديه ميزة لمحاكاة عدة عقد (على سبيل المثال، minikube start --nodes 3 مع سائق دوكير سيبدأ 3 عقد كيوبس كحاويات على نفس المضيف)، لكن هذا فقط للاختبار. لا يمكننا استخدام مينيكاب لإنشاء كластر حقيقي متعدد العقد عبر 3 خوادم مادية منفصلة. إذا كان لدينا 3 أجهزة، فسنتوجب علينا تشغيل 3 مثيلات مستقلة من مينيكاب (ليس في كластر واحد). هذا ليس تجربة كластر حقيقية (لن يعرفوا عن بعضهم البعض). لذلك، مينيكاب ليس موصى به إذا كان هدفنا هو استخدام جميع 3 العقد في كластر كيوبس واحد – إنه أفضل لسيناريوهات حيث نملك جهازًا واحدًا (حاسوبنا أو خادم واحد) ونريد تشغيل كيوبس عليه. إنه أيضًا رائع لتعلم أساسيات كيوبس وتطوير التطبيقات محليًا.

  • أدوات الواجهة السطرية والواجهة الرسومية: واجهة minikube السطرية هي الواجهة الرئيسية. نستخدمها لبدء/إيقاف الكластر، ولها اختصارات مفيدة: على سبيل المثال، minikube dashboard سيؤدي إلى تمكين لوحة تحكم كيوبس وفتحها في متصفحنا. minikube addons enable <addon> يمكن تمكين مجموعة متنوعة من المكونات الاختيارية (الدخول، metallb، مقياس الخدمة، إلخ). ينشئ مينيكاب الوصول إلى kubectl تلقائيًا (يقوم بتكوين سياق “minikube” في ملف kubeconfig). بالنسبة للواجهة الرسومية، كما ذكرنا، يمكن الوصول بسهولة إلى لوحة تحكم كيوبس عبر أمر dashboard. لا يحتوي مينيكاب على واجهة ويب خاصة به؛ يعتمد على الأدوات القياسية. يمكن أيضًا تأمين مينيكاب بسهولة لأننا يمكننا minikube ssh للوصول إلى وحدة العقدة إذا لزم الأمر. في المجمل، الأدوات مريحة جدًا لسيناريو العقدة الواحدة.

كوباديم (كيوبس عادي على عقدتنا الخاصة)

الميزات الرئيسية: كوباديم ليس “توزيعًا” بل هو الأداة الرسمية لإنشاء كластر كيوبس من الصفر. باستخدام كوباديم، نقوم بتثبيت مكونات كيوبس القياسية على أجهزتنا. إنه في الأساس طريقة نقوم بـ “صنع كластرنا الخاص” وفقًا لأفضل الممارسات دون إضافات تقدمها التوزيعات. سيقوم كوباديم بإعداد عقدة التحكم (التي تعمل على etcd، خادم الواجهة، مدير التحكم، المخطط)، وربط عقد العمال إليها. النتيجة هي كластر كيوبس قياسي تمامًا مما نحصل عليه على خوادم سحابية. هذه الطريقة توفر لنا التحكم الكامل والمرونة – نختار مُعدّل الشبكة، مُعدّل التخزين، إلخ – لكنها تتطلب أيضًا العمل اليدوي الأكبر والمعرفة. غالبًا ما تُستخدم في بيئات الإنتاج أو التعلم لفهم تفاصيل كيوبس.

  • سهولة التثبيت والصيانة: مقارنة بالآخرين، كوباديم هو الأكثر تعقيدًا. يجب علينا تثبيت الاعتماديات يدويًا (مُعدّل الحاويات مثل containerd، كوباديم، kubelet، kubectl) على كل عقدة. ثم نقوم بتشغيل kubeadm init على العقدة الرئيسية، وkubeadm join على العمال مع الرمز الذي يعطيه. كما نحتاج أيضًا إلى إعداد CNI (مُعدّل الشبكة) بعد التهيئة (كاليكو، فلينل، إلخ) لأن كوباديم لا يثبيت واحدًا افتراضيًا. هناك خطوات موثقة جيدًا لكل هذا (العملية ليست صعبة، لكنها تتضمن خطوات عديدة) – في الأساس، يحصل كوباديم على كластر بدائي لكن ينتظرنا لمعالجة الإضافات. من حيث الصيانة، نحن مسؤولون عن التحديثات (يحتوي كوباديم على أمر تحديث، لكن يجب علينا إفراغ العقد، تحديث الملفات، إلخ يدويًا)، بالإضافة إلى مراقبة صحة etcd، تجديد الشهادات، إلخ. في المجمل، كوباديم هو قوي لكن يدوي. غالبًا ما يُسمى “الطريقة الصعبة” (رغم أنه ليس صعبًا مثل بناءه من المصدر). لمحبّي التعلم في مختبر منزلي، كوباديم طريقة رائعة لفهم كيوبس بعمق. لكن إذا كان أولويتنا هي “السهولة والصيانة المنخفضة”، فإن كوباديم سيكون أكثر عملًا من K3s/MicroK8s. كل تحديث أو تغيير سيتطلب جهدًا يدويًا. مع ذلك، بمجرد إعداده، فهو المعيار: كластر كيوبس قياسي بدون تبسيطات مخفية.

  • دعم الحجم المستمر: لا يوجد افتراضيًا (يجب إضافته يدويًا). كластر مثبت باستخدام كوباديم هو في الأساس كيوبس فارغ – لا يحتوي على فئة تخزين افتراضية أو مُعدّل توزيع تلقائي من البداية. في بيئات السحابة، سيوفر مزود السحابة عادةً فئة تخزين افتراضية (مثل AWS EBS، إلخ)، لكن في بيئات مختبر منزلي معدنية، سنتوجب علينا تثبيت حلنا الخاص. الطرق الشائعة:

    • مُعدّل hostPath: يمكننا تقليد ما تفعله K3s/Minikube بتثبيت شيء مثل مُعدّل Rancher Local Path (الذي هو متحكم صغير + فئة تخزين تنشئ حوافز hostPath). هذا إضافة بسيطة (فقط ملف YAML) ويعطي لنا تخزين ديناميكي محلي.
    • NFS أو NAS: يستخدم بعض مستخدمي مختبر منزلي خادم NFS (أو NAS) ثم يستخدم حوافز ثابتة أو مُعدّل NFS CSI للاستفادة.
    • OpenEBS/Longhorn/Ceph: هناك خيارات أكثر تعقيدًا مثل تثبيت Longhorn أو Ceph RBD عبر Rook إذا أردنا تخزين موزع عبر العقد. هذه تتطلب موارد أكثر وتعقيدًا.

    النقطة الرئيسية هي أن كوباديم لا “يحل” تخزيننا – نحن نحتاج إلى اتخاذ قرار وتكوينه. إذا كانت السهولة أولوية، فإن أبسط طريقة هي تثبيت مُعدّل hostPath أو استخدام NFS. على سبيل المثال، يمكن تثبيت مُعدّل local-path من Rancher عبر بضع أوامر kubectl apply وسيحاكي سلوك K3s (إنشاء حوافز تحت /var/lib/rancher/ على أي عقدة). لكن هذا خطوة يدوية. حتى نقوم بذلك، أي PVC ننشئه سيظل في حالة “معلق” لأن كيوبس لا يحتوي على توزيع افتراضي. إذن، بينما يدعم كوباديم بالتأكيد الحوافز المستمرة (إنه كيوبس كامل)، فإن دعم الحوافز الديناميكية يعتمد على الجهد الذي نبذله لتكوينه.

  • دعم LoadBalancer: لا يوجد افتراضيًا (يجب إضافته يدويًا). قصة مشابهة هنا: في كластر تقليدي معدني، لا يوجد تنفيذ داخلي لـ LoadBalancer. إذا أنشأنا خدمة من نوع LoadBalancer على كластر كوباديم عادي، فستظل في حالة معلقة إلى الأبد حتى نثبيت متحكم لمعالجتها. الحل الشائع هو تثبيت MetalLB نحن أنفسنا. يمكن تثبيت MetalLB عبر ملف تعريف أو خريطة Helm – سنقوم بتكوين نطاق IP وسينتقل MetalLB إلى تخصيص هذه IPs لخدمات LoadBalancer (مثل MicroK8s). هناك العديد من الدليلات المتاحة لتثبيت MetalLB على كластرات كوباديم. خيار آخر يستخدمه بعض المستخدمين هو kube-vip لـ VIP للتحكم وخدمات LoadBalancer، لكن MetalLB أسهل لخدمات LoadBalancer. في الأساس، مع كوباديم لدينا الحرية (أو العبء) لضبط أي آلية توزيع تحميل تناسب احتياجاتنا. إذا لم نضبط أي شيء، فسنكون محدودين بخدمات NodePort للوصول الخارجي. في مختبر منزلي، يُنصح بتركيب MetalLB – إنه مباشر ويمنحنا وظيفة IP خدمة مشابهة للسحابة. لكن مرة أخرى، هذه خطوة إضافية يجب علينا تنفيذها (مختلفًا عن K3s الذي يعمل بشكل افتراضي أو MicroK8s مع تمكين بسيط).

  • متطلبات الموارد: كيوبس القياسي أثقل قليلاً من الإصدارات المبسطة. كل عقدة ستقوم بتشغيل kubelet وkube-proxy، والوحدة الرئيسية ستقوم بتشغيل etcd ومكونات التحكم. يمكن أن تعمل عقدة واحدة من التحكم في 2 جيجابايت من الذاكرة، لكننا غالبًا نريد قليلاً أكثر للراحة إذا كنا نشغل حاويات عليها. يشير دليل padok إلى 2 جيجابايت للوحدة الرئيسية، و2 جيجابايت للوحدة العاملة كحد أدنى. في حالتنا (16 جيجابايت لكل عقدة)، هذا أمر مقبول. قد يستخدم etcd وخدمة API عدة مئات من ميجابايت من الذاكرة لكل منهما في حالة الراحة. لا يوجد فرق كبير في وقت التشغيل بين كластر كوباديم وMicroK8s – في النهاية، MicroK8s هو نفس المكونات. الفرق فقط هو ما يعمل افتراضيًا (قد يُفعّل MicroK8s DNS والتخزين افتراضيًا، بينما في كوباديم نقوم بتثبيته). إذن، من حيث الموارد، يمكن أن يكون كوباديم خفيفًا أو ثقيلًا حسب ما نكوّنه. مع عدم تثبيت أي شيء إضافي، يمكن أن يكون خفيفًا جدًا. مع تكوين عادي (لنفترض أننا نضيف CoreDNS، لوحة التحكم، إلخ)، نتوقع استخدام ~1 جيجابايت أو نحو ذلك للاستهلاك المبدئي. لدينا الكثير من الذاكرة، لذا لا توجد مشكلة في الموارد. إنها أكثر علاقة بالوقت البشري والموارد المطلوبة لإدارته بدلاً من المعالج/الذاكرة.

  • العقدة الواحدة مقابل العقد المتعددة: يمكن لـ كوباديم القيام بالكليتين، مع المرونة الكاملة. يمكننا تهيئة كластر ذو عقدة واحدة (وحتى نطلب من كوباديم أن تسمح للعقدة الواحدة بتشغيل الأحمال عن طريق إزالة تقييد الماستر). أو يمكننا أن يكون لدينا ماستر واحد ونضم عاملين (مزيج شائع من 3 عقد). يمكننا حتى إعداد 3 ماسترات و3 عمال، إلخ – أي تكوين. في حالتنا، من المحتمل أن يكون تكوين كوباديم هو عقدة واحدة من التحكم وعاملين (بما أن التوازي ليس مطلوبًا، لا نحتاج إلى عدة ماسترات). هذا يمنحنا كластرًا وظيفيًا من 3 عقد. عملية تكوين العقد المتعددة موثقة جيدًا: في الأساس، نقوم بتثبيت كيوبس على جميع العقد، نبدأ واحدًا، نضم الآخرين. النتيجة مماثلة لما سيقدمه كластر مُدار أو توزيع آخر: عقدتنا الثلاثة تظهر في kubectl get nodes، إلخ. إذن، كوباديم يلبي بالتأكيد “يمكن استخدام جميع 3 العقد” متطلبات.

  • أدوات الواجهة السطرية والواجهة الرسومية: مع كوباديم، فإن الواجهة السطرية الخاصة هي kubeadm نفسها، المستخدمة لخطوات التثبيت والتحديث لاحقًا. في اليوم-to-Day، نستخدم kubectl لإدارة الكластر. لا توجد واجهة إدارة خاصة سوى ما يوفره كيوبس. بالنسبة للواجهة الرسومية، لا توجد أي شيء مضمّن افتراضيًا – يمكننا تثبيت لوحة تحكم كيوبس أو أي أداة أخرى يدويًا (مثل أي كластر). في الأساس، يمنحنا كوباديم لوحة كيوبس فارغة. من على عاتقنا أن نرسم عليها – وهذا يشمل تثبيت الراحة مثل لوحة التحكم، متحكمات الدخول، فئات التخزين، إلخ. يمكن أيضًا توصيل أدوات لوحة تحكم ثالثة (مثل Lens، Octant، إلخ) مع كластر كوباديم إذا أردنا تجربة إدارة واجهة رسومية، لكن هذه أدوات خارجية. في الخلاصة، مع كوباديم نحصل على بيئة كيوبس نقيّة – أقصى مرونة، لكن أيضًا الحاجة لضبط كل شيء كما لو كان هذا كластر إنتاج.

  • كوبسبراي راجع أيضًا كيفية تثبيت هذا النسخة من كيوبس مع كوبسبراي.

جدول المقارنة جنبًا إلى جنب

فيما يلي ملخص يقارن بين الخيارات الأربعة على نقاط رئيسية:

الجوانب K3s (K8s خفيف من Rancher) MicroK8s (K8s “Low-Ops” من Canonical) Minikube (K8s لتطويرSingleNode) Kubeadm (Kubernetes الأصلي)
التركيب نسخة واحدة من سكريبت التثبيت (ملف واحد). يعمل كخدمة واحدة في النظام. تركيب سريع جدًا. تثبيت عبر أوامر واحدة عبر snap على Ubuntu. جميع المكونات متضمنة. سهولة تجميعها مع microk8s join. تثبيت CLI لـ minikube، ثم minikube start لتشغيل VM/حاويات محلية. متعدد المنصات وسهل الاستخدام للمبتدئين. تثبيت يدوي لـ kubeadm، kubelet، إلخ. على كل عقدة. تشغيل kubeadm init + kubeadm join مع المتطلبات. يتضمن خطوات متعددة (التشغيل، وحدة الشبكة، إلخ).
الصيانة والتحديثات التحديثات يدوية (استبدال الملف الثنائي أو استخدام سكريبت التثبيت للنسخة الجديدة). بسيط، لأنه ملف واحد فقط؛ القليل مما يجب إدارة. لا تحديث تلقائي. تحديثات عبر snap refresh (يمكن أن تكون تلقائية). إضافات وخدمات العقدة تُدار عبر microk8s CLI. عمومًا منخفضة العمليات؛ تحديثات تلقائية متاحة. سهل حذف/إعادة إنشاء العقدة لتطوير. التحديثات عبر تحديث نسخة minikube وإعادة تشغيل العقدة. مخصص للاستخدام المؤقت (أقل تركيز على استمرارية التحديث في المكان نفسه). المستخدم مسؤول عن جميع التحديثات. استخدام kubeadm upgrade ولكن يجب إفراغ العقد، إدارة نسخة etcd، إلخ. التحكم الكامل، ولكنك تقوم بالعمل (لا تحديثات تلقائية).
نسخة K8s يتبع التحديثات بشكل وثيق (غالبًا ما يُستخدم في الإصدارات الحافة). متوافق مع CNCF. بعض الميزات معطلة افتراضيًا (النسخة التجريبية/القديمة). يتبع إصدارات K8s الأصلية (قنوات snap لـ 1.27، 1.28، إلخ). متوافق مع CNCF. في الأساس ملفات K8s الأصلية. يمكننا اختيار إصدار Kubernetes عند البدء (مثل minikube start --kubernetes-version=v1.27). الافتراضي هو أحدث إصدار مستقر. أي إصدار نريده (تثبيت إصدارات محددة من kubeadm/kubelet). Kubernetes الأصلي الكامل – نحدد الإصدار ومتى نقوم بالتحديث.
الميزات الافتراضية الميزات الافتراضية المضمنة: Flannel CNI، CoreDNS، Traefik ingress، تحميل توازن الخدمة، فئة تخزين محلية، metrics-server، إلخ. (يمكن تعطيلها إذا لم تكن مطلوبة). القليل من التكوين المطلوب للعمل. الميزات الافتراضية المحدودة: DNS عادة مفعل، والباقي خياري. إضافات سهلة عبر الأوامر لـ ingress (NGINX)، MetalLB، hostpath storage، dashboard، إلخ. يمكن تمكين وضع HA على 3+ عقد. الميزات المضمنة في VM: عادة ما تشمل Docker/containerd runtime، Kubernetes مع إضافات افتراضية مثل StorageProvisioner وDNS. إضافات خيارية (ingress، dashboard، إلخ) تُفعّل عبر CLI. لا تدعم العقد المتعددة افتراضيًا. بدون إضافات: لا شيء سوى Kubernetes الأساسية. لا ingress، ولا فئة تخزين أو توازن تحميل افتراضي، ولا dashboard حتى نثبيتها. نختار CNI (يجب تثبيت واحد للشبكة). في الأساس، عبارة عن عقدة DIY.
دعم الحجم الثابت نعم – مدمج. يحتوي Rancher على local-path dynamic provisioner، والذي ينشئ hostPath PVs على العقدة لأي PVC. فئة التخزين الافتراضية “local-path” تستخدم القرص المحلي تلقائيًا. نعم – إضافة سهلة. تمكين hostpath-storage للحصول على فئة تخزين افتراضية لـ PVs الديناميكية باستخدام hostPath. حتى تمكينه، لا توجد فئة تخزين افتراضية. الإضافة لا تدعم العقد المتعددة في الإنتاج، ولكنها مناسبة لـ homelab. نعم – مدمج. فئة التخزين الافتراضية تستخدم مُزود hostPath داخل VM لـ minikube. يتم تلبية PVCs عبر متحكم بسيط ينشئ hostPath PV على نظام الملفات للعقدة. تستمر البيانات عبر إعادة التشغيل في بعض الدirs. لا (يدوي). لا توجد فئة تخزين افتراضية – العقدة لن تحتوي على فئة تخزين في البداية. يجب على المستخدم تثبيت حل لتخزين (مثل local path provisioner، NFS، Ceph، إلخ). النهج الأساسي: تطبيق YAML لـ hostPath provisioner لمحاكاة ما تفعله K3s/Minikube. حتى يتم ذلك، تبقى PVCs معلقة.
دعم توازن التحميل نعم – خدمة ServiceLB مدمجة. متحكم K3s servicelb (Klipper) يراقب خدمات LoadBalancer ويقوم بتوزيع الأحمال على العقدة لعرضها. يستخدم IP العقدة وports المضيف لتحويل البيانات. يعمل دون تكوين. مناسب للعناصر الصغيرة؛ يستخدم IP داخلي/خارجي للخدمة. نعم – عبر إضافة MetalLB. تمكين metallb مع نطاق IP لتحديد. يوفر توازن تحميل حقيقي من طبقة 2 على المعدات المعدنية. لا يتم تمكينه افتراضيًا. بمجرد تمكينه، تحصل كل خدمة LoadBalancer على IP فريد من مجموعتنا. يتطلب بعض التكوين الأولي (نطاق IP). نعم – عبر نفق أو MetalLB. لا توجد توازن تحميل سحابي، ولكن يمكننا تشغيل minikube tunnel لتعيين IP خارجي لخدمات LoadBalancer (يخلق مسارًا على المضيف). أو تمكين إضافة MetalLB في minikube للحصول على IPs تلقائية. بشكل افتراضي، خدمات LoadBalancer ستظهر “معلقة” حتى نستخدم أحد هذه الطرق. لا (يدوي). لا يوجد توازن تحميل مدمج. عادة ما يتم تثبيت MetalLB يدويًا للحصول على وظيفة توازن تحميل على المعدات المعدنية. بمجرد تثبيت MetalLB (أو متحكم توازن تحميل آخر)، تعمل خدمات LoadBalancer. دون ذلك، تظل خدمات LoadBalancer معلقة إلى الأبد.
الشبكة (CNI) الافتراضي = Flannel (شبكة تغطية). K3s يدعم أيضًا استبدال CNI إذا لزم الأمر. يحتوي على CoreDNS مثبت لـ DNS العقدة. Traefik ingress مفعل افتراضيًا (يمكن تعطيله). الافتراضي = Calico (للمersions الحديثة في وضع HA) أو افتراض بسيط. (MicroK8s استخدم Flannel سابقًا؛ الآن يميل إلى استخدام Calico لضمان الحماية). CoreDNS مفعل افتراضيًا. NGINX ingress متاح عبر إضافة (microk8s enable ingress). الافتراضي = kubenet/bridge (يعتمد على السائق؛ غالبًا ما يستخدم شبكة NAT بسيطة). CoreDNS يعمل افتراضيًا. يمكننا تمكين إضافة NGINX ingress إذا لزم الأمر. تقتصر الشبكة على VM واحد؛ NodePort متوفر عبر minikube ip. اختيار CNI. لا يثبيب kubeadm أي مكون CNI – يجب علينا تثبيت واحد (Calico، Flannel، Weave، إلخ). لدينا التحكم الكامل. معظم الدليل يشير إلى تطبيق YAML لـ Calico بعد kubeadm init. CoreDNS مثبت افتراضيًا كـ DNS للعقدة. متحكم ingress – نختار ونثبيته بأنفسنا (مثل NGINX أو Traefik عبر manifests/Helm).
التوسيع إلى عقد متعددة نعم. مصمم لدعم العقد المتعددة. سهل الانضمام عبر رمز. يمكن استخدام قاعدة بيانات خارجية أو etcd مدمجة لـ multi-master. مثالي لـ homelab مع 2-3+ عقد. لا توجد اعتمادات إضافية مطلوبة – K3s لديه تجميع مدمج. نعم. يدعم تجميع عقد MicroK8s متعددة (مع microk8s join). يمكن تمكين وضع HA مع 3+ ماستر (Dqlite). سهل جدًا لتشكيل عقدة، خاصة إذا كانت جميع العقد تعمل على Ubuntu + snap. لا (فيزيائي). مصمم لعقدة واحدة. يمكن محاكاة عقد متعددة على جهاز واحد (عدة عقد في حاويات Docker)، ولكن لا يمكن أن تمتد عبر عدة مضيفين في عقدة واحدة. استخدم مثيلات Minikube منفصلة لـ clusters منفصلة. نعم. يدعم العقد المتعددة تمامًا (هذا هو الغرض). يمكننا أن نكون لدينا 1 ماستر + عدة عمال، أو حتى عدة ماستر (على الرغم من أن إعداد HA لـ kubeadm أكثر تعقيدًا). لا يوجد قيود مدمجة على حجم العقدة.
الإفراط في استخدام الموارد منخفض جدًا. الذاكرة للوحدة التحكمية ~<0.5 GB عند الراحة. عملية واحدة للوحدة التحكمية تؤدي إلى بصمة صغيرة. فعالة من حيث المعالج (على الرغم من استخدامها قليلاً أكثر من MicroK8s في الراحة حسب بعض التقارير). Ideal for low-power أو كمية كبيرة من القدرة الاحتياطية. منخفض. ~0.5–0.6 GB للوحدة التحكمية عند الراحة. قاعدة الذاكرة أعلى قليلاً من K3s، ولكن تبقى مستقرة. تستخدم snap من Ubuntu (قد يكون هناك بعض الإفراط في استخدام الموارد). لا تزال خفيفة نسبيًا مقارنة بـ Kubernetes الكامل. معتدل. الذاكرة الافتراضية 2 GB تُخصص (الاستخدام ~0.6 GB عند الراحة). تعمل على Kubernetes واحد كامل، بالإضافة إلى طبقة VM. لا تشكل مشكلة على أنظمة 16 GB، ولكنها تستخدم موارد من عقدة صغيرة على جهاز واحد. معتدل. عقدة واحدة مع عامل واحد قد تستخدم ~1 GB عند الراحة بعد إضافة إضافات معتادة. كل عقدة إضافية تضيف إفراطًا قليلًا (فقط kubelet، proxy). مشابه لتشغيل Kubernetes في VMs سحابية من حجم مماثل. على 3 عقد مع 16 GB لكل منها، الإفراط في استخدام الموارد لا يُلاحظ في السياق.
أدوات CLI استخدام k3s للتركيب وكمُغلف لـ kubectl (أو استخدام kubectl القياسي). لا يوجد CLI إدارة منفصل (K3s يركز بشكل كبير على “التركيب والنسيان”). بعض النصوص المساعدة (مثل k3s-killall.sh). يمكن إضافة واجهة Rancher إذا أردنا ذلك. CLI غني microk8s: مثلاً، microk8s enable/disable <addon>، microk8s status. أيضًا يحتوي على microk8s kubectl. مصمم لتبسيط المهام الشائعة (لا حاجة لتحرير ملفات النظام مباشرة للأساسيات). minikube CLI لبدء/إيقاف العقدة، إدارة التكوين والإضافات، والحصول على المعلومات (IP، عنوان الخدمة، السجلات). أيضًا يوفر أوامر مساعدة مثل minikube dashboard. التفاعل مع العقدة عبر kubectl (التكوين مُحدد تلقائيًا لسياق minikube). فقط kubeadm للاستخدام الأولي والتحديثات. العمليات اليومية عبر kubectl والأدوات الأخرى لـ Kubernetes. لا يوجد CLI خاص بالنسخة إلا في مرحلة البداية. ستكون تعمل مع الأوامر الخام لـ Kubernetes وربما أدوات النظام لصيانة.
واجهة المستخدم / لوحة التحكم لا تُضمن افتراضيًا. يمكن تثبيت لوحة تحكم Kubernetes يدويًا أو استخدام أدوات خارجية (لا شيء خاص بـ Rancher إلا إذا أضفنا Rancher). يركز K3s على التشغيل بدون واجهة. لا تُضمن افتراضيًا، لكن متاحة عبر أمر واحد: microk8s enable dashboard تثبيت واجهة Dashboard القياسية. الوصول السهل للعقدة عبر microk8s dashboard-proxy. كما أنها تتكامل جيدًا مع Lens من Canonical إذا أردنا ذلك (Lens يمكن الوصول مباشرة إلى MicroK8s). لا تُفعّل افتراضيًا، لكن أمر minikube dashboard سيقوم بتثبيت وفتح واجهة Dashboard عبر الويب لنا. هذا مخصص لراحة التطوير المحلي – أمر واحد وسنحصل على واجهة لرؤية الأحمال. لا تُضمن. قد نثبيت Dashboard (تطبيق YAML) إذا أردنا ذلك. وإلا، نستخدم CLI أو تطبيقات لوحة تحكم خارجية. في homelab، قد نثبيت Dashboard ونشكل NodePort أو نستخدم kubectl proxy لعرضها. لا يهتم Kubeadm بالواجهات.

المصادر: البيانات أعلاه مُجمعة من الوثائق الرسمية والدليل المستخدم: على سبيل المثال، مساحة الذاكرة من مقارنة MicroK8s الخاصة، تخزين الافتراضي في وثائق K3s، سلوك خدمة K3s LoadBalancer من وثائق K3s، تفاصيل إضافات MicroK8s من وثائق Canonical، PV وtunnel من Minikube من وثائق Kubernetes، وتقارير تجربة عامة. (انظر المراجع للحصول على الاستشهادات الكاملة.)

التوصيات

مع الأولويات (سهولة التثبيت/الصيانة، والدعم المدمج للتخزين والتوازنات الحمولة) والسيناريو (3 عقد Ubuntu، لا يهم الـ HA):

  • الخيارات المفضلة: K3s أو MicroK8s هما أكثر ملاءمة لبيئة homelab بـ 3 عقد:

    • كلاهما سهل جداً للتثبيت (أوامر واحدة لكل عقد) ويحتاج إلى صيانة قليلة. يخففان معظم تعقيد تشغيل العقد.
    • كلاهما يدعم التجميع متعدد العقد بشكل افتراضي (يمكننا تجميع 3 عقد ورؤية تجميع واحد موحد).
    • يوفر كل منهما حلًا لـ Volumes المستمرة والتوازنات الحمولة دون جهد كبير: K3s يحتوي عليها بشكل افتراضي (تخزين Local Path، Klipper LB) وMicroK8s يجعلها متاحة عبر أوامر enable البسيطة. هذا يعني أنه يمكننا نشر تطبيقات عادية (قواعد بيانات مع PVCs، خدمات مع نوع=LoadBalancer) مع أقل تكوين يدوي.
    • K3s قد يكون جذابًا إذا أردنا الحد الأدنى من المساحة و لا نمانع من استخدام إعداداته الافتراضية (مثل إدخال Traefik). إنه نهج “تثبيت ويعمل” مع إعدادات متحيزة. كما أنه شائع جدًا في مجتمع homelab لبساطته. سنستخدم kubectl القياسي في الغالب، ويمكننا تعديل أو تعطيل المكونات المعبأة إذا لزم الأمر. قد يكون K3s مفضلاً إذا لم نكن نستخدم Ubuntu أو إذا أحببنا نظام Rancher (أو نخطط لاستخدام واجهة Rancher لاحقًا).
    • MicroK8s قد يكون جذابًا إذا أردنا حلًا مدعومًا من Ubuntu ونفضل تمكين الميزات عبر أوامر واحدة. إنه في الأساس Kubernetes نقي تحت الغطاء، وهو ما يجد البعض أسهل في التوسع. يمكن للملحقات (مثل microk8s enable ingress dns storage metallb) أن يمنحنا “سحابة صغيرة” كاملة الوظائف في دقائق. كما أن MicroK8s يتعامل مع التحديثات بسلاسة عبر Snaps، وهو ما يمكن أن يكون مفيدًا للحفاظ على تحديث العقد دون تدخل يدوي (يمكننا إيقافه أو التحكم في القناة لتجنب المفاجآت). إذا كنا نستخدم Ubuntu على جميع العقد (وهو الحال لدينا) ولا نمانع من استخدام Snaps، فإن MicroK8s هو خيار ممتاز لعقد منخفضة الصيانة.

    بكلمات بسيطة: لا يمكننا أن نخطئ في اختيار K3s أو MicroK8s في هذا السيناريو. كلاهما سيمنحنا Kubernetes سهل الاستخدام وصديق لبيئة homelab مع الميزات التي نحتاجها. يبلغ العديد من المستخدمين عن تجارب إيجابية مع كلاهما في إعدادات المنزلية بـ 2-3 عقد. قد يكون MicroK8s لديه ميزة طفيفة في سهولة الاستخدام (بسبب الملحقات والتكامل)، بينما قد يكون K3s لديه ميزة طفيفة في التشغيل الخفيف والوضوح تحت الغطاء.

  • متى نختار Minikube: إذا كنا نعمل فقط على جهاز واحد أو نريد تجميع تطويري مؤقت، فإن Minikube رائع لذلك. إنه أسهل طريقة لتشغيل Kubernetes على جهاز كمبيوتر أو عقد واحد للاختبار. ومع ذلك، لعقد دائم بـ 3 عقد، Minikube ليس الأداة المناسبة – لن يدمج تلك 3 عقد في تجميع واحد. سننتهي بتحقيق استفادة قليلة من معداتنا أو إدارة 3 تجميعات منفصلة، وهو ما لا نريده. إذن، في هذا homelab مع عقد متعددة، Minikube ليس موصى به كحل أساسي. قد نستخدم Minikube لا تزال على جهازنا الشخصي لتجربة الأشياء قبل نشرها في تجميع homelab، ولكن بالنسبة للتجميع نفسه، نستخدم شيئًا مثل K3s/MicroK8s.

  • متى نختار Kubeadm: إذا كان هدفنا هو تعلم تفاصيل Kubernetes أو الحصول على تحكم كامل وتكوين “مثيل الإنتاج”، فإن kubeadm هو تجربة جيدة. سيجبرنا ذلك على فهم كيفية تثبيت CNI والتخزين، وسنقوم ببناء التجميع قطعة تلو الأخرى. ومع ذلك، من حيث سهولة الاستخدام، فإن kubeadm هو الأكثر تدخلًا يدويًا. كل ميزة نحتاجها (مثل التخزين أو LB) يجب أن نكوّنها. في تجميع homelab موجه للتعلم، قد يكون هذا ميزة (تعليمية)؛ أما في تجميع مجرد أن يعمل، فهو عيب. كما أن الصيانة ستكون أكثر تعقيدًا (خاصة أثناء التحديثات). ما لم نكن نريد تجربة Kubernetes النقي لتعلم أو احتياجات مخصصة معينة، فإن استخدام K3s أو MicroK8s سيوفر لنا وقتًا وجهدًا كبيرين في بيئة homelab. مع ذلك، يفضل بعض المستخدمين الخبراء kubeadm حتى في المنزل لتجنب أي ميزات مخصصة للطرف الثالث وتحقيق التحكم الكامل في كل شيء. إنها بالفعل تعتمد على كمية الجهد التي نريد إنفاقها. بالنسبة لمعظم الناس، kubeadm هو مبالغة لعقد صغيرة حيث لا تهم توفرية عالية.

  • خيارات أخرى: هناك عدة نسخ خفيفة من Kubernetes أخرى، مثل k0s (من Mirantis) والأدوات مثل kind (Kubernetes في Docker). من أجل التكتم:

    • k0s هو توزيع Kubernetes بملف واحد آخر، يشبه K3s/MicroK8s من حيث الأهداف، ويتركز على المرونة والمساحة الصغيرة. إنه جديد نسبيًا لكنه يحظى بشعبية في مجتمع homelab. يمكنه أيضًا العمل بسهولة على 3 عقد لدينا. لا يملك حاليًا قاعدة مستخدمين كبيرة مثل K3s/MicroK8s، لكنه خيار يستحق الانتباه (خاصة إذا أحببت فكرة Kubernetes المفتوحة والمخصصة والصغيرة – تقارير حتى تظهر أن k0s يستخدم موارد أقل في حالة عدم الاستخدام مقارنة بـ K3s/MicroK8s في إعدادات مماثلة).
    • kind هو بشكل أساسي لاختبار تجميعات Kubernetes في حاويات Docker (غالبًا ما يُستخدم في خطوط إنتاج CI). إنه ليس شيئًا نستخدمه كتجميع دائم في homelab – إنه أكثر مناسبة لعقد مؤقتة سريعة على جهاز واحد (مثيل لهدف Minikube).
    • Rancher Kubernetes Engine (RKE) أو K3d أو غيرها أيضًا موجودة، لكنها موجهة إما لوحدات مخصصة (k3d يشغل تجميع K3s في Docker) أو سيناريوهات نشر أكثر تعقيدًا. في homelab، K3s و MicroK8s أصبحا نوعًا من الحلول السهلة المقبولة.

الخاتمة: لبيئة homelab بـ 3 عقد جيدة، MicroK8s أو K3s هما الخياران الموصى بهما للحصول على تجميع Kubernetes وظيفي مع أقل المتاعب. سيسمح لنا ذلك باستخدام جميع عقدنا في تجميع واحد، ويوفر دعمًا مدمجًا للوحدات المستمرة والخدمات الموزعة، وهو بالضبط ما طلبناه. إذا أردنا حلًا أكثر سهولة وتكاملًا مع Ubuntu، فاختر MicroK8s. إذا أردنا حلًا خفيف جدًا ومثبتًا ومدعومًا من Rancher، فاختر K3s. سنحصل على تجميع يعمل في دقائق إما منهما. بمجرد تشغيله، يمكننا نشر لوحة تحكم Kubernetes أو أدوات أخرى لإدارته، وبدء استضافة تطبيقاتنا مع تخزين مستمر وعرض سهل للخدمات. استمتع برحلتك في Kubernetes في homelab!

صفحات توزيعات Kubernetes

روابط مفيدة أخرى