Kubernetes

يجلب Rediacc تقنية Kubernetes إلى المنتج دون التخلي عن عقلية المستودع التي بُني عليها باقي المنصة. الادعاء المميز مباشر: يمكنك تفريع أو نقل عنقود قيد التشغيل، بما في ذلك بياناته، إلى جهاز أو مركز بيانات آخر بفترة انتقال قصيرة. هذا ليس ترحيلاً بالإيقاف ثم الاستعادة، وليس سحر انعدام التوقف. تُعاد الأعباء إلى التشغيل على الوجهة، وتُقاس فترة الانتقال بالثواني، وتنتقل البيانات معها.

تعمل تقنية Kubernetes بواسطة k3s، وهي توزيعة Kubernetes معتمدة، مضمّنة في renet بنفس الطريقة التي تُضمَّن بها الملفات التنفيذية الأخرى على جانب الخادم.

نموذج الكائنات

يقلب Rediacc الصورة المعتادة “العنقود يغلّف كل شيء” حتى تظل عقلية المستودع سارية:

العنقود هو الحاوية. يستضيف الجهاز مستودعات Docker (بلا تغيير) و/أو عناقيد. يحافظ عنقود ذو عقدة واحدة على جهاز واحد على قصة “ملف واحد يحرك النظام بأكمله” على مستوى العنقود. تعيش حالة العنقود (مجلد بيانات k3s: مخزن بياناته المضمّن وcontainerd) في ملفات صور نسخ عند الكتابة مدعومة بمخزن البيانات، واحدة لكل عقدة، مع ارتباط --data-dir الخاص بـ k3s داخل نقطة تحميل الصورة.
مستودع Kubernetes هو فضاء أسماء. ينشئ rdc repo create <repo> -m <name> مستودعاً موطنه وقت التشغيل هو فضاء أسماء Kubernetes <repo> داخل ذلك العنقود.
الأحجام الثابتة هي وحدات نسخ عند الكتابة منفصلة. الأحجام الثابتة هي صور RBD على Ceph، أو ملفات صور صغيرة لمخزن البيانات عبر موفر PV محلي من renet على الطبقة المحلية. ليست أبداً مجلدات داخل صورة عنقود معتمة: نظام الملفات الداخلي ليس له reflinks، لذا تتطلب التفريعات المستقلة لكل مستودع صور PV مستقلة.

هذا الفصل هو ما يجعل كلا الوعدين ممكنَين فعلياً في آن واحد: تفريعات فضاء أسماء دائمة النسخ عند الكتابة (بيانات كل مستودع تُستنسخ بشكل مستقل) وقابلية نقل العنقود بأكمله (صور العنقود بالإضافة إلى كل صورة PV تنتقل معاً).

المفهوم	مستودع Docker	مستودع Kubernetes
موطن وقت التشغيل	عملية Docker معزولة	فضاء أسماء في عنقود
البيئة المحقونة	`DOCKER_HOST`	`KUBECONFIG`
غلاف النشر	`renet compose`	`renet kube`
وحدة البيانات	صورة LUKS واحدة	صور العنقود بالإضافة إلى صور لكل PV
وحدة التفريع	صورة المستودع	فضاء الأسماء بالإضافة إلى استنساخات PV الخاصة به
استنساخ المكان بأكمله	(المستودع هو المكان)	`rdc cluster fork` / `rdc cluster migrate`

تعريف وإنشاء عنقود

العنقود هو مجموعة مسمّاة من تجمعات العقد على شبكة خاصة. عرّفه أولاً في الإعداد، ثم جهّزه.

# تعريف عنقود مع تجمعات (لا شيء يُجهَّز بعد)
rdc cluster create prod --declare-only \
  --provider my-linode \
  --pool ceph:ceph:3 \
  --pool k8s:k8s-server:3

# تجهيز أعضاء التجمع، إقلاع renet على كل منها، تثبيت المكونات (Ceph أولاً)
rdc cluster create prod

مرجع CLI: rdc cluster create

أدوار التجمع هي ceph وk8s-server وk8s-agent وhyperconverged (اختيار صريح، لأن أهداف ذاكرة Ceph وعتبات إخلاء kubelet تتنافس على الذاكرة العشوائية). يحمل كل تجمع تفاوت العتاد كمعاملات حجم وقرص لكل تجمع: عُقد Ceph الكثيفة القرص، وعُقد Kubernetes الكثيفة المعالج/الذاكرة.

