/ عقدة سيج
/ نوع الميزة
سم مكعبConnorDoylebalajismaniamnolancon

يمكنني المساعدة في تصميم هذا التصميم بناءً على التعلم من Borg. لذا احسبني كمراجع / موافق.

يمكنني المساعدة في تصميم هذا التصميم بناءً على التعلم من Borg. لذا احسبني كمراجع / موافق.

هل هناك أي وثائق عامة حول كيفية عمل هذه الميزة في البرج؟

ليس عن NUMA AFAIK.

في الإثنين ، 11 فبراير ، 2019 ، الساعة 7:50 صباحًا ، كتب جيريمي إيدير < [email protected] :

يمكنني المساعدة في تصميم هذا التصميم بناءً على التعلم من Borg. لذا احسبني
كمراجع / موافق.

هل هناك أي وثائق عامة حول كيفية عمل هذه الميزة في البرج؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/enhancements/issues/693#issuecomment-462378195 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AGvIKPfanjb9Q5DxXAiBgv9C6Y809JX0ks5vMZFZgaJpZM4aE3uz
.

لمعلوماتك @ claurence

مشكلة التتبع هذه و KEP (https://github.com/kubernetes/enhancements/pull/781) لم يتم إجراؤها في الوقت المناسب لتجميد تحسينات الإصدار 1.14 أو الموعد النهائي الممتد. أقدر أنك قمت بفتحها قبل المواعيد النهائية ، لكن يبدو أنها لم تحصل على مراجعة كافية أو موافقة. سيحتاج هذا إلى المرور بعملية الاستثناء.

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

المرجع: https://github.com/kubernetes/kubernetes/issues/72828

/ سم مكعبjiayingz @ dchen1107

lmdaly أرى أن لديك 1.14 مدرجًا في الوصف باعتباره معلم ألفا - نظرًا لعدم وجود KEP مدمج قابل للتنفيذ ، لا يتم تتبع هذه المشكلة لـ 1.14 - إذا كانت هناك نوايا لإدراجها في هذا الإصدار ، يرجى تقديم طلب استثناء.

lmdaly أرى أن لديك 1.14 مدرجًا في الوصف باعتباره معلم ألفا - نظرًا لعدم وجود KEP مدمج قابل للتنفيذ ، لا يتم تتبع هذه المشكلة لـ 1.14 - إذا كانت هناك نوايا لإدراجها في هذا الإصدار ، يرجى تقديم طلب استثناء.

تم الآن دمج claurence ، KEP (تم دمج KEP مسبقًا في الريبو المجتمعي. كان هذا فقط لنقله إلى مستودع التحسينات الجديد وفقًا للإرشادات الجديدة) ، هل ما زلنا بحاجة إلى إرسال طلب استثناء لتعقب هذه المشكلة 1.14؟

أثناء قراءة التصميم و PRs PRs بالكامل ، يساورني مخاوف من أن التنفيذ الحالي ليس عامًا مثل تصميم الهيكل الأصلي الذي اقترحناه في https://github.com/kubernetes/enhancements/pull/781. يقرأ هذا حاليًا أكثر مثل طوبولوجيا NUMA في مستوى العقدة.

تركت بعض التعليقات لمزيد من المناقشة هنا: https://github.com/kubernetes/kubernetes/pull/74345#discussion_r264387724

التطبيق الحالي ليس عام

شارك نفس القلق بشأن ذلك :) ماذا عن الآخرين ، على سبيل المثال الروابط بين الجهاز (nvlinke for GPU)؟

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

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

أعتقد أن المشكلة الرئيسية التي أراها مع التنفيذ الحالي والقدرة على دعم التقارب بين الأجهزة هي ما يلي:

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

على سبيل المثال ، مع وحدات معالجة الرسومات Nvidia ، للحصول على اتصال مثالي ، تحتاج أولاً إلى البحث عن مجموعة وحدات معالجة الرسومات وتخصيصها مع NVLINKs الأكثر اتصالاً _ قبل تحديد تقارب المقبس الذي تمتلكه هذه المجموعة.

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

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

ربما أكون في حيرة من أمري بشأن التدفق بطريقة ما. هكذا أفهمها:

1) عند التهيئة ، تسجل المكونات الإضافية للجهاز (وليس devicemanager ) نفسها بـ topologymanager حتى تتمكن من إصدار عمليات رد نداء عليها في وقت لاحق.

2) عند إرسال الكبسولة ، يستدعي kubelet lifecycle.PodAdmitHandler على topologymanager .

3) يستدعي lifecycle.PodAdmitHandler GetTopologyHints على كل مكون إضافي للجهاز

4) يقوم بعد ذلك بدمج هذه التلميحات لإنتاج TopologyHint موحد مرتبط بالجراب

5) إذا قررت قبول الكبسولة ، فإنها ستعود بنجاح من lifecycle.PodAdmitHandler وتخزين TopologyHint للحجرة في متجر محلي محلي

6) في وقت ما في المستقبل ، cpumanager و devicemanager call GetAffinity(pod) على مدير topology لاسترداد TopologyHint المرتبط مع الجراب

7) يستخدم cpumanager تلميح Topology هذا لتخصيص وحدة المعالجة المركزية

8) يستخدم devicemanager تلميح الطبولوجيا هذا لتخصيص مجموعة من الأجهزة

9) يستمر تهيئة الكبسولة ...

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

إذا كانت هذه التلميحات تهدف إلى ترميز "التفضيلات" للتخصيص ، فأنا أعتقد أن ما تقوله هو أن يكون لديك بنية مثل:

type TopologyHints struct {
    hints []struct {
        SocketID int
        DeviceIDs []int
    }
}

حيث لا نمرر فقط قائمة تفضيلات تقارب المقبس ، ولكن كيف تقترن تفضيلات تقارب المقبس مع تفضيلات GPU القابلة للتخصيص.

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

هل هناك شيء في مكان يسمح لي بذلك بالفعل وقد فاتني؟

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

