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

sttts هل يمكنك تقديم الروابط المناسبة للمستندات والعلاقات العامة؟ أعتقد أنك الأقرب إلى هذا الرمز.

@ pweil- sttts - حسب مناقشتنا ، هذه ميزة نود رعايتها في Kubernetes 1.6 ضمن @ kubernetes / sig-node

@ pweil- derekwaynecarr من فضلك ، أكد أنه يجب تعيين هذه الميزة بـ 1.6 معلم.

idvoretskyi ، نستهدف نقله إلى

sttts شكرا.

يبدو أن هذا لا يزال ألفا:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

ولم أتمكن من العثور على أي وثائق على kubernetes.io/docs.

@ pweil- أي تحديثات لـ 1.8؟ هل هذه الميزة لا تزال على المسار الصحيح للإصدار؟

idvoretskyi لم تكن هذه أولوية لـ 1.8. @ php-coder هل يمكنك إضافة بطاقة إلى هذا لتخطيط PM؟ نحن بحاجة إلى التوقف عن ترك هذا السقوط من خلال الثغرات وتحويله إلى بيتا و GA.

@ pweil- إذا لم تكن هذه الميزة مخططة لـ 1.8 - من فضلك ، قم بتحديث المعلم بـ "المرحلة التالية" أو "1.9"

أود أن أرى هذا يصل إلى الإصدار التجريبي. تشمل الأولويات (أو المتطلبات) لذلك ما يلي:

1. يجب نقل التعليقات التوضيحية (Pod & PodSecurityPolicy) إلى الحقول الموجودة في الحاوية SecurityContext (راجع https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field- في نسخة api الموجودة)
2. استقر على تنسيق seccomp لمواصفات OCI ، وحدد ملف تعريف Kubernetes الافتراضي (هل يمكننا إعادة استخدام Docker؟) https://github.com/kubernetes/kubernetes/issues/39128
   أ. اكتشف كيف يتم تسليم ملف تعريف Kubernetes إلى وقت تشغيل الحاوية عبر CRI (/ ccyujuhong @ Random-Liu)
   ب. docker/default يجب أن يظل مسموحًا به إذا كان وقت التشغيل هو عامل الإرساء (للتوافق مع الإصدارات السابقة)
3. يجب أن يكون ملف تعريف Kubernetes الافتراضي هو الوضع الافتراضي الجديد. للتوافق مع الإصدارات السابقة ، يجب أن يكون هذا سلوكًا اختياريًا (أي يتم التحكم في العلامة). https://github.com/kubernetes/kubernetes/issues/39845

هل أي شخص مهتم بقيادة هذا العمل من أجل 1.9 (أو 1.10) معلم رئيسي؟ jessfraz @ kubernetes / sig-auth-feature-طلبات و @ kubernetes / sig-node-feature-طلبات أنا أنظر إليك: غمزة:

مناسب أيضًا: https://github.com/kubernetes/community/pull/660 (هل نحتاج إلى تسوية القرارات في ذلك العلاقات العامة قبل المتابعة؟)

/ ccdestijl

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

في 22 أيلول (سبتمبر) 2017 الساعة 20:54 ، "Tim Allclair (St. Clair)" [email protected]
كتب:

/ ccdestijl https://github.com/destijl

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

حسنًا ، سوف أقوم بتحديث الاقتراح والبدء في هذا غدًا إذا لم يفعل ذلك أي شخص آخر ؛)

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

منع المشكلات من الإغلاق التلقائي بتعليق /lifecycle frozen .

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

أرسل ملاحظاتك إلى اختبار sig و kubernetes / test-infra و / أو @fejta .
/ دورة الحياة التي لا معنى لها

مرحبًا jessfraz لست متأكدًا مما إذا كنت قد حصلت على أي شيء في هذا - ليس لدي عرض النطاق الترددي

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

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

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

يتم إغلاق المشكلات الفاسدة بعد 30 يومًا من عدم النشاط.
أعد فتح المشكلة مع /reopen .
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/أغلق

/ إعادة الفتح
/ دورة الحياة مجمدة
/ إزالة دورة الحياة فاسدة

@ php-coder: لا يمكنك إعادة فتح قضية / العلاقات العامة إلا إذا قمت بتأليفها أو تم تكليفك بها.

/ إعادة الفتح
/ دورة الحياة مجمدة

