Kubernetes: إذا كان kubelet غير متاح ، يفشل AttachDetachController في فرض الفصل عند حذف البود

[MILESTONENOTIFIER] المشكلة الرئيسية: محدثة للعملية

verult

• sig/storage : سيتم تصعيد المشكلة إلى SIGs إذا لزم الأمر.
• priority/important-soon : التصعيد إلى مالكي الإصدار ومالك SIG ؛ الخروج من المرحلة الهامة بعد عدة محاولات تصعيد فاشلة.
• kind/bug : إصلاح خطأ تم اكتشافه أثناء الإصدار الحالي.
  
  
  
  

  مساعدة

• تعليمات إضافية
• أوامر لوضع الملصقات

ربما أصبت بحالة مماثلة ولكن ليس نفس الشيء.

التسلسل العام على النحو التالي:

• قم بتكوين volumes.kubernetes.io/controller-managed-attach-detach لجعل وحدة تحكم الإرفاق / الفصل مسؤولة عن عمليتي attaching و detaching كليهما ؛
• أنشئ statefulset مع وحدات التخزين التي يوفرها glusterfs ؛
• استخدم iptables لمحاكاة فشل قسم شبكة العامل الرئيسي. نتيجة لذلك ، لا يستطيع kubelet على العقدة العاملة التحدث ضد apiserver في الوقت الحالي ؛
• يكتشف NodeLifecycleController لاحقًا العقدة التي لا يمكن الوصول إليها ويطرد البودات الموجودة على العقدة التي لا يمكن الوصول إليها ؛
• ستتم إعادة إنشاء الكبسولات التي تم إخلاؤها وجدولتها في عقدة أخرى متوفرة بأحجام سابقة.

تعمل وحدة تحكم الإرفاق / الفصل كما هو متوقع. أستخدم الإصدار 1.9.3 .

orainxiong هل تم تعيين terminationGracePeriod داخل مجموعة الحالة؟

terminationGracePeriod هو 0 إذا كنت أتذكر بشكل صحيح. أعتقد أنه قد يكون السبب الجذري.

@ saad-ali هل يمكننا الحصول على تحديث ما إذا كان شخص ما يعمل على هذه المشكلة؟

يمكنني إلقاء نظرة على هذا

/تعيين

@ saad-ali ، verult وأنا حددت موعدًا لعقد اجتماع للحديث عن هذه المسألة يوم الاثنين 27 أغسطس 11 صباحًا (نيويورك ، الولايات المتحدة الأمريكية).

مرحبًا @ saad-ali و verult وgnufied.

لدي قلق بشأن كيفية إصلاح هذه المشكلة.
فيما يتعلق بتنفيذ https://github.com/kubernetes/kubernetes/pull/67847 \ https://github.com/kubernetes/kubernetes/pull/67419 ، لست متأكدًا من توفير تصميم العلاقات العامة بشكل كافٍ.
كان الحل الذي تم اقتراحه في هذا العلاقات العامة هو الاستفادة من DeletionGracePeriodSeconds بدلاً من استخدام podStatus.ContainerStatuses ( HERE ).

من الجيد عدم الوثوق في podStatus.ContainerStatuses لأنه في سيناريو تحطم عامل ، لا يستجيب kubelet وستظل ContainerStatuses قيد التشغيل إلى الأبد (مما يمنع فصل POD). لذا فإن إضافة DeletionGracePeriodSeconds كمحفز آخر لفرض فصل PVCs من POD غير المستجيب فكرة جيدة.

لكن أعتقد أننا يجب أن نكون حذرين للغاية من فصل القوة عن PVC ، لأنه إذا كان سيناريو انقسام الدماغ (العقدة العاملة لم تتحطم حقًا ، كانت مجرد مشكلة في الشبكة) ولا يزال POD قيد التشغيل وكتابة IO إلى PVC ، مما يؤدي إلى فصل PVC قد يؤدي إلى تلف البيانات.
لذلك ربما يكون من الوحشي للغاية أن تثق في DeletionGracePeriodSeconds (AFAIK الذي يواجه العميل هذه المهلة هو TerminationGracePeriodSeconds وهو افتراضيًا 30 ثانية إذا لم تحدده في مواصفات pod.). لذلك إذا أخذنا تطبيق العلاقات العامة هذا ، فقد يكون هناك تطبيق من شأنه فصل القوة في الدماغ المنقسم وربما لا يستطيع هذا التطبيق التعامل مع مثل هذا الفصل.

أود أن أقترح تطبيق التوقف الذي سيفصله من ناحية عن PODs في سيناريو العقدة المنهارة ، ولكن من ناحية أخرى سيتم توفير ما يكفي أيضًا لسيناريو الدماغ المنقسم.
الاقتراح هو إضافة تعليق توضيحي جديد على مواصفات POD (على سبيل المثال: AllowForceDetachAfterGracePeriod مع خطأ افتراضي) ، وبعد ذلك فقط إذا حدده العميل في مواصفات البود بقيمة حقيقية ،
عندئذٍ ستفرض k8s فصل PODs لهذا POD ، ولكن إذا كانت خاطئة ، فلن يفرض فصل POD - مما يحافظ على السلوك الحالي - لذلك سيتعين على العميل حذف POD يدويًا (قم بذلك بطريقة الحفظ واليدوية منع فقدان البيانات).
لذلك من خلال إضافة تعليق الأمان هذا ، نوفر للعميل القدرة على تحديد ما إذا كان هذا الكبسولة يمكنه التعافي من عملية الفصل. وبعد ذلك ستقوم بملء الحفظ لاختيار هذا الإصلاح لإصدارات k8s الأقدم ، لأنك لن تؤثر على أي سلوك موجود (فقط PODs مع هذا التعليق التوضيحي ستحصل على السلوك الجديد).

أفكار؟
اسمحوا لي أن أعرف ما إذا كان القتل أكثر من اللازم ، أو ربما المدخر للمستخدم لتجنب فقدان البيانات المحتملة.

gnufied وأنا ناقشت هذا في وضع عدم الاتصال. من فضلك صححني إذا كنت مخطئًا ، هيمانت ، لكن حجتك كانت أن تعيين التعليق التوضيحي على "صحيح" يعادل تعيين فترة TerminationGracePeriod عالية جدًا ، مما يؤدي أيضًا إلى "تعطيل" هذا السلوك المنفصل عن طريق تأخيره إلى أجل غير مسمى.

من ناحية أخرى ، نظرًا لأن TerminationGracePeriod الافتراضي هو 30 ثانية ، فلا يمكننا اختيار هذه العلاقات العامة بأمان إلى الإصدارات الأقدم.

أحد الخيارات هو استخدام تعليق توضيحي + DeletionGracePeriod لجميع الإصدارات قبل 1.12 ، وفقط DeletionGracePeriod لـ 1.12 وما بعده.

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

~> kubectl delete pod <foo> --force=true --grace-period=0

هذا يعني أنه سيتعين علينا نقل هذه العلاقات العامة إلى https://github.com/kubernetes/kubernetes/pull/67977 ومن الواضح أننا لا نستطيع backport.

لا تتأثر الإصدارات القديمة من AWS و Openstack و Vsphere بهذا الخطأ بالمناسبة - لأنه في موفري السحابة يتم حذف العقدة عند إيقاف التشغيل. لم يتم تغيير هذا السلوك إلا مؤخرًا في موفري الخدمات السحابية ولم يعد يتم حذف كائن العقدة ، وبالتالي تظل البودات في مرحلة "غير معروف" ولم يتم فصل وحدة التخزين

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