أعتقد أن ما يحدث ، إجراء بعض التصحيحات _ الثانوية_ لتدفقك هو:

1. عند التهيئة ، تسجل المكونات الإضافية للجهاز نفسها بـ devicemanager حتى تتمكن من إصدار عمليات رد نداء عليها في وقت لاحق.

2. يستدعي lifecycle.PodAdmitHandler GetTopologyHints على كل مكون مدرك للطوبولوجيا في Kubelet ، حاليًا devicemanager و cpumanager .

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

من أجل هذا:

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

هذا ما تم تقديم topologymanager نفسه لتحقيقه. من إحدى المسودات السابقة ،

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

أرى.

لذا فإن كلا من devicemanager و cpumanager يطبقان GetTopologyHints() بالإضافة إلى استدعاء GetAffinity() ، لتجنب تفاعل الاتجاه من topologymanager مع أي مكونات إضافية للجهاز . بالنظر عن كثب إلى الكود ، أرى أن devicemanager ببساطة بتفويض التحكم إلى المكونات الإضافية للمساعدة في ملء TopologyHints ، وهو أمر منطقي أكثر في النهاية على أي حال.

بالعودة إلى السؤال / المشكلة الأصلية التي أثرتها على الرغم من ...

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

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

على سبيل المثال ، ضع في اعتبارك الشكل أدناه ، عند محاولة تخصيص 2 GPU لحجرة ذات اتصال مثالي:

تحتوي مجموعات GPU المكونة من (2 ، 3) و (6 ، 7) على 2 NVLINKs وتوجد على نفس ناقل PCIe. لذلك يجب اعتبارهم مرشحين متساويين عند محاولة تخصيص وحدتي GPU للحجرة. اعتمادًا على المجموعة المختارة ، من الواضح أنه سيتم تفضيل مقبس مختلف لأن (2 ، 3) متصل بالمقبس 0 و (6 ، 7) متصل بالمقبس 1.

ستحتاج هذه المعلومات إلى أن يتم ترميزها بطريقة ما في بنية TopologyHints بحيث يمكن لـ devicemanager تنفيذ أحد هذه التخصيصات المرغوبة في النهاية (على سبيل المثال ، أيًا كان ما يُدعى topologymanager يدمج التلميحات نازل إلى). وبالمثل ، فإن التبعية بين تخصيصات الجهاز المفضلة والمقبس المفضل يجب أن يتم ترميزها بـ TopologyHints بحيث يمكن لـ cpumanager تخصيص وحدات المعالجة المركزية من المقبس الصحيح.

قد يبدو الحل المحتمل الخاص بوحدات معالجة الرسومات Nvidia لهذا المثال مشابهًا لما يلي:

type TopologyHint struct {
    SocketID int
    DeviceIDs []int
}

type TopologyHints []TopologyHint

devicemanagerhints := &TopologyHints{
    {SocketID: 0, DeviceIDs: []int{2, 3}},
    {SocketID: 1, DeviceIDs: []int{6, 7}},
}

cpumanagerhints := &TopologyHints{
    {SocketID: 1},
}

حيث يقوم topologymanager بدمج هذه التلميحات لإرجاع {SocketID: 1, DeviceIDs: []int{6, 7}} كتلميح مفضل عند استدعاء GetAffinity() devicemanager و cpumanager لاحقًا GetAffinity() .

في حين أن هذا قد يوفر أو لا يوفر حلاً عامًا كافياً لجميع المسرعات ، فإن استبدال SocketMask في TopologyHints Struct بشيء منظم إلى حد كبير مثل ما يلي سيسمح لنا بتوسيع تلميح فردي بمزيد من الحقول في المستقبل:

لاحظ أن GetTopologyHints() لا يزال يُرجع TopologyHints ، بينما GetAffinity() تم تعديله لإرجاع TopologyHint بدلاً من TopologyHints .

type TopologyHint struct {
    SocketID int
}

type TopologyHints []TopologyHint

&TopologyHints{
    {SocketID: 0},
    {SocketID: 1},
}

type HintProvider interface {
    GetTopologyHints(pod v1.Pod, container v1.Container) TopologyHints
}

type Store interface {
    GetAffinity(podUID string, containerName string) TopologyHint
}

أفكار؟

klueska ربما

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

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

عند التخصيص ، يستدعي مدير الجهاز GetAffinity للحصول على تخصيص المقبس المطلوب (دعنا نقول أن المقبس هو 1 في هذه الحالة) ، باستخدام هذه المعلومات والمعلومات التي يتم إرسالها مرة أخرى بواسطة المكونات الإضافية للجهاز ، يمكنه رؤية أنه في المقبس 1 يجب تعيين الأجهزة ( 6،7) لأنها أجهزة NV Link.

هل هذا منطقي أم أن هناك شيئًا أفتقده؟

شكرا لأخذ الوقت لتوضيح هذا معي. لابد أنني أساءت تفسير اقتراحConnorDoyle الأصلي:

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

قرأت هذا على أنه الرغبة في تمديد TopologyHints هيكلة بمعلومات من نقطة إلى نقطة مباشرة.

يبدو أنك تقترح بدلاً من ذلك أن يتم تمديد واجهة برمجة التطبيقات الإضافية للجهاز فقط لتوفير معلومات من نقطة إلى نقطة إلى devicemanager ، حتى يتمكن من استخدام هذه المعلومات لإعلام SocketMask لتعيينه في TopologyHints Struct عندما يتم استدعاء GetTopologyHints() .

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

في الوقت الحالي ، لدينا حل مخصص في Nvidia يقوم بتصحيح kubelet للقيام بشكل أساسي بما تقترحه (باستثناء أننا لا نتخلى عن أي قرارات تتعلق بالمكونات الإضافية للجهاز - devicemanager تم جعل GPU على دراية واتخاذ قرارات تخصيص GPU المستندة إلى الهيكل نفسه).

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

شكرا مرة أخرى لأخذ الوقت لتوضيح كل شيء.