يوم الإثنين 26 مارس 2018 الساعة 7:07 صباحًا ، k8s-ci-robot [email protected]
كتب:

@ php-coder https://github.com/php-coder : لا يمكنك إعادة فتح مشكلة / العلاقات العامة
إلا إذا قمت بتأليفه أو تم تكليفك به.

ردا على هذا
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
:

/ إعادة الفتح
/ دورة الحياة مجمدة
/ إزالة دورة الحياة فاسدة

تعليمات للتفاعل معي باستخدام تعليقات العلاقات العامة متوفرة هنا
https://git.k8s.io/community/contributors/devel/pull-requests.md . لو
لديك أسئلة أو اقتراحات تتعلق بسلوكي ، يرجى تقديم
قضية ضد kubernetes / test-infra
https://github.com/kubernetes/test-infra/issues/new؟title=Prow٪20issue:
مخزن.

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

smarterclayton : لا يمكنك إعادة فتح إصدار / العلاقات العامة إلا إذا قمت بتأليفه أو تم

/ إعادة الفتح

idvoretskyi : لا يمكنك إعادة فتح قضية / العلاقات العامة إلا إذا قمت بتأليفها أو تم

Ihor 1 ، بوت 0

@ pweil- @ php-coderjessfraz
أي خطط لهذا في 1.11؟

إذا كان الأمر كذلك ، فيرجى التأكد من تحديث الميزة بما يلي:

• وصف
• منعطف
• معين (ق)
• ملصقات:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

ccidvoretskyi

يعمل @ wangzhen127 على ذلك ، ولكن لا يمكن تعيينه لأنه ليس عضوًا بعد.

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

شكرا على التحديث ، تيم!
/ إزالة دورة الحياة مجمدة

@ pweil- tallclair - نقوم لجدول بيانات تتبع 1.11 ميزات .
هل تمانع في ملء أي حقول غير مكتملة / فارغة لعنصر سطر هذه الميزة؟

@ pweil- tallclair - تمت إزالة هذه الميزة من 1.11 ، حيث لم تكن هناك تحديثات أو تقدم أو مستندات.

نسخة إلى :

@ pweil- tallclair @ kubernetes / sig-auth-feature-requirements @ kubernetes / sig-node-feature-applications -

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

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

• وصف ميزة من سطر واحد (يمكن استخدامه كملاحظة إصدار):
• جهة الاتصال الأساسية (المسؤول):
• SIGs المسؤولة:
• رابط اقتراح التصميم (مجتمع الريبو):
• رابط لـ e2e و / أو اختبارات الوحدة:
• المراجع (المراجعون) - (لـ LGTM) يوصون بموافقة أكثر من 2 من المراجعين (واحد على الأقل من ملف OWNERS في منطقة الكود) على المراجعة. يفضل المراجعون من عدة شركات:
• الموافق (من المحتمل أن يكون من SIG / المنطقة التي تنتمي إليها الميزة):
• هدف الميزة (أي الهدف يساوي أي حدث رئيسي):
  
  
  
  • هدف إطلاق ألفا (س ص)
  
  
  • هدف إصدار بيتا (س ص)
  
  
  • هدف الإطلاق المستقر (xy)
  
  

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

بالإضافة إلى ذلك ، يرجى العلم بالمواعيد النهائية التالية ذات الصلة:

• الموعد النهائي لمحرر المستندات (فتح العناصر النائبة PRs): 8/21
• تجميد حالة الاختبار: 8/28

يرجى التأكد من تضمين ملاحظات الإصدار ذات الصلة في جميع العلاقات العامة الخاصة بالميزات أيضًا.

شحن سعيد!

/ ccjustaugustus @ kacole2robertsandoval @ rajendar38

لا توجد تغييرات مخطط لها في 1.12

شكرا على التحديث ،tallclair!

هل أي شخص مهتم بقيادة هذا العمل من أجل 1.9 (أو 1.10) معلم رئيسي؟ jessfraz @ kubernetes / sig-auth-feature-طلبات و @ kubernetes / sig-node-feature-طلبات أنا أنظر إليك تغمز

tallclair يمكنني محاولة التقاط هذا الآن إذا كان لا يزال مرغوبًا فيه

stlaz : تكرار الإشارات لتشغيل إشعار:
طلبات @ kubernetes / sig-auth-feature ، @ kubernetes / sig-node-features-features

