kubeadm مقابل k3s: اختيار توزيع Kubernetes في 2026

مقال مرتبط · هذا الدليل جزء من سلسلة Kubernetes منزلي على Proxmox VE. الدليل السابق: توفير VMs Talos Linux. الدليل التالي: Cilium CNI eBPF.

قبل تثبيت Kubernetes على الست VMs المُنشَأة في الدليل السابق، قرار تقني واحد يُهَيكِل باقي المسار: اختيار توزيع Kubernetes. خياران يسودان الاستعمال المنزلي في مايو 2026: kubeadm، الأداة الرسمية لمشروع Kubernetes، الذي يُنتج عنقودًا « قياسيًّا » مطابقًا لما تجد في المؤسّسات؛ وk3s، التوزيع المُختَزَل الذي تقوده SUSE، المُحَزَّم في binary أقلّ من 100 ميغا. يُفَكِّك هذا الدليل التسويات التقنية بين الاثنين ويُثبّت كلًّا منهما على Talos لمقارنة النتيجة على نفس العتاد.

الخطوة 1 — فهم ما يفعله kubeadm فعلًا

kubeadm هي أداة bootstrap لـ Kubernetes يصونها المشروع upstream. مهمّتها تحويل Linux عاري إلى عقدة Kubernetes مطابقة لمواصفات المشروع. لا يُقدّم CNI، ولا تخزينًا، ولا Ingress، ولا metrics-server: هذه الخيارات تُترك للمُشغّل. هذا تمامًا ما يجعله الأداة المرجعية لفهم Kubernetes في العمق.

# على عقدة Ubuntu 24.04 (خارج Talos)، تثبيت kubeadm 1.35
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gpg
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /" | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
  --control-plane-endpoint=192.168.1.60:6443 --upload-certs

خرج kubeadm init يعرض أوامر kubeadm join الواجب تنفيذها على باقي العقد، صالحة 24 ساعة. عند هذه المرحلة، العنقود قائم لكنّه ناقص: pods CoreDNS في Pending لأنّه لم يُثَبَّت CNI بعد. هذا مقصود: kubeadm لا يقرّر عنك.

على Talos، kubeadm غير مرئيّ لأنّ Talos يقوده داخليًّا عند الإقلاع، لكنّ النتيجة مطابقة: عنقود Kubernetes upstream كامل ومطابق للمواصفات.

الخطوة 2 — فهم ما يفعله k3s بدلًا منه

k3s يتّخذ المقاربة المعاكسة. هو binary واحد أقلّ من 100 ميغا يحوي control plane (kube-apiserver، kube-controller-manager، kube-scheduler)، kubelet، containerd، Flannel CNI، Traefik Ingress controller، ServiceLB، local-path-provisioner، وmetrics-server. يستبدل etcd افتراضيًّا بـ SQLite، ممّا يُبسّط الانطلاق جذريًّا لكنّه يقيّد الإتاحة العالية. النسخة المُختبَرة هنا هي v1.35.4+k3s1، الصادرة في أبريل 2026.

# أوّل خادم k3s مع etcd مُضَمَّن (HA ممكن)
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.35.4+k3s1 sh -s - server \
  --cluster-init --token=monsecretpartage --tls-san=192.168.1.60

# خوادم إضافية تنضمّ إلى العنقود
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.35.4+k3s1 sh -s - server \
  --server=https://192.168.1.61:6443 --token=monsecretpartage

# استرداد kubeconfig
sudo cat /etc/rancher/k3s/k3s.yaml
# استبدل 127.0.0.1 بالـ IP للخادم في النسخة المحلّية

في أقلّ من دقيقة، العنقود قابل للاستعمال من البداية إلى النهاية: kubectl get nodes يُرجع عقدًا Ready، kubectl get svc -A يُدرج Traefik وServiceLB حاضرَين، kubectl get sc يعرض local-path كصنف تخزين افتراضي. هذا وعد k3s: انطلاق سريع واختبار فوري.

الخطوة 3 — مقارنة بصمة الذاكرة وزمن الإقلاع

على العتاد المنزلي، استهلاك ذاكرة مكوّنات النظام معيار عملي. القياس الآتي أُعيد في مايو 2026 على VMs متطابقتين (4 vCPU، 4 جيغا RAM، Talos 1.13 أو Ubuntu 24.04، حِمل عمل فارغ).