مرحبًا lmdaly ، أنا

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

هذه الميزة ستكون بوابة الميزة الخاصة بها ، وستكون ألفا.

/ معلم 1.15

derekwaynecarr : المعلم المقدم غير صالح لهذا المستودع. المراحل الرئيسية في هذا المستودع: [ keps-beta ، keps-ga ، v1.14 ، v1.15 ]

استخدم /milestone clear لمسح المرحلة الرئيسية.

/ معلم v1.15

/ تعيينlmdaly

https://github.com/kubernetes/kubernetes/issues/72828

كود العلاقات العامة

تضمين التغريدة
https://github.com/kubernetes/kubernetes/issues/72828
أنا وفريقي نفكر في اختبار مدير الهيكل للتطبيق الحساس لـ numa.
إذن ، لدينا بعض الأسئلة.
أعلاه العلاقات العامة ، هل هذه الضمانات الكاملة لمدير الطوبولوجيا؟
وهل تم اختباره أم أنه مستقر الآن؟

@ bg-chun نحن نفعل الشيء نفسه في Nvidia. لقد قمنا بسحب هذه العلاقات العامة الخاصة بـ WIP في مكدسنا الداخلي وقمنا ببناء إستراتيجية تخصيص مدركة لطوبولوجيا لوحدات المعالجة المركزية / وحدات معالجة الرسومات حولها. من خلال القيام بذلك ، اكتشفنا بعض المشكلات وقدمنا ​​بعض التعليقات المحددة حول هذه العلاقات العامة.

يرجى الاطلاع على موضوع المناقشة هنا لمزيد من التفاصيل:
https://kubernetes.slack.com/archives/C0BP8PW9G/p1556371768035800

مرحبًا ، lmdaly أنا ظل إصدار مستندات v1.15.

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

مجرد تذكير ودي ، نحن نبحث عن علاقات عامة ضد k / website (فرع dev-1.15) بحلول يوم الخميس ، 30 مايو. سيكون من الرائع أن تكون هذه هي بداية التوثيق الكامل ، ولكن حتى العنصر النائب PR مقبول. اسمحوا لي أن أعرف إذا كان لديك أي أسئلة! 😄

lmdaly مجرد تذكير ودي ، نحن نبحث عن

مرحبا lmdaly . تجميد الرمز يوم الخميس ، 30 مايو 2019 @ EOD PST . يجب أن تكون جميع التحسينات المدخلة على الإصدار كاملة التعليمات البرمجية ، بما في ذلك الاختبارات ، وأن يكون لديك مستندات PRs مفتوحة.

سيتم الاطلاع على https://github.com/kubernetes/kubernetes/issues/72828 لمعرفة ما إذا كان قد تم دمج الكل.

إذا كنت تعلم أن هذا سيتأخر ، فيرجى الرد وإخبارنا. شكرا!

daminisatya لقد دفعت مستند العلاقات العامة. https://github.com/kubernetes/website/pull/14572

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

شكرا lmdaly ✨

مرحبًا lmdaly ، اليوم هو تجميد الكود لدورة الإصدار 1.15. لا يزال هناك عدد غير قليل من k / k PRs التي لم يتم دمجها بعد من مشكلة التتبع الخاصة بك https://github.com/kubernetes/kubernetes/issues/72828. يتم الآن تصنيفها على أنها معرضة للخطر في ورقة تتبع التحسين 1.15 . هل هناك ثقة عالية سيتم دمجها بواسطة EOD PST اليوم؟ بعد هذه النقطة ، سيتم السماح فقط بقضايا حظر الإصدار والعلاقات العامة في الحدث الرئيسي مع استثناء.

/ معلم واضح

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

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

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

شكرا لك.

@ kacole2 شكرا للتذكير. ستدخل هذه الميزة كـ Alpha في 1.16.

يمكن العثور على القائمة المستمرة للعلاقات العامة هنا: https://github.com/kubernetes/kubernetes/issues/72828

شكرا!

توافق على أن هذا سيهبط في alpha لـ 1.16 ، سنقوم بإغلاق الجهد الذي بدأ والتقاطه في kep المدمج مسبقًا لـ 1.15.

مرحبًا lmdaly ، أنا ظل إصدار مستندات v1.16.

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

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

شكرا!

وثائق العلاقات العامة: https://github.com/kubernetes/website/pull/15716

lmdaly هل سيوفر مدير الهيكل أي معلومات أو واجهة برمجة تطبيقات لإعلام المستخدمين بتكوين NUMA للجزء المحدد؟

mJace شيء مرئي عبر kubectl يصف للحجرة؟

lmdaly نعم ، kubectl describe جيد. أو بعض واجهات برمجة التطبيقات لعرض المعلومات ذات الصلة.
نظرًا لأننا نعمل على تطوير خدمة لتوفير بعض المعلومات المتعلقة بالطوبولوجيا للقرون ، مثل حالة تثبيت وحدة المعالجة المركزية للقرص ، وعقدة numa الخاصة بها VF التي تم تمريرها.
ويمكن لبعض أدوات المراقبة مثل نطاق النسج استدعاء API للقيام ببعض الأعمال الفاخرة.
يمكن للمسؤول معرفة ما إذا كان VNF قيد التكوين الصحيح للأرقام ، على سبيل المثال.

فقط أحب أن أعرف ما إذا كان مدير الطبولوجيا سيغطي هذا الجزء.
أو إذا كان هناك أي عمل يمكننا القيام به إذا خطط Topology Manager لدعم هذا النوع من الوظائف.

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

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

أرى ، أعتقد أن وحدة المعالجة المركزية ومدير الأجهزة قادران على رؤية هذه المعلومات.

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

لقد قمت بإنشاء مشكلة ذات صلة في cadvisor.
https://github.com/google/cadvisor/issues/2290

/تعيين

+1 لمقترح mJace cadvisor.

