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

ليس لدي مالك في ذهني ، لكن التعرف على المشكلة يبدو وكأنه الخطوة 1.

@ deads2k أتعلم مورد طرف ثالث مؤخرًا ،

@ deads2k أتعلم مورد طرف ثالث مؤخرًا ،

لقد أعدت ترتيب القائمة من حيث ما أعتبره أولوية تكتيكية. يحاول الناس استخدام هذا الآن وستؤدي هذه المشكلات إلى حرقهم بشدة.

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

@ deads2k قضيت بعض الوقت في محاولة إعادة إنتاج العدد الأول:

Multiple Resources, single version, different add times - Adding resource A, waiting for it to appear, then adding resource B fails. Resource B is never added.

ولكن مع سوء الحظ. فيما يلي خطواتي الخاصة بإعادة الإنتاج:

1. قم بإنشاء مورد طرف ثالث مخصص وانتظر ظهوره

[root<strong i="12">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/lbclaim.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancerclaim.k8s.io
description: "Allow user to claim a loadbalancer instance"
versions:
- name: v1
[root<strong i="13">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/lbclaim.yaml
thirdpartyresource "loadbalancerclaim.k8s.io" created
[root<strong i="14">@localhost</strong> kubernetes]# curl  http://localhost:8080/apis/extensions/v1beta1/thirdpartyresources/
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/",
    "resourceVersion": "170"
  },
  "items": [
    {
      "metadata": {
        "name": "loadbalancerclaim.k8s.io",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/loadbalancerclaim.k8s.io",
        "uid": "dcb88b3a-9857-11e6-a19b-08002767e1f5",
        "resourceVersion": "146",
        "creationTimestamp": "2016-10-22T13:03:01Z"
      },
      "description": "Allow user to claim a loadbalancer instance",
      "versions": [
        {
          "name": "v1"
        }
      ]
    }
  ]
}

1. بعد لحظة (أكثر من 10 ثوانٍ) ، قم بإنشاء مورد طرف ثالث مخصص آخر

