اسمي سيرجي ، أنا من ITSumma ، وأريد أن أخبركم كيف نتعامل مع الحجز في Kubernetes. لقد قمت مؤخرًا بالكثير من العمل الاستشاري حول تنفيذ مجموعة متنوعة من حلول devops لمختلف الفرق ، وعلى وجه الخصوص ، أنا أعمل عن كثب في المشروعات التي تستخدم K8s. في مؤتمر Uptime لليوم الرابع ، الذي كان مكرسًا للتكرار في المباني المعقدة ، قدمت عرضًا تقديميًا حول المكعب الزائد ، وهنا سرده المجاني. سأحذر مقدمًا من أنه ليس دليلًا مباشرًا للعمل ، بل هو تعميم للأفكار حول هذا الموضوع.
من حيث المبدأ ، يمثل الرصد والتكرار أداتين رئيسيتين لزيادة مرونة أي مشروع. ولكن في cuber ، كل شيء متوازن من تلقاء نفسه ، كما تقول ، يتم تغيير كل شيء من تلقاء نفسه ، وإذا حدث شيء ما ، فسوف يرتفع من تلقاء نفسه ... وهذا هو ، خلال الدراسة السطحية الأولى للموضوع ، أجابني الإنترنت على السؤال "كيف يعمل النسخ الاحتياطي K8s؟" ؟ " كثير من الناس يعتقدون أن cuber هو شيء سحري يزيل كل مشاكل البنية التحتية ويجعل المشروع لا يسقط. لكن ... العالم ليس كما يبدو.
كيف نقترب من عملية النسخ الاحتياطي من قبل؟ كان لدينا منصات متطابقة للتنسيب - سواء كانت أجهزة افتراضية ، أو كانت خوادم حديدية ، قمنا بتطبيق ثلاث ممارسات أساسية:
- تزامن الرمز والإحصائيات
- تزامن التكوين
- تكرار قاعدة البيانات
وفويلا: في أي لحظة ننتقل إلى موقع الاحتياطي ، الجميع سعداء ، ننهض ، نختلف.
وما الذي يقدمونه لنا لزيادة التوافر المستمر لتطبيق kubernetes الخاص بنا؟ أول شيء تقول الوثائق غير الرسمية هو وضع الكثير من الآلات ، وجعل الكثير من الأساتذة - يجب أن يفي عددهم بالشروط اللازمة لتحقيق النصاب القانوني داخل المجموعة ، وهكذا يتم رفع جدولة etcd ، api ، MC ، على كل من الأساتذة ... ويبدو أن كل شيء على ما يرام : عندما تفشل العديد من عقد العمل أو الماجستير ، سيتم إعادة التوازن إلى نظامنا وسيستمر التطبيق في العمل. يشبه السحر مرة أخرى! ولكن غالبًا ما تقع المجموعة الخاصة بنا داخل نفس مركز البيانات وهذا يمكن أن يسبب أسئلة معينة. ماذا لو وصلت حفارة وحفرت كابل ، ضرب البرق ، كان هناك فيضان عالمي؟ يتم تغطية كل شيء ، لدينا مجموعة ليست أكثر. كيفية التعامل مع التحفظ مع مراعاة هذا الجانب من المشكلة؟
بادئ ذي بدء ، يجب أن يكون لديك كتلة أخرى في المحمية الساخنة ، أي كتلة يمكنك التبديل إليها في أي وقت. في الوقت نفسه ، من وجهة نظر cuber ، يجب أن تكون البنية التحتية متطابقة تماما. أي إذا كان هناك أي مكونات إضافية غير قياسية للعمل مع نظام الملفات ، وهي حلول مخصصة للدخول ، فيجب أن تكون متطابقة تمامًا في مجموعتين (أو ثلاث ، أو عشرة ، هناك ما يكفي من المال وقوة المسؤولين). من الضروري تحديد مجموعتين من التطبيقات بوضوح (publish'ov ، statefulset'ov ، daemonset'ov ، cronjob'ov ، وما إلى ذلك): أي منهما يمكن أن يعمل على احتياطي باستمرار ، والأفضل عدم البدء قبل التبديل المباشر.
فهل يجب أن تكون مجموعة النسخ الاحتياطي لدينا متطابقة تمامًا مع مجموعة القتال الخاصة بنا؟ لا. في السابق ، في إطار العمل مع مشاريع متجانسة ، مع بنية تحتية من الحديد ، حافظنا على محيط متطابق تمامًا تقريبًا ، ولكن في إطار cuber ، أعتقد أن هذا لا ينبغي أن يكون. لنلقِ نظرة على السبب.
على سبيل المثال ، لنبدأ بالكيانات الأساسية في kubernetes - عمليات النشر - يجب أن تكون متطابقة. يجب إطلاق التطبيقات التي يمكن أن تعترض معالجة حركة المرور في أي وقت وتسمح لمشروعنا بالاستمرار في العيش. إذا كنا نتحدث عن ملفات التكوين ، فعلينا أن ننظر هنا سواء كانت متطابقة أم لا. هذا هو ، إذا كنا ، الأشخاص الأذكياء ، لا نستخدم أي مواد محظورة ولا نحتفظ بالقاعدة في K8s ، ثم في ملفات التهيئة يجب أن يكون لدينا إعدادات وصول إلى قاعدة القتال (تم بناء عملية النسخ الاحتياطي بشكل منفصل). وفقًا لذلك ، لضمان الوصول إلى مثيل قاعدة بيانات النسخ الاحتياطي ، يجب أن يكون لدينا ملف تكوين منفصل (configmap). بالطريقة نفسها التي نتعامل بها مع الأسرار: كلمات المرور للوصول إلى قاعدة البيانات ، ومفاتيح api ؛ في أي وقت من الأوقات ، إما سر القتال أو احتياطي واحد يمكن أن تعمل معنا. إجمالًا ، لدينا بالفعل كيانان kubernetes لا ينبغي أن تكون إصداراتهما الاحتياطية متطابقة مع الكيانات القتالية. الكيان التالي يستحق المسكن هو cronjob. Cronjobs على الاحتياطي يجب أن لا تكون بأي حال من الأحوال متطابقة مع مجموعة من مجموعات إنتاج cronjob! إذا قمنا برفع مجموعة النسخ الاحتياطي ورفعناها بالكامل مع تمكين cronjob ، فعلى سبيل المثال ، سيتلقى الأشخاص رسالتين منك في نفس الوقت بدلاً من حرف واحد. أو قد يحدث نوع من تزامن البيانات مع مصادر خارجية مرتين ، على التوالي ، نبدأ في الأذى والبكاء والصراخ والقسيم.
ولكن كيف يعرض علينا الأشخاص من الإنترنت لتنظيم مجموعة نسخ احتياطي؟ الجواب الثاني الأكثر شعبية بعد "لماذا؟" - استخدام اتحاد Kubernetes.
ما هذا هذا ، دعنا نقول ، كتلة meta كبيرة. إذا تخيلنا بنية cuber - حيث لدينا سيد ، وعقد متعددة - ثم من وجهة نظر الاتحاد ، لدينا أيضًا عقدة رئيسية وعدة ، كل عقدة هي كتلة منفصلة. هذا هو ، نحن نعمل مع نفس الكيانات ، مع نفس العناصر البدائية كما هو الحال مع شخص واحد ، لكننا لا نلتفت ولا ندور في أجهزتنا المادية ، بل في مجموعات كاملة. في إطار الاتحاد ، نحن في تزامن كامل للموارد الفيدرالية من الآباء إلى أحفادهم. على سبيل المثال ، إذا أطلقنا بعض عمليات النشر من خلال الاتحاد ، فسيتم نشرها في كل مجموعة من مجموعاتنا الفرعية. إذا أخذنا أي شكل من أشكال configmap ، فإن السر يكمن في التمرير إلى الاتحاد - سوف ينتشر في جميع مجموعات الأطفال ؛ في الوقت نفسه ، يسمح لنا الاتحاد بتخصيص مواردنا للأطفال. أي أننا اتخذنا بعضًا من configmap ، وقمنا بنشرها من خلال الاتحاد ، ومن ثم ، إذا كنا بحاجة إلى إصلاح شيء ما على مجموعات محددة ، فسنذهب إلى التحرير على مجموعة منفصلة ، ولن تتم مزامنة هذا التغيير في أي مكان.
لم يكن Kubernetes Federation منذ فترة طويلة أداة موجودة بالفعل ، ولا يدعم المجموعة الكاملة من الموارد التي توفرها K8s نفسها: في وقت نشر أحد الإصدارات الأولى من الوثائق ، كان يتحدث عن دعم خرائط التهيئة فقط ، ونشر مجموعة النسخ المتماثلة ، إدخال. الأسرار غير مدعومة ، كما أن العمل مع وحدة التخزين غير مدعوم. مجموعة محدودة للغاية. خاصة إذا كنا نرغب في الحصول على المتعة ، على سبيل المثال ، من خلال تعريف المورد المخصص لنقل مواردنا إلى kubernetes ، فإننا لن ندفعهم إلى الاتحاد. هذا هو ، كما كان ... قرارًا مشابهًا جدًا للحقيقة ، ولكنه يجعلنا نطلق النار بشكل دوري في القدم. من ناحية أخرى ، يسمح لك الاتحاد بإدارة مجموعات النسخ المتماثل بمرونة. على سبيل المثال ، نريد إطلاق 10 نسخ متماثلة من تطبيقنا ، بشكل افتراضي ، سيقوم الاتحاد بتقسيم هذا الرقم بالتناسب بين عدد المجموعات. ويمكن أيضا أن يتم تكوين كل هذا! أي أنه يمكنك تحديد أنك بحاجة إلى الاحتفاظ بـ 6 نسخ متماثلة من تطبيقنا على مجموعة القتال ، و 4 نسخ متماثلة فقط من تطبيقنا على مجموعة النسخ الاحتياطي ، لتوفير الموارد أو للترفيه الخاص بك. وهو أيضا مريحة للغاية. ولكن مع الاتحاد يجب أن نستخدم بعض الحلول الجديدة ، وأن ننهي شيئًا ما أثناء التنقل ، ونجبر أنفسنا على التفكير أكثر ...
هل من الممكن الاقتراب من عملية حجز cuber بطريقة أبسط؟ ما هي الأدوات التي لدينا على الإطلاق؟
أولاً ، لدينا دائمًا نوع من أنظمة ci / cd ، أي أننا لا نتحرك يدويًا ، ولا نكتب إنشاء / تطبيق على الخوادم. النظام يولد yaml'ics للحاويات لدينا.
ثانياً ، هناك العديد من المجموعات ، لدينا إما سجل واحد أو عدة (إذا كنا أذكياء) ، والتي اتخذناها أيضًا واحتفظنا بها. وهناك أداة kubectl رائعة يمكن أن تعمل مع مجموعات متعددة في وقت واحد.
لذلك: في رأيي ، الحل الأبسط والأكثر صحة لبناء مجموعة النسخ الاحتياطي هو نشر متوازي بدائي. هناك نوع من خطوط الأنابيب في نظام ci / cd ؛ أولاً ، نبني حاوياتنا ونختبر ونطرح التطبيقات من خلال kubectl إلى عدة مجموعات مستقلة. يمكننا بناء حسابات متزامنة على عدة مجموعات. وفقًا لذلك ، نقرر أيضًا تقديم التكوينات في هذه المرحلة. يمكنك التحديد المسبق لمجموعة التكوينات الخاصة بمجموعتنا القتالية ، ومجموعة التكوينات الخاصة بمجموعة النسخ الاحتياطي وعلى مستوى ci / cd للنظام ، قم بنقل البيئة الموالية إلى الكتلة الموالية ، وبيئة النسخ الاحتياطي إلى كتلة النسخ الاحتياطي. بالمقارنة مع الاتحاد ، لا تحتاج إلى المتابعة بعد تحديد مورد اتحادي لكل مجموعة تابعة وإعادة تعريف شيء ما. فعلنا هذا مقدما. ما الزملاء جيدة نحن.
ولكن ... هناك ... كتبت ، هناك "جذر كل الشرور" ، ولكن هناك بالفعل اثنين منهم. الأول هو نظام الملفات. هناك نوع من PV ، أو نستخدم التخزين الخارجي. إذا قمنا بتخزين الملفات داخل المجموعة ، فسنحتاج إلى اتباع الممارسات القديمة المتبقية من وقت البنى التحتية الحديدية: على سبيل المثال ، قم بالمزامنة مع lsync. حسنًا ، أو أي عكاز آخر تفضله شخصيًا. نحن نلف كل شيء بسيارات أخرى ونعيش.
ثانيا ، وفي الواقع ، هناك حجر عثرة أكثر أهمية هو قاعدة البيانات. إذا كنا أذكياء ولم نحتفظ بقاعدة البيانات في المكعب ، فإن عملية نسخ البيانات احتياطيًا وفقًا لنفس المخطط القديم هي النسخ المتماثل للرقيق ، ثم التبديل ، وسنتابع النسخة المتماثلة وسنعيش بشكل جيد. ولكن إذا احتفظنا بقاعدة البيانات الخاصة بنا داخل المجموعة ، فهناك من حيث المبدأ العديد من الحلول الجاهزة لتنظيم نسخة متماثلة من السيد والعبد ، والعديد من الحلول لرفع قاعدة البيانات داخل المكعب.
لقد تم بالفعل قراءة مليار تقرير حول النسخ الاحتياطي لقواعد البيانات ، وقد تمت كتابة مليار مقال ، وليس هناك ما هو جديد هنا ، في الواقع. بشكل عام ، اتبع حلمك ، عيش كما تريد ، ابتكار بعض العكازات المعقدة أيضًا ، ولكن تأكد من التفكير في كيفية حجز كل هذا.
والآن حول كيف ، من حيث المبدأ ، سيكون لدينا عملية التحول إلى موقع النسخ الاحتياطي في حالة نشوب حريق. أولاً ، نقوم بنشر تطبيقات عديمي الجنسية بشكل متوازٍ. لا تؤثر على منطق العمل الخاص بتطبيقاتنا ، مشروعنا ، يمكننا باستمرار الاحتفاظ بمجموعتين من التطبيقات قيد التشغيل ، ويمكنهم البدء في تلقي حركة المرور. من المهم جدًا في عملية التبديل إلى موقع النسخ الاحتياطي معرفة ما إذا كانت التكوينات بحاجة إلى إعادة تعريف؟ على سبيل المثال ، لدينا مجموعة مبيعات kubernetes ، وهناك كتلة احتياطية kubernetes ، وهناك قاعدة بيانات رئيسية خارجية ، وهناك قاعدة بيانات رئيسية احتياطية. لدينا أربعة خيارات لكيفية بدء هذه التطبيقات في prod بالتفاعل مع بعضها البعض. يمكن لقاعدتنا التبديل ، وتبين أننا نحتاج إلى تبديل حركة المرور إلى القاعدة الجديدة في نظام prod ، أو يمكننا الحصول على الكتلة وانتقلنا إلى الاحتياطي ، لكننا نواصل العمل مع القاعدة الاحترافية ، حسناً ، الخيار الثالث ، عندما وصلنا إليها ، ثم يتم تثبيته ، ونحول كلا التطبيقين ، ونعيد تعريف التكوين الخاص بنا حتى تعمل التطبيقات الجديدة بالفعل مع قاعدة البيانات الجديدة.
حسنًا ، في الواقع ، ما هي الاستنتاجات التي يمكن استخلاصها من كل هذا؟
الاستنتاج الأول: العيش بشكل جيد مع احتياطي. لكن مكلفة. لكن من الناحية المثالية ، العيش مع أكثر من احتياطي واحد. من الناحية المثالية ، تحتاج عادة إلى العيش مع العديد من الاحتياطيات. أولاً ، يجب ألا يكون الاحتياطي في العاصمة على الأقل ، وثانيًا على الأقل في مضيف آخر. لقد حدث ذلك غالبًا - وفي ممارستي كان الأمر كذلك. لسوء الحظ ، لا يمكنني تسمية المشاريع ، فقط عندما كان هناك حريق في مركز البيانات ... أنا مثل هذا: نحن نتحول إلى الاحتياطي! وخوادم النسخ الاحتياطي في نفس الرف وقفت ...
أو تخيل أنه تم حظر Amazon في روسيا (وكان ذلك). وجميع: بمعنى حقيقة أن في الأمازون آخر يكمن الاحتياطي لدينا؟ إنه غير متاح أيضًا. لذلك أكرر: نحتفظ بالاحتياطي ، على الأقل ، في منطقة أخرى ، ويفضل مع مضيف آخر.
الاستنتاج الثاني: إذا كان التطبيق الخاص بك يتصل ببعض المصادر الخارجية (يمكن أن يكون إما قاعدة بيانات أو بعض api الخارجية) ، فتأكد من تعريفها كخدمة بنقطة نهاية خارجية بحيث لا تضطر إلى إعادة الإصلاح في وقت التبديل 15 من تطبيقاتك التي تطرق على نفس القاعدة. حدد قاعدة البيانات كخدمة منفصلة ، وطرقها كما لو كانت داخل مجموعتك: إذا كان لديك قاعدة بيانات ، فستغير عنوان IP في مكان واحد وتواصل العيش بسعادة.
وأخيرا: أنا أحب "المكعب" ، وكذلك التجارب عليه. أود أيضًا مشاركة نتائج هذه التجارب ، وبشكل عام ، تجربتي الشخصية. لذلك ، سجلت سلسلة من الندوات عبر الإنترنت حول K8s ، وكذلك في
قناة يوتيوب لدينا لمزيد من التفاصيل.