enisoc @ dchen1107fejtathockin @ kow3nsderekwaynecarr، فتحت هذه المسألة تتبع بحيث يمكننا مناقشة.

/تعيين

derekwaynecarr لقد أجريت بعض عمليات البحث للخروج من تغييرات kubelet المطلوبة لاجتماع sig-node الأسبوع المقبل ، وأعتقد أن التغييرات مطلوبة فقط في حزمة kuberuntime ، على وجه التحديد kuberuntime_manager.go in و kuberuntime_container.go .

في kuberuntime_manager.go يمكنك تعديل computePodActions لتنفيذ تشغيل إيقاف التشغيل (قتل sidecars عندما يتم إنهاء جميع السيارات الجانبية بشكل دائم) ، وبدء تشغيل العربات الجانبية أولاً.

في kuberuntime_container.go يمكنك تعديل killContainersWithSyncResult لإنهاء sidecars أخيرًا وإرسال خطافات preStop (كانت بتة خطافات preStop قابلة للنقاش بعض الشيء ، ولم تتم تسوية ما إذا كان يجب القيام بذلك أم لا. @ كان لدى التعليق ).

اسمحوا لي أن أعرف إذا كنت تريد مني المزيد من التحقيق.

@ kow3ns المناقشة أكثر منطقية بالنسبة لي إذا كان بإمكاننا تحديد وصف كامل لتسلسل الحاويات في مواصفات Pod (sig-app) ، وكيفية التعامل مع التسلسل في kubelet للبدء وإعادة التشغيل والتفكير المتتالي (sig-node). دعونا نلقي نظرة على اجتماع 5 فبراير عقدة التوقيع لتقديم المزيد من المدخلات.

سم مكعب @ جوزيف ايرفينغ

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

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

تحديث على هذا KEP:
لقد تحدثت إلى كل من derekwaynecarr و @ dchen1107 من sig-node حول هذا ولم يعبروا عن أي مخاوف كبيرة بشأن الاقتراح. سوف أقوم برفع خطاب العلاقات العامة إلى KEP مضيفًا بعض الملاحظات الأولية حول تفاصيل التنفيذ وتوضيح بعض النقاط التي ظهرت أثناء المناقشة.

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

@ جوزيف ايرفينغ في الواقع ، لا قيمة منطقية ولا قيمة containerLifecycle: Sidecar مناسبة للتوسعة المستقبلية المناسبة. بدلاً من ذلك ، يجب أن يكون containerLifecycle كائنًا ، تمامًا مثل deployment.spec.strategy ، مع type: Sidecar . سيسمح لنا هذا بعد ذلك بتقديم حقول إضافية. بالنسبة لحل "السيارة الجانبية طوال عمر الكبسولة" ، سيتم التعبير عنها وفقًا لهذه الأسطر:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

في مقابل

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

أرجوك سامحني التسمية السيئة - آمل أن تنقل الأسماء الفكرة.

ولكن هناك مشكلة واحدة في الأسلوب حيث نقدم containerLifecycle إلى pod.spec.containers . وبالتحديد ، من الخطأ أن يكون لديك أشرطة جانبية تعمل بالتوازي مع حاويات init المحددة تحت pod.spec.containers . لذلك إذا كنت تريد حقًا أن تكون قادرًا على توسيع هذا ليشمل حاويات init في النهاية ، فيجب أن تجد حلاً بديلاً - حل يسمح لك بتمييز الحاويات على أنها عربات جانبية عند مستوى أعلى - أي ليس أقل من pod.spec.containers أو pod.spec.initContainers ، ولكن شيء مثل pod.spec.sidecarContainers ، والذي أعتقد أنك ناقشته بالفعل ، لكنك رفضته. تتطلب مشكلة حاويات البادئة بالتأكيد حلًا على هذا المنوال.

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

تكمن مشكلة pod.spec.sidecarContainers أنه تغيير أكثر تعقيدًا بكثير ، حيث يجب تحديث الأدوات وسيتطلب kubelet الكثير من التعديل لدعم مجموعة أخرى من الحاويات. الاقتراح الحالي أكثر تواضعا بكثير ، فهو يعتمد فقط على ما هو موجود بالفعل.

@ جوزيف ايرفينغ يمكننا العمل مع ذلك نعم. ليس من المثالي أن يتم إغلاق السيارة الجانبية بعد تشغيل حاويات init ومن ثم تشغيل نفس السيارة الجانبية مرة أخرى ، ولكنها أفضل من عدم وجود هذا الخيار. المشكلة الأكبر هي أن Kubelets الأقدم لن تتعامل مع حاويات init-sidecar بشكل صحيح (كما هو الحال مع حاويات السيارة الجانبية الرئيسية).

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

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

فيما يتعلق بمناقشة التنفيذ في https://github.com/kubernetes/enhancements/pull/841 ، قمت بفتح صفحة العلاقات العامة الخاصة بشركة WIP تحتوي على PoC أساسي لهذا الاقتراح https://github.com/kubernetes/kubernetes/pull / 75099. إنها مجرد مسودة أولى ومن الواضح أنها ليست مثالية ولكن الوظيفة الأساسية تعمل وتعطيك فكرة عن مقدار التغيير المطلوب.

cc @ enisoc

لقد قمت بتجميع مقطع فيديو قصير يوضح فقط كيف يتصرف PoC حاليًا https://youtu.be/4hC8t6_8bTs. يمكن أن تكون رؤيتها أثناء العمل أفضل من القراءة عنها.
إخلاء المسؤولية: لست من مستخدمي YouTube المحترفين.

لقد فتحت اثنين من العلاقات العامة الجديدة:

• https://github.com/kubernetes/enhancements/pull/918 يدور حول معايير التخرج ، انحراف الإصدار ، الترقية / الرجوع إلى إصدار أقدم
• https://github.com/kubernetes/enhancements/pull/919 هو اتخاذ قرار بشأن تنفيذ واجهة برمجة التطبيقات

أي أفكار أو اقتراحات ستكون محل تقدير كبير.

@ Joseph-Irving معذرة إذا قمت بالتعليق متأخرًا في عملية التصميم ، لكن لدي حالة استخدام محتملة لحاويات جانبية قد لا تكون مدعومة في اقتراح التصميم الحالي. أردت فقط رفعه للنظر فيه. الجوهر هو أن لدي سيناريو حيث يجب إنهاء جانب واحد عند إنهاء الجراب قبل الحاوية الرئيسية ، بينما يجب إنهاء جانب جانبي آخر بعد الحاوية الرئيسية.

قد يكون المثال الملموس عبارة عن حجرة بها حاوية تطبيق Django ، وقنصل جانبي لتسجيل الخدمة ، و pgbouncer sidecar لإدارة الاتصالات بقاعدة البيانات. عندما يتم إنهاء الكبسولة ، أود إيقاف الجانب الجانبي للقنصل أولاً (لذلك لا يتم توجيه المزيد من حركة المرور إلى الحجرة) ، ثم حاوية التطبيق (من الناحية المثالية بعد فترة سماح قصيرة) ، ثم لوحة التحكم الجانبية. يبدو الاقتراح الحالي رائعًا للتعامل مع تبعية حاوية التطبيق <-> pgbouncer ، ولكن لا يبدو معبرًا بما يكفي لالتقاط الحالة التي أرغب في هدم عنصر جانبي _ قبل_ الحاوية الأساسية.

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

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