أنا لا أحب خيار التعليق التوضيحي هذا كثيرًا tbh. من الصعب التوثيق ومن السهل تفويته ولأنه تغيير في واجهة برمجة التطبيقات ، يجب أيضًا أن يمر بمراحل ألفا وبيتا. متفقًا على أن - https://github.com/kubernetes/kubernetes/pull/67977 ميزة حاليًا هي بوابة أيضًا ولكن لا أرى سببًا قويًا لضرورة أن تكون هذه الميزة مسورة. cc yastij

gnufied - تعتمد بعض مجموعات الإنتاج على عمليات إعادة التشغيل السريعة (أي إعادة التشغيل ولا تزال بها أقراص مرفقة). قد نرغب في منحهم بعض النطاق الترددي للانتقال.

yastij لا ينبغي أن

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

أتفق مع gnufied على التعليقات التوضيحية.

تتمثل الخطة في الترويج لهذا الإصدار التجريبي على 1.13. من خلال ما أراه ، فإن مهلة الإخلاء تؤثر على جميع الكبسولات التي قد تكون صعبة: بالنسبة للمجموعات المتشددة ، لا يعمل هذا نظرًا لأن مهلة الجراب وفترة السماح للعقد أقل من المعتاد. تضمن هذه النافذة (إصدار واحد) أن كل شيء يسير بسلاسة.

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

أتفق مع gnufied ، يجب أن نتجنب إضافة تعليق توضيحي آخر - كلما كان هناك سؤال كهذا ، فإن عرض الخيار للمستخدم النهائي هو أسهل طريقة للخروج ، ولكن ليس بالضرورة الأفضل. يجب أن نحاول أن نكون أذكياء ونفعل الشيء الصحيح تلقائيًا نيابة عن المستخدم.

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

سأترك الأمر لكم يا رفاق لوزن تلك المقايضات.

gnufied في الواقع في العقد المفتوحة لم تعد تُحذف بعد الآن. https://github.com/kubernetes/kubernetes/pull/59931 هذا يعني بشكل أساسي أنه في Openstack إذا قمت بإغلاق مثيل يحتوي على pod مع pvc ، فلا يمكن تجاوزه إلى مثيل آخر.

ومع ذلك ، # 67977 سيصلح هذه المشكلة

لقد تحدثت للتو إلى yastij أنه يجب علينا استخدام بوابة الميزة فقط لفصل التأخير. بعد ذلك ، يمكنه فصل وحدات التخزين في Openstack مرة أخرى ، إذا تم تشغيل بوابة الميزة ، فسيكون التأخير مثل 1 دقيقة وإذا لم يتم تشغيله ، فإن تأخير الفصل هو ما يعادل 8-10 دقائق.

أنت على صواب كما هو الحال في AWS ، فهذه المشكلة غير موجودة ولكن إذا تمت الموافقة على # 59930 (كما ينبغي لأن السلوك والمواصفات السحابية الأخرى هي أنه لا ينبغي حذف العقد). ثم تحصل AWS على هذه المشكلة أيضًا إذا لم تتم الموافقة على # 67977.

بعض الملاحظات التي أخذتها خلال اجتماع المؤتمر اليوم ( @ verult يرجى إضافة ملاحظاتك أيضًا):

• يجب أن يكون PRs https://github.com/kubernetes/kubernetes/pull/67847 ، https://github.com/kubernetes/kubernetes/pull/67419 معلقًا ، نظرًا للمخاطر المحتملة في حالة الدماغ المنقسم. وفي الوقت الحالي ، سيتعين على المستخدم حذف البودات يدويًا من العقدة المعطلة أو حذف كائن عقدة التعطل من أجل تشغيل عملية فصل PVC.

• لا يزال PR https://github.com/kubernetes/kubernetes/pull/67977 في مكانه ، لأنه سيسمح بفصل PVCs من العقدة مع nodeShutdown taint. لكنه ينطبق فقط على برامج تشغيل مزود السحابة.

• تم فتح تذكرة https://github.com/kubernetes/kubernetes/issues/68086 لجعل maxWaitForUnmountDuration كقيمة قابلة للتكوين (بدلاً من 6 دقائق مشفرة).

• لا يوصى باستخدام التعليق التوضيحي للقرص للإشارة إلى فرض فصل وضع PVC.

هل لدينا أي فكرة عن الإطار الزمني لحل هذه المشكلة؟ سيكون تجميد الكود في الأسبوع المقبل ، وعند هذه النقطة لن يُسمح إلا بالأخطاء الحرجة / العاجلة في الإنجاز.

شكرا لك! :)

@ shay-berman PR # 67977 يجب أن يظل معلقًا لأنه بدون المعالجة الفعلية للبودات من عقد إيقاف التشغيل ، فإن PR # 67977 ليس له أي تأثير على الإطلاق. لا يزال لن يتم فصل وحدات التخزين من عقد إيقاف التشغيل.

يارب احفظها

gnufied نعم لديها؟ لنفترض أن لدينا عقدتين: العقدة 1 والعقدة 2. ثم لدينا عملية نشر تسمى foobar والتي تحتوي على مادة PVC. يعمل foobar الآن في node1 ، ثم يتم إيقاف تشغيل node1.

والنتيجة هي أن node1 foobar pod ينتقل إلى حالة غير معروفة ويتم فصل الحجم باستخدام خطأ تعلق وحدة التخزين. سيبدأ حجرة foobar في العقدة 2 ويتم إرفاق الحجم (يستغرق هذا الآن ما يزيد قليلاً عن دقيقة واحدة). ماذا يحدث عندما يعود node1؟ سيؤدي فقط إلى إنهاء جراب foobar في العقدة 1 ولن يتلامس مع وحدات التخزين بعد الآن.

لقد اختبرت ذلك للتو :)

zetaab ، ماذا يحدث إذا لم يتم إغلاقها؟
أي ، الحاوية التي تستخدم PVC تعمل وتكتب إلى PVC.
يواجه التواصل مع kubelet مشكلة لمدة ساعة ، ثم يعود.

zetaab الخطأ المتدلي يجب أن يضيف فقط حجمًا إلى الحالة الفعلية للعالم للتعامل مع حالة حالات البود الفائتة. في حد ذاته - لا ينبغي أبدًا أن يتسبب في حدوث انفصال في الحجم. إذا حدث ذلك ، فمن المحتمل أن يكون لدينا خطأ. لقد اختبرت سيناريو مشابهًا على AWS مع أحدث تصحيح (https://github.com/kubernetes/kubernetes/pull/66835) يمنع حذف كائن العقدة ولا يتم فصل وحدات التخزين.

إذا تم فصل وحدات التخزين المفتوحة من عقد إيقاف التشغيل مع استمرار وجود كائنات البود ، فسأسميها السحر / الخطأ. :-)

itamarh مثل لقد علقت على أن العلاقات العامة لا تفعل أي شيء إذا كانت هناك مشكلة في الاتصال (لا تلوث). يبدأ Kubernetes نفسه في الإخلاء (لدي وقت إخلاء مدته دقيقة واحدة) ، لذلك بعد دقيقة واحدة سيحاول إنشاء حجرة إلى عقدة أخرى. ومع ذلك ، نظرًا لعدم فصل الحجم ، لا يمكن البدء.

لا أعرف ما إذا كان يجب أن يفرض محرك الأقراص في حالة حدوث مشكلة في الاتصال أم لا. كان السلوك قبل تغييرات Cloudprovider هو أنه سينتظر 6 دقائق قبل فصل القوة.

