الخلاصة

  • تسجل implementable قرار approvers من SIGs المتأثرة بالسماح بالانتقال إلى التنفيذ؛ ولا تسجل دمج كود أو احتواء إصدار محدد أو تفعيل أي عنقود للميزة.
  • المعلم الزمني للإصدار وProduction Readiness Review والاختبارات وfeature gate والإصدار المرقم ودعم المشغّل سجلات منفصلة لها أصحاب قرار مختلفون.
  • يحفظ إيصال موجز يمتد من المقترح إلى التشغيل هذه الانتقالات ولا يحوّل موافقة تصميم إلى ضمان خدمة غير موجود.

قرار implementable له صاحب ونطاق

ليست Kubernetes Enhancement Proposals مجرد بطاقات للأفكار. فالمسار العلني يجعلها سجلاً للدافع والتصميم والمسؤوليات وأهداف الاستقرار والمتابعة عبر أكثر من دورة. ويقول مسار KEP إن approvers يُختارون من SIGs المتأثرة، وإنهم يقررون متى ينتقل KEP إلى implementable. كما يميز المسار بين provisional وimplemented وdeferred وrejected وwithdrawn وreplaced. مسار KEP

لذلك فـ implementable حكم فعلي، لا تسمية خفيفة: إنه يعني أن من يملكون سلطة تقييم ذلك التصميم ضمن نطاق SIGs ذات الصلة وافقوا على بدء التنفيذ. لكن نطاق الحكم ينتهي هنا. فهو لا يثبت أن commit بعينه دُمج، ولا أن إصداراً بعينه قبله، ولا أن مدير عنقود فعّل قيمة في apiserver أو kubelet أو مكوّن آخر. وبالأولى لا يحل محل قرار الجهة التي تتحمل كلفة الحوادث وتعد عملاءها بالدعم.

حماية هذا الحد لا تقلل من شأن عمل SIGs؛ بل تمنع توسيع حكمهم لغوياً إلى وعد لم يصدر عنهم. فـ approvers التصميم ينظرون إلى البنية وواجهات API والاعتماديات بين SIGs. أما مشغّل العنقود فينظر إلى السعة والإضافات وانحراف الإصدارات والمراقبة ومسار التراجع وعقود الخدمة. إذا سُمي كلاهما «اعتماداً» واحداً اختفى من السجل صاحب الخسارة الثانية.

استهداف الإصدار يحتاج سلسلة أدلة مستقلة

يكتب قالب KEP الحد الثاني بوضوح. كي يُنظر في تغيير من أجل إصدار مستهدف، يجب أن تشير issue الخاصة بالـ enhancement المرتبطة بالـ KEP إلى المعلم قبل Enhancement Freeze. وقائمة signoff لا تقف عند implementable؛ فهي تضم تفاصيل التصميم وخطة الاختبار ومعايير graduation وProduction Readiness Review المكتملة والمعتمدة وسجل التنفيذ ووثائق المستخدم ومواد الدعم. ويطلب القالب العودة إلى القائمة كل مرة يُنظر فيها إلى enhancement من أجل معلم. قالب KEP

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

وتضيف Production Readiness Review سطح قرار آخر. يصفها Kubernetes بأنها عمل فريق منفصل عن SIG leads، ينظر في observability وscalability وsupportability والتشغيل الآمن وإمكان التعطيل أو rollback. ومنذ Kubernetes 1.21، أصبحت موافقة PRR لازمة لكي يكون enhancement جزءاً من إصدار. مسار Production Readiness Review

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

feature gate خيار لمكوّن، لا دليل اعتماد شامل

تعرّف مرجعية feature gates الـ gate بأنه زوج key=value يضبطه مكوّن Kubernetes عبر --feature-gates. ولا يدعم كل مكوّن إلا gates المرتبطة بوظائفه، كما تفصل الصفحة بين Alpha وBeta وstable وبين معلومات إدخال الإصدار وإزالته. مرجع Kubernetes Feature Gates

تجيب هذه الوثيقة عن «كيف يُضبط؟» لا عن «من ضبطه؟». وجود gate في المرجع لا يخبرنا إن كان true في عنقود ما. وقد تتطلب ميزة ما إعدادات متناسقة في أكثر من مكوّن، وقد يضيف موزع شروطاً، وقد يبقي مشغّل الخيار مغلقاً حتى يفحص إشارات المراقبة ودلالات التخزين وانحراف الإصدارات وطريق التراجع. المشروع يتيح المقبض؛ لا يديره بدلاً من المشغّل.

وتحافظ أمثلة graduation في قالب KEP على الفصل نفسه. فمرحلة Alpha تحتاج تنفيذاً خلف feature flag واختبارات e2e أولية. وBeta تحتاج متطلبات الوظيفة والأمن والمراقبة والاختبار ومعالجة الثغرات المعروفة. أما GA فتنظر إلى الاستخدام الفعلي ومدة التغذية الراجعة وحل ما ظهر في Beta؛ والوظائف غير الاختيارية تحتاج كذلك إلى conformance tests. قالب KEP هذه أدلة نضج في دورة المشروع، لا تفويض تشغيل باسم كل مشغّل.

الإصدار المرقم لا يتكلم باسم المشغّل

تسجل صفحة إصدارات Kubernetes فروع الإصدار ونسخ x.y.z والرقع وتواريخ EOL. وهي إيصال علني أقوى من حالة مقترح، لأنه يتيح تحديد المصنوعات التي أصدرها المشروع وفترة دعمه على مستوى المشروع. سجل إصدارات Kubernetes لكن تلك الفترة لا تبين ما الذي حزّمته منصة مُدارة، ولا هل عنقود بعينه متوافق، ولا هل التزم أحد بالاستجابة لحادث.

مستودع enhancements مفيد لتتبع KEPs والـ issues والدورات، لكنه ليس برهان اعتماد. Kubernetes enhancements إن القفز من KEP إلى إصدار، ومن إصدار إلى إعداد، ومن إعداد إلى دعم يمحو في كل مرحلة الشخص الوحيد القادر على إثبات المرحلة التالية.

الأجدى حفظ إيصال صغير من المقترح إلى التشغيل: هوية KEP ومراجعته غير القابلة للتبديل؛ SIG المالكة وSIGs المتأثرة؛ approvers والحالة؛ المعلم وfreeze؛ طلب PRR ونتيجته؛ مراجعات الكود والاختبار؛ الـ gate والمكوّن والقيمة الافتراضية؛ الإصدار المرقم وملاحظته؛ حد التوزيع؛ وبيان المشغّل الصريح عن التفعيل والدعم وانحراف الإصدارات وrollback. لا ينشئ الإيصال سلطة جديدة؛ إنه يعيد كل حكم إلى صاحبه.

وتنسجم هذه الدقة مع تمييز Lu Heng: المشاركة والخبرة قد تكونان دليلاً، لكنهما لا تصنعان تلقائياً تفويضاً لمن هو غائب؛ وعواقب التشغيل ينبغي أن يعترف بها بوضوح من يحملها. The Multi-Stakeholder Mirage Running-Code Primacy

ما الذي لا يثبته هذا السجل

لا تثبت هذه المصادر حالة KEP مسمى أو إدراج تغيير في إصدار محدد أو تفعيل gate في عنقود أو التزام توزيع أو مشغّل بالتوافق والدعم. وهي لا تقيم بائعاً أو عميلاً أو عنقوداً أو حادثة. والإيصال المقترح هنا توصية تحريرية من Daniel Kade، لا قاعدة من قواعد Kubernetes.

المصادر