[root<strong i="19">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/loadbalancer.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancer.k8s.io
description: "Allow user to curd a loadbalancer instance"
versions:
- name: v1
[root<strong i="20">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/loadbalancer.yaml
thirdpartyresource "loadbalancer.k8s.io" created

1. تحقق من وجود كلا الموارد

[root<strong i="25">@localhost</strong> kubernetes]# curl http://localhost:8080/apis/k8s.io/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "k8s.io/v1",
  "resources": [
    {
      "name": "loadbalancerclaims",
      "namespaced": true,
      "kind": "Loadbalancerclaim"
    },
    {
      "name": "loadbalancers",
      "namespaced": true,
      "kind": "Loadbalancer"
    }
  ]
}
[root<strong i="26">@localhost</strong> kubernetes]# kc get loadbalancers
No resources found.
[root<strong i="27">@localhost</strong> kubernetes]# kc get loadbalancerclaims
No resources found.

يبدو أننا ندعم بالفعل موارد متعددة ، إصدار واحد.

وألقي نظرة عميقة على التعليمات البرمجية ذات الصلة بنظام الحماية المؤقت (TPR). سيتم مزامنة thirdparty_controller بشكل دوري (كل 10 ثوانٍ) ، وسيتم تثبيت كل TPR جديد ، وكذلك القيام ببعض مهام الحذف. يحتوي ThirdPartyResourceServer على كافة تعيينات TPR المثبتة. كما نرى من SyncOneResource و InstallThirdPartyResource ، حتى هذه المجموعة موجودة ، ستستمر في تحديث المجموعة بواجهة برمجة التطبيقات الجديدة.

وجدت أيضًا أنني قادر على حذف مخطط تعريف TPR حتى مع وجود مثيلات TPR في النظام. أعتقد أن هذا لا ينبغي السماح به.

@ deads2k قضيت بعض الوقت في محاولة إعادة إنتاج العدد الأول:

حاول تمكين هذا الاختبار: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . إذا نجح ، فنحن جيدون. إذا فشلت ، هناك خطأ ما.

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

بالنسبة للمشكلة رقم 1 ، تم إصلاحها هنا:

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

brendandburns في الواقع لا ، يمكنك تشغيل اختبار تكامل التعليقات ، وسيفشل.

brendandburns بشكل صحيح ، لقد قمنا بدعم موارد متعددة ، إصدار واحد ، لكن

AdoHe هل قدمت مشكلة؟ يمكنني إلقاء نظرة.

brendandburns يمكنك أن ترى هنا:

https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 

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

brendandburns أخشى ألا أقدم مشكلة.

راجع أيضًا https://github.com/kubernetes/kubernetes/issues/32306 (يجب حذف TPR عند حذف مساحة الاسم)

@ deads2k هل يمكنك تحديث قائمة المراجعة؟

@ deads2k هل يمكنك تحديث قائمة المراجعة؟

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

@ deads2k أعمل بالفعل على Multiple Resources, single version و Multiple versions ، أعتقد أن الكثير من التعليمات البرمجية بحاجة إلى التحديث.

@ deads2k لا تزال الميزة لا تزال تستهدف 1.5؟

idvoretskyi أخشى ألا :(

@ deads2k : يجب إضافة ThirdPartyResources إلى واجهات برمجة التطبيقات الموحدة.

@ deads2k : محددات الحقول لا تعمل حاليًا عند الاستعلام عن ThirdPartyObjects ، هل هذا شيء

@ deads2krmohr kubectl لا يزال لديه العديد من القدرات المتميزة ضد TPR، القائمة أعلاه ينبغي تحديثها لتتبع هذه.

@ deads2k : محددات الحقول لا تعمل حاليًا عند الاستعلام عن ThirdPartyObjects ، هل هذا شيء

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

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

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

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

/ cc liggitt @ deads2kAdoHe

للحصول على تعقيد TPRs في كود apiserver ولجعل منطق TPR أكثر وضوحًا ، سأصوت بالتأكيد لـ tpr-apiserver مستقل. لكن IMO هذا لا يمنع أيًا من الإصلاحات.

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

سآخذ (مرة أخرى) تشغيلًا لإصلاح بعض هذه المشكلات ...

https://github.com/kubernetes/kubernetes/pull/40260 و https://github.com/kubernetes/kubernetes/pull/40096 سيجعلنا في حالة جيدة من جانب kubectl

المشكلة الأكثر خطورة من جانب الخادم في الوقت الحالي هي أن جامع القمامة يفقد عقله على ownerRefs التي تشير إلى TPRs.

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

liggitt سألقي نظرة على مراجعة هؤلاء. شكرا

هل لدى أي شخص مؤشر لكيفية الإشارة إلى نظام الحماية المؤقت في قواعد RBAC؟ لدي TPR اسمه مثل foo-bar.something.example.com. بصفتي مشرفًا للكتلة ، يمكنني الحصول على قائمة foobars في مساحة اسم معينة باستخدام kubectl get foobars .

عندما يحاول مستخدم عادي نفس الشيء يحصل على Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

لقد جربت كل أشكال مختلفة من foobar و foo-bar وما إلى ذلك والتي يمكنني التفكير فيها في قاعدة RBAC دون أي حظ حتى الآن.

في القاعدة ، أنت تبحث عن المورد = foobars apigroup = something.example.com الفعل = get ، list ، watch

@ deads2k هذا فعل الحيلة. شكرا!

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

The most severe server-side issue at the moment is the garbage collector losing its mind over ownerRefs that point to TPRs.

أي شيء متعلق بقضية تنظيف نظام الحماية المؤقت؟

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

تختلف كلتا مشكلتي أداة تجميع البيانات المهملة عن الحاجة إلى تنظيف كائنات ThirdPartyResourceData بشكل موثوق عند إزالة كائن ThirdPartyResource.

liggitt شكرًا على شرح المريض ، فما هي خطة TPR في 1.6؟

يسجل GC الآن فقط 1k مرة في الثانية بدلاً من 50k مرة في الثانية ،
لذلك لم يعد يفوز بالسباق مع محور دوار السجل. لكن الحل الحقيقي سيكون
قريبا ، نأمل.

في يوم السبت 4 فبراير 2017 الساعة 11:54 مساءً ، كتب TonyAdo [email protected] :

liggitt https://github.com/liggitt شكرًا على شرح المريض ، لذا
ما هي خطة TPR في 1.6؟

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

بعض القضايا المفتوحة المتعلقة بنظام الحماية المؤقت. ليس شاملا.

مشاكل المجموعة / الإصدار: https://github.com/kubernetes/kubernetes/pull/24299 ، https://github.com/kubernetes/kubernetes/pull/36977
شاهد: https://github.com/kubernetes/kubernetes/issues/25340
الرابط الذاتي: https://github.com/kubernetes/kubernetes/issues/37622
حذف مساحة الاسم: https://github.com/kubernetes/kubernetes/issues/37554
GC: https://github.com/kubernetes/kubernetes/issues/39816
المصممون النهائيون: https://github.com/kubernetes/kubernetes/issues/40715
تنظيف بيانات TPR: https://github.com/kubernetes/kubernetes/issues/35949
تحقق أقوى للبيانات الوصفية: https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
عدم وجود اختبارات الوحدة: https://github.com/kubernetes/kubernetes/pull/40956
التنظيف: https://github.com/kubernetes/kubernetes/issues/36998

الميزات التي يعتقد المستخدمون أنها أخطاء لأنها تعمل مع موارد أخرى:
السلوك غير المتزامن: https://github.com/kubernetes/kubernetes/issues/29002
الأعداد الصحيحة: https://github.com/kubernetes/kubernetes/issues/30213
YAML: https://github.com/kubernetes/kubernetes/issues/37455
إخراج kubectl لائق: https://github.com/kubernetes/kubernetes/issues/31343
تبسيط تسمية الموارد: https://github.com/kubernetes/kubernetes/issues/29415
التقديم: https://github.com/kubernetes/kubernetes/issues/29542 ، https://github.com/kubernetes/kubernetes/issues/39906
تحرير: https://github.com/kubernetes/kubernetes/issues/35993

/نسخة

الاشتراك لأننا نحاول التعامل مع TPRs في Dashboard.

مشكلات التتبع هي https://github.com/kubernetes/dashboard/issues/1671 و https://github.com/kubernetes/dashboard/issues/1504.

@ kubernetes / dashboard- صيانة

ما هي الحالة / الخطة الخاصة بـ TPR بدون مسافة اسم؟ لم أجد مناقشات حوله ، ربما فاتني شيء؟

sttts للبدء ، أنا مفتون بالتطوير في Kubernetes. وأريد المساهمة فيه ، لكن Go هي لغة جديدة بالنسبة لي. ما الذي أوصوني به يا رفاق حتى أتمكن من الحصول على هذا المشروع لـ GSoC 2017؟

لإضافة شيء عني ، أنا جيد إلى حد ما في C ++ و Java وأنا حاصل على درجة البكالوريوس في علوم الكمبيوتر. لقد بدأت أيضًا في قراءة الوثائق وحصلت على دورة Udacity التي تتضمن Kubernetes.

grpndrs لدينا قائمة بالمشكلات المصنفة والتي تعد نقطة بداية جيدة للوصول إلى الكود: https://github.com/kubernetes/kubernetes/issues؟q=is٪3Aopen+is٪3Aissue+label٪3Afor-new - المساهمون. لا تتردد في الاتصال بي في Slack ويمكننا المرور ببعض منها.

enisoc

هل لا يزال Multiple Resources, single version, different add times يمثل مشكلة؟ يمكنني إنشاء وحذف TPRs متعددة بدون مشكلة.

أيضًا ، هل يمكننا ترقيم مربعات الاختيار بـ Outstanding Capabilities حتى يسهل الرجوع إليها؟ @ deads2k أعتقد أنه يمكنك القيام بذلك على النحو التالي:

1. - [ ] ...
2. - [ ] ...

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

هل يعرف أي شخص كيف يأتي عنصر التحقق من هذا؟

لا أتوقع حدوث ذلك لـ 1.7. في الوقت الحالي ، نناقش بعض آلام النمو الهيكلية هنا https://github.com/kubernetes/community/pull/524 لتوفير قاعدة أكثر استقرارًا للنمو عليها.

لا أتوقع حدوث ذلك لـ 1.7. في الوقت الحالي ، نناقش بعض آلام النمو الهيكلية هنا kubernetes / community # 524 لتوفير قاعدة أكثر استقرارًا للنمو عليها.

نحن نخطط للمضي قدمًا مع https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md في الإطار الزمني 1.7. سأقوم بإجراء تحديثات هنا وفي مكالمات sig-apimachinery بينما نتحرك.

@ deads2k لم أر أي شيء هناك حول التحقق من صحة tpr. ألا تعتبر ذلك شيئًا مطلوبًا للإصدار التجريبي؟

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

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

@ deads2kenisoc بدأنا مؤخرا لاستخدام نظام الحماية المؤقت، والتحقق من صحة TPR ستكون حاسمة جدا لبعض من مشاريعنا المقبلة. إذا كان لدينا المورد للعمل عليه ، فهل تفكر في قبول مساهمين من المجتمع لتحقيق ذلك؟

@ deads2kenisoc بدأنا مؤخرا لاستخدام نظام الحماية المؤقت، والتحقق من صحة TPR ستكون حاسمة جدا لبعض من مشاريعنا المقبلة. إذا كان لدينا المورد للعمل عليه ، فهل تفكر في قبول مساهمين من المجتمع لتحقيق ذلك؟

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

أيضًا ، نظرًا لأن هذه ميزة بعيدة المدى ، فمن المهم ألا تصبح مساهمة مدفوعة. قد تساعد المساهمات النشطة (المراجعات والاختبارات والكود والترحيل) للانتقال إلى https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md . أنا deads2k على سلاك إذا كنت مهتمًا وتريد التحدث.

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

@ xiao-zhou يسعدنا أن يكون لدينا مشروع Google Summer of Code مقبول حول هذا الموضوع بالذات (تم الإعلان عنه بالأمس فقط). دعنا نتحدث على Slack حول كيفية التعاون في هذا الأمر. رائع جدًا أنك مهتم بهذا أيضًا ، لذلك لدينا بعض القوة لدفع هذا إلى الأمام!

@ xiao- zhousttts @ deads2k بمجرد أن يكون لديك اقتراح للتحقق من صحة نظام الحماية المؤقت ( ضع علامة عليّ في مراجعة الاقتراح؟ شكرا

sdminonne سيتم نشرها في sig-apimachinery. إذا قمت بالاشتراك في مجموعة google هذه ، فيجب أن يتم إعلامك.

sttts شكرا

@ deads2k هل ستقوم بإضافة ObservedGeneration لـ TPRs؟

https://github.com/kubernetes/kubernetes/issues/7328#issuecomment -287683598

@ deads2k هل ستقوم بإضافة ObservedGeneration لـ TPRs؟

لم أكن أخطط لذلك. لا يمكن للعميل الذي يهتم ببساطة مقارنة المواصفات وأسماء الحالة؟

قارن بين المواصفات وأسماء الحالة؟

لست متأكدا ما تعنيه هنا. صححني إذا كنت مخطئًا ولكني أعتقد أن هناك جزأين يتعلقان بـ ObservedGeneration: 1) يحتاج خادم واجهة برمجة التطبيقات إلى تحديث metadata.generation كل مرة يكون هناك تحديث في مواصفات TPR و 2) وحدة التحكم المسؤولة عن تقوم TPR بتحديث status.observedGeneration بناءً على metadata.Generation . أعتقد أن 1) هو ما أطلبه منك و 2) هو شيء يحتاج مؤلفو نظام الحماية من الإشعاع إلى الاهتمام به؟