يبدو جيدًا ، شكرًا @ جوزيف إيرفينغ. لذلك فقط لتأكيد فهمي على مستوى عالٍ: سيتم إرسال خطافات ما قبل التوقف إلى السيارات الجانبية أولاً ، متبوعة بخطافات ما قبل التوقف إلى السيارات غير الجانبية ، ثم SIGTERM إلى غير السيارات الجانبية ، ثم (بعد خروج جميع السيارات غير الجانبية ) SIGTERM إلى السيارات الجانبية؟ يبدو أن اقتراح التصميم (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) يشير إلى هذا ولكنه يقول أيضًا:

سيتم إرسال خطافات PreStop إلى العربات الجانبية والحاويات في نفس الوقت.

currankaushik نعم ما وصفته هو السلوك المقصود.

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

@ جوزيف ايرفينغ هل هذه الميزة تستهدف تضمين ألفا لـ 1.15؟

@ kacole2 نعم هذه هي الخطة ، على افتراض أنه يمكننا جعل KEP قابلاً للتنفيذ في الوقت المناسب لتجميد التعزيز (30 أبريل). وبمجرد الانتهاء من المعهد https://github.com/kubernetes/enhancements/pull/919 وخطة اختبار اتفق https://github.com/kubernetes/enhancements/pull/951 أعتقد أننا يجب أن تكون كل مجموعة.

/ معلم v1.15
/ المرحلة ألفا

@ Joseph-Irving Kubernetes 1.15 تجميد التحسين هو 30/4/2019. ليتم تضمينها في معلم Kubernetes 1.15 ، يجب أن يكون KEPs في حالة "قابلة للتنفيذ" مع خطط اختبار ومعايير تخرج مناسبة. يرجى تقديم أي تقارير PR مطلوبة لجعل KEP يلتزم بمعايير التضمين. إذا كان هذا سينزلق من 1.15 نقطة رئيسية ، فيرجى إخبارنا حتى نتمكن من إجراء تغييرات التتبع المناسبة.

mrbobbytables للأسف ، لم

لا داعى للقلق. نشكرك على سرعة الرد وإخبارنا بذلك!
/ معلم واضح

من فضلك ضع في اعتبارك ، هذا KEP مهم جدًا لـ Istio!

إنها أداة إيقاف عرض لجميع المشاريع التي تستخدم أطر عمل مع تمهيد / إيقاف تشغيل منسق (مجموعة akka ، lagom وما إلى ذلك) جنبًا إلى جنب مع شبكة خدمة istio see .

ccjroper

@ Joseph-Irving sry عن التعليق المتأخر ، لكني لا أرى ما يلي في مستند التصميم ، وكنت أتساءل ما هو السلوك المقصود من هؤلاء:

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

أيضًا ، عند حساب مرحلة pod ، إذا نجحت كل الحاوية الرئيسية ، وفشل جانب جانبي (وهو أمر شائع جدًا كما لو أن sidecar لا يمسك SIGTERM ، فسيكون رمز الإرجاع مثل 143 أو شيء من هذا القبيل) ، هل ما زالت مرحلة pod "ناجحة"؟

تتبع @ zhan849 حاليًا حاويات Succeeded .

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

فيما يتعلق بمرحلة pod: أود أن أزعم أن جميع التطبيقات التي تعمل في kubernetes يجب أن تتعامل مع SIGTERMs (خاصة السيارات الجانبية) ، ولكن في بعض الأحيان قد ترغب أيضًا في معرفة ما إذا كانت السيارات الجانبية الخاصة بك قد خرجت بطريقة سيئة ويجب أن ينعكس ذلك في مرحلة pod ، قد يؤدي إخفاء تلك المعلومات إلى حدوث ارتباك.

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

يتماشى هذان الأمران تمامًا مع ما تفعله الحاوية العادية وما يحدث حاليًا.
لا يبدو أن تغييرها مطلوب لتحقيق الأهداف المدرجة في Kep.

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

@ Joseph-Irving ، لدينا بعض إشارات السيارة الجانبية الأبسط التي تم تشغيلها داخليًا لبعض الاحتياجات العاجلة (لم نساهم لأن هذا قيد التقدم بالفعل في المجتمع) ، وإليك ما تعلمناه.

فيما يتعلق بمرحلة الجراب:

1. تنعكس حالة وجود الحاوية بالفعل في pod.status.containerStatuses لذلك لا نفقد المعلومات. أيضًا ، نظرًا لوجود حالة استخدام كبيرة للعربة الجانبية في الوظيفة (أو أي حوامل من أي وقت مضى التشغيل حتى النهاية مثل تلك الموجودة في Kubeflow) ، فسيتم تطبيق أعباء عمل ذات مغزى على الحاوية الرئيسية فقط وإذا تم وضع علامة على مرحلة pod على أنها فاشلة بسبب فشل السيارة الجانبية ، سينتج عن ذلك عمليات إعادة محاولات غير ضرورية ويؤدي إلى عواقب مضللة أخرى مثل فشل الوظيفة وما إلى ذلك.

2. على الرغم من أنه من المثالي أن تتعامل السيارات الجانبية مع SIGTERM ، إلا أنه في الإنتاج ، يمكن أن يكون هناك الكثير من السيارات الجانبية المبنية ببساطة على برنامج مفتوح المصدر ولا يتعاملون مع SIGTERMs بشكل جيد ، بما في ذلك kube-proxy ، postfix ، rsyslogd ، والعديد من الآخرين (وحتى إذا تم التعامل مع SIGTERM ، بالنسبة إلى SIGKILL غير القابل للتنظيف ، فلن يكون بالتأكيد 0)

فيما يتعلق بسياسة إعادة التشغيل (يمكن أن يكون قابلاً للجدل ولكن جعل السيارات الجانبية تلتزم بصرامة بإعادة التشغيل ، فالسياسة غير واقعية في الإنتاج):

1. إن إجبار sidecar على إعادة التشغيل عندما لا تزال الحاويات الرئيسية قيد التشغيل عن طريق تعيين "OnFailure" ليس خيارًا لأن هذا سيؤدي إلى إعادة تشغيل الحاويات الرئيسية الفاشلة وهو أمر مربك إلى جانب حد إعادة المحاولة على مستوى المهمة.

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

3. سيؤدي نشر الإخفاقات إلى وحدات التحكم ذات المستوى الأعلى إلى تشغيل سلاسل من التسوية والكثير من استدعاءات api ، لذا فإن التصعيد غير الضروري للأخطاء يمكن أن يجعل kubernetes أقل قابلية للتوسع.
   مثال أكثر تحديدًا: إذا كانت الحاويات الرئيسية للوظيفة لا تزال قيد التشغيل وفشل الجانب الجانبي ، فإن إعادة تشغيل الجهاز الجانبي سيكون له عملية PATCH pod واحدة فقط ومكالمة api ذات صلة بحدث واحد على الأكثر. ولكن إذا فشل الكبسولة بالكامل سيؤدي إلى تسوية الوظيفة ، والمزيد من وحدات التحكم على مستوى التوظيف مثل CronJob و CRDs الأخرى وقد يكون هناك عدة مرات استدعاء API.

أريد أيضًا معرفة ما إذا كان الأشخاص الآخرون قد شاهدوا مشكلات مماثلة (/ cc @ kow3ns )

هل سيشمل هذا التغيير السلوك المطلوب في https://github.com/kubernetes/community/pull/2342 ، بحيث تكون هناك طريقة لتهيئة البود بالكامل (أو الحاوية غير الجانبية فقط) لإعادة التشغيل إذا فشل السيارة الجانبية؟

JacobHenner لا توجد خطط حاليًا لتنفيذ هذا النوع من الآلية في KEP هذا ، لقد ناقشنا دمجها ، لكنها لا تعتمد كثيرًا على KEP ويمكن تطويرها بشكل مستقل عن هذا. لذلك يبدو أنه مناسب بشكل أفضل لامتلاك KEP الخاص به.