لاستخدام DPDK lib داخل الحاوية مع CPU Manager و Topology Manager ، تحليل تقارب وحدة المعالجة المركزية للحاوية ثم تمريرها إلى dpdk lib ، كلاهما مطلوب لتثبيت مؤشر ترابط DPDK lib.

لمزيد من التفاصيل ، إذا كان cpus غير مسموح به في النظام الفرعي cgroup cpuset الخاص بالحاوية ، فسيتم تصفية المكالمات إلى sched_setaffinity لتثبيت العملية على cpus.
يستخدم DPDK lib pthread_setaffinity_np لتثبيت الخيط ، و pthread_setaffinity_np عبارة عن غلاف على مستوى الخيط sched_setaffinity .
ويقوم مدير وحدة المعالجة المركزية في Kubernetes بتعيين cpus حصريًا على النظام الفرعي cgroup cpuset الخاص بالحاوية.

@ bg-chun لقد فهمت أن تغيير cadvisor على أنه يخدم غرضًا مختلفًا: المراقبة. بالنسبة لمتطلباتك ، من الممكن قراءة وحدات المعالجة المركزية المخصصة من داخل الحاوية عن طريق تحليل "Cpus_Allowed" أو "Cpus_Allowed_List" من "/ proc / self / status". هل هذا النهج يعمل من أجلك؟

معلومات ConnorDoyle في / proc / * / status مثل Cpus_Allowed تتأثر بـ sched_setaffinity . لذلك ، إذا قام التطبيق بتعيين شيء ما ، فسيكون مجموعة فرعية مما هو مسموح به بالفعل بواسطة وحدة تحكم Cgroup's cpuset .

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

تضمين التغريدة
شكرا لك على اقتراحك ، سوف أعتبره.
كانت خطتي تنشر خادم mini-rest-api لإخبار معلومات تخصيص وحدات المعالجة المركزية الحصرية بحاوية dpdk.

فيما يتعلق بالتغييرات ، لم أشاهد تغييرات cadvisor حتى الآن ، لا أرى سوى الاقتراح .
يقول الاقتراح able to tell if there is any cpu affinity set for the container. في الهدف و to tell if there is any cpu affinity set for the container processes. في العمل المستقبلي.

بعد قراءة الاقتراح ، اعتقدت أنه سيكون من الرائع أن يتمكن cadvisor من تحليل معلومات تثبيت وحدة المعالجة المركزية وتمريرها kubelet إلى الحاوية كمتغير بيئة مثل status.podIP ، metadata.name ، و limits.cpu .
هذا هو السبب الرئيسي لمغادرتي +1.

@ bg-chun يمكنك التحقق من العلاقات العامة الأولى في cadvisor
https://github.com/google/cadvisor/pull/2291

لقد أنهيت بعض الوظائف المماثلة في.
https://github.com/mJace/numacc
ولكن لست متأكدًا حقًا من الطريقة الصحيحة لتنفيذه في cadvisor
لهذا السبب أقوم فقط بإنشاء علاقات عامة مع ميزة جديدة واحدة -> إظهار PSR.

ولكن لست متأكدًا حقًا من الطريقة الصحيحة لتنفيذه في cadvisor

ربما يمكننا مناقشة هذا في إطار هذا الاقتراح؟ إذا كنت تعتقد أن هذه الميزة مطلوبة :)

تجميد كود lmdaly لـ 1.16 يوم الخميس 8/29. سنتعقب https://github.com/kubernetes/kubernetes/issues/72828 لملفات k / k PR المتبقية

@ kacole2 يتم دمج جميع العلاقات العامة المطلوبة لهذه الميزة أو في قائمة انتظار الدمج.

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

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

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

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

شكرا!

/ معلم واضح

lmdaly هل هناك رابط مباشر

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

@ moshe010nickolaevlmdaly، ونحن أيضا النظر في هذه الحالة استخدام المتعلقة RDMA وGPU توجيه. نود أن نتعاون في هذا. من الممكن أن تبدأ موضوع / مناقشة حول هذا؟

مرحبا! لدي سؤال حول NTM وجدولة. كما أفهم ، لا يعرف المجدول عن NUMAs ويمكنه تفضيل العقدة على عدم وجود موارد (وحدة المعالجة المركزية والذاكرة والجهاز) على NUMA المطلوب. لذا سيرفض مدير الهيكل تخصيص الموارد على تلك العقدة. هل هذا صحيح؟

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

أنا سعيد حقًا برؤية هذه الميزة. نحتاج أيضًا إلى وحدة المعالجة المركزية وصفحة Hugepage و SRIOV-VFs وغيرها من الأجهزة في عقدة NUMA واحدة.
لكن صفحة hugepage لا تدرك أنها مورد قياسي من خلال البرنامج المساعد للجهاز ، فهل تحتاج هذه الميزة إلى تغيير ميزة hugepage في k8s؟
تضمين التغريدة

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

ConnorDoyle هنا بعض التفاصيل
https://gist.githubusercontent.com/jianzzha/c2a66a2514c178cca76a432029ff3387/raw/264f13dfcd06f1f80c48c113aa235fab7c33d81e/hyper٪2520threading٪2520enabled

jianzzha ، ما هو المكون الإضافي للجهاز الذي تستخدمه؟ على سبيل المثال ، إذا كنت تستخدم المكوّن الإضافي لجهاز SR-IOV ، فأنت بحاجة إلى التأكد من أنه يُبلغ عن عقدة NUMA ، انظر [1]

[1] https://github.com/intel/sriov-network-device-plugin/commit/000db15405f3ce3b7c2f9feb180c3051aa3f7aea.

andyzheung تتم حاليًا مناقشة تكامل الصفحة الضخمة وتم تقديمه في اجتماع sig-node خلال الأسبوعين الماضيين. فيما يلي بعض الروابط ذات الصلة:

https://docs.google.com/presentation/d/1H5xhCjgCZJjdTm-mGUFwqoz8XmoVd8xTCwJ1AfVR_54/edit؟usp=sharing
https://github.com/kubernetes/enhancements/pull/1245
https://github.com/kubernetes/enhancements/pull/1199