لست متأكدا ما تعنيه هنا. صححني إذا كنت مخطئًا ولكني أعتقد أن هناك جزأين يتعلقان بـ ObservedGeneration: 1) يحتاج خادم API إلى تحديث metadata.generation في كل مرة يوجد فيها تحديث في مواصفات TPR و 2) وحدة التحكم المسؤولة عن حالة تحديثات TPR جيل على أساس البيانات الوصفية. أعتقد أن 1) هو ما أطلبه منك و 2) هو شيء يحتاج مؤلفو نظام الحماية من الإشعاع إلى الاهتمام به؟

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

في تعليقي المرتبط أعلاه ، كنت أطلب دعم الجيل لمثيلات TPR ، وليس لـ TPRs أنفسهم (على الرغم من أن ذلك سيكون لطيفًا أيضًا. هل هناك أسباب لعدم إضافته إلى جميع الكائنات؟).

على سبيل المثال ، إذا كان لديّ Kind: TPR; name: foo.example.com ومثال ذلك TPR Kind: Foo; name: foo123 ، فأنا مهتم بـ Generation / ObservedGeneration مقابل foo123 حتى تتمكن وحدة تحكم Foo من إعلام عملاء Foo بما إذا كانت قد تمت معالجتها تحديث لمثيل foo123 . هل له معنى؟ لا أرى كيف يمكن تحقيق ذلك بدون الدعم المناسب من جانب خادم k8s.