@ Joseph-Irving فقط لمشاركة ضمنيتنا التي عالجت المزالق المذكورة أعلاه للرجوع إليها (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar) نظرًا لأن هدفنا هو انتظار الدعم الرسمي ، فنحن نحاول للحفاظ على التغيير محليًا قدر الإمكان في هذا الالتزام.

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

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

أوافق بشكل عام على أن KEP الجانبي يجب أن يأخذ في الاعتبار مرحلة pod وإعادة السياسة قبل أن ينتقل إلى حالة قابلة للتنفيذ. لا يهمني ما إذا كان هذا KEP أم لا ، لكنني أتفق بشكل عام مع حجج @ zhan849 ويجب التعامل معها هنا.

شكرا smarterclayton !
@ Joseph-Irving ، أخبرنا إذا كان هناك أي شيء آخر تريد منا مشاركته مع sidecar في الممارسة العملية.

smarterclayton @ zhan849 ، أنا لا أختلف بشكل خاص مع النقاط التي

سأعيد هذه التعليقات إلى sig-apps / sig-node وأرى ما يفكرون فيه. كانت sig-node على وجه الخصوص حريصة على إبقاء السيارات الجانبية قريبة من الحاويات العادية قدر الإمكان ، إذا كان derekwaynecarr أو @ dchen1107 تريد أن تتناغم في ذلك سيكون موضع تقدير.

تم الآن دمج خطة الاختبار https://github.com/kubernetes/enhancements/pull/951 وتصميم واجهة برمجة التطبيقات https://github.com/kubernetes/enhancements/pull/919 PRs.

لقد فتحت https://github.com/kubernetes/enhancements/pull/1109 للحصول على علامة KEP على أنها قابلة للتنفيذ ، بمجرد أن يسعد الجميع بذلك ، يجب أن نكون قادرين على بدء التطوير لهذا كـ alpha في 1.16 🤞

تم وضع علامة Kep على أنها قابلة للتنفيذ ، لذا سأقوم برفع مستوى العلاقات العامة للوصول إلى 1.16 بدءًا من الأسبوع المقبل!

لقد رفعت https://github.com/kubernetes/kubernetes/pull/79649 لتنفيذ واجهة برمجة التطبيقات ، وسيكون لديّ علاقات عامة منفصلة لتغييرات Kubelet.

مرحبًا @ Joseph-Irving ، أنا قائد التحسين 1.16. هل ستتخرج هذه الميزة بمراحل ألفا / بيتا / مستقرة في 1.16؟ يرجى إعلامي حتى يمكن إضافته إلى جدول بيانات التتبع 1.16 . إذا لم يتم التخرج ، فسأقوم بإزالته من الحدث الرئيسي وتغيير التسمية المتعقبة.

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

التواريخ الرئيسية هي تجميد التحسين 7/30 وتجميد الرمز 8/29.

شكرا لك.

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

مرحبًا @ kacole2 ، هذا يستهدف Alpha لـ 1.16 ، وقد تم تمييز KEP بأنه قابل للتنفيذ.
العلاقات العامة الوحيدة لهذا حاليًا هي kubernetes / kubernetes # 79649 لواجهة برمجة التطبيقات

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

لقد فتحت https://github.com/kubernetes/kubernetes/pull/80744 الذي ينفذ تغييرات kubelet.

يرجى ملاحظة أن kubernetes / kubernetes # 79649 (api) لا يزال مفتوحًا لذا تحتوي هذه العلاقات العامة على التزامات منها ، مما يجعلها تبدو كبيرة. لقد قسمتها إلى التزامات يقوم كل منها بتنفيذ جزء مختلف من الوظائف ، لذا يجب أن يكون من السهل مراجعتها بهذه الطريقة.

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

cc @ kacole2

@ جوزيف ايرفينغ

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

إذا كان الأمر كذلك ، فقط للتذكير الودية نحن نبحث عن علاقات عامة ضد k / موقع الويب (فرع dev-1.16) بحلول يوم الجمعة ، 23 أغسطس ، يمكن أن يكون فقط عنصرًا نائبًا للعلاقات العامة في هذا الوقت. اسمحوا لي أن أعرف إذا كان لديك أي أسئلة!

مرحبًا daminisatya ، نعم سيحتاج هذا إلى تحديثات لمحرّر المستندات ، لقد قمت https://github.com/kubernetes/website/pull/15693 كعنصر نائب للعلاقات العامة.
سأكون مهتمًا بمعرفة ما إذا كان لدى أي شخص أي آراء حول المكان الذي يجب أن يتوجه إليه محرر المستندات ، لقد وضعت شيئًا ما في content/en/docs/concepts/workloads/pods/pod-lifecycle.md في الوقت الحالي.

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

/تعيين

هل يمكن أن يسمح ذلك لكتابة عربة جانبية يمكنها بدء الخدمة الفعلية عند الطلب (وتدميرها)؟

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

Ciantic مع إطار عمل المشغل يمكنك القيام بذلك وأكثر من ذلك بكثير. إلق نظرة

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

لا تكمن المشكلة في عدم وجود خيارات متاحة مثل Osiris أو Keda أو Knative . لقد جربت الإصدار الأخير ، لكنه يستهلك 8 جيجا بايت من الذاكرة ، ومن الصعب القول أنه "بدون خادم" في تلك المرحلة.

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

لماذا يكون هذا مفيدا؟ إنه مفيد حقًا في حالات الاستخدام المنخفض والذاكرة المنخفضة ، على سبيل المثال k3s مع Raspberry Pi ، أو قطرة المحيط الرقمي لمشاريع الهوايات. لدى الكثير منا الكثير من خدمات الويب التي لا تحتاج إلى أن تكون قيد التشغيل طوال الوقت ، فمجرد امتلاك عربة جانبية يمكنها إيقاظهم عند الطلب سيكون كافياً.

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

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

مرحبًا بك @ جوزيف إيرفينغ - تحسينات 1.17 تؤدي هنا. أردت تسجيل الوصول ومعرفة ما إذا كنت تعتقد أن هذا التحسين سينتقل إلى ألفا في 1.17؟

جدول الإصدار الحالي هو:

• الاثنين 23 سبتمبر - تبدأ دورة الإصدار
• الثلاثاء ، 15 أكتوبر ، التخلص من الذخائر المتفجرة بتوقيت المحيط الهادئ - تجميد التحسينات
• الخميس ، 14 نوفمبر ، التخلص من الذخائر العنقودية - تجميد الرمز
• الثلاثاء ، 19 تشرين الثاني (نوفمبر) - يجب إكمال المستندات ومراجعتها
• الاثنين 9 كانون الأول (ديسمبر) - تم إصدار Kubernetes 1.17.0

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

شكرا!

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

العلاقات العامة المفتوحة الحالية هي:
https://github.com/kubernetes/kubernetes/pull/79649 - تغييرات واجهة برمجة التطبيقات
https://github.com/kubernetes/kubernetes/pull/80744 - تغييرات Kubelet

اسمحوا لي أن أعرف إذا كنت بحاجة إلى أي شيء آخر!

رائعة! شكرًا @ Joseph-Irving ، سأضيف المعلومات إلى ورقة التتبع 👍

@ جوزيف ايرفينغ

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

إذا كان الأمر كذلك ، فقط للتذكير الودية نحن نبحث عن علاقات عامة ضد k / موقع الويب (الفرع dev-1.17) بحلول يوم الجمعة ، 8 نوفمبر ، يمكن أن يكون مجرد عنصر نائب للعلاقات العامة في هذا الوقت. اسمحوا لي أن أعرف إذا كان لديك أي أسئلة!

شكرا!

