تشغيل Kubernetes في المنزل، على عتاد تملكه فعلًا، يُغيّر طريقة تعلّمك وتشغيلك لهذه المنصّة. لم تعد تستأجر عقدًا مُدارة من مزوّد سحابي: تُثبّت الـ hypervisor، تُجزّئ الآلات الافتراضية، تُهَيِّئ control plane، تختار CNI، تركّب تخزينًا موزَّعًا، تُسلّح التسليم المستمرّ. كلّ طبقة تصير صريحة. وكلّ طبقة تكشف قرارًا كنت تجهله حين كانت خدمة مُدارة تتّخذه نيابة عنك.
Proxmox VE 9.1 اليوم أحد أفضل الخيارات لهذه القاعدة. هو hypervisor حرّ مبنيّ على Debian 13 « Trixie »، بنواة Linux 6.17.2، يجمع افتراضية KVM، حاويات LXC، ZFS أصلي، Ceph مدمج، وواجهة ويب متكاملة. يقبل عتادًا اعتياديًّا — mini-PC من نوع Intel N150، أو Dell OptiPlex مستعمل، أو NUC، أو خادم Supermicro صامت — ويُوفّر ما يكفي من ميزات المؤسّسة ليعكس عنقود منزلي ما تجده فعلًا في الإنتاج.
يضع هذا الدليل النظرة العامّة: لماذا هذه المعمارية منطقية، ما القرارات الهيكلية الواجب اتّخاذها قبل أوّل تثبيت، كيف تتسلسل الخطوات الثماني للمسار، وأين يأخذ كلّ دليل تفصيلي الراية. الخيارات التقنية المرجعية مؤرّخة مايو 2026 وتستند إلى الإصدارات المستقرّة الحالية: Proxmox VE 9.1، Talos Linux 1.13.0 (يضمّ Kubernetes 1.36.0)، kubeadm على Kubernetes 1.35، k3s v1.35.4+k3s1، Cilium 1.19.3، Rook 1.19.5، Argo CD 3.4، kube-prometheus-stack 84.5.0، وVelero 1.18.
لماذا يستحقّ Kubernetes المنزلي وقتك
الحجّة المالية تأتي أوّلًا لكنّها ليست الأهمّ. عنقود مُدار لدى مزوّد سحابي، حتى من الفئة الدنيا، يكلّف عدّة عشرات من الدولارات شهريًّا بمجرّد إضافة أقراص مستمرّة وموزِّع تحميل. مضروبًا في سنة، تتجاوز بسهولة ثمن mini-PC مستعمل بـ 200 دولار. في المنزل، كهرباء عقدة صامتة بـ 15 وات تدور حول دولارَين إلى ثلاثة شهريًّا. الميزان يميل سريعًا نحو العتاد المملوك حالما تتعلّم أو تُجرّب أو تستضيف خدمات شخصية.
الحجّة التعليمية أثقل. على عنقود مُدار، الـ control plane غير مرئيّ. الشهادات مُدارة. الشبكة تعمل. التخزين موصول. حين ينكسر شيء في الإنتاج لا تعرف من أين تنظر لأنّك لم ترَ القطع تعمل منفصلة. بنية Proxmox+Kubernetes منزلية تُجبرك على عبور الطبقات: تُهَيِّئ بنفسك IOMMU وbridge شبكة الـ hypervisor، تُولّد سرّ bootstrap لعقد Talos، تُثبّت Cilium ثم تُلاحظ سياسات eBPF في النواة، تنشر Rook ثم تُراقب الـ OSD تتشكّل على Ceph. تصير المعرفة تشغيلية.
الحجّة السيادية تأتي ثالثة. للمستقلّ أو لمنشأة صغيرة، استضافة Gitea وVaultwarden وNextcloud وخادم بريد وbastion VPN أو أدوات داخلية على بنية تحتية خاصّة يُجنّب توزيع بيانات حسّاسة على عدّة مزوّدين. يجلب Kubernetes ابتدائية النشر القابل للتكرار: تموت عقدة، تستبدلها، تعود الـ pods. هي المرونة المنتظرة من سحابة، دون تأجير سحابة.
المعمارية المستهدفة في لمحة
المعمارية المستهدفة في هذا المسار بسيطة وقابلة للتكرار. خادم فيزيائي واحد يُشغّل Proxmox VE 9.1. على هذا الـ hypervisor نُجزّئ ست آلات افتراضية: ثلاث تُكوّن control plane Kubernetes (إتاحة عالية لـ etcd، scheduler، وAPI server)، ثلاث تُكوّن workers تُنفَّذ عليها الـ pods. كلّ VM تستهلك 2 إلى 4 vCPU و4 إلى 8 جيغا RAM. الأقراص تُخزَّن على pool ZFS محلّي للـ hypervisor، ممّا يجلب snapshots وضغطًا « مجّانًا ».
فوق ذلك، نُثبّت Talos Linux 1.13 — نظام تشغيل غير قابل للتغيير ومُختزَل مُصمَّم لـ Kubernetes فقط — أو Ubuntu 24.04 LTS إن فضّلت نظامًا مألوفًا تُديره عبر kubeadm. على هذه القاعدة، يُوفّر Kubernetes 1.35 أو 1.36 الـ APIs. يأخذ Cilium 1.19 مكان الـ CNI ويجلب سياسات شبكة eBPF عالية الأداء. ينشر Rook 1.19 عنقود Ceph يعمل داخل Kubernetes نفسه ويعرض volumes مستمرّة، تخزين كائنات متوافق مع S3، ونظام ملفّات مشترك. Argo CD 3.4 يُزامن المنفستات من مستودع Git. kube-prometheus-stack 84.5.0 يُوفّر Prometheus وGrafana وAlertmanager. Velero 1.18 ينسخ المجموع احتياطيًّا إلى bucket S3 بعيد.
إذا توفّر لك عدّة آلات فيزيائية، ترتفع المعمارية مستوى: ثلاث عقد Proxmox في عنقود، تستضيف كلّ منها جزءًا من control plane وworkers، ممّا يجلب الإتاحة العالية المادية. يبقى المسار الموصوف هنا صالحًا، يُكتفى بتكرار تثبيت Proxmox على كلّ مضيف قبل إعلان عنقود الـ hypervisors.
اختيار العتاد دون إفراط في الإنفاق
المعيار الحاسم هو كمّية RAM. يستهلك Kubernetes سريعًا. الـ control plane وحده يطلب 2 جيغا كحدّ أدنى لكلّ عقدة على Talos، و4 جيغا على Ubuntu+kubeadm. عنقود وظيفي بستّ VM وRook وPrometheus وثلاث أو أربع أحمال عمل يصمد بأمانة على 32 جيغا RAM فيزيائية، يصير مريحًا عند 64 جيغا، ويصير mockup حقيقيًّا عند 128 جيغا.
لميزانية محدودة، mini-PC جديد بمعالج Intel N150 أو N200 مع 32 جيغا DDR5 وSSD NVMe بسعة تيرابايت يكلّف نحو 380 دولارًا في مايو 2026 ويستهلك أقلّ من 15 وات في حمل متوسّط. هذا يكفي لعنقود تعلّم. للانتقال إلى 64 جيغا، سوق المستعمل يعرض Dell OptiPlex 7080 أو HP EliteDesk 800 G9 ممتازين بين 220 و440 دولارًا، قابلين عادةً للتوسيع إلى 64 أو 128 جيغا. لمن يريد عتاد خادم صامتًا، Supermicro X11 أو X12 مستعمل في صندوق Fractal Define يقبل 256 جيغا ECC، شبكتي SFP+، وعدّة أقراص لـ Ceph: تركّب آنذاك منصّة دائمة فعليّة.
التخزين يكاد يكون بنفس الأهمّية. لـ Ceph موزَّع مع Rook، خطّط لـ 3 أقراص مخصَّصة كحدّ أدنى، نمطيًّا NVMe أو SATA SSD. خلط SSD لنظام Proxmox وتخزين الـ VMs مع 2 أو 3 أقراص دوّارة لـ Ceph ممكن لكنّه يرفع زمن الاستجابة. الشبكة، من جهتها، تستطيع البدء بـ 1 Gbps: الانتقال إلى 2.5 أو 10 Gbps يصير وجيهًا حين يرتفع حِمل Ceph.
المسار في ثمانية دلائل
بناء بيئة Kubernetes منزلية متماسكة لا يتّسع في مقال واحد. كلّ لبنة كبرى تستحقّ دليلًا خطوة بخطوة مخصَّصًا، تتبعه بالترتيب أو تقرأه منفصلًا حين تبحث في نقطة محدّدة. هنا التسلسل الموصى به:
- تثبيت Proxmox VE 9.1 على خادم منزلي — من تنزيل ISO إلى ضبط ZFS، مرورًا بشبكة bridged ووصول ويب مُؤَمَّن.
- توفير VMs Talos Linux لـ Kubernetes — إنشاء ست آلات غير قابلة للتغيير جاهزة لاستقبال Talos، بأقراص وvCPU وملفّات CPU مناسبة.
- kubeadm مقابل k3s — فهم الفروق الحقيقية بين توزيع المرجع والتوزيع المُختَزَل لاتّخاذ القرار دون ندم.
- نشر Cilium CNI مع eBPF على Kubernetes — تثبيت الشبكة، تفعيل Hubble للمراقبة، كتابة أولى سياسات أمن الشبكة.
- تخزين مستمرّ مع Rook-Ceph على Kubernetes — تحضير الأقراص، نشر مُشغِّل Rook، إنشاء pools كتلية وbucket S3 داخلي.
- Bootstrap GitOps مع Argo CD على Kubernetes — تثبيت Argo CD، هيكلة مستودع Git، إنشاء أوّل Application تتزامن وحدها.
- مراقبة Kubernetes مع kube-prometheus-stack — نشر Prometheus، Grafana، Alertmanager وكشف لوحات التحكّم عبر Ingress.
- نسخ احتياطي لـ Kubernetes مع Velero — نسخ namespaces وvolumes إلى تخزين كائنات بعيد، اختبار استعادة كاملة.
اتّباع الترتيب يُقلّل الإحباطات: كلّ خطوة تُثبّت الشرط الأوّلي للتالية. القفز مباشرة إلى Argo CD دون CNI يعمل يُعطي أخطاء غامضة. تشغيل Velero دون تخزين كائنات يضيع ساعة. السلسلة مُصمَّمة لكي يكون العنقود قابلًا للاستعمال في كلّ منعطف.
المفاهيم الواجب إتقانها قبل وضع أوّل عقدة
فهم Kubernetes على مستوى المستخدم — نشر ملفّ YAML، قراءة حالة pod — ليس نفس تمرين تشغيل عنقود بنفسك. يجب معرفة ما يدور تحته لتشخيص الأعطال. خمسة مفاهيم تخدم بوصلة طوال المسار.
الـ control plane هو المُنسِّق. يتكوّن من API server (نقطة دخول HTTPS وحيدة)، etcd (قاعدة مفتاح-قيمة تُخزّن الحالة المرغوبة للعنقود)، scheduler (يختار على أيّ عقدة يُوضع كلّ pod)، وcontroller manager (يدور ليُقرّب الحالة الفعلية من المرغوبة). في الإتاحة العالية ننشر ثلاث نسخ منه. هذه الطبقة يجب نسخها احتياطيًّا قطعًا، لأنّ فقدان etcd يعني فقدان إعلان العنقود كلّه.
الـ kubelet هو الوكيل المثبَّت على كلّ worker. يتحدّث مع API server، يسأل عن الـ pods التي عليه تشغيلها، يتكلّم مع runtime الحاويات (containerd في كلّ التوزيعات الحديثة)، ويُبلّغ صحّة العقدة. حين يكون pod في Pending دون سبب ظاهر، فالسبب تقريبًا دائمًا إمّا مشكل API server، أو kubelet لم يستطع الإقلاع، أو StorageClass سيّئة.
الـ CNI (Container Network Interface) هو الطبقة التي تُعطي IP لكلّ pod وتوجّه الحزم بين العقد. Cilium، الذي سنُثبّته، يستعمل eBPF لإنجاز هذا العمل مباشرة في النواة Linux: سريع، قابل للمراقبة، قابل للبرمجة. اختيار CNI هيكلي لأنّه لا يُغيَّر أثناء المسار دون ألم.
الـ CSI (Container Storage Interface) هو المكافئ للتخزين. مُشغِّلات CSI تكشف التخزين لـ Kubernetes في شكل StorageClass وPersistentVolumeClaim. سيُوفّر Rook-Ceph مُشغِّل CSI يُنشئ عند الطلب volumes RBD (كتلية) أو CephFS (ملفّات مشتركة). دون CSI، لا يمكن تشغيل سوى أحمال عابرة.
الـ Ingress أخيرًا هو ما يكشف خدمات HTTPS للعالم الخارجي. مُشغّل Ingress (غالبًا Nginx أو Traefik أو ingress-nginx) يُترجم القواعد التصريحية إلى إعداد reverse proxy. منه تستجيب تطبيقاتك على https://gitea.exemple.lan بدل 10.96.42.17:3000.
ثلاثة قرارات هيكلية ينبغي حسمها مبكّرًا
قبل كتابة أيّ ملفّ YAML، ثلاثة خيارات تُحدّد تجربتك. مراجعتها في منتصف الطريق مكلفة. الأفضل حسمها على بيّنة.
نظام تشغيل العقد: Talos أم Ubuntu؟ Talos Linux 1.13 غير قابل للتغيير، بلا shell، بلا حزم تقليدية، يُهَيَّأ كلّيًّا بملفّ YAML تصريحي ويُدار عن بُعد بأداة talosctl. هو الخيار حين تقبل ألّا تفتح جلسة SSH على عقدة أبدًا. الجائزة: مساحة هجوم صغيرة جدًّا، تحديثات ذرّية، rollback بأمر واحد، سلوك قابل للتكرار. Ubuntu 24.04 LTS مع kubeadm هو الخيار المعاكس: تحتفظ بـ Linux مألوف، تُثبّت الحزم بنفسك، تشتغل عبر SSH. أكثر تعليمًا في البداية وأكثر تسامحًا مع التعديلات اليدوية، لكنّك تحمل أمن النظام على كتفيك.
توزيع Kubernetes: kubeadm أم k3s؟ kubeadm هو أداة المرجع لمشروع Kubernetes، تُستعمل على Talos كما على Ubuntu، تُنتج عنقودًا « قياسيًّا ». k3s توزيع مُختَزَل تقوده SUSE، مُحَزَّم في binary واحد، يُقلِع في أقلّ من دقيقة ويتّسع في 512 ميغا RAM لكلّ عقدة. يُضمِّن k3s افتراضيًّا Flannel كـ CNI، Traefik كـ Ingress، وSQLite كتخزين etcd قابل للاستبدال. الدليل المقارن يُفصِّل التسويات؛ كقاعدة عامّة، k3s يربح للتعلّم السريع أو العقد شديدة التقييد، kubeadm يربح للبقاء قريبًا ممّا تجده في إنتاج المؤسّسات.
التخزين: ZFS محلّي على Proxmox أم Ceph موزَّع عبر Rook؟ لعقدة وحيدة، ZFS محلّي على Proxmox يكفي تمامًا ويُتيح snapshots فورية مفيدة جدًّا. لتحضير أحمال يجب أن تنجو من فقدان عقدة، Rook-Ceph يجلب نسخًا حقيقيًّا بثلاث نسخ بين الـ workers، تخزين كائنات متوافقًا مع S3، ونظام ملفّات مشترك. الكثير من الإعدادات المنزلية تجمع الاثنين: ZFS تحت الـ hypervisor لأقراص الـ VMs، Rook-Ceph في Kubernetes لـ volumes الأحمال المستمرّة.
أمن أساسي يجب تطبيقه من البداية
عنقود Kubernetes غير مُؤَمَّن مكشوف على الإنترنت يُختَرَق في ساعات قليلة، حتى في المنزل خلف موجّه عادي. الخطأ الكلاسيكي فتح المنفذ 6443 إلى الخارج للوصول إلى kubectl أثناء التنقّل: هذا فتح للـ API server على العالم بأسره. أربعة حواجز تُوضَع منذ أوّل تثبيت وتبقى حتى نهاية حياة العنقود.
أوّلًا، العزل الشبكي: يعيش العنقود على VLAN مخصَّص لشبكتك المنزلية، مفصول عن Wi-Fi العائلي. الوصول من الخارج يمرّ حصرًا عبر VPN (WireGuard على الموجّه أو Tailscale على كلّ عقدة). لا توجيه منافذ مباشر إلى العقد.
ثانيًا، تدوير الأسرار: Talos يُعيد توليد شهاداته الداخلية تلقائيًّا؛ على Ubuntu+kubeadm، خطّط kubeadm certs renew كلّ أحد عشر شهرًا. ملفّات kubeconfig admin المُوزَّعة على أجهزة محمولة يجب أن تكون قصيرة العمر (بضعة أيّام) وقابلة للإلغاء.
ثالثًا، سياسات القبول ترفض افتراضيًّا pods المُمتازة. نُفعِّل Pod Security Admission في وضع restricted على كلّ namespaces العمل، ونُضيف OPA Gatekeeper أو Kyverno للقواعد الخاصّة (منع الصور غير الموقَّعة، فرض resources.limits، رفض الخدمات المكشوفة عبر NodePort).
رابعًا، مراقبة الأمن: Falco يُراقب syscalls المريبة على مستوى النواة، Trivy يفحص الصور عند النشر. الدليل Falco runtime security وaudit Kubernetes يُفصِّل هذه الطبقة، التي تُثبَّت بعد أن يصير العنقود إنتاجيًّا.
أخطاء شائعة يصادفها الجميع
| العَرَض | السبب المعتاد | اتّجاه الحلّ |
|---|---|---|
| الـ pods تبقى في Pending إلى ما لا نهاية | لا عقدة تُرضي resources.requests، أو الـ CNI غير مثبَّت |
افحص kubectl describe pod ثم kubectl get nodes -o wide وkubectl get pods -n kube-system |
| DNS الداخلي لم يعد يحلّ شيئًا | CoreDNS في CrashLoopBackOff، غالبًا بسبب سياسة شبكة Cilium مفرطة في التقييد | افحص سجلّات CoreDNS وعطّل مؤقّتًا CiliumNetworkPolicy في namespace kube-system |
| volumes Rook تبقى Pending | أقراص غير مُحَضَّرة (توقيعات سابقة)، أو لا StorageClass افتراضي | افحص lsblk على workers وkubectl get sc |
| API server غير قابل للوصول بعد reboot | etcd فقد quorum، غالبًا لأنّك أعدت تشغيل عقدتَين من ثلاث في آن | أعد تشغيل العقد واحدة واحدة، افحص etcdctl endpoint status |
| الشهادات تنتهي وتحجب kubectl | عنقود لم يُصَن لأكثر من سنة | على kubeadm: kubeadm certs renew all ثم إعادة تشغيل kubelet |
| Ingress يُرجع 502 Bad Gateway عشوائيًّا | خدمة backend بلا readinessProbe، أو MTU eBPF غير محاذي |
أضف readinessProbe HTTP وافحص cilium config view | grep -i mtu |
أسئلة تتكرّر
هل Proxmox إلزامي، ألا يمكن تثبيت Kubernetes على bare-metal؟ ممكن تمامًا. طبقة الـ hypervisor مفيدة فقط لتجزئة خادم فيزيائي واحد إلى عدّة عقد منطقية، عمل snapshots سهلة، واختبار إعدادات سريعة. على bare-metal على ثلاث آلات فيزيائية منفصلة، تتخطّى Proxmox وتُثبّت Talos مباشرة على كلّ مضيف. باقي المسار يبقى مطابقًا.
أيّ توزيع Kubernetes يستهلك أقلّ RAM؟ k3s بلا منافس على هذا المعيار. عقدة k3s بحمل خفيف تتّسع في 512 ميغا RAM. للمقارنة، عقدة kubeadm نادرًا ما تُقلِع تحت 1 جيغا، وعقدة Talos+kubeadm حوالي 1.5 جيغا.
هل يلزم فعلًا ثلاث control plane، أم يكفي واحد في المنزل؟ control plane واحد يعمل تمامًا للتعلّم. فقدان هذه العقدة يُوقف العنقود لكن لا يُفقد البيانات. لاستضافة خدمات لا تريدها أن تسقط أثناء انقطاعات الكهرباء أو إعادة التشغيل، ثلاث control plane تجلب الإتاحة العالية لـ etcd. الكلفة في RAM معقولة: ثلاث مرّات 2 جيغا.
أيمكن تشغيل GPU في هذا العنقود؟ نعم، شريطة تمرير GPU إلى VM عبر PCI passthrough في Proxmox، ثم تثبيت NVIDIA device plugin Kubernetes في هذه الـ VM. مفيد لاستضافة نماذج استدلال محلّية أو ترميز فيديو. ضبط IOMMU في Proxmox يجب أن يُنجَز قبل إنشاء الـ VM.
بأيّ تواتر يجب التحديث؟ Kubernetes يُصدر minor كلّ أربعة أشهر. في المنزل، ترقية كلّ ستّة أشهر تكفي بكثير. Talos يجعل هذه الترقيات شبه غير مؤلمة بفضل إجراء upgrade الذرّي. على kubeadm، خطّط ساعة إلى ساعتين لكلّ ترقية.
هل الضجيج واستهلاك الكهرباء قابلان للإدارة في شقّة؟ مع mini-PC حديث في صندوق بلا مروحة أو بمروحة PWM، الضجيج أقلّ من 25 ديسيبل والاستهلاك يدور بين 12 و30 وات في الراحة. متوافق مع غرفة جلوس. خوادم rack الحقيقية ممنوعة لأسباب صوتية.
مصادر ومراجع رسمية
- توثيق Proxmox VE 9:
pve.proxmox.com/pve-docs - ملاحظات إصدار Proxmox VE 9.1:
proxmox.com - توثيق Talos Linux:
talos.dev/v1.13 - التوثيق الرسمي Kubernetes 1.35:
kubernetes.io/docs - k3s release notes:
docs.k3s.io - توثيق Cilium:
docs.cilium.io/v1.19 - توثيق Rook:
rook.io - توثيق Argo CD:
argo-cd.readthedocs.io - kube-prometheus-stack chart:
prometheus-communityعلى GitHub - توثيق Velero:
velero.io/docs
بعد أن يصير العنقود إنتاجيًّا، إلى أين نُكمِل
بلوغ نهاية المسار بثمانية دلائل يُعطي عنقودًا وظيفيًّا، مَنسوخًا احتياطيًّا، مُراقَبًا، يُنشَر من مستودع Git. هي نقطة وصول معقولة. لكنّها أيضًا نقطة انطلاق للذهاب أبعد، لأنّ القيمة الحقيقية لمنصّة تتجلّى فيما تنشره فوقها وفي الانضباط التشغيلي الذي تُطبّقه بمرور الأشهر.
الامتداد الأوّل الطبيعي يخصّ الأمن المُشَدَّد. بمجرّد وضع Cilium، نُفعِّل Cilium Network Policies الافتراضية deny لكلّ namespace عمل، نُثبّت Falco للكشف عن السلوكيات الشاذّة على مستوى النواة، نضع Trivy أو Grype في سلسلة CI لفحص الصور قبل push، ونُوقِّع الصور بـ Cosign للتحقّق من الأصل عند النشر. عنقود CKS المنشور سلفًا على هذه المدوّنة يُغطّي كلّ لبنة بدليل مخصَّص.
الامتداد الثاني يخصّ الشبكة والكشف. لجعل خدمات قابلة للوصول من الخارج دون فتح الموجّه مباشرة، نُثبّت MetalLB (موزّع تحميل برمجي) أو Cilium في وضع L2 announcement، ثم cert-manager الذي يحصل تلقائيًّا على شهادات Let’s Encrypt. للأحمال التي تخرج إلى الخارج، نُهَيِّئ egress gateway Cilium يفرض المرور الخارج عبر IP مخصَّص — مفيد عند الاستيثاق لدى مزوّدين يُصفّون حسب IP المصدر.
الامتداد الثالث يخصّ الأحمال الفعلية المطلوب استضافتها. Gitea أو Forgejo للكود وCI، Vaultwarden لكلمات السرّ، Nextcloud لمشاركة الملفّات، Immich للصور، Paperless-ngx للوثائق، Jellyfin للوسائط العائلية. كلّ منها يصير Application Argo CD مُتزامنة من مستودع Git، مع volumes مستمرّة Rook وسرعة نسخ احتياطي Velero مُجَدوَلة كلّ ليلة. هنا تجني ثمار المسار الأوّلي: إضافة خدمة جديدة تأخذ عشر دقائق وcommit، لا يوم تثبيت يدوي.
الامتداد الرابع يخصّ الصمود المادي. إن بدأت بعقدة Proxmox واحدة، فهذه فرصة للانتقال إلى ثلاث مضيفات Proxmox في عنقود مع هجرة live للـ VMs، استبدال bridge الشبكة بـ OVS مع VLAN مخصَّص، ووضع UPS يقود إيقافًا نظيفًا للعقد عبر NUT. هذه الخطوات نادرًا ما تُنجَز في البداية لأنّها لا تجلب وظيفة مرئية، لكنّها تُحدّد العمر الحقيقي للعنقود.
دليل المسار الكامل
هذا المقال هو الدليل المرجعي لمسار Kubernetes منزلي على Proxmox VE. الدلائل العملية المرافقة تُغطّي كلّ طبقة من الـ hypervisor إلى النسخ الاحتياطي:
- تثبيت Proxmox VE 9.1 على خادم منزلي — ISO، ZFS، شبكة bridged، مستودع no-subscription، تأمين SSH.
- توفير VMs Talos Linux — إنشاء ست VMs، توليد machineconfig، bootstrap etcd، bring-up control plane K8s 1.36.
- kubeadm مقابل k3s — اختيار توزيع Kubernetes حسب نمط الاستعمال، مع اختبار صمود لفقدان عقدة.
- نشر Cilium CNI مع eBPF — تثبيت 1.19 مع kube-proxy replacement، Hubble UI، CiliumNetworkPolicy L4 وL7.
- تخزين مستمرّ مع Rook-Ceph — Ceph Squid على workers، RBD، CephFS، ObjectStore S3، dashboard.
- Bootstrap GitOps مع Argo CD — Argo CD 3.4، Application، app-of-apps، ApplicationSet، Sealed Secrets.
- مراقبة مع kube-prometheus-stack — Prometheus 3.0، Grafana 11.7، Alertmanager، ServiceMonitor، Ingress TLS.
- نسخ احتياطي مع Velero — Velero 1.18 نحو bucket Rook-Ceph S3، Kopia، جدوَلَة ليلية، اختبار استعادة وDR.