نعم ، يعتبر التوليد / الملحوظة الجيل منطقيًا لمخطط المستخدم لنظام الحماية المؤقت وليس لمورد نظام الحماية المؤقت الفعلي كما تطور.

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

القاعدة هي زيادة إنشاء الكائن فقط عند تحديث المواصفات ، وليس الحالة ، أليس كذلك؟

صيح.

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

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

kargakis لقد قمت بتحرير تعليق المستوى الأعلى لذكر هذه العناصر ، على الرغم من أنها خارج نطاق 1.7.

/نسخة

@ deads2k هل يجب إضافة اسم قصير لـ CustomResourceDefinition؟

تمت إضافة الاسم المختصر CRD لـ CustomResourceDefinition .

اقتراح تصميم للتحقق من CustomResources: https://github.com/kubernetes/community/pull/708 : ابتسامة:

@ deads2kenisoclavalamp
كان يتساءل عما إذا كان يمكن للمستخدم تكوين وحدة تحكم k8s وطرق (OR) CURD لكائنات CRD

في حالة الاستخدام الخاصة بي ، قمت بإنشاء networks.stable.example.com CRD واستخدمه لإنشاء شبكة كائن الشبكة 1:

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

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

كما هو مذكور في ملاحظات الإصدار 1.7 ومستنداته ، تم الآن إيقاف TPR ونخطط لإزالته في الإصدار 1.8. يجب على المستخدمين التبديل إلى CRD خلال الإطار الزمني 1.7.

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