مرحبًا @ VineethReddy02 ، نعم ، سيتطلب هذا وثائق ، العنصر النائب PR هنا https://github.com/kubernetes/website/pull/17190

لقد قمت برفع العلاقات العامة لتحديث KEP https://github.com/kubernetes/enhancements/pull/1344 وهو يعتمد على بعض المناقشات التي كنا نجريها في تطبيق العلاقات العامة https://github.com/kubernetes/kubernetes/pull / 80744.

أنا أقدر أي تعليقات

يا @ جوزيف ايرفينغ 1.17 تعزيز الظل هنا! 👋 أتواصل معك لأتعرف على كيفية تحقيق هذا التحسين.

يتتبع فريق التحسين حاليًا kubernetes / kubernetes # 79649 و kubernetes / kubernetes # 80744 في ورقة التتبع. هل هناك أي علاقات عامة أخرى k / k يجب تتبعها أيضًا؟

أيضًا ، تذكير ودي آخر بأننا نقترب بسرعة من تجميد الكود (14 تشرين الثاني (نوفمبر)).

مرحبًا annajung ، نعم هؤلاء هم العلاقات العامة الوحيدة التي تحتاج إلى تتبع.

مرحبًا @ Joseph-Irving ، غدًا هو تجميد الكود لدورة الإصدار 1.17 . يبدو أن k / k PRs لم يتم دمجها. نحن نضع علامة على هذا التحسين كـ At Risk في ورقة التتبع 1.17.

هل تعتقد أنه سيتم دمج جميع العلاقات العامة الضرورية بواسطة EoD ليوم 14 (الخميس)؟ بعد ذلك ، لن يُسمح إلا بقضايا حظر الإصدار والعلاقات العامة في الحدث الرئيسي باستثناء استثناء.

مرحبًا annajung ، للأسف يبدو أنه من غير المحتمل جدًا أن يتم دمجهم قبل تجميد الكود. لقد أحرزنا تقدمًا كبيرًا في دورة الإصدار هذه ، لذا نأمل أن نتمكن من دمجها مبكرًا في 1.18.

يا @ جوزيف ايرفينغ شكرا لك على التحديث. سوف أقوم بتحديث الإنجاز وفقًا لذلك وسأحدد هذا التحسين على أنه مؤجل إلى 1.18. شكرا لك!

/ معلم الإصدار 1.18.0

يا @ جوزيف ايرفينغ. 1.18 تحسينات تؤدي هنا 👋.

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

شكرا!

مرحبًا @ jeremyrickard ،

نعم ، الخطة هي الحصول على هذا في الإصدار 1.18.

حصل API PR (https://github.com/kubernetes/kubernetes/pull/79649) على مراجعة من thockin ، في أحد الأيام ، كان لديه بعض النقاط ولكن بمجرد معالجة هذه النقاط سنغلق تلك العلاقات العامة وندمج الالتزامات في (https://github.com/kubernetes/kubernetes/pull/80744) حتى نتمكن من دمج واجهة برمجة التطبيقات والتنفيذ معًا.

أما بالنسبة إلى Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744) فهي تحتاج فقط إلى المراجعة ، وآمل أن نتمكن من الحصول على بعض النطاق الترددي لعقدة سيج لمراجعتها في هذه الدورة.

شكرا على التحديث @ جوزيف ايرفينغ

تمت إضافته إلى ورقة التتبع!

آسف للتأخر عن الحفلة. هذا هو تحسن كبير في الحالات الشائعة. لكن لا يبدو أنه يغطي حالة أكثر تقدمًا.

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

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

ما رأيك في تعريف API هذا بدلاً من ذلك:

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

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

@ kfox1111 كيف يحدد التصميم المقترح أن

لا أعتقد أن تعتمد على تحديد المعايير. يمكن تحديده في الحاوية التابعة. ألن يكون الاستعداد المسبار و / أو StartupProbe - يشير نجاحه إلى أنه يمكن بدء تشغيل الحاويات التابعة.

مرحبًا @ Joseph-Irving ، أنا أحد ظلال مستندات الإصدار 1.18.
هل يتطلب هذا التحسين (أو العمل المخطط له للإصدار 1.18) أي مستندات جديدة (أو تعديلات على المستندات الحالية)؟ إذا لم يكن الأمر كذلك ، فهل يمكنك من فضلك تحديث 1.18 Enhancement Tracker Sheet (أو إعلامي وسأفعل ذلك)

إذا كان الأمر كذلك ، فقط للتذكير الودية نحن نبحث عن علاقات عامة ضد k / موقع الويب (الفرع dev-1.18) بحلول يوم الجمعة ، 28 فبراير ، يمكن أن يكون مجرد عنصر نائب للعلاقات العامة في هذا الوقت. اسمحوا لي أن أعرف إذا كان لديك أي أسئلة!

مرحبًا irvifa ، لقد طرحت عنصرًا نائبًا للعلاقات العامة هنا https://github.com/kubernetes/website/pull/19046

مرحبًا @ Joseph-Irving شكرًا لك على ردك السريع!

rubenhak - أتفق مع @ kfox1111 على أن وجود رسم بياني كامل للاعتماديات يمكن أن يصبح

rgulewich ، هل يمكنك توضيح المزيد ، ما الذي يمكن أن

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

rubenhak يمكن أن تكون هناك دورة في ترتيب التبعية للحاويات ، كيف يقرر k8s / kubelet كسر الدورة وتحديد الترتيب لبدء / إيقاف الحاويات؟ التفكير بصوت عالٍ ربما يكون هذا بمثابة التحقق من صحة واجهة برمجة التطبيقات.

مرحبًا @ جوزيف إيرفينغ ،

مجرد تذكير ودي بتجميد الكود لـ 1.18 في 05 مارس 2020 .

بينما نتتبع عملية تجميد الشفرة ، يرجى سرد / ربط أي من العلاقات العامة التي تعمل عليها من أجل تخريج هذا التحسين!

يا @ jeremyrickard ،

هل العلاقات العامة للتتبع https://github.com/kubernetes/kubernetes/pull/80744
يحتوي PR هذا على تغييرات API ولكن سيتم دمج الالتزامات في PR أعلاه بمجرد انتهاء المراجعة https://github.com/kubernetes/kubernetes/pull/79649

rubenhak يمكن أن تكون هناك دورة في ترتيب التبعية للحاويات ، كيف يقرر k8s / kubelet كسر الدورة وتحديد الترتيب لبدء / إيقاف الحاويات؟ التفكير بصوت عالٍ ربما يكون هذا بمثابة التحقق من صحة واجهة برمجة التطبيقات.

bjhaid ، يمكن أن يقوم جانب API بالتحقق. يعد اكتشاف الحلقة خوارزمية بسيطة ذات تعقيد زمني خطي (تمامًا مثل اجتياز DFS).

قد تكون هناك أيضًا حاجة لإعادة التحقق من الصحة بعد الحقن الجانبي أيضًا.

لقد كنت أفكر في هذا لفترة من الوقت ... معظم المشكلات المتعلقة بالتبعية تتلخص حقًا في شبكات الخدمة. (ربما يمكن للشخص أن يفكر في مثال آخر)

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

لكن من الناحية المثالية ، يجب أن تكون initContainers جميعها قادرة على استخدام شبكة الخدمة أيضًا.

لكن قد تحتاج initContainers إلى بدء حاويات جانبية أخرى.

بينما يمكننا تصميم نوع من نظام التبعية المعقد الذي يتضمن حاويات init وحاويات جانبية وحاويات عادية ، ربما يجب أن يكون لدينا فئتان فقط من السيارات الجانبية؟ السيارات الجانبية العادية ، والسيارات الجانبية للشبكة؟

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

