نشرت CNCF في 10 سبتمبر 2026 إرشادات مبنية على ثلاثة سيناريوهات فشل قابلة لإعادة الإنتاج، بهدف اختبار التعافي من الكوارث لتطبيقات Kubernetes ذات الحالة، لا الاكتفاء بمراقبة أن النسخ الاحتياطي انتهى بحالة Completed. التجارب، التي يمكن تشغيلها على حاسوب محمول من مستودع المختبر، استخدمت تطبيق PostgreSQL بمحتوى معروف يتكون من أربعة صفوف، بحيث يمكن التحقق من النتيجة الفعلية للاستعادة بدلاً من الاعتماد على مؤشرات حالة عامة.
أعدّ المادة Saiyam Pathak وSaloni Narang، وهما من سفراء CNCF. ويقتصر نطاقها على استعادة حالة التطبيقات داخل Kubernetes؛ فهي لا تعالج أطر الامتثال أو مقارنة المنتجات أو استعادة البنية التحتية الأساسية للسحابة أو مركز البيانات. وظهرت أدوات مثل Velero وواجهات CSI Snapshot بوصفها تطبيقات مرجعية للسيناريوهات، بينما تنطبق أنماط الفشل على الأدوات التي تؤدي الأدوار نفسها.
النسخ الاحتياطي المكتمل لا يثبت قابلية الاستعادة
في السيناريو الأول، فُصلت مكونات نسخة Kubernetes إلى تعريفات الموارد بصيغة YAML وبيانات وحدات التخزين الدائمة. استخدم المختبر Velero مع آلية نقل البيانات إلى مخزن كائنات متوافق مع S3 خارج العنقودين. وأظهر فحص كائنات DataUpload أن 47,989,888 بايت من بيانات وحدة التخزين نُقلت فعلياً إلى المخزن الخارجي.
بعد حذف مساحة الأسماء، بما في ذلك PVC، أعادت الاستعادة الصفوف الأربعة نفسها خلال نحو دقيقتين. لكن CNCF تحذر من أن حماية بيانات وحدة التخزين لا تجعل نسخة قاعدة البيانات متسقة تطبيقياً تلقائياً؛ فقد تحتاج التطبيقات إلى إجراءات flush أو quiesce. كما قد تتطلب الاستعادة على بنية مختلفة مواءمة StorageClass وتحويلات أخرى يجب أن يصممها الفريق ويختبرها.
والأهم أن أدوات النسخ الاحتياطي تستعيد الموارد إلى عنقود موجود مسبقاً، ولا تنشئ العقد أو الشبكة أو موازنات التحميل أو DNS. لذلك يجب أن تحدد خطة التعافي بوضوح البيئة التي ستستقبل النسخة، مع إسناد استعادة Kubernetes إلى البنية التحتية كبرمجية أو إلى Cluster API عند الحاجة.
Git يعيد النية، ولا يعيد الحالة المخزنة
في السيناريو الثاني، أُوقف عنقود الإنتاج، بينما كان عنقود التعافي موجوداً مسبقاً ويحتوي على متحكم GitOps مرتبط بمستودع Git وأداة نسخ احتياطي مرتبطة بالمخزن المشترك. نجحت مزامنة التطبيق، وأصبح StatefulSet قيد التشغيل، وظهرت لوحة المتابعة بحالة سليمة، لكن الاستعلام عن قاعدة البيانات أعاد الخطأ: relation "attendees" does not exist.
السبب ليس عطلاً في Kubernetes أو GitOps. فالمستودع احتوى على التعريفات فقط، ولذلك أعاد المتحكم إنشاء StatefulSet وService ووحدة تخزين فارغة جديدة. عملياً، يخزن Git الحالة المعلنة أو نية الفريق، بينما تخزن النسخ الاحتياطية البيانات الفعلية؛ ولا يستطيع أي منهما بمفرده استعادة التطبيق كاملاً.
تضمنت طريقة التعافي في المختبر إزالة التطبيق الفارغ الذي أنشأته المزامنة، ثم استعادة التطبيق مع وحداته من مخزن النسخ الاحتياطية، وأخيراً مقارنة البيانات بالمحتوى المتوقع. واستغرقت الرحلة من إيقاف الإنتاج إلى ظهور بيانات تم التحقق منها أربع دقائق في التجربة الحية وأقل بقليل من دقيقتين في إعادة الاختبار. وتوضح CNCF أن هذه الأرقام تغطي الجزء المبرمج فقط، ولا تشمل اكتشاف الحادث واتخاذ القرار وتحويل حركة المرور والعودة إلى البيئة الأصلية.
اللقطات المنفردة قد تنتج نقطة استعادة لم توجد قط
اختبر السيناريو الثالث تطبيقاً يستخدم وحدتي تخزين مترابطتين: واحدة للطلبات وأخرى للمدفوعات. كان المختبر يكتب أزواجاً متطابقة بمعدل خمس مرات في الثانية، مع شرط أن يقابل كل دفع طلباً. وعند أخذ لقطتين منفصلتين بفارق خمس ثوانٍ، بدت كل لقطة جاهزة وسليمة بمفردها، لكن الاستعادة كشفت أن آخر طلب مسجل كان 108352، مقابل 108377 دفعة، أي 25 دفعة بلا طلبات مطابقة.
توضح النتيجة أن نجاح كل عملية تخزين منفردة لا يضمن اتساق التطبيق متعدد وحدات التخزين؛ فقد تصف اللقطتان معاً لحظة زمنية لم توجد فعلياً. وتشير المادة إلى أن الفارق قد يتسع في الإنتاج عندما تمر أداة النسخ على عدد كبير من PVCs واحداً تلو الآخر.
يقدم VolumeGroupSnapshot، الذي وصل إلى حالة GA في Kubernetes 1.36، آلية لتحديد وحدات التخزين بوسم واحد وطلب نقطة استعادة متسقة عبر CSI. وفي التجربة المنسقة تطابق آخر رقم للطلبات والمدفوعات عند 109169، ونجح التحقق من العلاقة بينهما. لكن الدعم يعتمد على برنامج التشغيل؛ فدعم VolumeSnapshots العادية لا يثبت دعم لقطات المجموعات، كما أن معظم برامج التشغيل السحابية الكبرى التي فُحصت للمختبر لم تكن تنفذها حتى منتصف 2026. كذلك يجب تفعيل CRDs وميزة اللقطات والمكونات الإضافية ذات الصلة صراحة.
ما الذي يجب أن يقيسه اختبار التعافي؟
- استعادة تطبيق كامل إلى هدف نظيف لم يشغله من قبل، وليس مجرد حذف Pod ومراقبة إعادة إنشائه.
- التحقق من البيانات ومن مسار وصول المستخدم باستخدام محتوى متوقع، لا الاكتفاء بحالة الموارد أو ألوان لوحات المتابعة.
- قياس العملية كلها بساعة، مع إدراك أن زمن الاستعادة الفعلي يشمل الكشف والقرار وتحويل المرور وربما العودة إلى البيئة الأصلية.
- استخدام نطاقي فشل مستقلين، مثل عنقود إنتاج وعنقود تعافٍ، مع وضع مخزن النسخ الاحتياطية خارج كليهما.
القراءة التحريرية: فجوة بين الأدوات وتسلسل التعافي
التغيير العملي الذي تبرزه هذه التجارب هو نقل معيار النجاح من «اكتملت النسخة الاحتياطية» إلى «عادت البيانات الصحيحة ويمكن الوصول إليها». أما القيد الأوسع فهو أن Kubernetes الأساسي لا يحدد عقداً مشتركاً لتنسيق البيانات والتطبيق والعنقود وحركة المرور والهوية، ولا يوفر مورداً معيارياً مستداماً يصف وحدة التعافي الكاملة للتطبيق واعتماداته الخارجية. لذلك تظل الحدود بين GitOps والنسخ الاحتياطي والبنية التحتية ومسار المستخدم مسؤولية الفريق حتى عند توفر أدوات ناضجة لكل طبقة. وتذكر CNCF أن مبادرة Cloud Native Business Continuity التابعة لـ CNCF TAG Operational Resilience تسعى إلى جمع مساهمات حول تحليل فجوات المنظومة وإرشادات التعافي والبنى المرجعية.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.