تحديثات / خطط 1.8:

• دعم التحقق المستند إلى مخطط JSON والتقصير لـ CustomResources ( اقتراح )
• إضافة موارد فرعية (مثل الحالة والمقياس) للممثلين التجاريين (~ سيتم طرح الاقتراح قريبًا ~

شكراnikhita. لقد قمت بتحرير التعليق العلوي ليعكس 1.8 خطة.

يعرض Discovery المعلومات الصحيحة لـ CRS ولكن لا يستخدمها مصمم الخرائط REST - https://github.com/kubernetes/kubernetes/issues/49948

اقتراح لـ SubResources لـ CustomResources: https://github.com/kubernetes/community/pull/913 : tada:

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

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

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

هل هذا السؤال منطقي؟

hectoralicea هذا الريبو يستخدم لتخطيط الميزات التي يعمل عليها مطورو Kubernetes.

لطرح أسئلة عامة مثل هذه ، يرجى إرسالها إلى مجموعات مستخدمي Kubernetes. عادة ما تكون أكثر فائدة لهذا النوع من المناقشات عالية المستوى :)

راجع https://groups.google.com/forum/#!forum/kubernetes -users أو http://slack.k8s.io/ أو Stack Overflow.

colemickens @ deads2knikhitaenisoc واضاف لقد القسم 1.9.

sttts نسخة تجريبية محسنة في v1.9 ، أليس كذلك؟

luxas bugfixes بالطبع. لكن لا أعتقد أنه يتعين علينا سرد ذلك هنا.