gnufied من الغريب بعض الشيء أن يتم طرد القرون إلى عقدة أخرى؟ هل ينبغي لبعض أجهزة التحكم في البود التحقق من "هل هذا يحتوي على وحدات تخزين عالقة في العقدة"؟

دعنا نفكر في السيناريو التالي: لدي جراب مع pvc الموجود في العقدة 1 ، تتعطل هذه العقدة ولا يمكن أن تبدأ بعد الآن. كيف يجب أن تتصرف kubernetes؟

السيناريوهات المحتملة:

• لا تفعل شيئًا: انتظر حتى يأتي المسؤول متصلاً بالإنترنت (يمكن للمسؤول على سبيل المثال فصل وحدة التخزين يدويًا ، ثم يبدأ البود في عقدة أخرى. أو يمكنه فقط حذف الجهاز المعطل ، ويتم فصل وحدة التخزين. يمكن للأتمتة أيضًا حذف الأجهزة؟)
• فصل محرك الأقراص في 6 دقائق: أعتقد أن هذا كان السلوك قبل تحديثات Cloudprovider؟
• ؟

فقط لإضافة ما كتبه @ shay-berman المناقشة الكاملة هي كما يلي:

1. يجب أن يكون كل من https://github.com/kubernetes/kubernetes/pull/67977 و https://github.com/kubernetes/kubernetes/pull/67847 معلقًا في الوقت الحالي. لأننا اكتشفنا أن # 67977 لن يكون لها أي تأثير إذا لم تتم إزالة البود من DSWP (الحالة المرغوبة في العالم).

2. السبب في اختيارنا لوضع https://github.com/kubernetes/kubernetes/pull/67847 قيد الانتظار هو أن أي قيمة توقيت نقررها لفصل وحدة التخزين عن الكبسولة في مرحلة "غير معروف" غير آمنة بشكل أساسي. كانت هذه توصية من derekwaynecarr و liggitt أيضًا.

3. ناقشنا أيضًا إمكانية استخدام تلوث "إيقاف التشغيل" لإزالة القرون من DSWP. الفكرة الأساسية هي - إذا كانت العقدة بها تلوث "إيقاف التشغيل" ، فيمكن إزالة جميع حواجزها التي تم إنهاؤها بالكامل أو التي تحتوي على مجموعة DeletionTimeStamp من DSWP وبالتالي فصل المشغل. تكمن مشكلة القيام بذلك في وحدة تحكم الإرفاق / الفصل في - يجب أن تستخدم وحدة التحكم المرفقة / المنفصلة حالة البود كمصدر وحيد للحقيقة لإجراء عمليات الفصل. تمت الإشارة إلينا أن المجموعات ذات الحالة والقرون المدعومة من وحدة التحكم في النسخ قد تحتاج إلى غلاف خاص ، وبالتالي إذا كان يجب فصل وحدات التخزين عن العقدة التي تم إغلاقها ، فيجب أن يعتمد هذا القرار على حالة البود ويجب أن يأتي من وحدة تحكم دورة حياة العقدة / البود . على سبيل المثال - في المستقبل ، قد يقوم جهاز التحكم في دورة حياة العقدة بوضع علامة على حاويات الكبسولة الموجودة على عقدة إيقاف التشغيل / إيقاف التشغيل على أنها منتهية / غير قيد التشغيل ، وبالتالي فإن وحدة تحكم / فصل وحدة التحكم ستفصل وحدات التخزين عنها تلقائيًا. derekwaynecarr كانliggitt بعض النقاط صالحة ضد خاص غلاف هذا في إرفاق / فصل وحدة تحكم.

@ shay-berman ، العلاقات العامة التي كنا سنحتفظ بها هي تلك التي تم دمجها بالفعل ، والتي تقدم تلطيخ إغلاق العقدة: https://github.com/kubernetes/kubernetes/pull/59323

لقد أرسلت ملاحظات الاجتماع الخاصة بي إلى تخزين SIG. اسمحوا لي أن أعرف إذا كنت تواجه مشكلة في الوصول (سلاك الخاص بي هو cxing). أعتقد أنك بحاجة إلى أن تكون عضوًا في SIG Storage للوصول.

https://groups.google.com/forum/#!forum/kubernetes -sig-storage

@ jingxu97 @ msau42 و @ random-liu من sig-node تمت مناقشته في وضع عدم الاتصال حول احتمال وجود وحدة تحكم ذات مستوى أعلى لفرض حذف جراب. تتمثل إحدى المشكلات المحتملة في احتمال وجود حالة سباق إذا عادت العقدة مرة أخرى بعد فترة وجيزة.

تخيل أن لدينا جراب StatefulSet يحتوي على وحدة تخزين غير قابلة للإلحاق ، وافترض أن عقدة الإغلاق عادت إلى الأعلى مباشرة قبل حذف الكبسولة بالقوة. يرى Kubelet على العقدة أن الكبسولة لا تزال مجدولة عليها وتبدأ الحاويات. ثم يتم حذف الكبسولة بالقوة ، ويتم تشغيل جراب جديد على عقدة مختلفة. الآن هناك فرصة لأن نفس الحاويات تعمل على كلا العقدتين.

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

هل الرغبة هنا في التعامل مع إغلاق العقدة عن قصد دون إنهاءها ، ودون تطويقها / تصريفها ، مع استمرار نقل أعباء العمل والكميات بسرعة إلى عقدة أخرى؟

liggitt - نعم ، قد يغطي أيضًا إغلاق عقدة عندما قد تحتاج إلى ترحيلها وإعادة نشرها.

للإغلاق المتعمد للعقدة ، كيف لا يمكن إجراء استنزاف العقدة؟

@ msau42 - في الواقع يجب أن يكون كذلك. تغطي الميزة كلاهما على أي حال.

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

إنها مناقشة طويلة. أعتقد أن لدينا العديد من القضايا التي تم تناولها هنا ،

عندما لا يستجيب kubelet ، تكون حالات الكائنات التالية كما يلي ،
العقدة : حالة العقدة غير معروفة
جراب: في محاولة لنزع جراب بعد (5) دقائق. لن ينجح إخلاء القرنة عادةً لأن kubelet لن يستجيب وسيظل كائن pod في خادم api. سيؤدي هذا إلى فشل مجموعة الحالة في بدء جراب جديد.
وحدة التخزين : لن تقوم وحدة التحكم attach_detach بفصل وحدة التخزين لأن الحاوية لا تعتبر منتهية (حالة الحاوية لا تزال قيد التشغيل). سيؤدي ذلك إلى عدم قدرة وحدة التخزين على الارتباط بعقدة مختلفة.

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

الآن لدينا عقدة مغلقة متاحة. عندما تكتشف وحدة التحكم في العقدة السحابية أن العقدة في حالة إيقاف التشغيل ، فإنها ستلوث العقدة بشرط الإغلاق. يحاول PR https://github.com/kubernetes/kubernetes/pull/67977 استخدام هذا الخطأ لإصلاح مشكلة فصل وحدة التخزين.
بعد المناقشة مع yastij ، يمكننا تنفيذ العمل التالي

1. تحديث حالة العقدة لوحدة التحكم في العقدة لإزالة volumeInUse بعد إيقاف تشغيل العقدة ، (يمكن أيضًا وضع علامة على عدم تشغيل الحاوية)
2. سيحاول Attach_detach controller فصل وحدة التخزين إذا لم تعد وحدة التخزين قيد الاستخدام (تمت إزالة volumeInUse من حالة العقدة بالخطوة 1) بدون مشكلة (يمكن أن يمر بفحص safeToDetach الآن).