stlaz ، لا تزال هذه الميزة مطلوبة. لقد أمضيت بعض الوقت في إضافة ملفات تعريف seccomp إلى الإضافات كخطوات أولى للرقم # 39845 . لكن ليس لدي الوقت الكافي لدفع هذه الميزة. سيكون من الرائع إذا كنت ترغب في العمل على هذا. نرحب بأي مساعدة! :)

@ wangzhen127 شكرًا ، كنت أحاول استعراض الأشياء التي تم إجراؤها والمشكلات المفتوحة المتعلقة بهذه الميزة. يبدو أن التعليق https://github.com/kubernetes/features/issues/135#issuecomment -331592961 لا يزال ساريًا ويلخص بالضبط العمل الذي يجب القيام به الآن.

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

ملاحظة: آسف على الرد المتأخر ، كنت بعيدًا قليلاً.

يبدو أن التعليق رقم 135 (تعليق) لا يزال قائماً ويلخص بالضبط العمل الذي يجب القيام به الآن.

هذا صحيح. هناك شيء آخر أود إضافته وهو أن يكون لديك وضع "شكوى". لذلك يكون لدى المستخدمين خيار الحصول على تحذيرات (في السجلات) من استخدام عمليات تسجيل الدخول المحظورة بدلاً من القتل. تتوفر إجراءات التسجيل seccomp مع Linux kernel 4.14+ ( seccomp doc ). من المحتمل أن إصدارات kernel الأقدم ما زالت قيد الاستخدام. لذلك نحن بحاجة للتعامل مع ذلك. سيحتاج هذا أيضًا إلى إضافته إلى مواصفات OCI.

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

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

تتوفر إجراءات التسجيل seccomp مع Linux kernel 4.14+ ( seccomp doc ).

أعتقد أنه نظرًا لأننا سنحدد تنسيق seccomp الافتراضي الخاص بـ Kubernetes كجزء من الخطوة الثانية ، فيمكننا أيضًا أن يكون لدينا تنسيق يمكن تسجيله بدلاً من ذلك. هل هناك قيمة كافية لذلك؟ هل يمكن استخدامه للانتقال من "غير المحصور" إلى "kube / الافتراضي" عندما يفشل الأخير كثيرًا؟ هل سيهتمون بالتبديل إلى الخلف؟
هناك توزيعات LTS تستخدم 4.13- Linux kernels (Debian - 8،9؛ RHEL - 6، 7؛ Ubuntu LTS - 14.04، 16.04) ، لذا فإن توافق Kernel أمر يجب أخذه في الاعتبار بالتأكيد.

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

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

هل هناك قيمة كافية لذلك؟

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

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

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

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

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

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

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

أعتقد أنه اتجاه مختلف قليلاً عما تم النظر إليه في الأصل - فهو يتعارض مع العمل المنجز في https://github.com/kubernetes/kubernetes/issues/39845 ، ولكن إذا اتفقنا على ما سبق ، فيجب أن نفكر بعد ذلك في ملفات تعريف seccomp سنقوم بالشحن في النهاية. حتى الآن أرى runtime/default ، kube/default ، kube/logging ، بالإضافة إلى خيار تعيين الملف الشخصي على unconfined . الباقي بالطبع هو القدرة على الحصول على ملفات تعريف localhost/.* ، والتي يتم توفيرها بالفعل من خلال التطبيق الحالي.

هل من المقبول حدوث ذلك في الجزء التجريبي من دورة الحياة؟

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

الذهاب مع "غير محصور" كخيار افتراضي يبدو الآن جيدًا بالنسبة لي. بالنسبة إلى kubernetes / kubernetes # 39845 ، أضفت التعليقات التوضيحية إلى الإضافات. ولا أعتقد أنه يمكننا الذهاب إلى أبعد من ذلك.

حتى الآن أرى وقت التشغيل / الافتراضي ، kube / الافتراضي ، kube / logging ، جنبًا إلى جنب مع خيار ضبط ملف التعريف على غير مقيد. الباقي بالطبع هو القدرة على الحصول على ملفات تعريف المضيف /.* المحلية ، والتي يتم توفيرها بالفعل من خلال التنفيذ الحالي.

يعمل لدي. بالنسبة إلى kube/default ، قد نبدأ بـ docker/default .

تتوفر إجراءات التسجيل seccomp مع Linux kernel 4.14+ (seccomp doc).

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

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

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