لعقدة بـ 4 جيغا RAM، k3s يترك 3.4 جيغا حرّة للـ pods، kubeadm يترك حوالي 2.5 جيغا. على Raspberry Pi 5 بـ 8 جيغا، يصير الفرق هامشيًّا. على mini-PC بـ 32 جيغا مخصَّص للعنقود، لا يُلاحَظ في اليومي.

الخطوة 4 — مقارنة الإتاحة العالية

يستعمل kubeadm etcd أصليًّا ويدعم بسهولة quorum بـ 3 أو 5 أعضاء. هذا ما يُتوقَّع من عنقود مؤسّسة. فقدان control plane واحد لا يُوقِف العنقود؛ فقدان اثنين من ثلاثة نعم، لأنّ etcd يفقد الـ quorum.

k3s يُتيح ثلاثة أنماط تخزين للحالة: SQLite مُضَمَّن (افتراضي، لا HA)، etcd مُضَمَّن (مع --cluster-init، HA حتى 5 عقد، وهو ما هَيَّأناه أعلاه)، أو قاعدة خارجية MySQL/Postgres/etcd خارجي. لاستعمال منزلي جدّي، وضع etcd المُضَمَّن لـ k3s خيار ممتاز: تحتفظ ببساطة التثبيت مع الحصول على HA.

# تحقّق من أنّ etcd المُضَمَّن في k3s سليم
sudo k3s etcd-snapshot list

# قارن مع etcd kubeadm
sudo ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint status --write-out=table

الخرجان يُؤكِّدان quorum بـ 3 أعضاء يعمل. عمليًّا، التوزيعان يصمدان أمام فقدان عقدة control plane دون انقطاع API server، وهذا الهدف الرئيسي في homelab جدّي.

الخطوة 5 — اختيار حسب نمط الاستعمال

ثلاثة أنماط نموذجية تبرز من الخبرة المتراكمة لمجتمع homelab:

نمط « التعلّم والتجريب »: k3s يربح. يُقلِع سريعًا، يصمد على VM متواضعة، يُسلِّم كلّ شيء في حزمة. مثالي للتكرار على المنفستات، اختبار مُشَغِّل Helm، فهم المفاهيم. المطوّرون الذين يريدون عنقودًا قابلًا للرمي يختارون k3s دون تردّد.

نمط « منصّة مستقرّة تشبه الإنتاج »: kubeadm يربح. المطابقة مع upstream كاملة، السلوكيات مطابقة لما تجد على EKS أو AKS أو GKE، منظومة الأدوات (kubectl plugins، مشغِّلات، دروس) مُختبَرة ضدّ kubeadm. على Talos، توليفة Talos+kubeadm هي اليوم المرجع لمن يريد عنقود homelab قابلًا للصيانة سنوات.

نمط « عنقود ARM أو شديد التقييد »: k3s يربح على Raspberry Pi 5، Banana Pi، عقد بـ 2 جيغا RAM. توجد حتى نسخة k3s-armhf لـ Pi 32 بت القديمة. kubeadm يعمل أيضًا لكنّ overhead يثقل أكثر نسبيًّا على هذه الآلات.

لمسار هذه السلسلة، نُوصي بـ Talos+kubeadm لأنّ ما يلي (Cilium، Rook-Ceph، Argo CD، Velero) مطابق تمامًا لإعدادات المؤسّسات. لكن كلّ ما يلي قابل للتنفيذ على k3s ببعض التعديلات (تعطيل Flannel وTraefik المدمجَين عبر --flannel-backend=none --disable=traefik قبل تثبيت Cilium).

الخطوة 6 — التحقّق من النتيجة على العنقودين

أيًّا كان الخيار، التحقّق النهائي نفسه: عنقود Ready، pods نظام تعمل، DNS يعمل، API يستجيب من محطّة العمل.

kubectl get nodes -o wide
kubectl get pods -A
kubectl run test --image=busybox --rm -it --restart=Never -- nslookup kubernetes.default
# يجب الحلّ إلى عنوان 10.96.0.x

