بطريقة ما في التعليقات ، سألوا السؤال عن كيفية اختلاف المشاركة في Slurm عن قراءة الأدلة على Kubernetes. طلبت من Pavel Selivanov ، المتحدث باسم Slurm-2 و MegaSlurm ، تقديم مثال صغير عما سيقوله على Slurm. أعطي الكلمة له.
أتولى إدارة مجموعة Kubernetes. في الآونة الأخيرة ، كنت بحاجة إلى تحديث إصدار k8s ، بما في ذلك إعادة تشغيل جميع الأجهزة في المجموعة. لقد بدأت العملية في الساعة 12:00 ، وبحلول نهاية يوم العمل كان كل شيء جاهزًا. وللمرة الأولى ، ما زلت أتابع تقدم التحديث ، والمرة الثانية التي غادرت فيها الغداء لمدة 1.5 ساعة (في الإنصاف ، والاستيلاء على جهاز كمبيوتر محمول). تم تحديث المجموعة بنفسها ، دون مشاركتي وبشكل غير مرئي للعملاء ، لم يلاحظ التطوير أي شيء ، واستمرت عمليات النشر ، وعملت الخدمة كالمعتاد.
كيف يبدو.
المشاكل المحتملة
عند إعادة تشغيل الآلات ، هناك سيناريوهان سيئان.
- أطلق المطور تطبيق / redis في حالة واحدة. بغض النظر عن مدى دقة إخراج السيارة من الخدمة ، سيحدث التوقف.
- هناك نسختان طبق الأصل من التطبيق ، ويتم نشر واحدة. خرجت ، كان هناك نسخة طبق الأصل واحدة فقط ، ثم جاء المسؤول وأطفأ النسخة المتماثلة الأخيرة. مرة أخرى ، حتى ترتفع النسخة المتماثلة بعد النشر ، سيكون هناك وقت تعطل.
يمكنني تنسيق إعادة التشغيل مع التطوير ، كما يقولون ، وإيقاف النشر ، والتحقق من الحالات ، وسأعيد تشغيل الأجهزة ، لكني أحب فكرة DevOps التي يجب أن يتم تقليل التواصل البشري إليها. من الأفضل إعداد الأتمتة مرة واحدة بدلاً من تنسيق إجراءاتك في كل مرة.
شروط المهمة
أستخدم أمازون براحتها واستقرارها. كل شيء مؤتمت ، يمكنك إنشاء وإطفاء الأجهزة الافتراضية ، والتحقق من توافرها ، إلخ.
يتم نشر مجموعة Kubernetes وإدارتها وتحديثها من خلال أداة kops التي أحبها حقًا.
عند تحديث kops ، تستنزف تلقائيًا عقدة (عقدة استنزاف kubectl) ، وتنتظر حتى يتم إخلاء كل شيء من هذه العقدة ، وإزالتها ، وإنشاء عقدة جديدة في Amazon مع الإصدار الصحيح من مكونات Kubernetes ، وإرفاقها بالمجموعة ، والتحقق من أن العقدة قد دخلت المجموعة بشكل جيد ، وهكذا مع جميع العقد في دائرة حتى الإصدار المطلوب من Kubernetes في كل مكان.
الحل
في CI ، أستخدم kube-lint للتحقق من جميع القوائم التي سيتم إطلاقها في Kubernetes. يقوم Helm Template بإلقاء كل شيء سيتم إطلاقه ، قمت بتعيين مادة اللبيتر للتفريغ ، والتي تقوم بتقييم كل شيء وفقًا للقواعد المحددة.
على سبيل المثال ، تقول إحدى القواعد أنه بالنسبة لأي تطبيق في مجموعة Kubernetes ، يجب أن يكون عدد النسخ المتماثلة 2 على الأقل.
إذا لم تكن هناك نسخ متماثلة على الإطلاق (والتي يتم تعيينها افتراضيًا على 1) ، فهناك 0 أو 1 منها ، يحظر kube-lint النشر في المجموعة لتجنب المشاكل المستقبلية.
لنفترض أن النشر حسب التصميم مصمم بحيث يكون هناك نسخة متماثلة واحدة فقط. لهذه الحالة ، هناك ميزانية تعطل pod ، حيث يتم تعيين max_unavailable و min_available لتطبيق قيد التشغيل في Kubernetes. إذا كنت تريد دائمًا الحصول على نسخة متماثلة واحدة على الأقل ، فقم بتعيين min_available = 1.
كان هناك نسختان متماثلتان ، وبدأ النشر ، وتوفيت نسخة متماثلة واحدة ، وبقيت 1. على الجهاز حيث تعيش النسخة المتماثلة ، يبدأ المشرف عقدة تصريف kubectl. من الناحية النظرية ، يجب أن تبدأ Kubernetes في إزالة هذه النسخة المتماثلة الحية ونقلها إلى عقدة أخرى. لكن ميزانية تعطيل الجراب تعمل. يقول Kubernetes للمسؤول: عذرًا ، توجد النسخة المتماثلة هنا ، إذا قمنا بحذفها ، فسوف ننتهك ميزانية تعطيل pod. عقدة التصريف الذكية معلقة قبل انتهاء المهلة ويحاول انجراف العقدة. إذا تم الانتهاء من النشر وأصبحت كلتا النسخ المتماثلة متوفرة ، فسيتم عرض النسخة المتماثلة على هذه العقدة.
في MegaSlerme ، سأعرض مجموعة كاملة من القواعد التي تسمح لي بشرب القهوة في مقهى بينما يتم تحديث مجموعة Kubernetes بإعادة تشغيل جميع العقد.
مواضيعي في Slurm :
- إدخال Kubernetes ، المكونات الرئيسية
- جهاز الكتلة ، المكونات الرئيسية ، التسامح مع الخطأ ، شبكة k8s
- ملخصات Kubernetes المتقدمة
- التسجيل والمراقبة
مواضيعي في MegaSlerme :
- داخل عملية نظام مجموعة تجاوز الفشل
- إذن الكتلة باستخدام موفر خارجي
- تطبيقات آمنة ومتوفرة للغاية في المجموعة
- تنفيذ استراتيجيات النشر بخلاف RollingUpdate
- مشاكل في Kubernetes