tallclair أنت على حق ، لقد فقدت نوعًا ما في جميع تعليقات القضايا. للإشارة ، إليك التعليق الذي يشير إلى أنه تم التحقق من ملفات Dockerfiles: https://github.com/kubernetes/community/pull/660#issuecomment -303860107. أعتقد أننا يمكن أن نكون آمنين بعد كل شيء "القتل" الافتراضي.

أهلا
لقد تم تتبع هذا التحسين من قبل ، لذلك نود تسجيل الوصول ومعرفة ما إذا كانت هناك أي خطط لذلك لتخرج مراحل في Kubernetes 1.13. يهدف هذا الإصدار إلى أن يكون "أكثر استقرارًا" وسيكون له جدول زمني صارم. يُرجى عدم تضمين هذا التحسين إلا إذا كان هناك مستوى عالٍ من الثقة في أنه سيلبي المواعيد النهائية التالية:

• المستندات (فتح عنصر نائب PRs): 11/8
• كود سلاش: 11/9
• يبدأ تجميد الكود: 11/15
• المستندات كاملة ومراجعة: 11/27

يرجى تخصيص بعض الوقت لتحديث المعالم في المنشور الأصلي الخاص بك للتتبع المستقبلي و ping ورقة تتبع التحسينات 1.13

شكرا!

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

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

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

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

/ إزالة دورة الحياة مجمدة

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

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

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

/ إزالة دورة الحياة فاسدة

مرحبًا stlaz @ pweil- ، أنا قائد التحسين لـ 1.15. هل هذه الميزة ستخرج مراحل ألفا / بيتا / مستقرة في 1.15؟ يرجى إعلامي حتى يمكن تتبعها بشكل صحيح وإضافتها إلى جدول البيانات. سيتطلب هذا أيضًا تضمين KEP في 1.15

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

لا توجد تغييرات مخطط لها في 1.15

مرحبًا tallclair @ pweil- stlaz ، أنا جدول بيانات التتبع 1.16 . إذا لم يتم التخرج ، فسأقوم بإزالته من الحدث الرئيسي وتغيير التسمية المتعقبة.

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

للتذكير ، يتطلب كل تحسين KEP في حالة قابلة للتنفيذ مع معايير التخرج التي توضح متطلبات كل مرحلة من مراحل ألفا / بيتا / مستقرة.

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

شكرا لك.

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

مرحبًا tallclair @ pweil- ، ظل تعزيز 1.17 هنا! 🙂

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

شكرا لك!

🔔 تذكير ودي

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

• يجب أن يفي اقتراح تحسين Kubernetes (KEP) بالمعايير التالية قبل قبول "

  • تم دمج العلاقات العامة في
  • في حالة implementable
  • قم بتضمين خطة الاختبار ومعايير التخرج

• يجب أن يتم سرد جميع العلاقات العامة k / k ذات الصلة في هذه المسألة

نعم ، أخطط لترقية هذا إلى مستقر في الإصدار 1.17 - KEP هنا: https://github.com/kubernetes/enhancements/pull/1148

مرحبًا tallclair ، سأضيف هذا التحسين إلى ورقة التتبع ليتم تعقبها 👍

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

/ معلم الإصدار 1.17.0
/ مرحلة مستقرة

مرحبًا tallclair ، هل يمكنك من فضلك نشر روابط للاختبارات في testgrid وتتبع أي اختبارات تمت إضافتها لهذا التحسين؟

شكرا لك!

سوف تفعل. هناك مجموعة من اختبارات seccomp بالفعل ، لكن لا يمكنني العثور عليها في أي من علامات تبويب لوحة القيادة (هل هناك أي طريقة للبحث عبر جميع شبكات الاختبار لاختبار معين؟)
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

tallclair لا توجد طريقة جيدة للبحث عبر جميع testgrid = /

أفضل تخميني (على الأقل بالنسبة للأربعة التي أشرت إليها) هو أنه لم يتم تضمينها بالفعل. 😬

يبدو أنها يجب أن تكون جزءًا من لوحة معلومات ميزات node-kubelet ، لكن تكوين الوظيفة لميزات ci-kubernetes-node-kubelet لديها هذا لأنه test_args :

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

يتم تمييز اختبارات الجنكة نفسها بـ [Feature:Seccomp] ولن تتطابق علامة التركيز.

