تعرف على استعادة مجموعات Kubernetes استنادًا إلى لقطات etcd

لضمان استمرارية الأعمال في حالة وقوع كوارث، ستحتاج إلى تنفيذ إستراتيجية استعادة القدرة على العمل بعد الكوارث للتطبيقات التي تعمل على Kubernetes Clusters. استخدم توصيات Oracle Maximum Availability Architecture (Oracle MAA) التي توفر حماية للبيانات وتمكّنك من التبديل بسرعة إلى نظام بديل مع الحد الأدنى من فقدان البيانات والإنتاجية.

على الرغم من التغيير الهائل الذي ينطوي عليه تبني Kubernetes لبنية نظام تكنولوجيا المعلومات، يقدم نظام Kubernetes نماذج مماثلة لاستعادة القدرة على العمل بعد الكوارث كتطبيق تقليدي (مثل Oracle Java SE أو Oracle Java EE أو JavaScript). يجب أن تحتفظ بنسخة متسقة و"محدثة قدر الإمكان" من النظام الأساسي في موقع ثانوي يمكن من خلاله استئناف أحمال العمل إذا تسببت كارثة في حدوث توقف في المنطقة الأساسية.

يوفر دليل الحلول هذا توصيات وخدمات Oracle MAA التي ستنشئ نظام Kubernetes ثانوي وتمكّنك من الاسترداد في سيناريوهات الكوارث التي تؤثر على موقع ما وتجبر إعادة توجيه أحمال العمل إلى موقع نسخة متماثلة.

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

عندما يكون مستوى التحكم غير مهيأ.
عند فقد قاعدة بيانات etcd، أو تلفها، أو في حالة عدم ظهور etcd بشكل صحيح.
عندما يؤثر خطأ توزيع أو مستخدم غير صحيح على تطبيقات أو خدمات صغيرة متعددة ويجب إرجاع المجموعة إلى إصدار أو تجسيد سابق. ستعيد استعادة لقطة ETCD جميع البيانات الاصطناعية إلى النقطة الزمنية التي تم فيها أخذ اللقطة (النسخ الاحتياطي).

يركز هذا المستند على استنساخ بيانات Kubernetes' وغيرها إلى موقع ثانوي. يتم تخزين جميع معلومات نظام مجموعة Kubernetes في etcd، وهو مخزن قيم أساسي يُستخدم كمخزن دعم Kubernetes لبيانات المجموعة. يقدم دليل تشغيل الحلول هذا توصيات لاستنساخ مجموعة Kubernetes تم تكوينها باستخدام أداة Kubernetes kubeadm (راجع https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) استنادًا إلى استعادة etcd. قد تتطلب إجراءات الإعداد والسكريبتات المقدمة تخصيصات لنوع آخر من المجموعات (التي لم يتم تكوينها باستخدام kubeadm)، ولكن بشكل عام، تكون صالحة طالما كان هناك وصول إلى نقاط نهاية etcd التي يستخدمها مستوى التحكم في Kubernetes. يتطلب حل الاستنساخ هذا إعدادًا محددًا للمجموعة الثانوية وسيستخدم نسخة من etcd (وتسمى أيضًا لقطات etcd) وذلك من أجل تقديم نفس البيانات الاصطناعية الموجودة في الأساس.

يمكنك استخدام اللقطات الاصطناعية أو أدوات النسخ الاحتياطي لـ Kubernetes من جهة خارجية لاستنساخ مساحات أسماء وتطبيقات محددة عبر أنظمة Kubernetes. ومع ذلك، فإنها لا تحمي المجموعات من عمليات تلف الملفات والتكوينات الخاطئة في بيانات تعريف مستوى التحكم. بالإضافة إلى استخدامها للحماية من الكوارث، يمكنك استخدام لقطات وما إلى ذلك للاستعادة المحلية ولإرجاع Kubernetes Clusters إلى نقطة عمل سابقة في الوقت المناسب. إذا كان نظام مجموعة etcd الخاص بك غير صحي، فقد تستمر التطبيقات في العمل ولكن عمليات نقل pod، وتغييرات التكوين، والوصول السري، وأي عملية أخرى تتطلب توفر مستوى التحكم لن تعمل بشكل صحيح. ولهذا السبب يجب أن يكون الحفاظ على etcd جزءًا مهمًا من أي إجراءات دورة حياة Kubernetes Cluster.

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