jianzzha فيما يتعلق بعدم إعطاء البرنامج المساعد للجهاز تلميحات. هل تم تحديث المكون الإضافي الخاص بك للإبلاغ عن معلومات NUMA حول الأجهزة التي يقوم بتعدادها؟ يحتاج إلى إضافة هذا الحقل إلى رسالة الجهاز https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/deviceplugin/v1beta1/api.proto#L100

شكرا يا شباب. ثابت ويعمل الآن.

تضمين التغريدة
بخصوص nvidia-gpu-device-plugin ..
يمكنني رؤية علاقات عامة نشطة واحدة فقط
هل سيتم تحديث البرنامج المساعد nvidia-gpu-divice-plugin لتقديم تلميح طبولوجيا مع العلاقات العامة أعلاه؟ أو هل هناك شيء أفتقده؟

@ bg-chun نعم ينبغي أن يكون. فقط أزعج المؤلف. إذا لم يعد في اليوم التالي أو نحو ذلك ، فسوف أقوم بتحديث المكون الإضافي بنفسي.

@ bg- chunklueska لقد قمت بتحديث التصحيح.

تضمين التغريدة
شكرا لك على التحديث والإشعار.
سأقدم تحديث sr-iov-plugin وتحديث gpu-plugin للمستخدمين في مساحة العمل الخاصة بي.

أود أن أقترح تحسين للإصدار القادم.
يتعلق الأمر بشكل أساسي بإزالة "محاذاة الهيكل تحدث فقط إذا كان Pod في قيود QoS المضمونة".
هذا النوع من التقييد يجعل Topology Manager غير قابل للاستخدام بالنسبة لي في الوقت الحالي ، لأنني لا أرغب في طلب وحدات المعالجة المركزية الحصرية من K8s ، ومع ذلك أرغب في محاذاة مآخذ الأجهزة المتعددة ، القادمة من مجموعات متعددة (مثل GPU + SR -IOV VFs إلخ.)
وأيضًا ماذا لو كان عبء عملي غير حساس للذاكرة ، أو لا أرغب في تقييد استخدام الذاكرة (معايير أخرى لجودة الخدمة المضمونة).
في المستقبل ، عندما نأمل أن تتم محاذاة hugepages ، سيشعر هذا القيد بمزيد من تقييد IMO.

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

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

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

هذا هو العنصر رقم 8 في قائمة المهام الخاصة بنا لـ 1.17:
https://docs.google.com/document/d/1YTUvezTLGmVtEF3KyLOX3FzfSDw9w0zB-s2Tj6PNzLA/edit#heading = h.xnehh6metosd

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

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

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

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

+1 لإزالة قيود فئة QoS على محاذاة الهيكل (أضفته إلى القائمة: مبتسم :). لم أفهم أن Levovar تطلب تمكين الطوبولوجيا على أساس كل مورد ، فقط أنه يجب علينا محاذاة جميع الموارد القابلة للمحاذاة التي تستخدمها حاوية معينة.

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

IMO في المراحل المبكرة جدًا من التصميم على الأقل كان هناك علم على مستوى Pod إذا كانت ذاكرتي تخدمني جيدًا ، لكنها كانت حوالي 1.13: D
أنا شخصياً بخير لمحاولة مواءمة جميع الموارد طوال الوقت ، ولكن "في الأيام الماضية" كان هناك عادةً معارضة من المجتمع ضد الميزات التي قد تؤدي إلى تأخير بدء التشغيل ، أو في قرار الجدولة لجميع Pods ، بغض النظر عما إذا إنهم حقًا بحاجة إلى التحسين أم لا.

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

ومع ذلك ، إذا لم يكن هناك رد الآن ضد التحسين العام ، فأنا رائع تمامًا مع ذلك :)

mrbobbytables نحن نخطط لتخريج TopologyManager إلى beta في 1.17. مشكلة التتبع هنا: https://github.com/kubernetes/kubernetes/issues/83479

@ bg- chunklueska لقد قمت بتحديث التصحيح.

تم دمج التصحيح:
https://github.com/NVIDIA/k8s-device-plugin/commit/cc0aad87285b573127add4e487b13434a61ba0d6

تم إنشاء إصدار جديد مع التصحيح:
https://github.com/NVIDIA/k8s-device-plugin/releases/tag/1.0.0-beta2

تتبع بيتا للإصدار 1.17

رائع ، شكرًا لك derekwaynecarr . سأضيفه إلى الورقة :)
/ المرحلة بيتا

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

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

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

شكرا!

@ VineethReddy02 نعم ، لقد خططنا لتحديثات التوثيق لـ 1.17 ، إذا كان بإمكانك تحديث ورقة التعقب ، فسيكون ذلك رائعًا!

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

توجد مشكلة لتتبع الوثائق لهذا هنا: https://github.com/kubernetes/kubernetes/issues/83482

https://github.com/kubernetes/enhancements/pull/1340
يا رفاق ، فتحت KEP update PR لإضافة تسمية عقدة مضمنة ( beta.kubernetes.io/topology ) لـ Topology Manager.
ستكشف التسمية عن سياسة العقدة.
أعتقد أنه سيكون من المفيد جدولة الكبسولة إلى العقدة المعينة عندما تكون هناك عُقد ذات سياسات متعددة في نفس المجموعة.
هل لي أن أطلب مراجعة؟

مرحباlmdalyderekwaynecarr

جيريمي من فريق التحسينات 1.17 هنا 👋. هل يمكنك من فضلك سرد k / k PRs الموجودة في الرحلة لهذا حتى نتمكن من تعقبها؟ أرى أنه تم دمج # 83492 ، ولكن يبدو أن هناك عددًا قليلاً من المشكلات ذات الصلة التي تتدلى من عنصر التتبع الكلي. نحن بصدد إغلاق Code Freeze في 14 نوفمبر ، لذلك نود الحصول على فكرة عن كيفية حدوث ذلك قبل ذلك الحين! شكرا جزيلا!