أعتقد أنه يجب علينا إزالة علامة الميزة بمجرد انتقال هذا إلى GA. أعتقد أن seccomp قياسي في نظام التشغيل Linux ، لذا يجب أن تكون علامة [LinuxOnly] كافية.

بالنسبة للمشكلة العامة المتمثلة في عدم إجراء الاختبارات ، قمت بتقديم https://github.com/kubernetes/test-infra/issues/14647

مرحبًا tallclair ، نحن على بعد 5 أيام فقط من تجميد التحسينات (الثلاثاء ، 15 أكتوبر ، EOD PST) . تذكير ودي آخر بأنه حتى تتمكن من تخريج هذا في الإصدار 1.17 ، يجب دمج KEP ويجب أن يكون في حالة قابلة للتنفيذ. يبدو أن KEP لا يزال مفتوحًا وفي حالة مؤقتة.

مرحبًا tallclair ، للأسف

يرجى ملاحظة أنه يمكنك تقديم استثناء تحسين إذا كنت بحاجة إلى الحصول عليه لـ 1.17

/ معلم واضح

نعم ، لم أقم بإجراء الخفض. على أمل الحصول عليه
/ معلم الإصدار 1.18.0

هذا يبدو جيدا! سأضع علامة على هذا على أنه مؤجل إلى الإصدار 1.18 في ورقة تتبع التحسين .

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

يا tallclair

1.18 التحسينات فريق التدقيق! هل تخطط للتخرج إلى مستقر في 1.18؟ يبدو أن KEP لا يزال مفتوحًا.

جدول الإصدار هو كما يلي:

تعزيز التجميد: 28 يناير
تجميد الكود: 5 مارس
المستندات جاهزة: 16 مارس
الإصدار 1.18 الإصدار: 24 مارس

للتذكير ، يجب دمج KEP ، مع تعيين الحالة على implementable .

شكرا!

saschagrunert شكرا على العرض! أحتاج إلى الحصول على تصريح آخر في KEP للمتابعة من مراجعة API التي أجريتها معliggitt. بمجرد الموافقة على KEP ، أرحب بمساعدتك في التنفيذ.

أعتقد أن أكبر سؤال مفتوح في KEP في الوقت الحالي هو كيفية التعامل مع نوع ملف تعريف المضيف المحلي. نظرًا لأننا نريد إهمال الميزة (من الناحية المثالية لصالح شيء مثل https://github.com/kubernetes/enhancements/pull/1269، / ccpjbgf ) ، أود تجنب وضع حقل لها في واجهة برمجة التطبيقات .

مرحبًا tallclair ، أي تحديث حول ما إذا كان هذا سيجعله 1.18 أم لا؟ تم وضع علامة عليه حاليًا في المرحلة الرئيسية ولكنك لم تؤكد ما إذا كان يجب علينا تتبع هذا أم لا.

شكرا!

يبدو أن الإصدار 1.18 غير مرجح لهذا الغرض. أعتقد أننا يمكن أن نصطدم
/ معلم الإصدار 1.19.0

رائع ، شكرًا على التحديث tallclair :)

مرحبًا tallclair - 1.19 تحسينات ، stable هذا الإصدار؟

لا توجد خطط للتخرج في الإصدار 1.19. لدي برنامج KEP مفتوح ، لكنني لن أعمل عليه هذا الربع. pjbgf قد

tallclair - شكرا لك على التحديثات. : قليلا_ابتسامة_الوجه:

/ معلم v1.20.1

كان هناك تغيير طفيف في الخطط بشأن هذه الخطة - على النحو المتفق عليه في اجتماع عقده التوقيع أمس. هذا مخطط الآن لـ:

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

pjbgf : يجب أن تكون عضوًا في فريق GitHub kubernetes / milestone -keepers لتعيين هذا الإنجاز. إذا كنت تعتقد أنه يجب أن تكون قادرًا على إصدار الأمر / milestone ، فيرجى الاتصال بك واطلب منهم اقتراحك كمفوض إضافي لهذه المسؤولية.

palnabarun هل تمانع في ضبط هذه المشكلة على الإصدار

/ تعيين pjbgf

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

شكرا لكpjbgftallclair للتحديث. لقد قمت بتحديث ورقة التتبع وفقًا لخططك.

هل يمكنك إعلامي بمرحلة التخرج التي تستهدفها ورابط إلى KEP؟

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

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

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