رؤية pod test يُنشأ، يحلّ خدمة kubernetes.default ويُحذف بعد الأمر يُؤكِّد أنّ control plane وkubelet وDNS الداخلي تعمل معًا. هو معيار صلاحية عنقود Kubernetes الأدنى.

أخطاء شائعة وحلولها

لاستكمال المسار

توزيع Kubernetes اختير. أيًّا كان القرار (kubeadm على Talos كما في أمثلتنا، أو k3s للخفّة)، الخطوة التالية تثبيت CNI: دون شبكة pods، لا يستطيع العنقود فعل الكثير. دليل نشر Cilium CNI مع eBPF على Kubernetes يُفَصِّل التثبيت وتفعيل Hubble للمراقبة الشبكية. للنظرة العامّة، عُد إلى الدليل الرئيسي.

مصادر وتوثيق رسمي

• توثيق kubeadm: kubernetes.io/docs/setup
• توثيق k3s: docs.k3s.io
• ملاحظات إصدارات k3s v1.35.X: docs.k3s.io/release-notes
• إجراء ترقية kubeadm: kubernetes.io/docs/tasks/administer-cluster
• مقارنة رسمية لتوزيعات Kubernetes (CNCF): cncf.io

الخطوة 7 — مقارنة الأمن الافتراضي

وضعية الأمن الافتراضية تختلف محسوسًا بين التوزيعَين، ونادرًا ما يُطرَح هذا الجانب. ينتج kubeadm عنقودًا « عاريًا »: Pod Security Admission متاح لكن غير مُهَيَّأ، RBAC يعمل لكن حسابات system:masters غير مُقَيَّدة، API server يكشف مقاييسه دون توثيق. يجب التشديد بنشاط بعد التثبيت. هذا متّسق مع فلسفة kubeadm: اتّخاذ الخيارات على بيّنة.

k3s ذو سلوك أكثر إصرارًا. ملف الأمن الافتراضي يُفَعِّل تلقائيًّا تدوير شهادات kubelet، يُعَطِّل المنافذ غير المشفَّرة، ويمكن تفعيل ملف cis-1.6 عبر علم (--profile=cis-1.6) يُطبّق جزءًا من توصيات CIS Kubernetes. المقابل أقلّ رؤية على ما يحدث: k3s « يُخفي » خيارات يراها مُشَغِّل kubeadm صريحة.

# k3s لا يملك علم --profile=cis (خلافًا لـ RKE2). اتّبع hardening guide الرسمي
# docs.k3s.io/security/hardening-guide لتطبيق ضوابط CIS Kubernetes Benchmark v1.11 (أو أحدث) يدويًّا.

# تحقّق على kubeadm من أنّ Pod Security Admission نشط (PodSecurity GA منذ K8s 1.25، لا feature-gate لتفعيله)
kubectl label namespace demo \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

على العنقودين، سنُطبّق لاحقًا OPA Gatekeeper أو Kyverno للسياسات التجارية. لكنّ نقطة الانطلاق ليست متكافئة: k3s أكثر تشدّدًا افتراضيًّا، kubeadm يُعطي مزيد تحكّم.

الخطوة 8 — مقارنة دورة الحياة والتحديثات

الصيانة عبر الوقت كلفة كثيرًا ما يُستهان بها عند الانطلاق. التوزيعان يتبنّيان وتيرة Kubernetes (minor كلّ أربعة أشهر) لكن بأدوات مختلفة.

على kubeadm، إجراء الترقية موثَّق لكنّه يتطلّب انتباهًا مستدامًا: نسخ etcd احتياطيًّا، ترقية حزم kubeadm، تنفيذ kubeadm upgrade plan ثم kubeadm upgrade apply على أوّل control plane، ثم التكرار على الآخرين، ثم على workers في وضع drain/upgrade/uncordon. احسب ساعة إلى ساعتين لكلّ minor على عنقود بست عقد، دون حادث.

# ترقية kubeadm 1.35.4 ← 1.36.0 على أوّل control plane
sudo apt update
sudo apt-mark unhold kubeadm
sudo apt install -y kubeadm=1.36.0-00
sudo apt-mark hold kubeadm

sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.36.0