أعتقد أنه يمكن اعتبار https://github.com/kubernetes/kubernetes/pull/67977 بمثابة إصلاح للأخطاء بدلاً من ميزة. إنها تستخدم عقدة مغلقة تم إدخالها مؤخرًا (وهي ليست ذات بوابات). لن يحل مشكلة pod عدم حذفه من apiserver ، ولكن يمكنه فصل الحجم بشكل صحيح. فهل يمكننا دفع هذا العلاقات العامة أولاً ثم الخروج ببعض الحلول لمشكلة حذف البودات أثناء إغلاق العقدة؟ شكر!

أعتقد أنه يمكن اعتبار # 67977 بمثابة إصلاح للأخطاء بدلاً من ميزة. إنها تستخدم عقدة مغلقة تم إدخالها مؤخرًا (وهي ليست ذات بوابات). لن يحل مشكلة pod عدم حذفه من apiserver ، ولكن يمكنه فصل الحجم بشكل صحيح. فهل يمكننا دفع هذا العلاقات العامة أولاً ثم الخروج ببعض الحلول لمشكلة حذف البودات أثناء إغلاق العقدة؟

إجراء أخطاء محددة لإبلاغ وحدة تحكم "فصل القوة" بدلاً من منطق الجدولة / الإخلاء لا يبدو آمنًا. التنسيق حول وجود كائن البود هو ما توقعته.

هل هناك سابقة لاستخدام التلوث بهذه الطريقة؟

يعتبر تلوث الإغلاق الذي يُعلم بحالة تشغيل الحاوية أكثر منطقية ولكنه لا يزال مفعمًا بالحيوية

إذا لم يتم حذف كائن Pod ، فلن تتمكن StatefulSet من إعادة إنشاء جراب بديل.

تحديث حالة العقدة لوحدة التحكم في العقدة لإزالة volumeInUse بعد إيقاف تشغيل العقدة ، (يمكن أيضًا وضع علامة على عدم تشغيل الحاوية)

هل هذا قبل أو بعد إصدار المجلدات بالفعل؟ لأن فشل kublet بعد إضافة الصبغة وقبل تحرير وحدات التخزين سيظل يمثل مشكلة.

لدي خبرة في أنظمة HA التقليدية أكثر بكثير مما لدي مع k8s ، ولكن أحد المبادئ الأساسية في العالم القديم هو أنك لا تعرف ما لا تعرفه. يمكنك استخدام الاستدلال ووضع افتراضات ، لكن في بعض الأحيان سيكونون خاطئين ويعتمدون على عبء العمل الذي قد يكون مشكلة.

TL ؛ دكتور - أود أن أدافع عن حل هذا من خلال نهج المبارزة المتكامل بدلاً من الاستدلال

لقد بحثنا في أفضل طريقة لدمج مفهوم السياج في k8s لبعض الوقت بسبب نوع السيناريو الموضح هنا بالضبط. المبارزة ليست دائمًا مفهومًا شائعًا ، لكني أحب أن أفكر في المبارزة كطريقة لتحويل السؤال "هل سيتسبب X في الفساد أو فقدان البيانات)؟" في إجابة "لا" ، مع تمكين الاسترداد الآلي في إطار زمني محدد.

هدفنا الحالي هو إعادة استخدام عناصر مثل كاشف مشكلة العقدة وواجهات برمجة تطبيقات الكتلة / الآلة قيد التقدم لإنشاء إصدار أكثر تميزًا من https://github.com/kubernetes-sigs/cluster-api/blob/master /tools/repair/util/repair.go

نظرًا لأن هذا أصبح موضوعيًا ، فأنا أدرج وصفًا أكثر تصميم سياج العقدة .

[*] في سياقنا ، يرتبط هذا الموضوع أيضًا بالمخاوف المتعلقة بضمان أن يكون التصميم مناسبًا للمعادن العارية. هذا في الغالب متعامد مع المفهوم والحاجة إلى السياج وكذلك منطق الاسترداد الذي نتطلع إلى إنشائه.

التنسيق حول وجود كائن البود هو ما توقعته.

+1 اترك وحدة التحكم a / d غبية - وتفاعل مع حالة الجراب.

TL ؛ دكتور - أود أن أدافع عن حل هذا من خلال نهج المبارزة المتكامل بدلاً من الاستدلال

يبدو أنه النهج الصحيح. قم بتحسين المنطق لتحديد حالة العقدة وتحديث حالة البود وفقًا لذلك ، ويمكن أن يتفاعل a / d (ووحدات التحكم الأخرى) وفقًا لذلك.

السؤال هو ، متى سيتم إصلاح هذا الخطأ ، إذا تم احتجاز / رفض العلاقات العامة الواحدة تلو الأخرى كثيرًا؟ هذا الخطأ حرج للغاية ، لذلك يستحق IMHO أن يتم إصلاحه في أسرع وقت ممكن ، حتى لو لم يكن الحل مثاليًا.

أود أيضًا أن أقترح ، أنه من المحتمل أن تكون معظم برامج تشغيل وحدة التخزين الموزعة / المنسوخة على الشبكة قادرة على تحديد ما إذا كانت وحدة التخزين آمنة للفصل من العقدة المحددة ، لأنها "تعرف" العملاء (العقد) التي لا تزال متصلة بها خادم / الكتلة التخزين. لذلك إذا كانت العقدة معطلة (أو تم فصلها فقط) ، يمكن لبعض برامج تشغيل الحجم توفير هذه المعلومات لـ k8s. أرجوا أن تصحح لي إذا كنت مخطئا.

adamplyastijnikopen باعتبارها الحل المؤقت، هل من الممكن أن يكتب وحدة تحكم خارجي الساعات لهذه العقدة العيب اغلاق والقوة حذف القرون على هذه العقدة؟ لقد أصبح من الواضح أن الاستجابة على وجه التحديد لعيوب إيقاف تشغيل العقدة في وحدة التحكم في الإرفاق / الفصل أمر صعب ولن يساعد في ضبط حالة البودات ، لذلك ليس الحل الذي نريد متابعة متابعته.

@ msau42 وإذا كان مصدرًا خارجيًا ، فأنت تقصد مثل pod يعمل في kubernetes والذي سيشاهد تلوث العقدة ويتفاعل وفقًا لذلك؟ كيف يمكننا توجيه الجميع لتثبيته؟ أو وحدة تحكم جديدة داخل kubernetes؟

نعم ، يمكن تشغيله كجراب في kubernetes. سيحتاج التوزيعة / المزود إلى تقديم إرشادات حول كيفية تشغيله.

ستكون مشكلة مماثلة إذا قمنا ببوابة ألفا لحل بديل في الشجرة. ستحتاج إلى إرشاد المستخدمين لتمكين بوابة الميزات.

@ msau42liggitt @ سعد علي - هل نريد لإصلاح هذا عن 1.12؟ إذا كانت الإجابة بنعم ، فيمكننا تقديم استثناء لهذا والبدء في التفكير في تصميم إخلاء مشوه.