تتجسد أعضاء التجمع في resources.machines باسم <cluster>-<pool>-<n> مع مرجع عكسي، بحيث يعمل كل أمر -m موجود عليها: rdc machine status وrdc term connect وأوامر المستودع واستراتيجيات النسخ الاحتياطي تراها جميعاً عُقد العنقود كأجهزة عادية.

تُجهِّز مزودات السحابة عبر OpenTofu، متبعة نفس سجل ProviderMapping الذي يستخدمه rdc machine provision، ممتداً بكتلة شبكة خاصة (VLAN أو VPC، وحدة النقل القصوى المراد ختمها، وتسمية بطاقة الشبكة الخاصة). KVM المحلي هو مسار الاختبار المتاح دائماً عبر rdc ops.

# فحص العناقيد
rdc cluster status                 # سرد جميع العناقيد
rdc cluster status prod     # الإعداد الكامل لعنقود واحد

# تكبير أو تصغير تجمع (إضافة/إزالة أجهزة، ضم/تفريغ عقد)
rdc cluster scale prod --pool k8s --count 5


# تفكيك الأعضاء المجهزة وإزالة العنقود من الإعداد
rdc cluster destroy prod

مرجع CLI: rdc cluster status · rdc cluster scale · rdc cluster destroy

الحصول على kubeconfig

لا يُخزَّن kubeconfig أبداً في ملف الإعداد الخاص بك (فهو كبير ويتناوب). يُجلب عند الطلب عبر SSH ويُخزَّن مؤقتاً محلياً بصلاحيات 0600، متبعاً نفس نمط الحالة الجانبية مثل مجلدات عمل OpenTofu وذاكرة الشهادات المؤقتة.

rdc cluster kubeconfig prod
# يطبع: export KUBECONFIG=~/.config/rediacc/kube/prod.yaml

مرجع CLI: rdc cluster kubeconfig

مستودعات Kubernetes

علم الوجهة هو ما يحدد وقت التشغيل. لا يوجد علم للنوع.

# مستودع Docker (بلا تغيير): عملية Docker معزولة على جهاز
rdc repo create shop -m server-1 --size 10G

# مستودع Kubernetes: فضاء أسماء "shop" بالإضافة إلى تخزينه، داخل عنقود
rdc repo create shop --datastore prod --size 10G

مرجع CLI: rdc repo create

أفعال المستودع هي السطح الوحيد للعمل المرتبط بالمستودع. عبر قمع حل الوجهة، يصبح تقريباً مجموعة أوامر المستودع بأكملها متوافقة مع العناقيد: تقبل fork وmigrate وpush وpull وup وdown وresize وdiff وcommit وbranch وcheckout وmerge وtrim وcat وmount وsync وlist وstatus وlog كلها --cluster. تُحل وجهة العنقود إلى عقدة التحكم الخاصة به بالإضافة إلى سياق KUBECONFIG المثبَّت على فضاء أسماء المستودع، وهو نظير حل جهاز إلى DOCKER_HOST بالإضافة إلى مجلد عمل.

rdc repo sync upload shop --local ./config
rdc cluster kubeconfig prod           # تصدير KUBECONFIG، ثم استخدام kubectl مباشرة

مرجع CLI: rdc repo sync upload · rdc cluster kubeconfig

تتجسد عُقد العنقود أيضاً في resources.machines، بحيث يمكنك الاتصال عبر SSH بعقدة محددة باستخدام rdc term connect <cluster>-<pool>-<n> المعتاد.

ملف Rediaccfile ثنائي وقت التشغيل

تعتمد قابلية النقل بين Docker وKubernetes على اتفاقية، وليس على تحويل بيانات تلقائي. المستودع الذي يوفر مساراً لـ renet compose ومساراً لـ renet kube تحت نفس دالتي up() وdown() يهاجر بحرية في كلا الاتجاهين، لأن اتفاقيات مجلد البيانات متطابقة. يحقن renet DOCKER_HOST عند وجهة جهاز وKUBECONFIG عند وجهة عنقود؛ تقرأ up() أيهما مُعيَّن وتوجّه وفقاً لذلك.

up() {
  if [ -n "$KUBECONFIG" ]; then
    renet kube apply -f manifests/     # وقت تشغيل Kubernetes
  else
    renet compose -- up -d             # وقت تشغيل Docker
  fi
}

المستودع الذي يفتقر إلى وقت تشغيل الوجهة يحصل على رفض واضح بعد مرحلة نقل البيانات: تنتقل الصور، وتخبرك خطوة النشر أن المستودع لا يعرّف مساراً لـ Kubernetes (أو Docker)، بدلاً من إفساد الحالة.