# ثم kubelet وkubectl
sudo apt-mark unhold kubelet kubectl
sudo apt install -y kubelet=1.36.0-00 kubectl=1.36.0-00
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reexec
sudo systemctl restart kubelet

على k3s، الترقية أبسط جذريًّا: تُعيد تشغيل سكربت التثبيت بالنسخة الجديدة. k3s يُدير هجرة etcd، تدوير المنفستات المدمجة، وإعادة تشغيل الخدمة.

# ترقية k3s إلى v1.36.0+k3s1
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.36.0+k3s1 sh -

# تحقّق من الإصدار بعد الترقية
sudo k3s --version
kubectl get nodes -o wide

على Talos+kubeadm، الترقية مختلفة أيضًا: talosctl upgrade-k8s يُنسّق كلّ شيء، من ترقية control plane إلى workers، مع احترام drain وhealth checks. هذا على الأرجح أكثر التسويات راحة بين الثلاثة في مايو 2026.

الخطوة 9 — اختبار الصمود لفقدان عقدة

قبل إعلان جاهزية العنقود، نتحقّق أنّه يصمد لحدث غير مُؤاتٍ شائع: فقدان عقدة control plane. الاختبار يقوم بإيقاف عقدة عنيفًا ومراقبة بقاء الـ API متاحًا.

# على Proxmox، أوقف control plane الثاني عنيفًا
qm stop 1002

# من محطّة العمل، تحقّق أنّ kubectl لا يزال يستجيب
kubectl get nodes
# العقدة المُوقَفة تظهر NotReady، الباقي Ready
# الـ API يستجيب لأنّ quorum etcd محفوظ (2 من 3)

kubectl get pods -A
# لا pod نظام متأثّر

# أعد تشغيل العقدة
qm start 1002
sleep 60
kubectl get nodes
# العقدة تعود للانضمام في دقائق

رؤية أوامر kubectl تستجيب رغم إيقاف الـ VM يُؤكِّد عمل الإتاحة العالية. إن صار الـ API غير قابل للوصول حين تسقط عقدة، فـ etcd ليس في HA — نمطيًّا k3s مُطلَق دون --cluster-init، أو kubeadm بـ control plane واحد. أعد إعداد HA قبل المضيّ قُدُمًا.

أسئلة تتكرّر

أيمكن هجرة عنقود k3s إلى kubeadm دون إعادة بناء كلّ شيء؟ لا مباشرة. التوزيعان يخزّنان حالتهما في etcd باصطلاحات أسماء وCRDs مختلفة. هجرة في المكان غير مدعومة. الممارسة هي إعادة بناء العنقود الهدف وهجرة الأحمال عبر Velero (نسخ احتياطي للمصدر، استعادة على الهدف).

هل يلزم فعلًا ثلاث control plane على k3s أم نبقى على واحد؟ للتعلّم، واحد يكفي. لاستضافة خدمات نريد تشغيلها أثناء الأعطال أو التحديثات، ثلاثة هو الحدّ الأدنى. عقدة control plane تستهلك 512 ميغا RAM في k3s: ضرب 3 يبقى معقولًا حتى على mini-PC بـ 32 جيغا.

k3s في الإنتاج، جدّي أم مرتجل؟ SUSE تدعم k3s تجاريًّا، والعديد من نشرات edge في الإنتاج تدور على k3s (مثلًا بنية محطّات شحن، الأتمتة الصناعية). لـ homelab، خيار ممتاز لن تُلقي عليه نضوج المشروع ظلال شكّ.

أيمكن أن يختلف الخيار حسب العنقود؟ طبعًا. كثير من مُشَغِّلي المنازل لديهم k3s لصندوق الرمل وTalos+kubeadm للخدمات عالية الإتاحة. العنقودان يتقاسمان غالبًا Argo CD واحدًا يدفع المنفستات المناسبة لكلّ منهما. هو حتى تمرين ممتاز لفهم أنماط multi-cluster.

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

• Bun مقابل Node.js: قياسات أداء حقيقية 2026 (منهجية قابلة للتكرار)
• Docker مقابل Podman: مقارنة نزيهة 2026
• CKAD Certified Kubernetes Application Developer — دليل كامل 2026
• تركيب عنقود Kubernetes 1.35 CKAD بـ kind على VPS 2026