sttts كنت أفكر في التحقق من صحة CRD ... هل تمت تغطيته في مشكلة الميزات هذه وسيتم الانتقال إلى الإصدار التجريبي في الإصدار 1.9 أو الإصدار التجريبي؟

luxas من

Scope of work planned for v1.9

    CRD validation to beta kubernetes/kubernetes#22768 kubernetes/kubernetes#53829
    CRD sub-resources as alpha kubernetes/community#913

أوه ، شكرًا @ Kargakis ، لم أنظر هناك: راحة البال:: ابتسم:

@ deads2k ، enisoc لا توجد خطط لـ "مستقرة" في 1.9 ، أليس كذلك؟

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

@ deads2k : wave: الرجاء فتح توثيق العلاقات العامة وإضافة رابط إلى جدول بيانات التتبع. شكرا لك مقدما!

@ deads2k الرجاء فتح توثيق العلاقات العامة وإضافة رابط إلى جدول بيانات التتبع. شكرا لك مقدما!

zacharysarah يبدو أنني قد وضعت رابط جدول البيانات في غير محله. محرر المستندات للتحقق من صحة CRD هنا https://github.com/kubernetes/website/pull/6066

للسجل ، توجد مشكلة إصدار CRD هنا: https://github.com/kubernetes/features/issues/544.

قائمة مهام CRDs التي تنتقل إلى GA: https://github.com/kubernetes/kubernetes/issues/58682

nikhita هل يعني ذلك أن ميزة CRD بأكملها تنتقل إلى GA؟

هل يعني ذلك أن ميزة CRD بأكملها تنتقل إلى GA؟

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

stttsnikhita هل يمكنك تحديد خارطة طريق الميزة بدقة أكبر؟

هل يمكنك تحديد خارطة طريق الميزة بدقة أكبر؟

ل 1.10:

• مصادر فرعية للموارد المخصصة وإصلاحات الأخطاء (على الأقل تلك التي لم يتم شطبها) المدرجة في https://github.com/kubernetes/kubernetes/issues/58682.