شكرا على كل المناقشة. الإصلاح الذي اقترحته في هذا التعليق https://github.com/kubernetes/kubernetes/issues/65392#issuecomment -417509512 ليس فصلًا عن القوة في الواقع.
عندما تكون العقدة ملوثة بـ "إيقاف التشغيل" ، فنحن على يقين من أن الحوامل قد اختفت وأن الحاويات لم تعد تعمل. من الآمن لوحدة التحكم في العقدة تحديد حالة الحاوية وإزالة معلومات VolumeInUse من حالة العقدة (ملاحظة: يُستخدم حقل VolumeInUse للإشارة إلى وحدات التخزين التي يتم تركيبها / تركيبها بحيث تتجنب حالة السباق بين الرئيسي و kubelet للفصل بينما لا تزال مثبتة) .
الآن لا تحتاج وحدة التحكم attach_detach إلى أي تغيير على الإطلاق. عندما يتم طرد البود بواسطة وحدة تحكم العقدة ، نظرًا لأن حالة الحاوية لم تعد تعمل لفترة طويلة ، فإن وحدة التحكم attach_detach ستتحقق أولاً مما إذا كان من الآمن فصلها ثم محاولة فصلها لأن حالة العقدة توضح أن وحدة التخزين لم تعد مثبتة.
لذلك أعتقد أن هذا الإصلاح آمن.

يمكن أن يساعد الاقتراح @ msau42 أيضًا في حل المشكلة. ولكنه قد يتسبب في حدوث حالة سباق أثناء الحذف بالقوة. إذا حدث إعادة تشغيل عقدة الإغلاق في هذه اللحظة. قد يحدث الفصل أثناء تصاعد الحجم. يرجى إعلامي إذا كان لديك أي أسئلة حول الإصلاح أو أي مخاوف. شكر!

عندما تكون العقدة ملوثة بـ "إيقاف التشغيل" ، فنحن على يقين من أن الحوامل قد اختفت وأن الحاويات لم تعد تعمل. من الآمن لوحدة تحكم العقدة تحديد حالة الحاوية وإزالة معلومات VolumeInUse من حالة العقدة

قد يكون هذا مشكلة بالنسبة للمجموعات ذات الحالة. دعنا نقول إن جرابًا مدعومًا بمجموعات ذات حالة تعمل على العقدة X. العقدة مغلقة وهي ملوثة. يتم وضع علامة على حاويات الكبسولة على أنها "NotRunning" ويتم فصل وحدة التخزين عن العقدة X. الآن عندما تعود العقدة X - لن تتمكن المجموعة المدعومة بالحالة من العمل عليها. afaict - لن تكون هناك أحداث جديدة متعلقة بالجراب ، وبالتالي فإن إرفاق / فصل وحدة التحكم لن يعيد توصيل وحدة التخزين مرة أخرى.

@ jingxu97 @ dchen1107 وأنا

كحل قصير المدى ، إذا كنت حقًا بحاجة إلى هذا السلوك ، فنحن نقترح عليك حل:
1) جعل مهلة فصل القوة في وحدة تحكم A / D قابلة للتكوين. شخص ما يحتاج إلى إنشاء علاقات عامة لهذا تجميد الكود.
2) استخدام وحدة تحكم خارجية تفرض حذف السنفات على عقدة تم إيقاف تشغيلها.

فقط احذر من أن كلا الحلين يمكن أن يزيدا من خطر فصل وحدات التخزين عندما لا تزال مثبتة.

فقط لكي نكون واضحين "جعل فصل القوة قابل للتكوين" لن يفعل شيئًا لتغيير منطق فصل الحجم. سيؤدي ذلك فقط إلى الفصل بشكل أسرع عندما يتم حذف البود بالفعل.

@ msau42 الآن عندما لا يتم حذف العقد بعد الآن من المجموعة (تغيير Cloudprovider في السلوك في معظم السحب) ، لا يهم تكوين مهلة الفصل هذه. القرون لا يمكن أن تتحرك بعد الآن. السلوك هو هذا https://github.com/kubernetes/kubernetes/pull/67977#issuecomment -417233035

إذا كنت أتذكر بشكل صحيح السلوك القديم قبل تغيير Cloudprovider هو أنه بعد انتهاء مهلة فصل القوة ، تم فصل محرك الأقراص وتمكن الكبسولة من التحرك.

لذلك بدون وحدة التحكم الخارجية قد نرى بعض بطاقات الأخطاء حول هذا

كان السلوك السابق هو أنه عندما يتم حذف كائن Node ، فإن أداة تجميع البيانات المهملة ستفرض حذف البودات على تلك العقدة. الآن بعد أن لم يتم حذف كائن Node بعد الآن ، لا يوجد شيء لفرض حذف البودات. (سوف تقوم وحدة التحكم في العقدة بطرد البودات بعد 5 دقائق من عدم استجابة kubelet ، ولكنها ليست عملية حذف بالقوة). لذا فإن هذا الحل البديل لوحدة التحكم الخارجية هو محاكاة هذا السلوك المماثل كما لو تم حذف كائن العقدة ، مع زيادة خطر عودة العقدة بالفعل.

أسترجع توصيتي لجعل القوة قابلة للفصل وتقصيرها. لأنه سيؤثر على فصلنا عندما تظل آلية الأمان مثبتة حتى في سيناريوهات إنهاء البودات العادية.

لذلك مع حل وحدة التحكم فقط ، سيتم فصل الصوت بالقوة بعد 6 دقائق من حذف الكبسولة.

لذلك يبدو أن:

يوفر Shutdown taint + InstanceShutdownByProviderID القدرة على التمييز بين إيقاف التشغيل و kubelets غير مستجيب عن طريق تحديد عمليات الإغلاق بشكل صحيح ، والتحقق من حالة "آمن للحذف / الفصل".

ومع ذلك ، يتم تنفيذ "ISBPID" حاليًا فقط من أجل AWS و Openstack ، ومن المحتمل ألا يصل الباقي إلى 1.12 (؟).
وما ورد أعلاه لا يمكن أن يغطي المعدن على الإطلاق.

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

@ msau42 أفكر في السلوك التالي لوحدة التحكم الخارجية "المؤقتة":

حالة إغلاق العقدة (عند تنفيذ taint وعملها):

1. فرض حذف جميع البودات بعد مهلة قصيرة (على سبيل المثال 5 ثوانٍ)

حالة kubelet غير مستجيبة:

1. اصطياد الكوبيليت غير المستجيب
2. تأكد من بقائه غير مستجيب عدة مرات على مدار X دقيقة (على سبيل المثال ، حالة الاستطلاع كل 20 ثانية لمدة 4 دقائق)
3. إذا كان لا يزال معطلاً بعد انتهاء المهلة القصوى ، فقم بحذف جميع القرون المرتبطة به.

ما سبق يمكن أن يكون آمنًا نسبيًا. إذا كان هناك شيء آخر يمكن أن يجعله أكثر أمانًا ، فسيكون من الجيد إضافته. يمكن البدء في العمل عليه قريبًا.

يمكن أن يكون أمان الأعطال الإضافي المخصص عبارة عن جراب جانبي للقرون ذات وحدات تخزين و / ومجموعات StatefulSets التي تتحقق مما إذا كانت البود الرئيسي نشطًا / يقرأ ويكتب من وحدة التخزين على فترات. إذا لم يكن الأمر كذلك ، فيمكنه التحدث إلى وحدة التحكم والتحقق من أمان الحذف والفصل. نرحب بأي اقتراحات

بالنسبة لـ 1.13 وما بعده ، سيكون من الرائع تكوين فريق لتقديم حل قوي بشأن فصل الحجم على العقد المنسدلة على المدى الطويل ، من خلال التعامل مع المزامنة / استخدام السياج / غير ذلك.

تضمين التغريدة