jeremyrickard هذه هي مشكلة التتبع لـ 1.17 كما هو مذكور أعلاه: https://github.com/kubernetes/enhancements/issues/693#issuecomment -538123786

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

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

Docs PR هنا راجع للشغل: https://github.com/kubernetes/website/pull/17451

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

لا تهتم ، أرى في https://github.com/kubernetes/kubernetes/issues/85093 أنك ستنتقل إلى الإصدار التجريبي في 1.18 الآن ، وليس كجزء من 1.17. هل تريد منا تتبع هذا كتغيير رئيسي في إصدار ألفا كجزء من 1.17 معلمklueska؟ أم مجرد تأجيل التخرج إلى 1.18؟

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

يا @ klueska

1.18 التحسينات فريق التدقيق في! هل ما زلت تخطط للخروج من هذا الإصدار إلى الإصدار التجريبي 1.18؟ سيكون تجميد التحسين في 28 كانون الثاني (يناير) ، إذا تطلب KEP أي تحديثات ، بينما سيكون تجميد الرمز في الخامس من آذار (مارس).

شكرا لك!

نعم.

@ klueska شكرا على التحديث! تحديث ورقة التتبع.

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

/ معلم واضح

vpickard الرجاء انظر أعلاه

vpickard الرجاء انظر أعلاه

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

https://github.com/kubernetes/kubernetes/pull/87645

jeremyrickard هل هناك نموذج لخطة اختبار يمكنك أن تشير إليه كمرجع؟

vpickard يمكنك إلقاء نظرة على:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190530-pv-health-monitor.md#test -plan
و
https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20200120-skip-permission-change.md#test -plan

قم بتضمين نظرة عامة على اختبارات الوحدة واختبارات e2e.

إذا كان لديك أي شيء يظهر في شبكة الاختبار ، فسيكون من الرائع تضمينه.

تمت الموافقة على الاستثناء.

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

تم دمج خطة اختبار https://github.com/kubernetes/enhancements/pull/1527

مرحباklueskavpickard، مجرد تذكير ودية أن قانون تجميد سيدخل حيز التنفيذ يوم الخميس 5 مارس.

هل يمكنك ربط جميع العلاقات العامة k / k أو أي علاقات عامة أخرى يجب تتبعها من أجل هذا التحسين؟

شكرا لكم :)

مرحبا palnabarun

مشكلة تتبع هنا لـ 1.18:
https://github.com/kubernetes/kubernetes/issues/85093

العلاقات العامة المفتوحة الحالية:
https://github.com/kubernetes/kubernetes/pull/87758 (تمت الموافقة ، اختبارات التقشير)
https://github.com/kubernetes/kubernetes/pull/87759 (WIP)
https://github.com/kubernetes/kubernetes/pull/87650 (تمت المراجعة ، يحتاج إلى الموافقة)

https://github.com/kubernetes/kubernetes/pull/87645 (اختبار e2e للعلاقات العامة ، يحتاج إلى موافقة)

vpickard ، هل يمكنك إضافة أي

شكرا

شكرًا nolancon على ربط العلاقات العامة وقضية المظلة هنا. لقد أضفت PRs إلى ورقة التتبع.

مرحبًا palnabarun ، nolancon ،

عدد قليل من العلاقات العامة المفتوحة الإضافية المتعلقة باختبارات E2E:
https://github.com/kubernetes/test-infra/pull/16062 (يحتاج إلى مراجعة وموافقة)
https://github.com/kubernetes/test-infra/pull/16037 (يحتاج إلى مراجعة وموافقة)

شكرًا vpickard على التحديثات الإضافية. :)

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

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

مرحبًا irvifa ، شكرًا على
شكرا.

مرحبًا nolancon ، شكرًا على ردك السريع ، لقد غيرت الحالة إلى النائب العام للعلاقات العامة الآن .. شكرًا!

palnabarun لمعلوماتك ، لقد قمت بتقسيم هذه العلاقات العامة https://github.com/kubernetes/kubernetes/pull/87759 إلى اثنين من العلاقات العامة لتسهيل عملية المراجعة. والثاني هنا https://github.com/kubernetes/kubernetes/pull/87983 وسيتعين أيضًا تتبعه. شكرا.

nolancon شكرا لك على التحديثات.

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

لمعلوماتك ، نحن قريبون جدًا من Code Freeze في الخامس من مارس

nolancon شكرا لك على التحديثات.

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

لمعلوماتك ، نحن قريبون جدًا من Code Freeze في الخامس من مارس

palnabarun تحديث آخر ، https://github.com/kubernetes/kubernetes/pull/87983 مغلق الآن ولا يلزم تتبعه. تم تضمين التغييرات المطلوبة في صفحة العلاقات العامة الأصلية https://github.com/kubernetes/kubernetes/pull/87759 والتي تخضع للمراجعة.

تضمين التغريدة أنا أيضًا أتتبع مشكلة تعقب المظلة التي شاركتها أعلاه. :)

مرحبًا nolancon ، هذا تذكير بأننا على بعد يومين فقط من Code Freeze في الخامس من مارس .

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

مرحبًا nolancon ،

اليوم ، التخلص من الذخائر المتفجرة هو رمز التجميد .

هل تعتقد أن https://github.com/kubernetes/kubernetes/pull/87650 ستتم مراجعته بحلول الموعد النهائي؟

إذا لم يكن كذلك ، يرجى تقديم طلب استثناء .

مرحبًا nolancon ،

اليوم ، التخلص من الذخائر المتفجرة هو رمز التجميد .

هل تعتقد أن kubernetes / kubernetes # 87650 ستتم مراجعته بحلول الموعد النهائي؟

إذا لم يكن كذلك ، يرجى تقديم طلب استثناء .

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

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

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

5 مساءً بتوقيت المحيط الهادئ.