تجنب استمرار تعدد اللغات (يعد استخدام أنواع مختلفة من المتاجر الدائمة لبيانات وقت التشغيل من المستحيل تقريبًا حل المشكلة وفقًا لنظرية BAC)
استخدام متجر واحد لجميع أنواع البيانات المختلفة والخدمات الصغيرة والتطبيقات ذات التبعيات إلى أقصى حد ممكن
اطلع على Oracle MAA Best Practices لـ Oracle Database لحماية الكوارث في وقت التشغيل

قبل البدء

هناك العديد من الموجزات الفنية لـ Oracle Maximum Availability Architecture التي تصف كيفية إعداد نظام استعادة البيانات بعد الكوارث (DR) لأنظمة البرامج الوسيطة التقليدية. تعرض هذه المستندات بالتفصيل متطلبات حماية الكوارث لمكونات البنية الأساسية الخارجية (مثل التخزين وموازنات التحميل وقاعدة البيانات) التي تستخدمها تطبيقات Kubernetes.

لمزيد من التفاصيل، راجع ما يلي:

البنية

تعرض هذه البنية هيكل نظام استعادة القدرة على العمل بعد الكوارث (DR) لمجموعة Kubernetes.

يتم استنساخ جميع معلومات وقت التشغيل والتكوين وبيانات التعريف الموجودة في قاعدة البيانات الأساسية من المنطقة 1 إلى المنطقة 2 مع Oracle Autonomous Data Guard. يتم استنساخ تكوين مجموعة Kubernetes المطلوب من خلال لقطات etcd لحماية مستوى التحكم. يمكنك استخدام نسخ etcd أو لقطات البيانات الاصطناعية لحماية التكوين الخاصة بالتطبيق. راجع استخدام لقطات البيانات الاصطناعية لحماية مجموعات Kubernetes من الكوارث لمزيد من التفاصيل. يتم استضافة الصور المستخدمة من قبل الحاويات في السجلات إما المحلية لكل مجموعة أو في المستودعات الخارجية (لا تعتبر الصور تكوين مجموعة Kubernetes بنفسها).

ملاحظة:

إعداد Oracle Autonomous Data Guard لقاعدة بيانات وقت التشغيل خارج مجال هذا المستند.

فيما يلي وصف kubernetes-etcd-multiregion-dr.png

وصف الشكل التوضيحي kubernetes-etcd-multiregion-dr.png

kubernetes-etcd-multiregion-dr-oracle.zip

تدعم هذه البنية المكونات التالية:

Region (المنطقة)
منطقة Oracle Cloud Infrastructure هي منطقة جغرافية محلية تحتوي على مركز بيانات واحد أو أكثر، تسمى نطاقات التوفر. المناطق مستقلة عن المناطق الأخرى، والمسافات الشاسعة يمكن أن تفصل بينها (عبر البلدان أو حتى القارات).
موازن التحميل
توفر خدمة Oracle Cloud Infrastructure Load Balancing توزيع حركة المرور التلقائي من نقطة إدخال واحدة إلى خوادم متعددة في الواجهة الخلفية.
بوابة التوجيه الديناميكي (DRG)
DRG هو جهاز توجيه ظاهري يوفر مسارًا لحركة مرور الشبكة الخاصة بين VCNs في نفس المنطقة، بين VCN وشبكة خارج المنطقة، مثل VCN في منطقة Oracle Cloud Infrastructure أخرى، أو شبكة محلية، أو شبكة في موفر سحابة آخر.
Data Guard
يوفر Oracle Data Guard مجموعة شاملة من الخدمات التي تنشئ قاعدة بيانات بديلة واحدة أو أكثر وتحتفظ بها وإدارتها وتراقبها لتمكين قواعد بيانات Oracle الإنتاجية من البقاء متاحة دون انقطاع. يحتفظ Oracle Data Guard بقواعد البيانات الاحتياطية هذه كنسخ من قاعدة بيانات الإنتاج. بعد ذلك، إذا أصبحت قاعدة بيانات الإنتاج غير متاحة بسبب انقطاع مؤقت مخطط أو غير مخطط، يمكن لـ Oracle Data Guard تحويل أي قاعدة بيانات بديلة إلى دور الإنتاج، مما يقلل من وقت التوقف عن العمل المرتبط بالانقطاع المؤقت.
Oracle Real Application Clusters (Oracle RAC).
يتيح لك Oracle RAC تشغيل Oracle Database واحد عبر خوادم متعددة لزيادة التوافر إلى أقصى حد وتمكين قابلية التوسع الأفقية، مع الوصول إلى التخزين المشترك. يمكن لجلسات المستخدم التي تتصل بطبعات Oracle RAC تجاوز الفشل وإعادة تشغيل التغييرات بأمان أثناء الانقطاعات المؤقتة، دون إجراء أي تغييرات على تطبيقات المستخدم النهائي.
سجل الحاويات
Oracle Cloud Infrastructure Registry هو سجل مُدار من Oracle يمكنك من تبسيط سير عمل التطوير إلى الإنتاج. يسهل التسجيل عليك تخزين البيانات الاصطناعية والصور الخاصة بالتطوير ومشاركتها وإدارتها. تضمن بنية Oracle Cloud Infrastructure عالية التوفر والقابلة للتوسع أنه يمكنك نشر تطبيقاتك وإدارتها بشكل موثوق.
محرك حاوية Kubernetes
Oracle Cloud Infrastructure Container Engine for Kubernetes هي خدمة مدارة بالكامل وقابلة للتوسع وعالية التوافر يمكنك استخدامها لنشر تطبيقاتك المحفوظة في حاويات على السحابة. يمكنك تحديد موارد الحوسبة التي تتطلبها تطبيقاتك، ويقوم Container Engine for Kubernetes بتوفيرها على Oracle Cloud Infrastructure في عقد إيجار موجود. يستخدم محرك حاوية Kubernetes نظام Kubernetes لأتمتة نشر التطبيقات المحفوظة في حاويات وتوسيعها وإدارتها عبر مجموعات المضيفين.
مجموعة Kubernetes
مجموعة Kubernetes هي مجموعة من الأجهزة التي تقوم بتشغيل التطبيقات ذات الحاويات. يوفر نظام Kubernetes نظامًا أساسيًا مفتوح المصدر وقابل للتوسيع وقابل للتنقل لإدارة أحمال العمل والخدمات المحفوظة في حاويات في تلك العُقد. تتكون مجموعة kubernetes من نقاط توصيل العامل ونقاط توصيل مستوى التحكم.
مستوى التحكم في Kubernetes
يقوم مستوى التحكم في Kubernetes بإدارة الموارد لنقاط توصيل العامل ووحدات التنفيذ الأساسية داخل مجموعة Kubernetes. تقوم مكونات مستوى التحكم باكتشاف الأحداث والاستجابة لها وتنفيذ الجدولة ونقل موارد المجموعة. فيما يلي مكونات مستوى التحكم:
- kube-apiserver: تشغيل خادم Kubernetes API.
- إلخd: مخزن قيمة المفتاح الموزع لكل بيانات المجموعة.
- kube-sccheder: تحديد وحدات التنفيذ الأساسية الجديدة غير المخصصة لنقطة التوصيل التي سيتم تشغيلها عليها.
- kube-controller-manager: تشغيل عمليات التحكم.
- مدير التحكم في السحابة: يربط مجموعتك بواجهة برمجة تطبيقات خاصة بالسحابة.
نقطة توصيل عامل Kubernetes
نقطة توصيل عامل Kubernetes هي جهاز عامل يقوم بتشغيل التطبيقات الموجودة في حاويات ضمن مجموعة Kubernetes. تحتوي كل مجموعة على عقدة عامل واحدة على الأقل.
مراقب الدخول
وحدة التحكم في الدخول هي مكون يعمل في مجموعة Kubernetes ويدير موارد Ingress. وهو يستقبل حركة المرور من الشبكة الخارجية، ويوجهها إلى الخدمة الصحيحة، ويقوم بإجراء موازنة التحميل وإنهاء SSL. يعمل جهاز التحكم في الدخول عادةً كوحدة تنفيذ منفصلة في المجموعة ويمكن توسيعه بشكل مستقل عن الخدمات التي يديرها.
واجهة برمجة تطبيقات نقطة نهاية KUBE
واجهة برمجة تطبيقات نقطة نهاية KUBE هي مكون KUBE-apiserver لمستوى التحكم Kubernetes. يقوم بتشغيل خادم واجهة برمجة تطبيقات Kubernetes.
النسخ الاحتياطي لـ ETCD
ETCD Backup هو نسخة احتياطية من مكون etcd من مستوى التحكم Kubernetes. يحتوي etcd على مخزن قيمة المفتاح الموزع لكل بيانات المجموعة. من المهم إنشاء نسخة احتياطية لـ ETCD لاستعادة مجموعات Kubernetes لاستعادة القدرة على العمل بعد الكوارث.
لقطات YAML
لقطة YAML هي نسخة في الوقت المحدد من ملفات (yaml) التي تحتوي على تعريف البيانات الاصطناعية في مجموعة Kubernetes. اللقطة هي ملف tar يمكنك استخدامه لاستعادة تلك البيانات الاصطناعية في نفس مجموعة Kubernetes أو في مجموعة مختلفة.