ما سبق يمكن أن يكون آمنًا نسبيًا

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

• انقطاع الشبكة أو التكوين الخاطئ ، ما لم يكن kubelet يستخدم نفس المسار مثل وحدة التخزين وتتطلب عمليات الكتابة تأكيدًا شاملاً
• قبيبات إسفين

يمكن أن يكون أمان الأعطال الإضافي المخصص عبارة عن جراب جانبي للقرون ذات وحدات تخزين و / ومجموعات StatefulSets التي تتحقق مما إذا كانت البود الرئيسي نشطًا / يقرأ ويكتب من وحدة التخزين على فترات. إذا لم يكن الأمر كذلك ، فيمكنه التحدث إلى وحدة التحكم والتحقق من أمان الحذف والفصل. نرحب بأي اقتراحات

إذا كانت وحدة التحكم محلية ، فستتمكن من الوصول إليها أثناء انقطاع الشبكة ولكن من المفترض ألا يكون لديها أي معرفة إضافية بـ verify that it's safe to delete & detach .

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

يؤدي استخدام وحدة تحكم خارجية تفرض على حذف السنفات على عقدة تم إيقاف تشغيلها.

@ msau42 @ jingxu97 IIUC، shutdown هنا يعني أن العقدة ملوثة؟ ماذا عن الأحجام في العقد المعدنية التي لا تتم إدارتها من قبل موفري السحابة؟

NickrenREN - يجب القيام بذلك بواسطة بعض

لذلك نحن بحاجة إلى اقتراح مفصل وكامل لهذا الغرض.
أي ارتباط تصميم أو اقتراح لهذا؟ yastij

beekhof إذا كان https://github.com/kubernetes/kubernetes/issues/65392#issuecomment -417880760 - إذا ظل kubelet غير مستجيب ، فيجب أن تهاجر القرون إلى مكان آخر على أي حال.

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

من الناحية المثالية ، يكون برنامج تشغيل التخزين نفسه قادرًا على توفير المعلومات "الآمنة للفصل".
قد تكون قائمة موفري السحابة وبرامج تشغيل التخزين القادرة على القيام بذلك مفيدة للغاية.

في الإعدادات التي لم يكن ذلك ممكنًا فيها حتى الآن ، يمكن للعربة الجانبية المحلية التعامل معها كوظيفة إضافية أعلى وحدة التحكم الخارجية الرئيسية: إذا كان الجهاز المحلي / الجانبي غير قادر على التحدث إلى وحدة التحكم + kubelet ميت + جراب المشكلة هو غير نشط ، ثم فرض الحذف / التدمير الذاتي للقرن. قد تتضمن أجزاء التحقق الخاصة بفحص "عدم النشاط" بعض المتطلبات / الواجهات للتحدث إليها ، على سبيل المثال على الأقل في جبال الألب للقرون ذات الأحجام. يمكن تحسين هذا الحل بشكل كبير.

عندما يكون معظم موفري الخدمات السحابية وبرامج تشغيل التخزين قادرين على إعطاء حالة "الفصل الآمن" ، يجب أن يكون منطق الفصل الآمن أسهل في دمجه في كود k8s / CP نفسه.

NickrenREN @ msau42 كما أرى ، هناك الكثير من الالتباس في تلوث الإغلاق ، ووفقًا لـ https://github.com/kubernetes/kubernetes/issues/58635#issuecomment -397771924
لم يتم تنفيذ InstanceShutdownByProviderID حتى الآن في معظم موفري السحابة ، فهل ستصل إلى 1.12؟

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

nikopen https://github.com/kubernetes/kubernetes/pull/67977#issuecomment -416836342 إنه موجود في الوقت الحاضر في كثير جدًا.

أزور https://github.com/kubernetes/kubernetes/pull/68033

gce مفقود ، لكن اللاعبين الكبار الآخرين يمتلكون ذلك

إذا ظل kubelet غير مستجيب ، فيجب أن تهاجر القرون إلى مكان آخر على أي حال.

nikopen @ لكن كيف يمكنك ترتيب ذلك أو تأكيد حدوثه دون التمكن من التحدث إلى kubelet؟

في معظم الحالات ، يمكن لـ k8s تدوير السنفات البديلة بغض النظر ، ولكن يجب أن تنتظر مجموعات StatefulSets و Pods ذات الأحجام الثابتة حتى عودة kubelet أو يؤكد شيء ما أنه آمن. وإلا فهناك خطر حقيقي من الفساد.

beekhof إذا علمنا أن العقدة مغلقة (ملوثة) ، فمن الآمن دائمًا فصلها ، على الرغم من أن kubelet لا تستجيب. kubelet غير المستجيبة (في حين أن العقدة ليست ملوثة بسبب الإغلاق) هي حالة مختلفة تحتاج إلى حل أكثر تعقيدًا. يجب إصلاح هاتين الحالتين IMHO بشكل منفصل ، لذلك لا يتم حظر الأولى من قبل الثانية.

يتم بالفعل التعامل مع kubelet غير المستجيب بواسطة وحدة التحكم في العقدة ، والتي تطرد القرون (وليس الحذف القسري) بعد 5 دقائق.

لا أعتقد أن إغلاق العقدة يمكن أن يكون مضمونًا بنسبة 100٪ ليكون آمنًا لفصل وحدة تخزين ، ولهذا السبب أعتقد أن فرض حذف الكبسولة بعد مهلة قصيرة أمر غير آمن. إغلاق العقدة هو حالة مؤقتة فقط. ماذا لو كانت العقدة تعيد التشغيل وتعود بسرعة؟

@ msau42beekhofverult

يجب أن تكون هذه المشكلة priority/critical-urgent لتظل في المرحلة 1.12. هل يمكنك التحقق والفرز؟

ccchildsb @ saad-ali

يتم بالفعل التعامل مع kubelet غير المستجيب بواسطة وحدة التحكم في العقدة ، والتي تطرد القرون (وليس الحذف القسري) بعد 5 دقائق.
@ msau42 إذا كان kubelet غير مستجيب ، فكيف يمكن طرد البودات من العقد لعدم الاستمرار والكتابة إلى التخزين

لا أعتقد أن إغلاق العقدة يمكن أن يكون مضمونًا بنسبة 100٪ ليكون آمنًا لفصل وحدة تخزين ، ولهذا السبب أعتقد أن فرض حذف الكبسولة بعد مهلة قصيرة أمر غير آمن. إغلاق العقدة هو حالة مؤقتة فقط. ماذا لو كانت العقدة تعيد التشغيل وتعود بسرعة؟
لا ينبغي أن يؤدي إيقاف تشغيل العقدة إلى تحرير PV / PVC. يجب أن تسمح العقدة المعروفة بإغلاقها بفرض حذف الكبسولة ، مما يؤدي إلى تحرير التخزين؟

@ msau42 يفرق بين إيقاف التشغيل وإعادة التشغيل على مستوى Cloudprovider ، أي الذهاب إلى طريقة cloudprovider.

قم بتلطيخ إيقاف التشغيل فقط عند إصدار VM إشارة واضحة "إيقاف التشغيل"
أو
استطلع رأي حالة الجهاز الافتراضي لمسافة 1 م. لا ينبغي أن يكون في "حالة إيقاف التشغيل" لأكثر من ذلك عند إعادة التشغيل.

تقوم وحدة التحكم التي تراقب تلوث الإغلاق بإصدار تصريف العقدة ، مما يؤدي إلى تشغيل وحدة التحكم المرفقة أيضًا. يمكن أن يكون هذا على وحدة تحكم العقدة.

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