لا توجد مجموعة _exact_ من التسليمات المخطط لها للإصدارات القادمة ولكن الخطة هي الانتقال إلى GA بحلول نهاية العام (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

سننتقل إلى GA بمجرد اكتمال جميع المشكلات التي لم يتم شطبها في https://github.com/kubernetes/kubernetes/issues/58682 .

عندما تنتقل واجهة برمجة تطبيقات CRD إلى GA ، فقد تكون هناك ميزات فيها (على سبيل المثال: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg / features / kube_features.go # L35) التي يمكن أن تكون في إصدار ألفا / تجريبي.

stttsnikhita @ deads2k
أي خطط لهذا في 1.11؟

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

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

ccidvoretskyi

أي خطط لهذا في 1.11؟

ليس لدي أذونات لتعديل نص العلاقات العامة (إذا كان بإمكان شخص ما القيام بذلك ، فسيكون ذلك رائعًا!). لكن الخطة هي:

• تنفيذ إصدارات CRD. هناك مشكلة أخرى في الميزات: https://github.com/kubernetes/features/issues/544. اقتراح التصميم: https://github.com/kubernetes/community/pull/2026.
• أضف التقليم والتخلف عن الموارد المخصصة.
• دعم الخرائط في مخطط التحقق من صحة CRD. https://github.com/kubernetes/kubernetes/issues/59485
• تنفيذ دعم الحصة النسبية للموارد المخصصة (يمكن اعتبار ذلك بمثابة إصلاح للأخطاء أيضًا) https://github.com/kubernetes/kubernetes/issues/53777

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

يجب تحديث الوصف المكون من سطر واحد ليشمل "إضافة التحقق من الصحة ، والإعداد الافتراضي ، والمصادر الفرعية وإصدار إصدارات CRDs".

يجب أن تتضمن مقترحات التصميم المذكورة في الوصف ما يلي:

• https://github.com/kubernetes/community/pull/2026
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-subresources.md

هل يمكن لأي شخص إضافة هذه في هيئة العلاقات العامة أيضًا؟

ملصقات:

/ نوع الميزة

/ سم مكعب mbohlool

هل يمكن لأي شخص إضافة هذه في هيئة العلاقات العامة أيضًا؟

انتهى

nikhitastttsmbohlool - فقط للتوضيح، نحن تستهدف بيتا للدورة 1.11؟

nikhitastttsmbohlool - الأزيز مرة أخرى على هذا ...
هل نستهدف الإصدار التجريبي 1.11؟ فقط أريد التأكد من تجميد الميزات اليوم.

justaugustus CRDs هي بالفعل تجريبية. لم يتم التخطيط لـ GA لـ 1.11.

من المحتمل أن تبدأ جميع الميزات / الإضافات المدرجة (التقليم ، التقصير ، تعيين الإصدار) كألفا.

sttts Hmmm ، في هذه الحالة ، هل يجب أن يكون لدينا مشكلات منفصلة لتتبع تلك الميزات / الإضافات ومراحلها بشكل مستقل؟

للتسجيل - أنشأnikhita مشكلة للميزة الفرعية https://github.com/kubernetes/features/issues/571

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

مشكلة الميزة الفرعية الافتراضية والتقليم: https://github.com/kubernetes/features/issues/575

justaugustusidvoretskyi عن 1.12 أغراض التتبع: لن يكون هناك إضافات وربما الاصلاحات ولكن هذا سيبقى في مرحلة تجريبية ل1.12 (حتى لا تغير من ملامح وجهة نظر).

هناك ميزة فرعية جديدة تم التخطيط لها على أنها ألفا ، ولكن تم إنشاؤها كمسألة منفصلة: https://github.com/kubernetes/features/issues/575.

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

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

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

شكرا!

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

لا ، لا توجد خطط لتخرج هذا في 1.13. ستبقى واجهة برمجة تطبيقات CRD في مرحلة تجريبية.

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

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

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

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

@ deads2k مرحبًا - أنا قائد التحسين لـ 1.14 وأنا أتحقق من هذه المشكلة لمعرفة العمل (إن وجد) المخطط له لإصدار 1.14. تجميد التحسينات هو 29 يناير وأريد أن أذكر أن جميع التحسينات يجب أن تحتوي على KEP

claurence ستظل واجهة برمجة تطبيقات CRD في مرحلة تجريبية لـ 1.14 أيضًا.

مرحبًا nikhita @ deads2k ، أنا

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

سيبقى هذا في المرحلة التجريبية. العمل على التحقق من الصحة والتحويل ونشر OpenAPI يحدث في 1.15

وصف محدث مع روابط إلى KEPs ذات الصلة لـ 1.15

مهلا،liggitt @ deads2kjpbetzsttts أنا مستندات v1.15 الافراج الظل.

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

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

@ deads2kjpbetzstttsliggitt

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

محرر المستندات PR لـ 1.15: https://github.com/kubernetes/website/pull/14583

@ deads2k هل يمكنك تحديث وصف المشكلة؟

/ معلم v1.16.0
/ مرحلة مستقرة

مهلا،liggittjpbetzsttts أنا مستندات v1.16 تطلق الرصاص.

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

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

simonswine العنصر النائب PR https://github.com/kubernetes/website/pull/15982

liggittjpbetzsttts الخميس هو رمز التجميد. هل هناك أي علاقات عامة بارزة من شأنها أن تمنع هذا من التخرج إلى المستقرة؟ كل شيء في المنشور الأصلي للعمل المخطط له 1.15 * يبدو أنه مندمج.

أعتقد أن العلاقات العامة البارزة هي مجرد نتوء في إصدار بوابة الميزات (https://github.com/kubernetes/kubernetes/pull/81965) واثنين من إصلاحات الأخطاء البارزة التي يجب أن يتم إجراؤها في هذا الأسبوع: https://github.com/kubernetes / kubernetes / pull / 81436 ، https://github.com/kubernetes/kubernetes/issues/78707

مستندات جاهزة للمراجعة في https://github.com/kubernetes/website/pull/15982

تم إصداره باعتباره مستقرًا في الإصدار 1.16.0

تم تتبع العمل بعد GA في https://github.com/orgs/kubernetes/projects/28

/أغلق

liggitt : إغلاق هذه القضية.