هدم في الاتجاه المعاكس.

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

@ kfox1111 ، يقوم Vault الآن بالحقن السري باستخدام السيارات الجانبية. أي فئة يجب أن تناسب؟ أيضًا ، اعتمادًا على الحالة ، يمكن أن يعتمد الخزنة على شبكة الخدمة ، أو العكس.

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

إذا كان الغرض الوحيد من هذه الفئات هو تحديد الترتيب ، فلماذا لا نفعل ذلك صراحة؟

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

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

ماذا لو أدخلنا حقلاً في الحاوية؟

    // +optional
    Priority int

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

tedyu ، تحتوي التبعية على بيانات وصفية وقيمة أكثر بكثير مقارنةً بـ "الأولوية". يتطلب الأمر 30 سطرًا من كود c ++ لإنتاج ترتيب أولوية بالنظر إلى التبعية https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ . العكس غير ممكن.

فائدة أخرى هي أنه بالنظر إلى الرسم البياني للتبعية ، يمكن بدء حاويات معينة في نفس الوقت.
في المثال التالي: "A -> B، B -> C، D -> C" يمكن تشغيل الحاويات B و D في نفس الوقت إذا تمت تهيئة C. لا أقول إن التنفيذ يجب أن يدعم ذلك ، ولكن على الأقل يمكن أن يكون ذا قيمة كبيرة إذا سمحت واجهة برمجة التطبيقات بمثل هذا التعريف.

لن تعمل أولوية العدد الصحيح بشكل جيد - سيستخدم الأشخاص جميع أنواع الأرقام المختلفة غير المعيارية كما يفعلون مع خاصية CSS z-index (مثل -9999 ).

rubenhak ما
إذا كنت شغوفًا بمثل هذه الميزة ، أقترح عليك إنشاء KEP الخاص بك ونقله إلى مجموعات SIG المختلفة للحصول على تعليقاتهم عليها.

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

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

هذا KEP ليس ميزة GA حتى الآن ، إذا تمت الموافقة على KEP الخاص بك وتنفيذه ، فيمكننا إزالة هذه الميزة. لم يتم استبعاد بعضها البعض بعد.

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

إذا تمت الموافقة على KEP الخاص بك وتنفيذه ، فيمكننا إزالة هذا. لم يتم استبعاد بعضها البعض بعد.

هل _ أبدًا_ سيكونان متنافيين؟

أسأل نفسي ما إذا كانت هذه الميزة ذات قيمة _ حتى إذا _ يتم تمكين أمر بدء تشغيل / إيقاف تشغيل الحاوية بشكل أكثر وضوحًا (والذي أعتقد أنه سيكون رائعًا) من خلال تحسين آخر في المستقبل ... وأنا أفكر نعم.

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

على سبيل المثال ، من المفيد في الكبسولة التي تحتوي على restartPolicy != Always (وهي عبارة عن جراب ينفذ مهمة ، ربما) ، ألا يكون للحاويات المعينة على أنها عربات جانبية أي تأثير على الكبسولة التي تدخل حالة مكتملة.

@ kfox1111 ، يقوم Vault الآن بالحقن السري باستخدام السيارات الجانبية. أي فئة يجب أن تناسب؟ أيضًا ، اعتمادًا على الحالة ، يمكن أن يعتمد الخزنة على شبكة الخدمة ، أو العكس.

لقد عملنا من خلال برامج تشغيل csi المؤقتة بحيث لا تحتاج أشياء مثل vault إلى حاويات جانبية / حاويات init. أعتقد أن هناك سائق قبو في الأشغال.

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

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

هل لديك رابط إلى مناقشة سابقة متعلقة بمخطط التبعية؟

مرحبًا @ جوزيف إيرفينغ ،

تذكير ودي بأننا نقترب بسرعة كبيرة من تجميد الكود في 05 مارس 2020 . لا يبدو أن العلاقات العامة الخاصة بك قد اندمجت بعد ، هل ما زلت تشعر بأنك على الطريق الصحيح لتجميد الكود لهذا التحسين؟