قد يكون من الصعب جدًا تصور طريقة آمنة للقبض على كل شيء لكل من المعدن العاري وأي مزودي خدمة السحابة على حد سواء.

guineveresaenger لم يتم التخطيط لحل هذا في 1.12

nikopen ما أعنيه هو أنه سيكون لديك دائمًا نافذة حيث يمكن للعقدة أن تعود من حالة إيقاف التشغيل. ليس مجرد إعادة تشغيل ، ولكن يمكن للمستخدم أيضًا إعادة تشغيله. لذا مهما كانت قيمة المهلة التي نختارها لن تكون خالية من السباق.

للتوضيح ، إليك تسلسل يوضح السباق بقوة حذف الكبسولة:

1. يحصل VM على الاغلاق
2. تتم إضافة تلطيخ إيقاف التشغيل إلى العقدة.
3. يرى جهاز التحكم تلوثًا للإغلاق على العقدة.
4. يعود VM عبر الإنترنت ويبدأ تشغيل البودات مرة أخرى
5. قوة التحكم تحذف القرون على العقد
6. وحدة تحكم AD تفصل وحدات التخزين بينما لا تزال الحاوية مثبتة عليها.

@ msau42 هل تمانع في إزالته من المعلم؟ يمكنني القيام بذلك ولكن لا أريد حقًا أن أتجاوز رأس أي شخص. :)

أعتقد أنه ينبغي تسجيله في ملاحظات الإصدار من نوع ما. لست متأكدًا من أفضل طريقة للقيام بذلك ، ولكن منذ ما قبل هذا الإصدار ، كان السلوك الافتراضي على Openstack و vSphere و AWS هو فصل وحدات التخزين من عقد إيقاف التشغيل بعد هذا الإصدار ، ولم يعد الأمر كذلك. لم ينجح الانفصال في GCE-PD أبدًا ولكن تم حجبه من خلال إستراتيجية نشر الحملة العالمية للتعليم. قد لا يرى أولئك الذين يستخدمون kops للنشر على AWS أيضًا هذا الخطأ ، لأن kops ينشر كل شيء في ASG ويتم إنهاء عقدة إيقاف التشغيل واستبدالها تلقائيًا.

guineveresaenger ليس لدي أذونات رئيسية

دعونا نرى ما إذا كنت أفعل ... ؛)
/ معلم واضح

guineveresaenger : يجب أن تكون عضوًا في فريق جيثب kubernetes / kubernetes-milestone -keepingers لتحديد هذا الإنجاز.

كلا ، لا أفعل.

cc @ saad-ali، childsb ، tpepper - هل يمكنك من فضلك إزالتها من المعلم؟

@ msau42 الرجاء

adampl لا مانع من التعامل مع كليهما بشكل منفصل ، على الرغم من أنه يبدو أن النتيجة ستظل مثيرة للعرق. لذلك ربما هو نهج مؤقت فقط.

guineveresaenger ، gnufied توافق على أن هذا لا ينبغي أن

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

@ msau42 لتجنب السباق ، يجب ألا تزيل وحدة التحكم تلوث الإغلاق إلا بعد إجبار الحذف. يجب ألا تبدأ العقدة في تشغيل البودات أثناء تعرضها للإغلاق؟

beekhof صحيح ، إخلاء

itamarh هذا يتطلب تغيير kubelet للبحث عن تلوث الإغلاق. ويفترض أيضًا أن وحدة التحكم التي تضيف / تزيل التلوث هي نفسها التي تفرض حذف البودات. قد تكون هناك أيضًا مشكلات توقيت بين مزامنة كائن Pod و Node API التي يجب التحقيق فيها.

إذا كانت هذه المشكلة ستتم إزالتها من 1.12 ، فالرجاء على الأقل إلغاء تعليق # 67977 وإضافة منطق لمنع حالة السباق عند إعادة تشغيل الكبسولات بعد إيقاف التشغيل.

راجع للشغل ، في حالة أحجام أنواع RWO (برامج التشغيل) التي لا تدعم وضع RWX ، فسيتم دائمًا رفض التثبيت المزدوج ، لذلك سيكون السباق غير ضار ، أليس كذلك؟ أعتقد أن المشكلة تكمن فقط في الأنواع التي تدعم RWX ، لأنها لا ترفض عمليات التحميل المزدوجة غير المقصودة لوحدات تخزين RWO (ما لم تكن على علم بطريقة ما بالوضع المطلوب أيضًا ، وهو ما أشك فيه).

/ معلم واضح

adampl فإن AccessModes ( RWO و RWX ) لن يؤثر في الواقع على عمليات التحميل. تم تصميمه لمطابقة PVC / PV في الأصل ، ثم يتم استخدامه لربط الحجم (وليس لكميات التخزين).
نحتاج إلى تنظيف عناصر AccessModes أيضًا ، وأرسلنا مشكلة من قبل ، https://github.com/kubernetes/kubernetes/issues/67936 ، سيبدأ العمل قريبًا

@ msau42 @ jingxu97 -

في الواقع ، كما ذكرت أعلاه.

على سبيل المثال: امسح البودات قبل الإغلاق الفعلي بطريقة كريمة لضمان حذفها.

nikopen بالنسبة الرائعة هي kubectl drain .

المشكلة هي مع عقدة أو kubelet لا تستجيب. حتى التجفيف يمكن أن يفشل في منتصف العملية إذا تعطلت العقدة / الكوبليت بشكل غير متوقع أو فقدت الاتصال ، لذلك يجب أن تكون الكتلة قادرة على عزل العقدة الفاشلة (سياج AKA). يجب أن يكون IMHO مثل:

1. تطويق العقدة
2. بدء الاغلاق (إذا كان يعمل)
3. تحقق من الاغلاق
4. فرض حذف كافة القرون

ولكن بعد ذلك يجب أن تكون هناك طريقة للقيام بذلك على العقد المعدنية المجردة أيضًا.
لذلك نحن بحاجة إلى واجهة برمجة تطبيقات للخدمات الخارجية التي تدير حالة الطاقة للعقد المعدنية العارية.

أتفق معadampl

هناك حاجة إلى آلية السياج هنا. تحدث مع @ jingxu97rootfs و @msau42 حاليا، ونحن بحاجة إلى وضعه kubernetes خارج لأنه من الصعب أن يثبت تماما شروط السباق عبر مكونات kubernetes وتغيير محتمل قد كسر kubernetes الكثير.

للتوضيح ، نحن نهتم ليس فقط بإغلاق العقدة ، ولكن أيضًا بحالة غير معروفة لأنها قد تتسبب في انقسام الدماغ والكتابة المزدوجة. ونحن لا نهتم فقط بمثيلات عقد مزود الخدمات السحابية ، بل نهتم أيضًا بالعقد المعدنية المجردة.

يمكن أن يبدأ التنفيذ بشكل بسيط ولدينا هنا بعض عملاء قاعدة البيانات الذين يحتاجون إلى ذلك أيضًا.
سنناقش هذا ونضع نموذجًا أوليًا له ، ويمكنهم توفير بيئة مثيلات قاعدة بيانات كبيرة للتحقق من التنفيذ. سيرسل الاقتراح عند الانتهاء

/ cc @ jingxu97 @ msau42orainxiong

/ cc ddysher

NickrenREN أعتقد أنه يمكن إجراء المبارزة داخل kubernetes ونشرت سابقًا رابطًا لتصميم غير رسمي