استهداف GA

KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md
لا يزال لدى KEP أقسام لم يتم حلها ، مع متابعة العلاقات العامة: https://github.com/kubernetes/enhancements/pull/1747

مرحبًا tallclair ، شكرًا لك على التحديث. : +1:

لقد قمت بتحديث ورقة التتبع وفقًا لذلك.

ملاحظة: لقد قمت بتحديث وصف المشكلة بروابط إلى KEP وآخر تحديث لـ KEP PR.

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

مرحبًا tallclair 👋 1.19 دوكس ظل هنا! هل يتطلب هذا التحسين المخطط لـ 1.19 جديدًا أو تعديلًا للمستندات؟

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

annajung هذا من أجل

إضافة hasheddan الذي يلتقط هذا (https://github.com/kubernetes/kubernetes/issues/58211).

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

pjbgf - هل يمكنك من فضلك ربط جميع العلاقات العامة الخاصة بالتنفيذ هنا - k / k أو غير ذلك؟ : قليلا_ابتسامة_الوجه:

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

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

palnabarun ها هي الحالية:
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

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

مرحباpjbgfhasheddan مجرد تذكير ودية أن PR نائبا ضد ك / الموقع هي مقررة في الجمعة يونيو 12. واسمحوا لي أن أعرف مرة واحدة كنت قد قدمت PR، شكرا لك!

annajung شكرا للتذكير! سيتم افتتاحه قريبًا: +1:

مرحبًا pjbgf - شكرًا على إنشاء مشكلة المظلة. : +1:

نحن نتتبع نفس الشيء. : قليلا_ابتسامة_الوجه:

مرحبًا pjbgf - أردت فقط التحقق من تقدم التحسين.

تمت مراجعة الجدول الزمني للإصدار مؤخرًا ، ويمكن العثور على مزيد من التفاصيل هنا .

واسمحوا لي أن أعرف إذا كان لديك أي أسئلة. : قليلا_ابتسامة_الوجه:

جدول الإصدار المنقح هو:

• الخميس 9 تموز (يوليو): الأسبوع 13 - تجميد الرمز
• الخميس 16 يوليو: الأسبوع 14 - يجب إكمال المستندات ومراجعتها
• الثلاثاء 25 أغسطس: الأسبوع 20 - تم إصدار Kubernetes v1.19.0

شكرا لك على التحديثpalnabarun. تم الانتهاء من الكود بالكامل ، لكننا ننتظر الآن مراجعة متابعة. بشكل عام ، ما زلنا نبدو بحالة جيدة. : +1:

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

مرحبًا pjbgfhasheddan : wave: ، أرى أنه لا يزال هناك 3 عناصر عمل معلقة في https://github.com/kubernetes/kubernetes/issues/91286 للتغييرات المتعلقة بالتنفيذ وعنصر عمل واحد معلق للتوثيق. هل تعتقد أنهم سيتجاوزون تجميد الكود يوم الخميس 9 يوليو؟

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

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

palnabarun docs PR جاهز في الغالب ، فقط قم بإضافة دليل محدد لـ seccomp. لديك بالفعل LGTM من saschagrunert على التغييرات الحالية. شكرا لإبقائنا على المسار الصحيح هنا :)

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

annajung سيفعل! شكرا!

hasheddan - شكرا لك على التحديث. :ابتسامة:

pjbgf - لقد رأيت أنه في https://github.com/kubernetes/kubernetes/issues/91286 لم يتم دمج عنصري عمل أساسيين ولم يتم دمجهما في مجموعة الدمج أيضًا. هل تعتقد أنهم سيدخلون قبل تجميد الكود؟

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

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

شكرا لرؤساء متابعة.

من أجل الوضوح ، فإن 2 prs التي ننتظر دمجها هي:
https://github.com/kubernetes/kubernetes/pull/91408 و https://github.com/kubernetes/kubernetes/pull/92856