تمت الموافقة على PR ولكنه يفتقد إلى حدث رئيسي تحتاج عقدة سيج إلى إضافته للدمج. لقد قمت بضربهم في فترة الركود ، وآمل أن يتفكك الأمر ولا تحتاج إلى استثناء. =)

يبدو أن جميع العلاقات العامة لهذه الحافظة قد اندمجت (وتمت الموافقة عليها بحلول الموعد النهائي) ، لقد قمت بتحديث ورقة تتبع التحسينات الخاصة بنا. :ابتسامة:

/ معلم واضح

(إزالة مشكلة التحسين هذه من الإصدار 1.18 مع اكتمال المرحلة الرئيسية)

مرحباnolanconlmdaly، والتحسينات الظل ل1.19 هنا. أي خطط لهذا في 1.19؟

التحسين الوحيد المخطط له لـ 1.19 هو هذا:
https://github.com/kubernetes/enhancements/pull/1121

سيكون باقي العمل على إعادة بناء الكود / إصلاحات الأخطاء حسب الضرورة.

هل هناك أي طريقة لتغيير صاحب هذا الإصدار لي بدلاً منlmdaly؟

شكرًا ، سأقوم بتحديث جهة الاتصال.

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

/ تعيين @ klueska
/ إلغاء تعيينlmdaly

ها هو ، كيفن https://prow.k8s.io/command-help

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

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

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

• KEP Update PR: https://github.com/kubernetes/enhancements/pull/1752
• العلاقات العامة لـ kubelet: WIP

مرحبًا klueska 👋 1.19 docs shadow هنا! هل يتطلب هذا التحسين المخطط له 1.19 جديدًا أو تعديلًا للمستندات؟

تذكير ودي أنه في حالة الحاجة إلى تعديل / تعديل المستندات ، يلزم وجود عنصر نائب PR مقابل k / موقع الويب (الفرع dev-1.19 ) بحلول يوم الجمعة ، 12 يونيو.

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

مرحباannajung. هناك تحسينان معلقان يتطلب كلاهما إجراء تغييرات في المستندات:

1121

1752

ما زلنا نقرر ما إذا كانت هذه ستصل إلى 1.19 أم سيتم دفعها إلى 1.20. إذا قررنا الاحتفاظ بها لمدة 1.19 ، فسأكون متأكدًا من إنشاء عنصر نائب PR للمستندات بحلول 12 يونيو.

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

تضمين التغريدة
آمل أن يكون هذا هو المكان المناسب لطرح بعض التعليقات وإبداء الرأي.

أقوم بتشغيل TopologyManager و CPUManager على مجموعة k8s الخاصة بي v1.17.
وسياستهم هي best-effort و static
هذه هي موارد جرابتي

      resources:
        requests:
          cpu: 2
          intel.com/sriov_pool_a: '1'
        limits:
          cpu: 2
          intel.com/sriov_pool_a: '1'

يوجد PF الخاص بـ sriov_pool_a في عقدة NUMA 0 ، لذلك أتوقع أن يعمل البود الخاص بي على وحدة المعالجة المركزية الخاصة بالعقدة 0 من NUMA أيضًا.
لكنني اكتشفت أن عملية البود الخاص بي تعمل على وحدة المعالجة المركزية الخاصة بـ NUMA node 1.
أيضًا ، لا يوجد قناع تقارب لوحدة المعالجة المركزية تم تعيينه وفقًا لنتيجة taskset -p <pid> .

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

هل هناك أي مثال أو اختبار يمكنني القيام به لمعرفة ما إذا كان TopoloyManager يعمل بشكل صحيح؟

تمت إضافة مستندات العلاقات العامة https://github.com/kubernetes/website/pull/21607

مرحبًا @ klueska ،

لمتابعة البريد الإلكتروني المرسل إلى k-dev يوم الاثنين ، أردت إخبارك بأنه تم تمديد تجميد التعليمات البرمجية حتى يوم الخميس 9 يوليو. يمكنك الاطلاع على الجدول المنقح هنا: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19
نتوقع أن يتم دمج جميع العلاقات العامة بحلول ذلك الوقت. واسمحوا لي أن أعرف إذا كان لديك أي أسئلة. 😄

الأفضل،
كيرستن

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

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

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

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

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

أتمنى أن يساعد هذا في الرد على مخاوفك! يُرجى إعلامي إذا كان لديك أي أسئلة أخرى!

أيضًا ، مجرد تذكير ودي بالتواريخ:
الموعد النهائي لمحرر المستندات - العلاقات العامة جاهزة للمراجعة بحلول السادس من تموز (يوليو)
"المستندات كاملة - تمت مراجعة جميع العلاقات العامة وجاهزة للدمج" بحلول 16 تموز (يوليو)

مرحبًا klueska : wave: - 1.19 تحسينات تؤدي هنا ،

هل يمكنك من فضلك ربط جميع العلاقات العامة للتنفيذ هنا ، حتى يتمكن فريق الإصدار من تتبعها؟ : قليلا_ابتسامة_الوجه:

شكرا لك.

تضمين التغريدة
يمكن العثور على تتبع العلاقات العامة https://github.com/kubernetes/enhancements/pull/1121 على:
https://github.com/kubernetes/kubernetes/pull/92665

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

