مقال مرتبط · هذا الدليل جزء من سلسلة Kubernetes منزلي على Proxmox VE. الدليل السابق: تثبيت Proxmox VE 9.1. الدليل التالي: kubeadm مقابل k3s.
Talos Linux نظام تشغيل غير قابل للتغيير مُصمَّم لـ Kubernetes فقط. لا shell، لا SSH، لا مدير حزم: كلّ شيء يمرّ عبر API gRPC تُقاد من أداة talosctl. هذا الانضباط يُلغي فئات كاملة من الأخطاء (تحديثات جزئية، انجراف الإعدادات، اقتحامات عبر اختراق جلسة shell). الإصدار 1.13.0، الصادر في 27 أبريل 2026، يحوي افتراضيًّا Kubernetes 1.36.0 ويستفيد من نواة مُجمَّعة بـ Clang/ThinLTO. يصف هذا الدليل إنشاء ست آلات افتراضية Talos على Proxmox، ضبطها في وضع controlplane أو worker، وbootstrap أوّلي لعنقود Kubernetes.
المتطلّبات وتحضير محطّة العمل
على الخادم: Proxmox VE 9.1 يعمل مع pool ZFS جاهز لاستقبال أقراص الـ VMs (راجع الدليل السابق) و24 جيغا RAM على الأقلّ متاحة (4×3 جيغا للـ workers، 3×2 جيغا للـ control plane).
على محطّة العمل: ثبِّت talosctl وkubectl. هما الأداتان الوحيدتان اللازمتان لإدارة العنقود.
# تثبيت talosctl 1.13.0 (Linux x86_64)
curl -sL https://github.com/siderolabs/talos/releases/download/v1.13.0/talosctl-linux-amd64 \
-o /usr/local/bin/talosctl
chmod +x /usr/local/bin/talosctl
talosctl version --client
# تثبيت kubectl 1.36 (متوافق مع K8s 1.36 المُضَمَّن في Talos 1.13)
curl -sL https://dl.k8s.io/release/v1.36.0/bin/linux/amd64/kubectl \
-o /usr/local/bin/kubectl
chmod +x /usr/local/bin/kubectl
kubectl version --clientالأمران --version --client يجب أن يُرجعا على التوالي 1.13.0 وv1.36.0. هذا تأكيد أنّ الـ binaries في مكانها وقابلة للتنفيذ.
الخطوة 1 — تنزيل صورة Talos لـ Proxmox
تنشر Talos صورًا مخصَّصة حسب الـ hypervisor. لـ Proxmox، نُنزِّل صورة قرص qcow2 أو ISO bare-metal، ونستوردها مباشرة في VM. تُوزِّع Sider Labs صورة عامّة nocloud-amd64.iso وقرصًا nocloud-amd64.qcow2 يُكوَّن مع ISO إقلاع للإعداد.
# على Proxmox، في /var/lib/vz/template/iso
cd /var/lib/vz/template/iso
wget https://github.com/siderolabs/talos/releases/download/v1.13.0/metal-amd64.iso
ls -la metal-amd64.iso
# يجب عرض نحو 80 ميغاصورة metal-amd64.iso هي صورة bare-metal لـ Talos: تُقلِع الآلة في وضع « maintenance » دون إعداد، جاهزة لاستقبال machineconfig عبر الـ API. تظهر هذه الصورة بعدها في Proxmox تحت تخزين local، قسم ISO Images.
الخطوة 2 — إنشاء VM template لـ Talos
بدل إنشاء ست VMs يدويًّا، نُنشئ template ثم نستنسخ. في واجهة الويب Proxmox: Create VM. املأ الشاشات التالية:
# General
Node: pve01
VM ID: 9000
Name: talos-template
# OS
Use CD/DVD disc image: ISO local: metal-amd64.iso
Guest OS Type: Linux 6.x - 2.6 Kernel
# System
BIOS: OVMF (UEFI)
Machine: q35
Add EFI Disk: Yes (storage vmpool)
SCSI Controller: VirtIO SCSI (وليس "VirtIO SCSI single" الذي قد يُعَطِّل bootstrap Talos على Proxmox)
Qemu Agent: Enabled
# Disks
SCSI 0: vmpool, 32 GiB, Discard=on, SSD emulation=on, IO thread=on
# CPU
Sockets: 1
Cores: 4
Type: host # أساسي لأحمال K8s، يكشف كلّ تعليمات CPU المضيف
# Memory
Memory: 4096 MiB
Ballooning: مُعَطَّل
# Network
Bridge: vmbr0
Model: VirtIO (paravirtualized)
Firewall: مُعَطَّل لهذه الـ VM (Cilium يُدير الأمن الشبكي لاحقًا)ثبِّت الإنشاء. قبل التشغيل، افتح تبويب Hardware للـ VM وتحقّق من التماسك. بعد ذلك حوِّل الـ VM إلى template عبر VM 9000 ← More ← Convert to template. الـ template talos-template صار قابلًا للاستنساخ.
الخطوة 3 — استنساخ الست VMs
ثلاثة استنساخات لـ control plane، ثلاثة للـ workers. على كلّ منها، عدِّل ملف RAM/CPU وفق الدور.
# على console Proxmox، استنسخ دفعة عبر CLI pvesh
for i in 1 2 3; do
pvesh create /nodes/pve01/qemu/9000/clone \
-newid 100$i -name talos-cp-$i -full -storage vmpool
done
for i in 1 2 3; do
pvesh create /nodes/pve01/qemu/9000/clone \
-newid 110$i -name talos-wk-$i -full -storage vmpool
done
# عدِّل الـ workers: 6 جيغا RAM، 4 vCPU، +1 قرص بـ 32 جيغا لـ Rook-Ceph
for i in 1 2 3; do
qm set 110$i -memory 6144 -cores 4
qm set 110$i -scsi1 vmpool:32,discard=on,ssd=1
doneفي النهاية، تظهر ست VMs في شجرة Proxmox: talos-cp-1، talos-cp-2، talos-cp-3، talos-wk-1، talos-wk-2، talos-wk-3. شَغِّل الستّ. تحصل كلّ منها على IP عبر DHCP وتدخل وضع maintenance لـ Talos. سجِّل الـ IPs المُسَنَدَة (مرئية على console Proxmox لكلّ VM).
للباقي، نفترض الـ IPs الآتية (عدِّل): control plane 192.168.1.61/62/63، workers 192.168.1.71/72/73، وVIP 192.168.1.60 ستكون endpoint مستقرّ لـ Kubernetes API server.
الخطوة 4 — توليد إعداد Talos
يُقاد Talos بملفّين YAML: controlplane.yaml (مُطَبَّق على عقد control plane) وworker.yaml (مُطَبَّق على workers). يُولَّدان بأمر واحد، يُمَعلَمَان باسم العنقود وendpoint الـ API server.
mkdir -p ~/talos-homelab && cd ~/talos-homelab
talosctl gen config homelab https://192.168.1.60:6443 \
--kubernetes-version 1.36.0 \
--install-disk /dev/sda \
--output-types controlplane,worker,talosconfig
ls -la
# controlplane.yaml worker.yaml talosconfigثلاثة ملفّات تظهر. controlplane.yaml وworker.yaml يحملان أسرار العنقود وشهاداته — يجب حمايتهما كأنّهما كلمة سرّ رئيسية. talosconfig ملفّ الإعداد المحلّي لـ talosctl، نظير kubeconfig لكن لقيادة عقد Talos نفسها.
هَيِّئ talosctl ليعرف endpoints المخاطَب:
talosctl --talosconfig=./talosconfig \
config endpoint 192.168.1.61 192.168.1.62 192.168.1.63
talosctl --talosconfig=./talosconfig \
config node 192.168.1.61 192.168.1.62 192.168.1.63 \
192.168.1.71 192.168.1.72 192.168.1.73
export TALOSCONFIG=$(pwd)/talosconfigتصدير TALOSCONFIG يُتيح حذف خيار --talosconfig من الأوامر اللاحقة كلّها.
الخطوة 5 — تطبيق الإعداد على كلّ عقدة
كلّ VM في وضع maintenance وتستمع على المنفذ 50000 منتظرةً machineconfig الخاصّ بها. نُرسله عقدة عقدة.
# Control plane
for ip in 192.168.1.61 192.168.1.62 192.168.1.63; do
talosctl apply-config --insecure -n $ip --file controlplane.yaml
done
# Workers
for ip in 192.168.1.71 192.168.1.72 192.168.1.73; do
talosctl apply-config --insecure -n $ip --file worker.yaml
doneالعلامة --insecure ضرورية للاتصال الأوّل (الشهادات المتبادلة لم تتكوّن بعد). بعد الـ apply، تُعيد كلّ VM التشغيل، تُثبّت Talos على /dev/sda، ثم تُعيد التشغيل ثانية على النظام المثبَّت. احسب 3 إلى 5 دقائق لكلّ عقدة.
الخطوة 6 — bootstrap الـ etcd على أوّل control plane
عند هذه المرحلة، العقد الست نشطة لكنّ عنقود Kubernetes لم يُهَيَّأ بعد: لا عضو نشط في etcd. أمر bootstrap يُهَيِّئ etcd على أوّل control plane فقط، الذي سيعمل كقائد أوّلي.
talosctl bootstrap -n 192.168.1.61
# تابع التقدّم
talosctl health -n 192.168.1.61
# يجب أن يتقدّم من "discovered nodes" ← "etcd to be healthy" ← "kubernetes is healthy"العملية تستغرق دقيقتين. في النهاية، talosctl health يعرض healthy على كلّ الفحوص. الـ control plane الاثنان الآخران ينضمّان إلى etcd تلقائيًّا لأنّ machineconfig أشارت لهم إلى endpoint المشترك. إذا بقيت الصحّة عالقة أكثر من 5 دقائق، افحص السجلّات بـ talosctl logs -n 192.168.1.61 etcd.
الخطوة 7 — استرداد kubeconfig والتحقّق من العنقود
عنقود Kubernetes الآن يستجيب على VIP. استرد kubeconfig ليتمكّن kubectl من التفاعل معه.
talosctl kubeconfig ~/.kube/config -n 192.168.1.61
kubectl get nodes -o wide
# يجب ظهور ستّ عقد، كلّها في STATUS Ready (أو NotReady ما دام الـ CNI غير مثبَّت)
kubectl get pods -A
# pods kube-system موجودة: kube-apiserver، kube-controller-manager، etcd...
# pods CoreDNS تبقى Pending ما دام الـ CNI غير مثبَّت: هذا طبيعيرؤية العقد الست والـ API server يُجيب يُؤكِّد أنّ العنقود يعمل على مستوى control plane. حالة NotReady على العقد متوقّعة: تعني أنّه لم يُنشئ CNI شبكة pods بعد. هذه الخطوة التالية من المسار، تُعالَج في دليل نشر Cilium CNI مع eBPF.
الخطوة 8 — حفظ الملفّات الحسّاسة
ثلاثة ملفّات يجب ألّا تُفقَد أبدًا، وإلّا اضطُرّ المرء لإعادة بناء العنقود: controlplane.yaml، worker.yaml، وtalosconfig. تحوي مجموع الأسرار والشهادات. شَفِّرها بـ age أو sops وخزّنها خارج الخادم.
# مثال مع age (مفتاح غير متماثل بسيط)
age-keygen -o ~/.age/talos-key.txt
PUBLIC_KEY=$(grep "public key" ~/.age/talos-key.txt | awk '{print $4}')
cd ~/talos-homelab
tar czf - controlplane.yaml worker.yaml talosconfig | \
age -r $PUBLIC_KEY -o talos-secrets.age
# احفظ talos-secrets.age والمفتاح الخاصّ منفصلَين
# (مفتاح USB مشفَّر، مدير كلمات السرّ، إلخ.)الأرشيف المشفَّر يبلغ بضعة كيلوبايت. نسخة على وسيط خارجي ونسخة في خدمة نسخ احتياطي شخصية تُؤمِّن البيئة من فقدان محطّة العمل.
أخطاء شائعة وحلولها
| العَرَض | السبب | الحلّ |
|---|---|---|
talosctl apply-config يُرجع connection refused |
VM لم تُقلَع أو IP مختلف عن المنتظر | تحقّق من console Proxmox للـ VM، اقرأ الـ IP الحقيقي على الشاشة |
| الـ bootstrap يبقى عند « etcd to be healthy » | قرص /dev/sda غير موجود، التثبيت لم يحدث |
تحقّق من --install-disk، عدِّل عبر talosctl edit machineconfig إن لزم |
kubectl يُبيّن x509 certificate signed by unknown authority |
kubeconfig خاطئ مُستورَد | أعد التوليد بـ talosctl kubeconfig --force |
| العقد تبقى NotReady بعد 10 دقائق | لا CNI مثبَّت | انتقل إلى دليل Cilium |
talosctl health يُبلِّغ component apid is unhealthy |
شبكة الـ VM انقطعت أثناء apply | أعد talosctl reset على العقدة ثم أعد تطبيق الإعداد |
لاستكمال المسار
عنقود Kubernetes جاهز: ست عقد Talos، control plane HA، kubectl يعمل. القرار التالي يخصّ توزيع Kubernetes ذاته: دليل kubeadm مقابل k3s يُقارن التسويات ويُوضّح لماذا يبقى Talos+kubeadm الأكثر تمثيلًا لعنقود مؤسّسة. للنظرة العامّة، عُد إلى الدليل الرئيسي.
مصادر وتوثيق رسمي
- توثيق Talos Linux 1.13:
talos.dev/v1.13 - دليل Talos على Proxmox:
talos.dev/proxmox - ملاحظات إصدار Talos 1.13.0: GitHub releases
- مرجع machineconfig Talos:
talos.dev/reference/configuration - توثيق Kubernetes 1.36:
kubernetes.io/docs - أداة age (تشفير):
github.com/FiloSottile/age
لماذا Talos بدل Ubuntu المثبَّت يدويًّا
اختيار Talos كنظام تشغيل لعقد Kubernetes يستحقّ التبرير، لأنّه يكسر عادات إدارة Linux الكلاسيكية. ثلاث خصائص تشرح لماذا هو خيار ممتاز لبيئة منزلية تطمح للجدّية.
أولى الخصائص: عدم قابلية نظام الملفّات للتغيير. rootfs لـ Talos في وضع للقراءة فقط. لا عملية، حتى root، تستطيع تعديل ملفّ نظام. التعديلات تتمّ حصرًا عبر تحديث ذرّي للصورة كلّها (talosctl upgrade). هذا قضاء على سبب رئيسي للانحراف: على Ubuntu مُدار 6 أشهر تجد دائمًا ملفّات إعدادات منسيّة، حزمًا مثبَّتة على عَجَل، مهامّ cron أُنشِئت بسرعة. على Talos، حالة النظام في لحظة T هي تمامًا ما تصفه machineconfig — لا أكثر ولا أقلّ.
الثانية: غياب SSH والـ shell. مساحة الهجوم الشبكي مختزَلة إلى منفذين: 50000 (API Talos، mTLS إلزامي) و6443 (Kubernetes API). لا جلسة shell ممكنة، فلا هجوم باختراق كلمة سرّ SSH أو حقن أوامر في sudoers. كلّ العمليات تمرّ عبر talosctl الذي يتحدّث API gRPC مشفَّر. هذا النموذج مطابق لما يفعله مزوّدو السحاب على عقدهم المُدارة.
الثالثة: الإعداد التصريحي الكامل. ملفّ controlplane.yaml يصف العقدة كاملة: إصدار Kubernetes، معاملات kubelet، سجلّات الصور، الشهادات، خيارات الشبكة، labels وtaints. لإعادة بناء عنقود مطابق على عتاد جديد، يكفي إعادة تطبيق هذا الإعداد. لا قائمة فحص ذهنية، لا نسيان لخيار --feature-gates سيُغيّر السلوك بعد 6 أشهر.
العيب هو كلفة التعلّم الأوّلي. talosctl ليس kubectl ولا ssh. التشخيصات الأولى تتمّ بـ talosctl logs <service>، talosctl dmesg، talosctl restart <service>. توثيق Sider Labs واضح لكنّه لا يبلغ عمق توثيق Ubuntu المُتراكم على عشرين سنة. لمبتدئ، أسبوعان إلى ثلاثة من الاستعمال المنتظم يكفيان للارتياح.
تباينات النشر الواجب معرفتها
معمارية الست عقد الموصوفة هي الخيار الافتراضي الموصى به. ثلاث تباينات تستحقّ الذكر لأنّها تُقابل سياقات منزلية شائعة.
Single-node Talos للانطلاق صغيرًا: يمكن اختبار Talos على VM وحيدة تتحمّل دوري control plane وworker. يُولَّد الإعداد بخيار --with-cluster-discovery=false ونزيل taint node-role.kubernetes.io/control-plane بعد bootstrap لإتاحة وضع pods بواسطة scheduler. مفيد لعرض أو labo خفيف؛ يُجَنَّب لاستضافة خدمات لا نريد سقوطها.
هجين control plane Talos + workers Ubuntu: إن كان لديك خوادم Ubuntu قائمة تريد إدماجها كـ workers، يمكنك الإبقاء على Talos للـ control plane وضمّ Ubuntu كعقد عبر kubeadm join. التعايش يعمل؛ تخسر عدم قابلية التغيير على workers، وهي تسوية مقبولة إن استثمرت في stack Ansible ناضج.
عنقود على ARM (Ampere، Raspberry Pi 5): Talos ينشر صور arm64. الإجراء مطابق باستبدال amd64 بـ arm64 في كلّ URLs وخيارات --install-disk. انتبه: بعض صور الأحمال (مثل kube-prometheus-stack أو Velero) لها تغطية arm64 أحدث. تحقّق من التوفّر قبل هجرة حِمل حرج.
أيّ كان السيناريو، التسلسل يبقى مطابقًا: Proxmox جاهز، صورة Talos مُنزَّلة، VMs مُوَفَّرة، machineconfig مُولَّدة ومُطَبَّقة، bootstrap، kubeconfig مُستَرَدّ. هذه القابلية للتكرار هي ما يجعل البيئة قابلة للصيانة على المدى البعيد.