تفريع مستودع

rdc repo fork على مستودع Kubernetes ينسخ البيانات دائماً، وفوراً دائماً. لا يوجد علم --full ولا متغيرات.

rdc repo fork shop --tag joseph

مرجع CLI: rdc repo fork

هذا ينشئ فضاء الأسماء shop-joseph في نفس العنقود، ويستنسخ كل حجم بنسخ عند الكتابة (استنساخ RBD على Ceph، أو reflink لملفات صور PV على الطبقة المحلية)، وينشر الأعباء هناك. رابط URL الخاص بالتفريع نشط فوراً تحت الشهادة البرية الخاصة بالأصل، لذا لا تُصدَر شهادة أو سجل DNS جديد.

تصعيد الوجهة:

--to-cluster <name> يفرّع إلى عنقود موجود آخر. نفس طبقة Ceph: يبقى استنساخ RBD نسخاً عند الكتابة. طبقة مختلفة: تنقل آلية الدفع الصور.
--provider <p> يجهّز عنقوداً جديداً أولاً، بمواصفات تجمع تعكس افتراضياً شكل العنقود المصدر (الأعلام تتجاوز ذلك).

مقيساً في مختبر اختبار KVM، يكتمل تفريع فضاء الأسماء في حوالي ثانية إلى خمس ثوانٍ مع بقاء عبء الأصل دون مساس وتباعد فضائي الأسماء بشكل مستقل.

تفريع أو نقل عنقود بأكمله

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

# استنساخ عنقود بأكمله، بما في ذلك بيانات مستودعاته، إلى عنقود جديد
rdc cluster fork prod --to spare --tag staging

# نقل عنقود بأكمله، بما في ذلك بيانات مستودعاته، إلى جهاز أو مركز بيانات آخر
rdc cluster migrate prod --to spare

مرجع CLI: rdc cluster fork · rdc cluster migrate

كلاهما ينسّق نسخاً عند الكتابة لصور العنقود بالإضافة إلى كل صورة PV لمستودع، ثم يعيد كتابة هوية العقدة بحيث يقلع النسخ أو العنقود المنقول بصحة على عناوينه الجديدة. بما أن k3s تخزّن حالة مستوى التحكم في مخزن بياناتها المضمّن، فإن صورة العنقود نفسها هي اللقطة: ترتيب الاتساق هو مستوى التحكم أولاً، ثم الأحجام الثابتة، ثم الوكلاء.

الأرقام الصادقة، مقيسة من طرف إلى طرف في مختبر اختبار KVM:

العملية	ما تفعله	القياس
تفريع فضاء الأسماء	استنساخ فضاء أسماء مستودع بالإضافة إلى أحجامه الثابتة في مكانه	~1 إلى 5 ثوانٍ
تفريع RBD لصورة واحدة	نسخ استنساخ PV مدعوم بـ Ceph بنسخ عند الكتابة	~5 ثوانٍ
تفريع عنقود كامل بعقدتين	تفريغ، وreflink لمستوى التحكم والوكيل، وإعادة كتابة الهوية إلى عناوين IP جديدة، بقاء الأصل دون مساس	~46 ثانية
هجرة عنقود بين الأجهزة	نسخ مسبق ساخن بالإضافة إلى فترة انتقال الإيقاف وإعادة التشغيل	~16 ثانية فترة انتقال

السلوك الافتراضي هو متسق عند الانهيار وسليم مرجعياً: نفس دلالات دورة إيقاف التشغيل وإعادته، وهو ما تراه الأعباء أيضاً. تتوفر اللقطات المتسقة على مستوى التطبيق عندما تُجمَّد أنظمة ملفات العبء أثناء النسخ. هذا لا يُقدَّم عمداً على أنه انعدام توقف. لا أحد آخر يقدّم “تفريع عنقود قيد التشغيل بما في ذلك بياناته” على الإطلاق؛ التأطير الصادق هو فترة انتقال قصيرة ومقيسة بدلاً من مطلق تسويقي.

التخزين: ceph-csi والأحجام الثابتة

تُجهَّز Ceph بواسطة تدفق cephadm الخاص بـ renet على تجمع ceph، خارج أي عنقود Kubernetes، وتستهلكه العناقيد عبر بيانات ceph-csi المُولَّدة من قوالب renet. تحصل كل نسخة عنقود (وكل تفريع) على فضاء أسماء RBD/RADOS خاص بها، وهو أولية العزل لكل مستأجر. يقع التخزين تحت جميع العناقيد، لذا فهو يدعم أيضاً مستودعات Docker البسيطة وطبقة مخزن البيانات، ويستنسخ تفريع العنقود صور RBD تحت Kubernetes بدلاً من تفريع طبقة التخزين الخاصة به.