اعتبارات الحماية من الكوارث في Kubernetes

عند تنفيذ إجراءات الحماية من الكوارث لنظام Kubernetes، ضع في اعتبارك ما يلي:

استعادة القدرة على العمل بعد الكوارث (DR) المتماثلة: توصي Oracle باستخدام نفس سعة المورد والتكوين في المرحلة الابتدائية والثانوية. يجب أن يكون لمجموعات Kubernetes في المنطقتين موارد متشابهة متاحة، مثل عدد نقاط التوصيل العاملة (وسعة أجهزتها) والبنية الأساسية الأخرى (التخزين المشترك وموازنات التحميل وقواعد البيانات، وما إلى ذلك). يجب أن تكون الموارد التي تعتمد عليها مجموعة Kubernetes في المنطقة الثانوية قادرة على مواكبة أحمال العمل نفسها كأساسية. كما يجب أن يكون النظامان متسقين وظيفيًا مع نفس الخدمات التي يعتمد عليها النظام المستعاد، ويجب استخدام السيارات الجانبية وخرائط التكوين (CMs) في كلا الموقعين.
الاسم البديل والافتراضية لاسم المضيف: من المهم تخطيط أسماء المضيفات المستخدمة بواسطة نقاط التوصيل في الموقع الثانوي. يجب أن تكون أسماء المضيفين أو أسماء المضيفات البديلة لمستوى التحكم ونقاط توصيل العامل "نشطة" في الموقع الثانوي قبل استعادة لقطة etcd من مجموعة Kubernetes أساسية. يتم تخزين أسماء نقاط التوصيل في بيانات اصطناعية مختلفة لمجموعة Kubernetes لتحديد نقاط توصيل العامل، ولوضع علامة على تخصيصات وحدات التنفيذ الأساسية، وفي خرائط التكوين (config) التي تصف المجموعة نفسها، وفي ملفات وإدخالات التكوين المتعددة. يجب أن يحدد موقعك الثانوي عناوين العامل ومستوى التحكم والنهاية الأمامية kube-api بنفس أسماء المضيف المستخدمة في مجموعة Kubernetes الأساسية (قد يختلف الاسم المؤهل بالكامل في اسم المجال، ولكن يجب أن يكون اسم المضيف هو نفسه. وبدون استخدام الاسم البديل لاسم المضيف، لن تعمل استعادة اللقطة etcd بشكل صحيح حيث لن تتمكن الكؤوس وأدوات الجدولة ووحدات التحكم، وبصفة عامة، لن تتمكن خدمات مستوى التحكم من الوصول إلى نقاط النهاية والمضيفين المناسبين المستخدمين بواسطة التكوين المستنسخ. لا تستخدم عناوين IP (بروتوكول الإنترنت) لتعريف نقاط التوصيل في kubernetes، واستخدم أسماء المضيفين دائمًا بدلاً من ذلك.
تقدم صور الحاويات نموذجًا مشابهًا للثنائيات: قد لا تتغير الصور بمعدل تكرار تكوين Kubernetes وقد لا تحتاج إلى تحديث الصور باستخدام كل استنساخ لمجموعة Kubernetes. يجب أن تكون الصور التي يستخدمها النظام الأساسي هي نفس الصور المستخدمة في النظام الثانوي أو قد يحدث عدم اتساق أو فشل. على أي حال، نسخ الصور خارج من مجال كتيب التشغيل هذا. هناك استراتيجيات متعددة يمكنك استخدامها للحفاظ على استخدام متسق للصور بين موقعين، بما في ذلك ما يلي:
- حفظ الصور في الأصل وتحميلها إلى نقاط توصيل العامل الثانوية. وهذا النهج سهل التنفيذ للغاية ولكنه يتكبد نفقات إدارية إضافية. إن استخدام سجلات الحاويات له فوائد كبيرة وحفظ الصور محليًا يجعل إدارة الإصدارات والتحديثات أكثر صعوبة.
- يمكن أن توجد الصور في سجلات الحاويات الخارجية تمامًا في مناطق أو مراكز بيانات مختلفة عن تلك التي تستخدمها الحاويات الأساسية والبديلة. يتم الحفاظ على المنتجات والمكتبات الخارجية من قبل أطراف ثالثة وعادة ما يكون توافرها ضمنا في إصداراتها.
- يمكن أن توجد الصور في سجلات الحاويات الموجودة في الأساس والاستعداد. يتم تحديث كل منطقة بالتوازي عند تحرير إصدار جديد للصورة. وهذا يوفر تحكمًا أفضل في البرامج المستخدمة ولكنه يتكبد تكاليف إضافية للإدارة العليا. يتطلب تكرار الصور وإدارة بيانات الاعتماد للوصول إلى سجلين مختلفين. تُستخدم أدوات CI/CD عادةً لهذا النهج.

يقدم كتيب الحلول هذا مثالاً باستخدام مجموعات Kubernetes التي تم تكوينها باستخدام الأداة kubeadm. التوصيات عامة لمجموعات Kubernetes المخصصة المثبتة في الأنظمة المحلية ولكن قد تتطلب معظم الاسكربتات تعديلات للمجموعات التي لم يتم إنشاؤها باستخدام أداة kubeadm. يجب استخدام الخطوات والاسكربتات المقدمة بين مجموعات Kubernetes التي تقوم بتشغيل نفس إصدار etcd وKubernetes. قد تؤدي استعادة لقطات etcd عبر إصدارات kubernetes المختلفة إلى حالات عدم تناسق ومجموعات etcd غير مستقرة.

حول المنتجات والأدوار المطلوبة

يتطلب هذا الحل المنتجات والأدوار التالية:

مجموعة Kubernetes
الحصن القادر على إدارة نظام Kubernetes يصل إلى نقاط نهاية etcd للمجموعة والوصول إلى نقاط توصيل مستوى التحكم المختلفة باستخدام ssh
(اختياري) Oracle Cloud Infrastructure (OCI)
يعتمد هذا الكتيب على استخدام مناطق OCI ومواردها للمناطق الأساسية والثانوية. ومع ذلك، ينطبق هذا الحل أيضًا على مجموعات Kubernetes الموجودة في أماكن العمل.

هذه هي الأدوار المطلوبة لكل خدمة.

اسم الخدمة: الدور	مطلوب لـ ...
مجموعة Kubernetes (الرئيسية): `administrator`	تشغيل كل الاسكربتات.
نقاط توصيل Kubernetes (الأساسية): المستخدم الذي يمتلك حقوق sudo في الجذر	قم بتشغيل الاسكربتات التالية: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`
Kubernetes Cluster (ثانوي): `administrator`	تشغيل كل الاسكربتات.
نقاط توصيل Kubernetes (الثانوية): مستخدم لديه حقوق sudo للجذر	قم بتشغيل الاسكربتات التالية: `maak8s-force-stop-cp.sh` `maak8-etcd-backup.sh` `maak8-etcd-restore.sh`

اطلع على منتجات Oracle وحلولها وخدماتها للحصول على ما تريده.