مرحبًا @ jeremyrickard ، تمت مراجعة واجهة برمجة التطبيقات (https://github.com/kubernetes/kubernetes/pull/79649) بشكل أساسي. سنقوم بإغلاق هذه العلاقات العامة والانتقال بالكامل إلى تطبيق العلاقات العامة للتنفيذ حتى يمكن دمج كل (API والتنفيذ) في علاقات عامة واحدة.

تمت مراجعة تطبيق العلاقات العامة (https://github.com/kubernetes/kubernetes/pull/80744) بدقة ، لذلك أحاول الحصول على موافقة عقدة التوقيع لإلقاء نظرة على الموافقة النهائية.

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

أتمنى أن ترى هذا يدخل عن طريق تجميد الكود. سيجعل حل Istio لـ https://github.com/istio/istio/issues/7136 أبسط وأفضل.

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

لقد حاولت الوصول إلى المعتمدين على عقدة سيج بعدة طرق ولكن لم يكن لدي أي ردود. لذلك أنا لست متفائلًا جدًا بأن هذا سيجعلها 1.18.

@ Joseph-Irving تم إنشاء قناة Slack # pr-reviews لهذه الحالات. هل جربت ذلك؟ إنها طريقة للحصول على تصعيد بشأن مراجعات العلاقات العامة. (لم أره هناك)

مرحبًا @ جوزيف إيرفينغ ،

لم يتبق سوى أيام قليلة من تجميد التعليمات البرمجية الآن. هل تريد تأجيل هذا إلى 1.19 بناءً على النطاق الترددي للمراجع؟ أو حاول القيام بالدفع؟

يا @ jeremyrickard ،

لم يستجب لي أحد بخصوص دمج هذه العلاقات العامة في 1.18 لذا أشك بشدة في حدوث ذلك.

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

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

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

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

أنا آسف للتشدق الطويل (لم يتم توجيهه إليك شخصيًا جيريمي أو أي شخص شخصيًا في هذا الشأن) ، لكن هذا كان يأكل روحي ببطء لفترة طويلة الآن.

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

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

dims ربما يمكنك إلقاء بعض الضوء؟

thockin لقد استمعت إليك أثناء مقابلتك في Kubernetes Podcast قبل عام تقريبًا وتحدثت عن المساهمة في Kubernetes. ربما كنت أنت أو أي شخص آخر في حلقة بودكاست أخرى هو الذي شعر بالسوء حقًا لأن KEP الجانبي هذا لم يصل إلى 1.16. حسنًا ، ها نحن ذا مرة أخرى.

يبدو أن هذه المشكلة هي مثال رئيسي على مدى صعوبة المساهمة إذا لم تكن موظفًا في على سبيل المثال. جوجل ، ريدهات أو لاعب كبير آخر.

لقد طلبت في Slack أيضًا المساعدة في مراجعتها ولكن تم إخباري للتو أن هناك تعليقًا واضحًا من قِبل

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

من المرجح أن يواجه أي شخص يقوم بتشغيل أي نوع من الهياكل التي تعتمد على شبكة جانبية ، مشاكل في بدء تشغيل / إيقاف تشغيل الحاوية التي من المحتمل أن يحلها KEP. Ctrl-F لـ "Istio" في هذه التذكرة ، وسترى مجموعة من الإزعاجات المتعلقة بطلب الحاوية.

هل هناك أي مشرفين على Istio هنا؟ الكثير من موظفي Google ، وقد يكون لهم تأثير أكبر مع أفراد K8s داخليًا.

بصفتنا متجرًا لـ Istio / K8s ، فنحن نتجذر تمامًا لك للحصول على هذه الأرض ، @ Joseph-Irving! ✊❤️

مجد لـ @ Joseph-Irving لجعله جانبيًا إلى هذا الحد.

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

لقد كنا نفكر في k8s لفترة من الوقت بسبب هذا ونتطلع حقًا لرؤية هذه الميزة المهمة مدعومة رسميًا.

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

thockin لقد تم الإبلاغ أعلاه أنك وضعت

هناك الكثير من مستخدمي Linkerd الذين ينتظرون بفارغ الصبر هذا أيضًا. انتظر هناك @ جوزيف ايرفينغ ، نحن نتجذر من أجلك.

لست متأكدًا مما إذا كان الجميع هنا قد رأوا ولكن بعد إجراء بعض التنقيب ومشاهدة فيديو kubecon ، وجدت أن Lyft قد فعلت شيئًا مشابهًا لهذا. إليك الالتزام المذكور من مفترق kubernetes الخاص بهم: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

كمتجر Istio + Kubernetes ، كنا ننتظر بفارغ الصبر هذه الميزة. ويزداد إحباطه المتزايد لأنه ينزلق من الإصدار إلى الإصدار.

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

كيف يتم تشغيل istio في السيارة الجانبية عند استخدام برنامج تشغيل istio cni؟ أعتقد أن حاويات init التي تحاول الوصول إلى الشبكة ستظل تفشل في العمل بشكل صحيح كما هو موثق في وثائق المنظمة.

ومن ثم سؤالي أعلاه إذا كانت الشبكة الجانبية هي شيء خاص بها.

يبدو أن هذه المشكلة هي مثال رئيسي على مدى صعوبة المساهمة إذا لم تكن موظفًا في على سبيل المثال. جوجل ، ريدهات أو لاعب كبير آخر.

ههه! ما لا تعرفه هو أن هؤلاء الأشخاص يتعثرون أحيانًا أيضًا!

بجدية ، أنا آسف. لدي أعذار ، لكن هذا سيء لذا لن أزعجني.

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

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

لقد طلبت استثناءً ، دعنا نرى ما إذا كان بإمكاننا محاولة إدخال هذا:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

ربما كنت أنت أو أي شخص آخر في حلقة أخرى من [Kubernetes Podcast] الذي شعر بالسوء حقًا لأن هذا الفيلم الجانبي KEP لم يصل إلى 1.16

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

هل هناك أي مشرفين على Istio هنا؟ الكثير من موظفي Google ، وقد يكون لهم تأثير أكبر مع أفراد K8s داخليًا.

duderino و howardjohn علقا على هذا الموضوع بالفعل.

لكي نكون واضحين ، نحتاج إلى الدمج:
kubernetes / kubernetes # 79649
kubernetes / kubernetes # 80744

هل هناك أي علاقات عامة أخرى يجب أن نتتبعها؟

شكرا!

• فريق التحسينات

شكراً جزيلاً لكل من نشر رسائل دعم (عامة أو خاصة) كانت موضع تقدير كبير ❤️

كان هناك جهد شجاع من قبل أعضاء المجتمع لمحاولة الوصول إلى 1.18 ، بما في ذلك فريق التحرير الذي وافق على طلب التمديد ، ولكن للأسف ، تم اتخاذ قرار بتأجيل ذلك إلى 1.19. يمكنك مشاهدة المحادثة ذات الصلة بدءًا من هذا التعليق: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

على الرغم من عدم دخوله إلى 1.18 ، فقد حظي هذا باهتمام أكبر في الأيام القليلة الماضية مما كان عليه منذ فترة طويلة ، لذلك آمل أن ينتقل هذا الزخم إلى 1.19.

ccjeremyrickard ، kikisdeliveryservice

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

/ معلم الإصدار 1.19.0

تحية للجميع. قامت مجموعة منا بمناقشة هذا الموضوع خلال الأسبوع الماضي.

أولا ، نعتذر عما حدث هنا. نحن لسنا سعداء حيال ذلك.

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

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

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

وقعت هذه الميزة أيضًا ضحية عدم اليقين الإجرائي حول KEPs. بصفتي مراجعًا لنظام KEP ، هل أنا ملزم بأن أكون مراجعًا للرموز؟ لتفويض مراجع كود؟ أو لمجرد قراءة KEP؟ مع نشر KEPs ، كيف نضمن توفر الراعي لمجموعة التغييرات المدرجة في الميزانية في فترة معينة من الإصدارات. إذا كان KEP يمتد على SIGs ، فكيف نضع ميزانية ونخصص الوقت عبر مجموعات SIG؟ نحن بحاجة لتوضيح هذا. سنعمل على بعض مقترحات التغيير KEP (KEP KEPs) لتعزيز تحديد الأدوار في عملية KEP.

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

مع تزايد عدد المستخدمين الذين يتبنون Kubernetes ، نرى عددًا متزايدًا من حالات الحافة الغريبة أو الرقائق التي يتم الإبلاغ عنها في العقدة sig-node. نظرًا لأن دورة حياة Pod هي جوهر Kubernetes ، يجب إجراء أي تغيير يتم إجراؤه على هذا النظام الفرعي بعناية. يجب أن تكون قدرتنا على دمج الميزات الجديدة متوازنة مع رغبتنا في تحسين الموثوقية. كيف نفكر في دورة حياة Pod اليوم مختلفة قليلاً عن الطريقة التي فكرنا بها عندما بدأت هذه الميزة. هذا لا يقلل من حالات الاستخدام التي أدت إلى ذلك بأي شكل من الأشكال ، لكنه يشير إلى أن KEPs طويلة الأمد بحاجة إلى إعادة المراجعة بشكل دوري بمرور الوقت.

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

ماذا يعني ذلك بالنسبة لهذا العلاقات العامة و KEP المرتبط؟ لسنا متأكدين بنسبة 100٪. ربما يعني ذلك أنه لا ينبغي علينا المضي قدماً في هذا الأمر حتى الآن.

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

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

نحتاج إلى SIG Node للمساعدة في تحديد الهدف على المدى المتوسط ​​لأسلوب حياة القرون ، وما هي شهيتهم لأخذ ذلك. إذا كان لنا أن نتفق على أن هذا هو خطوة إضافية نحو الهدف، يمكننا افراج عن ذلك، ولكن ما لم نعرف الهدف، ونحن ربما على القيادة الأمامية لدينا.

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

شكرا،
كلايتون ، ديفيد ، دون ، ديريك ، جون ، تيم

لمحاولة تحفيز بعض الحركة إلى الأمام: Derek أو Dawn - هل هناك أي شخص لديه عقدة سيج يمكن أن يخصص بعض الوقت للقيام ببعض العصف الذهني حول دورة حياة حاوية وحاوية أكثر شمولية؟

thockin سيضيف هذا إلى أجندة sig-node.

thockinderekwaynecarr ماذا يكون ليرة تركية، والدكتور لماذا هذا لا يمكن أن تذهب في؟

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

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

علاوة على ذلك ، هل هناك أي توصيات لبدء تشغيل الشرائح الجانبية قبل حاويات التطبيق الرئيسية وإغلاقها بعد إنهاء حاوية التطبيق الرئيسية اليوم؟

... ما هو TL ؛ دكتور لماذا لا يمكن أن يحدث هذا؟

naseemkullah من https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ... 👇

ماذا يعني ذلك بالنسبة لهذا العلاقات العامة و KEP المرتبط؟ لسنا متأكدين بنسبة 100٪. ربما يعني ذلك أنه لا ينبغي علينا المضي قدماً في هذا الأمر حتى الآن.

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

[...]

نحتاج إلى SIG Node للمساعدة في تحديد الهدف على المدى المتوسط ​​لأسلوب حياة القرون ، وما هي شهيتهم لأخذ ذلك. إذا تمكنا من الاتفاق على أن هذه _ هي _ خطوة تدريجية نحو الهدف ، فيمكننا إلغاء حظرها ، ولكن ما لم نعرف الهدف ، فربما نفرط في قيادة مصابيحنا الأمامية.

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

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

سيضيف هذا إلى جدول أعمال sig-node.

thockinderekwaynecarr هناك أي تعديل حدث في الحالة الراهنة من هذا؟ لقد بحثت في ملاحظات اجتماع sig-node ولا أرى أي شيء عن هذا.

هناك عدد كبير من المطورين في هذا الموضوع سيكونون أكثر من سعداء بالمساهمة بالوقت في تنفيذ هذا ، حيث إنه مهم للعديد من حالات الاستخدام (يحتوي KEP نفسه على 2.5 ضعف: +1: مثل أي KEP آخر). ماذا يمكننا أن نفعل لتحقيق ذلك؟ إن وجود قائمة بالمتطلبات الأساسية لاستقرار هذه المنطقة ، حتى لو امتدت إلى العديد من الإصدارات لتحقيقها ، والتي يمكن أن نبدأ العمل عليها بنشاط سيكون بمثابة تحسن كبير مما نحن عليه اليوم.

مرحبا @ جوزيف ايرفينغthockinkhenidak @ kow3ns - 1.19 تحسينات الرصاص هنا، أردت أن تحقق في إذا كنت تعتقد أن هذا التعزيز يتخرج في 1.19؟

من أجل الحصول على هذا الجزء من الإصدار:

1. يجب دمج KEP PR في حالة قابلة للتنفيذ
2. يجب أن يكون لدى KEP خطط اختبار
3. يجب أن يكون لدى KEP معايير التخرج.

جدول الإصدار الحالي هو:

• الاثنين 13 أبريل: الأسبوع 1 - تبدأ دورة الإصدار
• الثلاثاء 19 مايو: الأسبوع السادس - تجميد التحسينات
• الخميس 25 يونيو: الأسبوع 11 - تجميد الرمز
• الخميس 9 يوليو: الأسبوع 14 - يجب إكمال المستندات ومراجعتها
• الثلاثاء 4 أغسطس: الأسبوع 17 - تم إصدار Kubernetes v1.19.0

palnabarun ، وفقًا لهذا التعليق https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ، تم تعليق KEP هذا إلى أجل غير مسمى ، لذلك لن يتم تخرجه في 1.19.

شكرا لك @ جوزيف ايرفينغ لتوضيح الوضع. : +1:

نقدر جهودكم!

إلى كل من يتوق إلى الحصول على هذا ، ومرة ​​أخرى إلى @ Joseph-Irving - أنا شخصيًا آسف جدًا لهذا الموقف. أريد هذا (أو شيء من هذا القبيل) أيضًا ، ولكن حقيقة الأمر هي أن عقدة سيج لديها عمل أكثر من الأشخاص للقيام به الآن ، وهم ليسوا مستعدين للنظر في ذلك.

تمتص. فهمتها. أنا حقا أفعل.

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

لدى sig-node المزيد من العمل الذي يتعين القيام به أكثر من الأشخاص للقيام به الآن

مفهوم. لقد عززنا ، مع التركيز ، احتياجات قدرة سيج-عقدة داخليًا. نحن نجلب ونوجه متطوعي sig-node OSS ، بعضهم من ذوي الخبرة بعضًا جديدًا ، وكلهم لديهم الرغبة في العمل في هذا المجال (أربعة حتى الآن). سأستشهد بتعليقكthockin ، شكرًا لك!

/ معلم واضح

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

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

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

يرجى الاطلاع على آخر تحديث هنا: https://github.com/kubernetes/enhancements/pull/1874

dims أعتقد أنني قد أسيء فهم. ما قصدته هو أننا بحاجة إلى قائمة من الأهداف والغايات القابلة للتنفيذ. إذا كان هناك ديون تقنية يجب التعامل معها ، فيمكننا الاحتفاظ بـ GitHub Milestone أو تقديم قائمة نقطية بعناصر الإجراءات المعلقة في تعليق OPs حتى يتمكن الأشخاص الذين يزورون هذه المشكلة من معرفة ما يجب معالجته على الفور.

أنا بالتأكيد على استعداد لتقديم مساعدتي للتوقيع / العقدة مع تطوير KEP هذا ، لكن لا أعرف كيف

@ tariq1890 السؤال المحدد موجود هنا: "المتطلبات المسبقة لعقدة kubelet (التي لم يتم تقديمها بعد KEP) إغلاق رشيق" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

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

- يخفت

لذلك ، تلخيص https://github.com/kubernetes/enhancements/pull/1874 لمن هم في هذه المشكلة: تعتقد Sig-node (وآخرون) أنه من غير الحكمة تقديم ميزة جديدة مثل KEP ، والتي تضيف سلوكًا أكثر تعقيدًا إلى إنهاء pod ، بينما لا تزال هناك مشكلة عامة تتمثل في إنهاء pod أثناء إغلاق العقدة.
لذلك تقرر عدم تقدم هذه الميزة حتى يتم تنفيذ حل إنهاء العقدة.
يوجد حاليًا مستند google هنا: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
والذي يحتوي على الكثير من النقاش حول هذه المشكلة ، ولكن لم يتم تقديم KEP لهذا الأمر بعد.
لا تزال هناك أسئلة مفتوحة ، لذا فإن التعليق عليها قد يكون مفيدًا ، وأعتقد أن bobbypage و mrunalp يقودان هذا الجهد ، لذا ربما يمكنهم مشاركة أي طرق أخرى يمكن أن يساعد بها الأشخاص في المضي قدمًا.

@ جوزيف ايرفينغ شكرا جزيلا على التلخيص. آمل أن تُترجم كل الطاقة + الخمسة في هذا التحسين إلى مشاركة أكبر من الجميع في عقدة سيج على أساس منتظم وليس مجرد مرة واحدة للميزات. هناك الكثير من العمل الذي يتعين القيام به وعدد قليل جدًا من الأيدي.

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

أنا أعمل حاليًا على العلاقات العامة لتوضيح هذه المشكلات وبعض البدائل التي يمكنني التفكير فيها.

أيضًا ، أصبحت حالة KEP الآن مؤقتة (بدلاً من كونها قابلة للتنفيذ) لذا يمكن مراجعتها وتعيينها على أنها قابلة للتنفيذ مرة أخرى فقط عندما يتفق جميع الأشخاص على الشعور بالراحة للمضي قدمًا في KEP.

أعتقد أن هذا كان الجزء الوحيد المفقود من المعلومات في هذه المسألة. شكرا!

rata هل فتحت المشكلات / العلاقات العامة بالطريقة الصحيحة للتعامل مع المشكلات؟

mattfarina هذه هي العلاقات العامة https://github.com/kubernetes/enhancements/pull/1913
يحتوي على عدد من الحلول المقترحة للمشاكل الحالية / حالات الحافة في KEP
يحتوي أيضًا على تفاصيل عدد من البدائل التي تمت مناقشتها واتخاذ قرار ضدها ، حتى يكون لدينا سجل أفضل لسبب اتخاذ قرارات معينة.

أرغب بشدة في رؤية وظيفة sidecar تغطي أيضًا القياس:
اليوم ، يعتمد تحجيم HPA على مقياس (مثل وحدة المعالجة المركزية). إذا كان الكبسولة يحتوي على أكثر من حاوية ، فسيتم استخدام المتوسط ​​عبر جميع الحاويات (على حد علمي). بالنسبة للقرون التي تحتوي على sidecar (app + nginx وما إلى ذلك) ، فإن هذا يجعل من الصعب جدًا جعل وظيفة القياس بشكل صحيح. كنت آمل أن يتضمن تنفيذ الجانب الجانبي في Kubernetes وضع علامة على حاوية واحدة في الحاوية على أنها "موثوقة" من حيث المقاييس المستخدمة في تحجيم HPA.

أرغب بشدة في رؤية وظيفة sidecar تغطي أيضًا القياس:

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

هل لدى أي شخص أي إشارة إلى الحل البديل الحالي لهذه المشكلة ، أو يمكن أن يكون لطيفًا جدًا لمشاركته ، وتحديداً في حالة الشخص الجانبي Istio Envoy؟

أتذكر حلًا بديلًا محتملًا يتضمن:

• صورة Envoy مخصصة تتجاهل SIGTERM.
• استدعاء / quitquitquit على Envoy من داخل حاوية التطبيق عند إيقاف التشغيل (على غرار الحل البديل لإكمال المهمة)

هل لدى أي شخص أي إشارة إلى الحل البديل الحالي لهذه المشكلة ، أو يمكن أن يكون لطيفًا جدًا لمشاركته ، وتحديداً في حالة الشخص الجانبي Istio Envoy؟

نستخدم صورة عفريت مخصصة مثل supervisor لإغلاق برنامج المستخدم. سيستمع البرنامج الخفي أيضًا إلى منفذ معين لنقل الحالة الصحية لبرامج المستخدمين (خرجوا أم لا).

هنا هو الحل:

• استخدام صورة الخفي كـ initContainers لنسخ الثنائي إلى وحدة تخزين مشتركة.
• سيختطف CD أمر المستخدمين ، دع البرنامج الخفي يبدأ أولاً. بعد ذلك ، يقوم البرنامج الخفي بتشغيل برنامج المستخدمين حتى يصبح Envoy جاهزًا.
• أيضًا ، أضفنا preStop ، وهو نص برمجي يستمر في التحقق من الحالة الصحية للبرنامج الخفي ، لـ Envoy.

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

إنه حل بديل معقد ، لكنه يعمل بشكل جيد في بيئة الإنتاج لدينا.

الرابط في الوصف يعطي 404

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

وأعتقد أنه ينبغي أن يكون:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

نعم ، تم نقله في https://github.com/kubernetes/enhancements/pull/1913 ، لقد قمت بتحديث الرابط

هل لدى أي شخص أي إشارة إلى الحل البديل الحالي لهذه المشكلة ، أو يمكن أن يكون لطيفًا جدًا لمشاركته ، وتحديداً في حالة الشخص الجانبي Istio Envoy؟

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

كان علينا نقل هذا إلى الإصدار الذي نقوم بتشغيله ولكنه واضح تمامًا ويسعدنا بالنتائج حتى الآن.

بالنسبة للإغلاق ، فإننا أيضًا "نحل" باستخدام خطاف preStop ولكن نضيف سكونًا عشوائيًا نأمل أن يتم إيقاف تشغيل التطبيق بأمان قبل متابعة SIGTERM.

العلاقات العامة ذات الصلة: https://github.com/kubernetes/enhancements/pull/1980

مرحبًا @ Joseph- Irvingthockin والجميع: ابتسم:

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

شكرا!
كيرستن

kikisdeliveryservice سوف

هل لدى أي شخص أي إشارة إلى الحل البديل الحالي لهذه المشكلة ، أو يمكن أن يكون لطيفًا جدًا لمشاركته ، وتحديداً في حالة الشخص الجانبي Istio Envoy؟

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

كان علينا نقل هذا إلى الإصدار الذي نقوم بتشغيله ولكنه واضح تمامًا ويسعدنا بالنتائج حتى الآن.

بالنسبة للإغلاق ، فإننا أيضًا "نحل" باستخدام خطاف preStop ولكن نضيف سكونًا عشوائيًا نأمل أن يتم إيقاف تشغيل التطبيق بأمان قبل متابعة SIGTERM.

هل يمكنك إظهار بعض الأفكار بالتفصيل عن كيفية القيام بذلك؟ كيف يمكن تحقيق إضافة "توقف مسبق" إلى السيارة الجانبية Istio-proxy؟ يبدو أنه يحتاج إلى بعض التهيئة المخصصة أو استخدام عربة جانبية مخصصة. أواجه نفس المشكلة التي عندما تنخفض البودات ، تحاول الحاوية الرئيسية إنهاء المهام لكنها تفقد الاتصال بالخارج على الأرجح لأن Istio-sidecar أغلق فورًا بعد SIGTERM. الآن أنا فقط أستخدم الحقن الجانبي الافتراضي. شكرا لك!

حسنًا ، هذا الموضوع يتم اختطافه. دعنا نبقى في الموضوع ، من فضلك.

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

يستخدم KEP أيضًا تنسيقًا قديمًا ، لذا سيكون التحديث رائعًا (بمجرد الانتهاء من صياغة التفاصيل): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

kikisdeliveryservice شكرا على الباقي. سيفعل إذا تقرر تضمينه في 1.20. شكرا! :)

لن يكون هذا جزءًا من 1.20. شكرا جزيلا على pinging! :)

لدي اهتمام بهذه المشكلة ، وأردت أن أشكر كل من @ Joseph-Irving و howardjohn على

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

يمكنني تخيل الحلول التالية لهذه المشكلة -

1. تحديد كيان حاوية جديد "حاوية جانبية" تبدأ بعد initContainers ، قبل "الحاويات الرئيسية" ، وتنتهي بعد إنهاء "الحاويات الرئيسية" (وفقًا للاقتراح الأصلي @ Joseph-Irving)
2. حدد حقلاً إضافيًا في (1) يحدد ما إذا كانت "حاوية السيارة الجانبية" تبدأ قبل initContainer لكل اقتراح luksa ).
3. انطلق على نطاق أوسع.

شخصيًا ، الخيار (2) يحل مشكلتي الفورية.

لكني أتساءل عما إذا كانت هذه الأسئلة لا تتحدث عن مشكلة أكثر استراتيجية في K8s حول الجدولة وكيف نحدد الكبسولة. في حالتي الخاصة (المتعلقة بـ Istio) ، اقترحت شيئًا مثل مستويات التشغيل داخل القرون.

الخيار (2) يحل مشكلتي أيضًا ، لكن يمكنني تخيل هياكل تبعية أكثر تعقيدًا والتي قد تتطلب تضمين DAG من تبعيات الحاوية داخل pod / statefulSet / daemonSet / أيا كان - هذا هو الخيار (3) الذي أفكر فيه.

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

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

michalzxc إذا لم أكن مخطئًا ، يتم تنفيذ حاويات init واحدة تلو الأخرى بالتتابع ، لذلك لا يمكنك حاليًا أن يكون لديك مبعوث بجوار حاوية أخرى كـ init-container .

أهلا!

استمرت المناقشة الجانبية في هذه الأماكن (لقد قمت بتحديث sig-node Slack ، و github PR الذي بدأ هذا والعديد من القوائم البريدية):
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

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

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

لن يتقدم برنامج KEP هذا ، ويشعر Sig-node وآخرون أن هذه ليست خطوة تدريجية في الاتجاه الصحيح ، لذا فقد عادوا إلى لوحة الرسم وسيخرجون ببعض KEPs الجديدة التي نأمل أن تحل جميع الاستخدامات الحالات المذكورة في هذا KEP بالإضافة إلى حالات أخرى.

يرجى الاطلاعrata الصورة التعليق السابق https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
للأماكن حيث يمكنك المساهمة في المناقشة.

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

/أغلق

@ جوزيف ايرفينغ: إغلاق هذه القضية.