يعرض Olivier Calzi، الحاصل على صفة CNCF Golden Kubestronaut وفق النص الأصلي، تجربة بناء مسار ترقية ذاتي التعافي لعنقود Kubernetes يعمل على Kairos. في الترقية الفعلية إلى Hadron v0.4.0، استغرق التنفيذ 11 دقيقة، ولم يتطلب أي تدخل بشري بعد دمج التغيير، كما لم ينكسر نصاب etcd ولم تتعرض أحمال العمل إلى انقطاع.
الفكرة الأساسية في التجربة هي نقل ترقية عقد التحكم من سلسلة أوامر يدوية ومراقبة مستمرة إلى مسار يعتمد على تعريفات محفوظة في Git، ومراجعة بشرية قبل الدمج، ثم تنفيذ آلي متتابع يحافظ على سلامة العنقود.
بنية العنقود وأساس الترقية
بدأت البيئة بعنقود إدارة جرى تمهيده باستخدام OpenTofu، ويتكون من ثلاث عقد للتحكم مع K3s HA وCilium CNI. جرى توفير المكونات على هيئة شيفرة قبل تشغيل أي حمل عمل، بحيث يمثل العنقود أساساً لمنصة يمكن أن تستضيف أدوات وأحمال عمل وعناقيد إضافية مستقبلاً.
يعمل العنقود على Kairos Hadron، وهو توزيعة Linux غير قابلة للتغيير تعتمد على ترقيات أقسام A/B وصور موقعة باستخدام Cosign. وبدلاً من تعديل نظام التشغيل الموجود مباشرة، تكتب Kairos صورة جديدة إلى القسم غير النشط ثم تعيد التشغيل للإقلاع منها. وفي حال حدوث مشكلة، يمكن الرجوع إلى القسم السابق عبر الإقلاع منه.
كان ضبط ترتيب الترقية محورياً في هذه البنية. ففي نسخة سابقة من المسار، أدت القيمة concurrency: 0 إلى إعادة تشغيل العقد الثلاث في الوقت نفسه، خلافاً لافتراض الكاتب بأنها تعني تشغيل عقدة واحدة في كل مرة. نجا نصاب etcd خلال اختبار المختبر المنزلي، لكن ذلك كان مصادفة وليس نتيجة تصميم آمن. لذلك جرى تعديل القيمة إلى concurrency: 1 لتصبح الترقية متتابعة.
الأدوات الست ومسؤولية كل منها
- Gitea: مستودع Git مستضاف ذاتياً على عنقود Kairos وK3s منفصل، ويشغل مشغّل Gitea Actions لتنفيذ CI. يحتوي المستودع على البيانات التعريفية والسياسات ومواصفات الترقية.
- Renovate: يراقب الوسوم الجديدة لصورة quay.io/kairos/hadron على Quay، ويفتح طلب دمج لتحديث سطرين هما وسم الصورة واسم مورد الترقية.
- Kyverno: يطبق سياسة قبول على العنقود ترفض أي مورد ترقية لا يستخدم صورة تطابق quay.io/kairos/hadron:*، ما يمنع أخطاء الإعداد ومحاولات انتحال الوسوم قبل وصولها إلى العقد.
- Cosign: يتحقق من توقيع الصورة مقابل هوية OIDC الخاصة بـGitHub Actions التابعة للمصدر. ولا يقتصر التحقق على صحة الوسم، بل يتأكد من أن الأثر أنتجته آلية CI المعتمدة.
- ArgoCD: يطبق نموذج GitOps؛ فعند اكتشاف التغيير بعد دمج طلب الدمج، يطبق البيان الجديد من دون تشغيل أمر kubectl apply يدوياً.
- kairos-operator: ينفذ الترقية فعلياً. فهو يراقب موارد NodeOpUpgrade، ويعزل عقدة واحدة، ويسحب الصورة، ويكتبها في قسم A/B الجديد، ثم يعيد التشغيل وينتظر عودة العقدة قبل الانتقال إلى التالية.
كيف أدى تغييران إلى تشغيل المسار
اقتصر التغيير الذي أطلق ترقية 7 يوليو إلى Hadron v0.4.0 على تحديث وسم الصورة من إصدار v0.3.0 إلى v0.4.0، وتغيير اسم مورد الترقية من hadron-mgmt-v0-3-0 إلى hadron-mgmt-v0-4-0. وكان تغيير الاسم ضرورياً لأن مورد NodeOpUpgrade يُستخدم مرة واحدة؛ إذ يضعه kairos-operator في حالة مكتملة ولا يعيد معالجته.
لذلك فإن تعديل spec.image في المورد الموجود وحده لا يكفي. ويجب أن يؤدي تحديث metadata.name إلى حذف المورد القديم وإنشاء مورد جديد، وهو ما يراه المشغل كإشارة فعلية لبدء الترقية.
الخلل الذي كشفته المراجعة البشرية
لم يعمل المسار بصورة مثالية في أول تشغيل فعلي. فقد استخدم مدير Renovate المخصص تعبيراً باسم extractVersionTemplate لتحويل الإصدار ذي الشرطات في اسم المورد، مثل v0-3-0، إلى صيغة SemVer قابلة للمقارنة. لكن هذا الحقل غير موجود في مخطط مدير Renovate المخصص، ولذلك لم ينفذ أي إجراء ظاهرياً.
نتيجة ذلك أن Renovate حدّث الصورة إلى الوسم الجديد، لكنه أبقى اسم المورد كما هو. لم يرَ kairos-operator مورداً جديداً، فلم ينفذ الترقية، وبدا المسار وكأنه معطل رغم أن نصف التغيير فقط قد نُفذ.
عولج الخلل باستبدال الحقل بـcurrentValueTemplate، الذي يحول v0-3-0 إلى v0.3.0 كي تعمل مقارنة الإصدارات، ثم يعيد بناء الصيغة ذات الشرطات للوسم الجديد. وتوضح هذه الحالة دور المراجعة البشرية في المسار: ليس تنفيذ الترقية، بل اكتشاف الموضع الذي قد ينفذ فيه النظام الآلي الإجراء الخطأ بطريقة تبدو صحيحة.
النتيجة والخطوات التالية
أظهرت سجلات ترقية 7 يوليو أن الزمن الكلي بلغ 11 دقيقة، مع بقاء نصاب etcd سليماً طوال العملية، وعدم تسجيل تدخل بشري بعد الدمج أو تعطيل لأحمال العمل. كما جرى ربط عنقود البوابة، وهو نشر Kairos منفصل أحادي العقدة ويشغل Netbird، بحلقة ArgoCD نفسها المستخدمة لعنقود الإدارة، ما أتاح له مسار الترقية الآلي ذاته من دون عملية منفصلة.
تتضمن الخطوة التالية إضافة مرحلة تشغيل تجريبي في CI باستخدام kairos-agent upgrade –recovery على الصورة الجديدة قبل دمج طلب التغيير، بهدف اكتشاف الإخفاقات قبل أن تصل إلى عقدة حية. وتقدم التجربة نموذجاً عملياً لترقية متتابعة قابلة للمراجعة، تجمع بين نظام تشغيل غير قابل للتغيير، والتحقق من سلسلة الإمداد، وGitOps، وآليات تمنع إعادة استخدام مورد ترقية مكتمل.