أحد العناصر الموجودة في قائمة TODO الخاصة بي هو دمج التصميم المحدث في الاقتراح الحالي ، لكنني أرحب بأي شخص مهتم بالتعاون للتواصل أو اقتراح التغييرات قبل ذلك.

/ سم مكعب @ jingxu97 @ msau42orainxiongadamplddysher

مرحبًا @ jingxu97 ، فهمت من @ saad-ali أنك ستتعامل مع هذه العلاقات العامة لإصدار 1.13.
أود أيضًا أن أثير اهتمامك بالمسائل التكميلية -> https://github.com/kubernetes/kubernetes/issues/68086 و https://github.com/kubernetes/kubernetes/issues/69168 والتي تتعلق بنفس الطريقة بـ الموضوع.

مرحبًا @ jingxu97 @ saad-ali @ msau42 ،

حيث إنني أتابع المشكلات لفريق الإصدار 1.13 ،

هل هناك تقدير ما إذا كان هذا و # 68086 ، # 69168 يجعله v1.13؟

مرحبًا ، nikopen ، هل لدينا أي قرار بشأن الحل وخطة الإصدار لهذا الأمر؟
شكر.

أعتقد أن @ jingxu97 لديها اقتراح وضعته معًا لمعالجة هذا الأمر. يتطلب تغييرات على جانب العقدة ، لذلك من الناحية المثالية نحتاج إلى عقدة سيج لاستلامها.

/ معلم v1.14.0

@ jingxu97 - هل يمكننا المزامنة حول هذا الاقتراح ، أي KEP موجود حتى الآن؟

@ jingxu97 ، نتحدث أنا وبعض اللاعبين الآخرين عن تنفيذ Node Fencing في وضع عدم الاتصال ، وسوف نرسل الاقتراح عندما يكون جاهزًا

+1 على المبارزة. إذا تم تقسيمها إلى فئتين من physical & external فيمكننا الحصول على العقد لإرسال تفاصيل STONITH الخاصة بهم حول القبول ، وإلا ، يمكن لموفر السحابة (أو مزود STONITH؟) تقديم حل لطلبات المبارزة .

مرحبًا @ jingxu97 @ saad-ali ، سيأتي تجميد الكود لـ 1.14 في غضون 10 أيام ، إذا لم يكن هذا جاهزًا في الأسابيع 2-3 المقبلة ، فلا تتردد في نقله إلى الإصدار 1.15.

nikopen - تم نقل التحسينات kubernetes / التحسينات # 719 من 1.14 ، يجب أيضًا نقل هذه المشكلة.

حسنا!

/ معلم v1.15

مرحبًا yastij ، كيف سيتم حل هذه المشكلة في 1.15؟ من خلال وجود آلية جديدة للمبارزة أو عن طريق وضع علامة يدويًا على التلوث للإخلاء؟

شكر

@ shay-berman - سنعتمد على ملاحظة التلوث وإضافة بعض التغييرات إلى kubelet لجعل فصل الأحجام عن العقد آمنًا.

شكرا للتحديث.
إذن بعد الإصلاح - هل سيتعين على المستخدم القيام بشيء يدويًا لاستعادة PODs ذات الحالة التي علقت على عقدة العامل المحطمة؟
أم أنه سيكون قرار تلقائي من قبل k8s؟

في وضع Cloudprovider ، لن تكون هناك حاجة للمستخدم للعمل يدويًا. بالنسبة للإعدادات المحلية ، سيحتاج المستخدمون إلى إما:

• توفير مكون خارجي يقوم بهذا المنطق.
• تعمل يدويًا في عملية التلوين / إزالة التلوث

مرحبا! بدأنا تجميد الرمز لـ 1.15 غدًا EOD. هل تريد فقط تسجيل الوصول لمعرفة ما إذا كانت هذه المشكلة لا تزال مخططة لدورة 1.15؟

timmycarr - هذا لا يهبط في 1.15

/ معلم واضح

ليتم إحياؤها عند طرح اقتراح جديد

تم طرح هذه القضية عدة مرات. في الواقع ، إنه يؤذي العديد من المستخدمين. لا يُعد تعليق البودات في حالة عدم توفرها لمدة تزيد عن 6 دقائق حلاً مستدامًا للحفاظ على أعباء عمل الإنتاج متاحة بشكل كبير. أدرك أن الحل النهائي على الأرجح لن يكون بسيطًا ، وسيتطلب المزيد من مناقشات التصميم. ولكن هل تعتقد أن إصلاحًا أصغر من خلال جعل ReconcilerMaxWaitForUnmountDuration قابلًا للتكوين يمكن تنفيذه حتى يتم اتخاذ القرار النهائي؟ سيساعد المستخدمين كثيرا

cc @ شاي بيرمان liggitt

@ alena1108 شكرا لتقاسم

@ jingxu97 لقد رأيت أنه يحدث لنشر aws (حجم ebs) وإعدادات vsphere لمستخدمينا. عندما يتم إغلاق العقدة وتصبح غير متوفرة ، تظل وحدات التخزين على المضيف لمدة 6 دقائق ، ولا يمكن بدء تشغيل الكبسولة الجديدة على العقدة السليمة حتى يتم فصل الحجم القديم.

يمكن أن يتأثر صاحب الحالة بهذا السلوك أيضًا. لقد وثقنا التفاصيل هنا

@ alena1108 هل يمكنك وصف السيناريوهات التي يتم فيها إغلاق العقدة دون إجراء تطويق واستنزاف أولاً؟

@ msau42 عندما يتم إغلاق /

هل يمكنك أن تكون أكثر تحديدًا حول أنواع "الأسباب المختلفة" الموجودة؟ إنه ليس واضحًا بالنسبة لي وأريد أن أفهم حالة الاستخدام الأساسية هذه.

@ msau42 لا يمكنني التحدث إلا عن تجربتي الخاصة هنا ، لكنني رأيت سلوكًا كهذا عندما تفشل الأجهزة الأساسية لجهاز افتراضي يشغل عقدة. لم تتح لمدير الكتلة مطلقًا الفرصة لتطويق / استنزاف العقدة أولاً في هذا السيناريو.

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

إنها أقل مشكلة إذا كان لديك قياس تلقائي للعقدة (حيث يمكن إرفاق وحدة التخزين بعقدة أخرى بمجرد حذف العقدة الفاشلة) ، ولكن عندما لا يكون هذا خيارًا ، بقدر ما أعرف أن أي بودات بها PVs مرفقة يمكن ' يتم إعادة جدولتها حتى تعود العقدة عبر الإنترنت أو تتم إزالتها من المجموعة بالكامل. (لقد مر وقت منذ أن واجهت هذا بنفسي ونظرت فيه ، إذا لم يعد الأمر كذلك ، فسأكون سعيدًا لأنني مخطئ في هذا!)

هناك عمل مستمر على حل جديد لهذه المشكلة: https://github.com/kubernetes/enhancements/pull/1116

ومع ذلك ، ما زلت غير متأكد من كيفية عمله مع المجموعات غير السحابية.

@ msau42 تفشل الآلات في بعض الأحيان ...

adampl شكرا على الرابط. سيكون حل المشكلة بطريقة أو بأخرى أمرًا رائعًا ، حتى لو اقتصر على عقد مزود السحابة فقط. هل تعرف ما هو إصدار k8s الذي تستهدفه؟ cc @ smarterclayton

@ alena1108 - نأمل 1.16

NickrenREN مرحبًا ، هل

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، يرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها
/ دورة الحياة مجمدة