على الطبقة المحلية (بدون Ceph)، يدعم موفر PV محلي من renet كل حجم ثابت بملف صورة صغير نسخ عند الكتابة في مخزن البيانات، مستنسخ عبر reflink عند التفريع. راجع مرجع الخادم للتخطيط على القرص وأوامر renet.

اختيار توزيعة

التوزيعة تجريد بواجهة صغيرة وحقيقية (install، join، kubeconfig، healthcheck، upgrade، وما إلى ذلك):

k3s هي الافتراضية والتوزيعة المضمّنة الوحيدة. هي Apache-2.0، معتمدة من CNCF، ملف تنفيذي واحد قابل للنقل، وكلا Traefik المضمّن فيها وServiceLB معطّلان لصالح وكيل Rediacc. يرتبط --data-dir الخاص بها عند البدء، وهو بالضبط ما يحتاجه تفريع العنقود وهجرته عند تغيّر مسار تحميل الصورة. تُعلَّم k3s بـ repoEmbeddable.
external هي جلب kubeconfig الخاص بك. فقط getKubeconfig وhealthcheck يقومان بعمل حقيقي؛ أفعال دورة الحياة تُعيد نتائج “غير قابل للتطبيق” من الدرجة الأولى بدلاً من الأخطاء.
RKE2 هي الطبقة الثالثة المخطط لها لعملاء FIPS/CIS، وليست جزءاً من هذا الإصدار.

يرفض تفريع العنقود وهجرته العمل على توزيعة غير repoEmbeddable بخطأ واضح بدلاً من إفساد الحالة، لأن تضمين حالة العنقود في صور مخزن البيانات يتطلب مجلد بيانات يرتبط عند البدء.

السجل

مشكلتا صور مختلفتان، وأداتان:

ألم المنبع (حدود معدل Docker Hub، سحب مرفوض، عدم اتصال): تعمل ذاكرة تخزين مؤقتة مضمّنة تمر عبرها zot على تجمع التحكم مع sync.onDemand مقابل منابع متعددة (docker.io وghcr.io وquay.io). هي مضمّنة في renet بنفس طريقة الملفات التنفيذية الأخرى، وتحل محل سجل اختبار العمليات بحيث يمارسها كل تشغيل.
التوزيع داخل العنقود: تسمح مرآة السجل المضمّنة في k3s للعُقد بمشاركة الصور المسحوبة بالفعل نداً لند.

التوصيل شفاف ولا يتطلب إعادة تشغيل عبر certs.d/hosts.toml الخاص بـ containerd وregistries.yaml الخاص بـ k3s. يبقى مخزن containerd لكل مستودع داخل صورة العنقود مصدر الحقيقة الذي تنقله التفريعات والهجرات؛ السجل هو ذاكرة تخزين مؤقتة أمام الإنترنت، وليس حالة أبداً.

الشبكات وعناوين URL

تتبع عناوين URL لمستودعات Kubernetes المخطط المسطّح، مع طي هوية فضاء الأسماء في التسمية الأقصى يساراً والعنقود كالتسمية الثانية المستقرة:

{service}--{repo}.{cluster}.{machine}.{base}          مستودع Kubernetes (فضاء الأسماء = المستودع)
{service}--{repo}-{tag}.{cluster}.{machine}.{base}    تفريع (فضاء الأسماء = repo-tag)

يرث كل فضاء أسماء وكل تفريع الشهادة البرية وسجل DNS الخاصين بالأصل، لذا تكون عناوين URL الخاصة بالتفريع نشطة فوراً ولا تُصدَر شهادات جديدة إلا عند إنشاء عنقود أو مستودع جديد. يكتشف الموجّه خدمات Kubernetes باستطلاع العنقود بحثاً عن Services موسومة بـ rediacc.*، وهو نظير Kubernetes لقراءة تسميات Docker. راجع الشبكات لنموذج التوجيه والبنية المعمارية لطبقات التخزين.

الإسناد

ينقل Rediacc عدة ملفات تنفيذية من أطراف ثالثة (k3s وzot وغيرها مما يضمّنه renet). اطبع إصداراتها ومعرّفات ترخيص SPDX وعناوين URL لأرشيف المصدر في أي وقت:

rdc credits
rdc credits --licenses    # نص THIRD_PARTY_LICENSES الكامل المرفق مع الإصدارات

مرجع CLI: rdc credits