يبدو أن الأخير (https://github.com/kubernetes/kubernetes/pull/92856) فشل في التحقق من التحقق. وفقًا لـ https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 ، سيتطلب هذا rebase / repush / rereview قبل أن يتمكن من الدمج ..

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

مرحبًا pjbgf : wave: نحن الآن في تجميد التعليمات البرمجية.

نظرًا لأن https://github.com/kubernetes/kubernetes/pull/91408 موجود في مجموعة الدمج و https://github.com/kubernetes/kubernetes/pull/92856 يتطلب إعادة تأسيس على https://github.com/ kubernetes / kubernetes / pull / 91408 وفقًا لـ https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700 ، نشعر أن أفضل إجراء هنا هو تقديم طلب استثناء للحصول على وقت إضافي لإكمال الثانية العلاقات العامة بعد أن يتضح تجمع الدمج.

إزالة التحسين من الإنجاز في الوقت الحالي.

شكرا لك!

أفضل،
إصدار Kubernetes v1.19 Release Enhancements Team

/ معلم واضح

نظرًا لأن kubernetes / kubernetes # 91408 موجود في مجموعة الدمج ويتطلب kubernetes / kubernetes # 92856 تغيير قاعدة البيانات على kubernetes / kubernetes # 91408 وفقًا لـ kubernetes / kubernetes # 92856 (تعليق) ، نشعر أن أفضل إجراء هنا سيكون تقديم استثناء طلب الحصول على وقت إضافي لإكمال العلاقات العامة الثانية بعد توضيح تجمع الدمج.

لا يتطلب تغيير العنوان على PR معتمد في قائمة انتظار الدمج طلب استثناء. تم استكمال رمز العلاقات العامة واعتماده قبل يوم كامل من الموعد النهائي.

مرحبًا liggitt : wave: ، شكرًا لك على

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

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

pjbgfsaschagrunerthasheddan - شكرا لكم على كل مساهماتكم. : 100:

شكرًا لك palnabarun على التتبع التفصيلي

saschagrunert ، تم دمج PR kubernetes / kubernetes # 92856 النهائي في النهاية. تهاني! سوف أقوم بتحديث ورقة التتبع لتعكس ذلك.

tallclairpjbgf هل تعتقد أننا يمكن إغلاق هذه القضية الآن منذ seccomp هو GA؟

saschagrunert عادةً ما ننتظر حدوث الإصدار ، ثم نضع علامة على KEP المقابل كـ implemented ثم نغلق مشكلة التحسين.

لا تتردد في المضي قدمًا وإجراء تغيير لوضع علامة على https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md كـ implemented . : قليلا_ابتسامة_الوجه:

saschagrunert عادةً ما ننتظر حدوث الإصدار ، ثم نضع علامة على KEP المقابل كـ implemented ثم نغلق مشكلة التحسين.

لا تتردد في المضي قدمًا وإجراء تغيير لوضع علامة على https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md كـ implemented .

شكرا للتوضيح ، فتح العلاقات العامة في https://github.com/kubernetes/enhancements/pull/1932

تم تحديث KEP ليتم تنفيذه (تم دمج العلاقات العامة أخيرًا!)

لا تتردد في إغلاق هذه المشكلة saschagrunert

شكرا لكم جميعا على كل ما تبذلونه من العمل !!

/ معلم واضح

/أغلق
تم ذلك.

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

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

نعم ، هذا مخطط للإصدار 1.23. يتكامل هذا مع آلية التحذير (لم يتم تنفيذها بعد) ، والتي يمكن إجراؤها بعد وجود وظائف الأداة المساعدة الضرورية (راجع https://github.com/kubernetes/kubernetes/issues/94626).

من KEP:

لزيادة الوعي باستخدام التعليقات التوضيحية (في حالة الأتمتة القديمة) ، سيتم استخدام آلية تحذير لتسليط الضوء على أنه سيتم إسقاط الدعم في الإصدار 1.23. الآليات التي يتم أخذها في الاعتبار هي التعليقات التوضيحية للتدقيق أو التعليقات التوضيحية على الكائن أو الأحداث أو التحذير كما هو موضح في KEP # 1693.

...

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

هل تفضل إعادة فتح هذه المشكلة حتى يتم تنفيذ هذه البتات أيضًا؟

نعم ، دعنا نبقي هذا مفتوحًا حتى يتم تغليف الميزة بالكامل. هل هناك قضية ak / k مقدمة للعمل الذي وصفته؟

نعم ، دعنا نبقي هذا مفتوحًا حتى يتم تغليف الميزة بالكامل. هل هناك قضية ak / k مقدمة للعمل الذي وصفته؟

الآن لدينا واحدة ، هناك: https://github.com/kubernetes/kubernetes/issues/95171 :)