مرحبًا klueska : wave: ، أرى أن كلا من PRs (https://github.com/kubernetes/enhancements/pull/1121 و https://github.com/kubernetes/enhancements/pull/1752) التي ذكرتها الرجوع إلى نفس التحسين. نظرًا لأن https://github.com/kubernetes/enhancements/pull/1752 يوسع متطلبات تخرج Beta ولن يتم إدخالها في الإصدار ، هل يمكننا افتراض أنه لا توجد تغييرات أخرى متوقعة في 1.19؟

شكرا لك. : قليلا_ابتسامة_الوجه:

يبدأ تجميد التعليمات البرمجية يوم الخميس 9 يوليو ، EOD PST

palnabarun هذه https://github.com/kubernetes/kubernetes/pull/92794

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

مدهش! شكرا لك على التحديث. : +1:

سنراقب https://github.com/kubernetes/kubernetes/pull/92794.

annajung https://github.com/kubernetes/website/pull/21607 جاهز الآن للمراجعة.

تهانينا ، تم دمجklueska kubernetes / kubernetes # 92794 أخيرًا ، وسوف أقوم بتحديث ورقة التتبع وفقًا لذلك 😄

/ معلم واضح

(إزالة مشكلة التحسين هذه من الإصدار 1.19 مع اكتمال المرحلة الرئيسية)

مرحبًا @ klueska

تحسينات تؤدي هنا. هل هناك أي خطط لهذا للتخرج في 1.20؟

شكرا!
كيرستن

لا توجد خطط للتخرج ، ولكن هناك علاقات عامة يجب تتبعها لـ 1.20 تتعلق بهذا التحسين:
https://github.com/kubernetes/kubernetes/pull/92967

على الرغم من عدم تخرجه في 1.20 ، يرجى الاستمرار في ربط العلاقات العامة ذات الصلة بهذه المشكلة كما فعلت للتو.

kikisdeliveryservice ، هل يمكنك المساعدة في فهم العملية. لم يتم تخرج ميزة Topology Manager في 1.20 ، ولكن ستتم إضافة الميزة الجديدة إليها ويتم العمل عليها الآن: https://github.com/kubernetes/enhancements/pull/1752 k / k: https: // github. com / kubernetes / kubernetes / pull / 92967. هل هذا شيء نحتاج إلى تتبعه مع فريق الإصدار؟ قد يبسط تتبع تحديث المستندات لـ 1.20 أو ربما شيء آخر يتم تتبعه.

التغيير مضاف لذلك لا يوجد سبب كبير لتسميته beta2 أو شيء من هذا القبيل.

نتوء العلاقات العامة ذات الصلة الذي يعكس حقيقة أن الميزة الإضافية لم يتم شحنها في 1.19: https://github.com/kubernetes/enhancements/pull/1950

تحديث وثائق الويب Topology Manager لتشمل ميزة النطاق: https://github.com/kubernetes/website/pull/24781

أعتقد أنه يمكن تتبعها بـ 1.20 ولا تحتاج بالضرورة إلى التخرج. kikisdeliveryservice يرجى الاتصال إذا كان هذا غير صحيح. سوف أتتبع موقع k / موقع الويب المشترك كجزء من إصدار 1.20 حتى أسمع خلاف ذلك.

مرحبا SergeyKanzhelev

بالنظر إلى التاريخ ، فإن هذا ليس هو الحال في الواقع. قيل لي أن هذا لن يتخرج أعلاه ، وهو أمر جيد ولماذا لم يتم تتبع KEP. ومع ذلك ، تمت إعادة تحديد هذا التحسين (غير معروف لفريق التحسينات) مؤخرًا بواسطة @ k-wiatrzyk لـ 1.20 كإصدار تجريبي (https://github.com/kubernetes/enhancements/pull/1950).

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

تم دمج الميزة بالفعل في KEP (الموجود مسبقًا) (قبل الموعد النهائي للتحسين).
https://github.com/kubernetes/enhancements/pull/1752

عند التنفيذ ، تعد العلاقات العامة بالفعل جزءًا من الإنجاز.
https://github.com/kubernetes/kubernetes/pull/92967

لم أكن أعلم أنه كان هناك المزيد لأفعله.

مع من نحن بحاجة إلى تقديم استثناء ، ولماذا بالضبط؟

مرحبًا klueska ، تم دمج العلاقات العامة التي تشير إليها في يونيو لإضافة بيتا إلى Kep في 1.19: https://github.com/bg-chun/enhancements/blob/f3df83cc997ff49bfbb59414545c3e4002796f19/keps/sig-node/0035-20190130-topology -manager.md

كان الموعد النهائي للتحسينات لـ 1.20 هو السادس من أكتوبر ، ولكن تم دمج التغيير ونقل الإصدار التجريبي إلى 1.20 وإزالة المرجع إلى 1.19 قبل 3 أيام عبر https://github.com/kubernetes/enhancements/pull/1950

يمكنك العثور على تعليمات حول إرسال طلب استثناء هنا: https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

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

تم ترقية ميزة "مدير طوبولوجيا العقدة" بالفعل إلى الإصدار التجريبي في 1.18.
إنه لا يتدرج إلى GA في 1.20 (إنه يبقى في مرحلة تجريبية).

العلاقات العامة التي يتم دمجها لـ 1.20 (على سبيل المثال kubernetes / kubernetes # 92967) هي تحسين للرمز الحالي لـ Topology Manager ، ولكنها لا تتعلق بـ "bump" من حيث حالتها مثل alpha / beta / ga ، إلخ.

لقد أرسلت بريد Call of Exception لأن الموعد النهائي اليوم (فقط في حالة): https://groups.google.com/g/kubernetes-sig-node/c/lsy0fO6cBUY/m/_ujNkQtCCQAJ

kikisdeliveryserviceklueskaannajung
تمت الموافقة على دعوة الاستثناء ، يمكنك العثور على التأكيد هنا: https://groups.google.com/g/kubernetes-sig-release/c/otE2ymBKeMA/m/ML_HMQO7BwAJ

شكرًا @ k-wiatrzyk & @ klueska تم تحديث ورقة التتبع.

نسخة إلى :

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

يبدو أن kubernetes / kubernetes # 92967 معتمد ولكنه يحتاج إلى تغيير أساسي.

فقط للتذكير بأن Code Freeze سيأتي بعد يومين يوم الخميس ، 12 نوفمبر . يجب دمج جميع PRs بحلول ذلك التاريخ ، وإلا فإن الاستثناء مطلوب.

الأفضل،
كيرستن

تم دمج العلاقات العامة ، وتحديث الورقة - رائع! : smile_cat: