@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.

ऐसा लगता है कि हम पहले से ही एकाधिक संसाधनों, एकल संस्करण का समर्थन करते हैं।

और मैं टीपीआर संबंधित कोड पर एक गहरी नजर रखता हूं। thirdparty_controller समय-समय पर सिंक (हर 10 सेकंड) करेगा, यह हर नए टीपीआर को स्थापित करेगा, और कुछ हटाने का काम भी करेगा। ThirdPartyResourceServer में सभी स्थापित TPR मैपिंग शामिल हैं। जैसा कि हम SyncOneResource और InstallThirdPartyResource से देख सकते हैं, यहां तक ​​​​कि यह समूह भी मौजूद है, यह अभी भी नए एपीआई के साथ समूह को अपडेट करेगा।

इसके अलावा, मैंने पाया कि सिस्टम में टीपीआर इंस्टेंस होने पर भी मैं एक टीपीआर स्कीमा डिफ को हटाने में सक्षम हूं। मुझे लगता है कि इसकी अनुमति नहीं दी जानी चाहिए।

@ deads2k मैंने पहले अंक को पुन: पेश करने का प्रयास करने में कुछ समय बिताया:

इस परीक्षण को सक्षम करने का प्रयास करें: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 । अगर यह काम करता है, तो हम अच्छे हैं। अगर यह विफल रहता है, तो कुछ गलत है।

@ deads2k हाय डेविड, कृपया मेरे द्वारा स्लैक पर भेजे गए संदेश पर एक नज़र डालें। इसके अलावा, मैं असफल एकीकरण परीक्षण में एक फिक्स जोड़ता हूं, जब टीपीआर हटा दिया जाता है तो तृतीय पक्ष संसाधन नियंत्रक संबंधित रूट हैंडलर को हटा देगा, इससे एकीकरण परीक्षण में मदद मिलेगी, लेकिन मुझे यकीन नहीं है कि यह कोई अन्य समस्या लाएगा या नहीं .

समस्या # 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 देखें (नाम स्थान हटाए जाने पर टीपीआर हटा दिया जाना चाहिए)

@ deads2k क्या आप चेकलिस्ट को अपडेट कर सकते हैं?

@ deads2k क्या आप चेकलिस्ट को अपडेट कर सकते हैं?

सभी मुद्दे अभी भी बकाया हैं। यह वास्तव में 1.3 से (पहले से) बीटा thirdparyresources कार्यान्वयन में समस्याओं को ट्रैक करने के लिए एक सुविधा है। हमें अपनी समस्याओं पर नज़र रखने के लिए जगह चाहिए थी, लेकिन 1.5 में अन्य प्रयासों के लिए ऊर्जा समर्पित करनी पड़ी।

@ deads2k मैं पहले से ही Multiple Resources, single version और Multiple versions पर काम कर रहा हूं, मुझे लगता है कि बहुत सारे कोड को अपडेट करने की आवश्यकता है।

@ deads2k अभी भी 1.5 को लक्षित करता है?

@idvoretskyi मुझे डर नहीं है :(

@ deads2k : थर्डपार्टी रिसोर्सेज को फ़ेडरेटेड एपीआई में जोड़ा जाना चाहिए।

@ deads2k :

@ deads2k @rmohr kubectl में अभी भी टीपीआर के खिलाफ कई उत्कृष्ट क्षमताएं हैं, इन्हें ट्रैक करने के लिए उपरोक्त सूची को अपडेट किया जाना चाहिए।

@ deads2k :

यह सभी API प्रकारों में असंगत फ़ील्ड चयनकर्ता समर्थन की अधिक सामान्य समस्या है।

मैं इसे भी देखना शुरू कर रहा हूं। "बाहरी" नियंत्रकों जैसे चिंगारी का समर्थन करने के लिए थर्डपार्टी संसाधन बहुत महत्वपूर्ण हैं, और इससे पहले कि हम उप-संसाधन जैसी चीजों को जोड़ सकें, हमें इसे ठीक करना चाहिए।

फ़ील्ड चयनकर्ता केवल नियमित API ऑब्जेक्ट में हाथ से क्यूरेट किए गए फ़ील्ड पर काम करते हैं। मैं उनसे टीपीआर में किसी भी क्षेत्र के लिए काम करने की उम्मीद नहीं करता - एपिसर्वर मनमाने ढंग से प्रश्न करने के लिए नहीं बनाया गया है। अगर आपको उस व्यवहार की ज़रूरत है तो टीपीआर आपके लिए काम नहीं करेगा।

क्या टीपीआर को एडऑन एपीआई सर्वर में स्थानांतरित करने के लिए अगला कदम है?
ऐसा लगता है कि यहां सूची में कुछ मुद्दों को ठीक करने के लिए कुछ बकाया पीआर हैं जिन्हें इस मद पर अवरुद्ध किया जा सकता है।

/सीसी @liggitt @deads2k @AdoHe

एपिसर्वर कोड में टीपीआर की जटिलता को कम करने के लिए और टीपीआर तर्क को और अधिक स्पष्ट करने के लिए, मैं निश्चित रूप से एक स्टैंडअलोन tpr-apiserver लिए वोट करूंगा। लेकिन आईएमओ यह वास्तव में किसी भी सुधार को अवरुद्ध नहीं करता है।

मैं कई गैर-परिवर्तनीय प्रकारों से निपटने के दौरान एपीआई सेमेन्टिक्स (प्राप्त, सूची, घड़ी, अद्यतन, पैच) को संभालने के बारे में कुछ आइटम जोड़ रहा हूं। मुझे लगता है कि शायद एक डिज़ाइन दस्तावेज़ की आवश्यकता है, क्योंकि अर्थशास्त्र सामान्य एपीआई अर्थशास्त्र से मेल खाने की संभावना नहीं है।

मैं इनमें से कुछ मुद्दों को ठीक करने के लिए (अभी तक एक और) दौड़ लूंगा ...

https://github.com/kubernetes/kubernetes/pull/40260 और https://github.com/kubernetes/kubernetes/pull/40096 हमें Kubectl की तरफ अच्छे आकार में लाएंगे

इस समय सबसे गंभीर सर्वर-साइड समस्या है कूड़ा उठाने वाला जो TPRs की ओर इशारा करने वाले मालिकRefs पर अपना दिमाग खो देता है।

एक बार जब हम इसे हल कर लेते हैं, तो हमें यह तय करना चाहिए कि किसी दिए गए टीपीआर के कई संस्करणों के आसपास एपीआई शब्दार्थ क्या होना चाहिए, और सुनिश्चित करें कि टीपीआर प्रकार में वह डेटा है जिसकी हमें आवश्यकता है। यह सर्वर-साइड स्टोरेज इंपैक्ट को प्रभावित करने की संभावना है, इसलिए हम बहुत अधिक सर्वर-साइड काम करने से पहले डिज़ाइन को कम कर देंगे।

@liggitt मैं डालेगा । धन्यवाद

क्या किसी के पास कोई संकेत है कि आरबीएसी नियमों में टीपीआर को कैसे संदर्भित किया जाए? मेरे पास एक टीपीआर है जिसका नाम foo-bar.something.example.com है। क्लस्टर व्यवस्थापक के रूप में मैं किसी दिए गए नाम स्थान में kubectl get foobars साथ 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 verb=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.

टीपीआर सफाई मुद्दे से संबंधित कुछ?

नहीं, यह कचरा संग्रहकर्ता के साथ एक समस्या थी जो यह नहीं जानता था कि मालिक को कैसे देखना है, यह संकलित प्रकारों के अलावा किसी अन्य चीज़ के लिए है। रिवर्स इश्यू भी मौजूद है, कचरा संग्रहकर्ता संकलित प्रकारों के अलावा किसी अन्य चीज़ पर अंतिम रूप देने वालों पर ध्यान नहीं दे रहा है।

ये दोनों कचरा संग्रहकर्ता मुद्दे थर्डपार्टी रिसोर्सडेटा ऑब्जेक्ट को थर्डपार्टी रिसोर्स ऑब्जेक्ट को हटा दिए जाने पर विश्वसनीय रूप से साफ करने की आवश्यकता से अलग हैं।

@liggitt रोगी स्पष्टीकरण के लिए धन्यवाद, तो 1.6 में

GC अब प्रति सेकंड 50k बार के बजाय केवल 1k बार प्रति सेकंड लॉग करता है,
इसलिए यह अब लॉग रोटेटर के साथ रेस नहीं जीतता है। लेकिन एक वास्तविक सुधार होगा
जल्द ही आ रहा है, उम्मीद है।

शनिवार, 4 फरवरी, 2017 को रात 11:54 बजे, टोनीएडो नोटिफिकेशन @github.com ने लिखा:

@liggitt https://github.com/liggitt रोगी स्पष्टीकरण के लिए धन्यवाद, इसलिए
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
जीसी: https://github.com/kubernetes/kubernetes/issues/39816
अंतिम रूप देने वाले: https://github.com/kubernetes/kubernetes/issues/40715
टीपीआर डेटा की सफाई: 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

वे सुविधाएँ जो उपयोगकर्ताओं को लगता है कि वे बग हैं क्योंकि वे अन्य संसाधनों के लिए काम करती हैं:
Async व्यवहार: https://github.com/kubernetes/kubernetes/issues/29002
पूर्णांक: https://github.com/kubernetes/kubernetes/issues/30213
वाईएएमएल: 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

/सीसी

सदस्यता लेने के रूप में हम डैशबोर्ड में टीपीआर को संभालने की कोशिश कर रहे हैं।

ट्रैकिंग समस्याएं https://github.com/kubernetes/dashboard/issues/1671 और https://github.com/kubernetes/dashboard/issues/1504 हैं।

@kubernetes/डैशबोर्ड-रखरखाव

गैर-नामित टीपीआर की स्थिति/योजना क्या है? मुझे इसके बारे में चर्चा नहीं मिली, शायद कुछ छूट गया?

@sttts शुरू करने के लिए, मैं कुबेरनेट्स के विकास से चिंतित हूं। और मैं इसमें योगदान देना चाहता हूं, लेकिन गो मेरे लिए एक नई भाषा है। आप लोग मुझे क्या करने की सलाह देते हैं ताकि मुझे यह प्रोजेक्ट GSoC 2017 के लिए मिल सके?

मेरे बारे में कुछ जोड़ने के लिए, मैं सी ++ और जावा में काफी अच्छा हूं और मेरे पास कंप्यूटर साइंस में स्नातक है। मैंने प्रलेखन पढ़ना भी शुरू कर दिया है और कुबेरनेट्स को शामिल करते हुए उडेसिटी पाठ्यक्रम लिया है।

@grpndrs हमारे पास लेबल किए गए मुद्दों की एक सूची है जो कोड में आने के लिए एक अच्छा प्रारंभिक बिंदु है: https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -योगदानकर्ता। बेझिझक मुझसे संपर्क करें और हम उनमें से कुछ के माध्यम से जा सकते हैं।

@enisoc

क्या Multiple Resources, single version, different add times अभी भी एक मुद्दा है? मैं बिना किसी समस्या के कई टीपीआर बना और हटा सकता हूं।

साथ ही, क्या हम चेकबॉक्स को Outstanding Capabilities में क्रमांकित कर सकते हैं ताकि इसका संदर्भ लेना आसान हो जाए? @ deads2k मुझे लगता है कि आप इसे ऐसा कर सकते हैं:

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

क्या किसी को पता है कि इसका सत्यापन घटक कैसे आ रहा है? मैं टीपीआर के साथ बहुत काम करता हूं और यह सुविधा अमूल्य होगी और बहुत सारे कस्टम कोड बचाएगी। मुझे इस सुविधा में योगदान देना अच्छा लगेगा, लेकिन मैं यह जानना चाहता हूं कि क्या इस मुद्दे की सदस्यता लेने वाले किसी व्यक्ति को इसकी स्थिति पता है

क्या किसी को पता है कि इसका सत्यापन घटक कैसे आ रहा है?

मुझे उम्मीद नहीं है कि यह 1.7 के लिए होगा। फिलहाल, हम यहां कुछ संरचनात्मक बढ़ते दर्द पर चर्चा कर रहे हैं https://github.com/kubernetes/community/pull/524 आगे बढ़ने के लिए एक अधिक स्थिर आधार प्रदान करने के लिए।

मुझे उम्मीद नहीं है कि यह 1.7 के लिए होगा। फिलहाल, हम यहां कुछ संरचनात्मक बढ़ते दर्द पर चर्चा कर रहे हैं, कुबेरनेट्स/समुदाय#524 पर बढ़ने के लिए एक अधिक स्थिर आधार प्रदान करने के लिए।

हम 1.7 समय सीमा में https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md के साथ आगे बढ़ने की योजना बना रहे हैं। जैसे-जैसे हम आगे बढ़ेंगे, मैं यहां और सिग-एपिमैचिनरी कॉल्स में अपडेट करूंगा।

@ deads2k मैंने

@frankgreco प्रस्ताव टीपीआर के निर्माण के लिए एक ठोस आधार के बारे में है। सत्यापन जैसी सुविधाएँ बाद में जोड़ी जा सकती हैं, लेकिन यहाँ दायरे से बाहर हैं।

मैंने इस धागे की मूल टिप्पणी को नए टेम्पलेट का उपयोग करने के लिए संपादित किया है, और 1.7 के लिए नियोजित कार्य के दायरे को स्पष्ट करने के लिए, जैसा कि मैं इसे समझता हूं। कृपया इसे देखें और ठीक करें/टिप्पणी करें।

@ deads2k @enisoc हम हाल ही में TPR का उपयोग करना शुरू कर रहे हैं, और TPR सत्यापन हमारी कुछ आगामी परियोजनाओं के लिए बहुत महत्वपूर्ण होने जा रहा है। यदि हमारे पास इस पर काम करने के लिए संसाधन हैं, तो क्या आप इसे पूरा करने के लिए सामुदायिक योगदानकर्ताओं को स्वीकार करने पर विचार करेंगे?

@ deads2k @enisoc हम हाल ही में TPR का उपयोग करना शुरू कर रहे हैं, और TPR सत्यापन हमारी कुछ आगामी परियोजनाओं के लिए बहुत महत्वपूर्ण होने जा रहा है। यदि हमारे पास इस पर काम करने के लिए संसाधन हैं, तो क्या आप इसे पूरा करने के लिए सामुदायिक योगदानकर्ताओं को स्वीकार करने पर विचार करेंगे?

बिल्कुल। कुछ इस तरह के लिए, हम पुल अनुरोधों को देखना शुरू करने से पहले एक डिज़ाइन प्रस्ताव चाहते हैं। इसके अलावा, यह देखते हुए कि कितने अलग-अलग दृष्टिकोण संभव हैं, मेरा सुझाव है कि आप शीर्ष तीन या इतने ही विचारों को सूचीबद्ध करें और एक संक्षिप्त विवरण दें कि आप जो चुनते हैं वह सबसे अच्छा क्यों है। इसके सर्वर साइड के बाद से, प्रदर्शन और सुरक्षा संबंधी विचार बहुत महत्वपूर्ण हैं।

साथ ही, चूंकि यह एक दूरगामी विशेषता है, इसलिए यह महत्वपूर्ण है कि यह एक ड्राइव-बाय योगदान न बने। https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md में संक्रमण के लिए सक्रिय योगदान (समीक्षा, परीक्षण, कोड, माइग्रेशन) से मदद मिलेगी। यदि आप रुचि रखते हैं और बात करना चाहते हैं तो मैं सुस्त हूं।

धन्यवाद @ deads2k! यह पूरी तरह से वाजिब है। हम टीपीआर सत्यापन के लिए कुछ डिजाइन प्रस्ताव लेकर आएंगे, इसे साझा करने का सबसे अच्छा तरीका क्या है? मैं भी सुस्त हो जाऊंगा

@ जिओ-झोउ हम इस विषय के आसपास एक स्वीकृत Google समर ऑफ कोड प्रोजेक्ट पाकर खुश हैं (कल ही घोषित किया गया था)। आइए स्लैक पर चैट करें कि इस पर कैसे सहयोग किया जाए। बहुत अच्छा है कि आप इसमें भी रुचि रखते हैं, इसलिए इसे आगे बढ़ाने के लिए हमारे पास काफी ताकत है!

@ जिओ-झोउ @sttts @ deads2k जैसे ही आपके पास

@sdminonne इसे sig-apimachinery में पोस्ट किया जाएगा। यदि आप उस Google समूह की सदस्यता लेते हैं, तो आपको सूचित किया जाना चाहिए।

@sttts धन्यवाद

@ deads2k क्या आप

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

@ deads2k क्या आप

मैं करने की योजना नहीं बना रहा था। क्या एक ग्राहक जो परवाह करता है वह केवल कल्पना और स्थिति के नामों की तुलना नहीं कर सकता है?

कल्पना और स्थिति के नामों की तुलना करें?

आपका यहाँ क्या मतलब है मुझे पक्का नहीं है। मुझे सुधारें अगर मैं गलत हूं, लेकिन मुझे लगता है कि दो भाग फिर से देखे गए हैं: 1) एपीआई सर्वर को हर बार टीपीआर की विशिष्टता में अपडेट होने पर metadata.generation को अपडेट करने की आवश्यकता होती है और 2) नियंत्रक के लिए जिम्मेदार टीपीआर status.observedGeneration आधार पर metadata.Generation अपडेट करता है। मुझे लगता है 1) मैं आपसे यही पूछ रहा हूं और 2) क्या टीपीआर लेखकों को ध्यान रखने की जरूरत है?

आपका यहाँ क्या मतलब है मुझे पक्का नहीं है। मुझे सही करें यदि मैं गलत हूं, लेकिन मुझे लगता है कि दो भाग फिर से देखे गए हैं: 1) एपीआई सर्वर को मेटाडेटा अपडेट करने की आवश्यकता होती है। हर बार टीपीआर की विशिष्टता में एक अपडेट होता है और 2) टीपीआर अपडेट स्थिति के लिए जिम्मेदार नियंत्रक .ऑब्जर्व्डजनरेशन मेटाडेटा पर आधारित है। जेनरेशन। मुझे लगता है 1) मैं आपसे यही पूछ रहा हूं और 2) क्या टीपीआर लेखकों को ध्यान रखने की जरूरत है?

ओह, मैंने गलत समझा कि आप किस बारे में पूछ रहे थे। आप CustomResource के लिए मनाया गया जनरेशन चाहते हैं, CustomResourceDefinition नहीं। मैंने सोचा था कि अवलोकन पीढ़ी केवल आवश्यक कार्रवाई के लिए निर्दिष्ट परिवर्तनों के लिए टक्कर लगी थी। इसका मतलब है कि मेटाडेटा के अपडेट ने इसे ट्रिगर नहीं किया और कुछ विशिष्ट फ़ील्ड के अपडेट से भी इसे टकराने से बचा जा सकता है।

ऊपर दी गई मेरी टिप्पणी में मैं टीपीआर उदाहरणों के लिए जनरेशन समर्थन मांग रहा था, न कि टीपीआर के लिए (हालांकि यह भी अच्छा होगा। इसे सभी वस्तुओं में जोड़ने का कोई कारण नहीं है?)।

उदाहरण के लिए अगर मेरे पास Kind: TPR; name: foo.example.com और उस टीपीआर Kind: Foo; name: foo123 उदाहरण है, तो मुझे foo123 लिए जेनरेशन/ऑब्जर्व्ड जेनरेशन में दिलचस्पी है ताकि फू कंट्रोलर फू उपभोक्ताओं को यह बता सके कि क्या यह संसाधित हो गया है foo123 उदाहरण के लिए एक अद्यतन। क्या इस का कोई मतलब निकलता है? मैं यह नहीं देखता कि k8s सर्वर साइड पर उचित समर्थन के बिना इसे कैसे प्राप्त किया जा सकता है।

हाँ, पीढ़ी/अवलोकन जनरेशन टीपीआर के उपयोगकर्ता स्कीमा के लिए समझ में आता है, न कि वास्तविक टीपीआर संसाधन के लिए जैसा कि यह विकसित हुआ है।

@kargakis नियम केवल विशिष्ट अद्यतन पर वस्तु पीढ़ी को बढ़ाना है, स्थिति नहीं, है ना? यदि ऐसा है तो इसका मतलब है कि हमें पहले आधिकारिक तौर पर टीपीआर उदाहरण पर स्पेक/स्टेटस स्प्लिट का समर्थन करने की आवश्यकता है। मैं 1.8 को लक्षित करते हुए टीपीआर स्थिति के लिए एक प्रस्ताव लिखने की योजना बना रहा था। मैं प्रस्ताव में वृद्धिशील वस्तु पीढ़ी को शामिल करना सुनिश्चित कर सकता हूं।

नियम केवल विशिष्ट अद्यतन पर वस्तु पीढ़ी को बढ़ाना है, स्थिति नहीं, है ना?

सही।

यदि ऐसा है तो इसका मतलब है कि हमें पहले आधिकारिक तौर पर टीपीआर उदाहरण पर स्पेक/स्टेटस स्प्लिट का समर्थन करने की आवश्यकता है।

हाँ, मुझे उस विभाजन को मौजूदा मुद्दे के हिस्से के रूप में खोजने की उम्मीद थी, लेकिन ऐसा लगता है कि वहां पहुंचने से पहले और काम करने की जरूरत है ..

@kargakis मैंने इन वस्तुओं का उल्लेख करने के लिए शीर्ष-स्तरीय टिप्पणी संपादित की है, हालांकि वे 1.7 के दायरे से बाहर हैं।

/सीसी

@ deads2k क्या हमें CustomResourceDefinition के लिए

CustomResourceDefinition के लिए संक्षिप्त नाम CRD जोड़ा गया ।

CustomResources के सत्यापन के लिए एक डिज़ाइन प्रस्ताव: https://github.com/kubernetes/community/pull/708 :smile:

@deads2k @enisoc @lavalamp
सोच रहा था कि क्या उपयोगकर्ता सीआरडी ऑब्जेक्ट्स के लिए k8s नियंत्रक और (या) CURD विधियों को कॉन्फ़िगर कर सकता है

मेरे विशेष उपयोग-मामले में मैं एक networks.stable.example.com CRD बनाता हूं और इसका उपयोग नेटवर्क ऑब्जेक्ट net1 बनाने के लिए करता हूं:

मुझे यह सुनिश्चित करने की ज़रूरत है कि एक नया नेटवर्क सीआरडी ऑब्जेक्ट बनाने की अनुमति नहीं है यदि एक नेटवर्क सीआरडी ऑब्जेक्ट एक ओवरलैपिंग सबनेट रेंज के साथ पहले से मौजूद है

यदि ऐसा तंत्र मौजूद नहीं है, तो मुझे कुछ विचारों को एक डिजाइन दस्तावेज़ में एक साथ रखने में खुशी होगी।

जैसा कि 1.7 रिलीज़ नोट और दस्तावेज़ में बताया गया है, TPR अब बहिष्कृत कर दिया गया है और हम इसे 1.8 में निकालने की योजना बना रहे हैं। उपयोगकर्ताओं को 1.7 समय सीमा के दौरान सीआरडी पर स्विच करना चाहिए।

यदि आपका कोई प्रश्न या चिंता है तो कृपया हटाने के लिए ट्रैकिंग समस्या पर टिप्पणी करें।

1.8 के लिए अद्यतन/योजनाएं:

• CustomResources ( प्रस्ताव ) के लिए JSON स्कीमा आधारित सत्यापन और डिफ़ॉल्ट का समर्थन करें
• सीआर के लिए उप-संसाधन (जैसे स्थिति और पैमाने) जोड़ें (~प्रस्ताव जल्द ही बाहर हो जाएगा~ प्रस्ताव )

धन्यवाद @ निखिता। मैंने 1.8 योजनाओं को दर्शाने के लिए शीर्ष टिप्पणी संपादित की है।

डिस्कवरी सीआर के लिए सही जानकारी देता है लेकिन आरईएसटी मैपर इसका उपयोग नहीं करता है - https://github.com/kubernetes/kubernetes/issues/49948

CustomResources के लिए उप-संसाधनों का प्रस्ताव: https://github.com/kubernetes/community/pull/913 :tada:

कृपया मेरी गलत पोस्ट को क्षमा करें, लेकिन मैं इस पृष्ठ पर कुछ अन्य कुबेरनेट्स पृष्ठ से यह सोचकर आया था कि कुबेरनेट्स में केवल तीसरे पक्ष के कंटेनर संसाधनों के प्रबंधन के लिए एक सूक्ष्म सेवा ढांचा शामिल है।

रेडहैट ओपनशिफ्ट कुबेरनेट्स को एक माइक्रो-सर्विसेज प्लेटफॉर्म के रूप में बाजार में उतारता है, लेकिन फिर भी, मुझे यह सुविधा नहीं मिल रही है। मैं बहुत हल्के वजन वाले स्वतंत्र एप्लिकेशन माइक्रो-सर्विसेज के अपने सूट को होस्ट करने के लिए चीज़ जैसे एप्लिकेशन सर्वर की तलाश में हूं।

क्या ऐसी कोई चीज मौजूद है, या क्या हमें स्प्रिंगबूट में मोटे जावा युद्ध ऐप बनाने और उन्हें एक टॉमकैट सर्वर पर तैनात करने के लिए आरोपित किया गया है जो कुबेरनेट्स प्रबंधित कंटेनर के अंदर बैठता है, जिसे प्रबंधित करना मुश्किल है और तैनात करना मुश्किल है। मुझे एक माइक्रो-सर्विसेज प्लेटफॉर्म की जरूरत है जहां 1 एडमिनिस्ट्रेटर 100 माइक्रो-सर्विसेज को मैनेज और ऑपरेट कर सके।

क्या यह प्रश्न समझ में आता है?

@hectoralicea इस रेपो का उपयोग कुबेरनेट्स डेवलपर्स द्वारा काम की गई सुविधाओं की योजना बनाने के लिए किया जाता है।

इस तरह के सामान्य प्रश्नों के लिए, कृपया Kubernetes उपयोगकर्ता समूहों पर पोस्ट करें। वे इस तरह की उच्च स्तरीय चर्चा के लिए आमतौर पर अधिक सहायक होते हैं :)

देखें https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ , या स्टैक ओवरफ़्लो।

@colemickens @deads2k @nikhita @enisoc मैंने

@sttts v1.9 में बेहतर बीटा संस्करण, है ना?

@luxas निश्चित रूप से

@sttts मैं सीआरडी सत्यापन के बारे में सोच रहा था ... क्या यह इस सुविधाओं के मुद्दे में शामिल है और v1.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 , वहाँ नहीं देखा: facepalm:: मुस्कान:

@ deads2k , @enisoc 1.9 में "स्थिर" के लिए कोई योजना नहीं है, है ना?

@idvoretskyi राइट।

@ deads2k : wave: कृपया एक दस्तावेज़ पीआर खोलें और ट्रैकिंग स्प्रेडशीट में एक लिंक जोड़ें। अग्रिम में धन्यवाद!

@ deads2k कृपया एक दस्तावेज़ पीआर खोलें और ट्रैकिंग स्प्रेडशीट में एक लिंक जोड़ें। अग्रिम में धन्यवाद!

@zacharysarah मुझे लगता है कि स्प्रेडशीट लिंक गलत हो गया है। सीआरडी सत्यापन के लिए डॉक्स यहां https://github.com/kubernetes/website/pull/6066

रिकॉर्ड के लिए, सीआरडी संस्करण समस्या यहां मौजूद है: https://github.com/kubernetes/features/issues/544।

जीए में जाने वाले सीआरडी के कार्यों की सूची: https://github.com/kubernetes/kubernetes/issues/58682

@ निखिता क्या इसका मतलब यह है कि संपूर्ण सीआरडी सुविधा जीए में जा रही है?

क्या इसका मतलब यह है कि संपूर्ण CRD सुविधा GA में जा रही है?

एपीआई जीए, यानी v1 में स्थानांतरित हो जाएगा, संभवतः कुछ बीटा/अल्फा उप-सुविधाओं के साथ। हालांकि यह समाप्त नहीं हुआ है कि यह कब होगा, यानी 1.10 संभव है या नहीं।

@sttts @nikhita क्या आप फीचर रोडमैप को अधिक सटीक रूप से परिभाषित कर सकते हैं?

क्या आप फीचर रोडमैप को अधिक सटीक रूप से परिभाषित कर सकते हैं?

1.10 के लिए:

• https://github.com/kubernetes/kubernetes/issues/58682 में सूचीबद्ध कस्टम संसाधनों और बग फिक्स (कम से कम जिन्हें पार नहीं किया गया) के लिए उप-संसाधन

अगली रिलीज़ के लिए डिलिवरेबल्स का कोई _exact_ सेट नहीं है, लेकिन योजना वर्ष के अंत तक जीए जाने की है (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc)।

एक बार https://github.com/kubernetes/kubernetes/issues/58682 में पार नहीं किए गए सभी मुद्दों को पूरा करने के बाद हम GA में जाएंगे।

जब सीआरडी एपीआई जीए जाता है, तो इसमें विशेषताएं हो सकती हैं (उदाहरण: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg/features/kube_features.go#L35) जो अल्फ़ा/बीटा में हो सकता है।

@sttts @nikhita @deads2k
1.11 में इसके लिए कोई योजना?

यदि हां, तो क्या आप कृपया सुनिश्चित कर सकते हैं कि यह सुविधा उपयुक्त के साथ अप-टू-डेट है:

• विवरण
• माइलस्टोन
• समनुदेशिती
• लेबल:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

1.11 में इसके लिए कोई योजना?

मेरे पास पीआर बॉडी को संपादित करने की अनुमति नहीं है (यदि कोई ऐसा कर सकता है, तो यह बहुत अच्छा होगा!) लेकिन योजना है:

• सीआरडी संस्करण लागू करें। इसकी एक और विशेषता समस्या है: https://github.com/kubernetes/features/issues/544। डिजाइन प्रस्ताव: https://github.com/kubernetes/community/pull/2026।
• कस्टम संसाधनों के लिए छंटाई और डिफ़ॉल्ट जोड़ें।
• सीआरडी सत्यापन स्कीमा में समर्थन मानचित्र। https://github.com/kubernetes/kubernetes/issues/59485
• कस्टम संसाधनों के लिए कोटा समर्थन लागू करें (इसे बग फिक्स भी माना जा सकता है) https://github.com/kubernetes/kubernetes/issues/53777

यदि हां, तो क्या आप कृपया सुनिश्चित कर सकते हैं कि यह सुविधा उपयुक्त के साथ अप-टू-डेट है:
विवरण

"सत्यापन, डिफ़ॉल्ट, उप - संसाधन संस्करण जोड़ें" शामिल करने के लिए एक-पंक्ति विवरण को अद्यतन किया जाना चाहिए।

विवरण में उल्लिखित डिजाइन प्रस्तावों में शामिल होना चाहिए:

• 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

क्या कोई कृपया इन्हें पीआर बॉडी में भी शामिल कर सकता है?

किया हुआ

@nikhita @sttts @mbohlool - केवल स्पष्ट करने के लिए, क्या हम 1.11 चक्र के लिए बीटा को लक्षित कर रहे हैं?

@nikhita @sttts @mbohlool - इस पर फिर से विचार कर रही हूं ...
क्या हम 1.11 के लिए बीटा को लक्षित कर रहे हैं? बस यह सुनिश्चित करना चाहते हैं कि आज फीचर फ्रीज हो गया है।

@justaugustus CRDs पहले से ही बीटा हैं। 1.11 के लिए जीए की योजना नहीं है।

सभी सूचीबद्ध सुविधाएं/एक्सटेंशन (छंटनी, डिफ़ॉल्ट, संस्करण) संभवतः अल्फा के रूप में शुरू होंगे।

@sttts हमम , उस स्थिति में, क्या हमारे पास उन सुविधाओं/एक्सटेंशन और उनके चरणों को स्वतंत्र रूप से ट्रैक करने के लिए अलग-अलग मुद्दे होने चाहिए?

रिकॉर्ड करने के लिए - @nikhita ने सुविधा के लिए एक समस्या बनाई है https://github.com/kubernetes/features/issues/571

@sttts @justaugustus

डिफ़ॉल्ट और प्रूनिंग उप-सुविधा समस्या: https://github.com/kubernetes/features/issues/575

1.12 ट्रैकिंग उद्देश्यों के लिए @justaugustus @idvoretskyi : इसमें अतिरिक्त और शायद बग फिक्स होंगे लेकिन यह 1.12 के लिए बीटा में रहेगा (इसलिए सुविधाओं के नजरिए से कोई बदलाव नहीं)।

एक नई उप-सुविधा है जिसे अल्फा के रूप में नियोजित किया गया है, लेकिन इसे एक अलग मुद्दे के रूप में बनाया गया है: https://github.com/kubernetes/features/issues/575।

नमस्ते
इस एन्हांसमेंट को पहले भी ट्रैक किया जा चुका है, इसलिए हम चेक इन करना चाहते हैं और देखना चाहते हैं कि कुबेरनेट्स 1.13 में स्नातक चरणों के लिए इसके लिए कोई योजना है या नहीं। इस रिलीज़ को अधिक 'स्थिर' होने का लक्ष्य रखा गया है और इसमें एक आक्रामक समयरेखा होगी। कृपया इस वृद्धि को केवल तभी शामिल करें जब उच्च स्तर का विश्वास हो कि यह निम्नलिखित समय सीमा को पूरा करेगा:

• दस्तावेज़ (ओपन प्लेसहोल्डर पीआर): 11/8
• कोड स्लश: 11/9
• कोड फ्रीज शुरू होता है: 11/15
• डॉक्स पूर्ण और समीक्षित: 11/27

कृपया भविष्य की ट्रैकिंग के लिए अपनी मूल पोस्ट पर मील के पत्थर को अपडेट करने के लिए कुछ समय दें और यदि इसे 1.13 एन्हांसमेंट ट्रैकिंग शीट में शामिल करने की आवश्यकता है तो @ kacole2 को पिंग करें

धन्यवाद!

इस एन्हांसमेंट को पहले भी ट्रैक किया जा चुका है, इसलिए हम चेक इन करना चाहते हैं और देखना चाहते हैं कि कुबेरनेट्स 1.13 में स्नातक चरणों के लिए इसके लिए कोई योजना है या नहीं।

नहीं, 1.13 में इसे पूरा करने की कोई योजना नहीं है। सीआरडी एपीआई बीटा में रहेगा।

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close साथ ऐसा करें।

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

@ deads2k हैलो - मैं 1.14 के लिए एन्हांसमेंट का नेतृत्व कर रहा हूं और मैं इस मुद्दे पर जांच कर रहा हूं कि 1.14 रिलीज के लिए क्या काम (यदि कोई हो) की योजना बनाई जा रही है। एन्हांसमेंट फ़्रीज़ 29 जनवरी है और मैं याद दिलाना चाहता हूँ कि सभी एन्हांसमेंट में KEP होना चाहिए

@claurence सीआरडी एपीआई 1.14 के लिए भी बीटा में रहेगा।

नमस्ते @nikhita @deads2k , मैं 1.15 के लिए एन्हांसमेंट लीड हूं। क्या यह सुविधा 1.15 में अल्फा/बीटा/स्थिर चरणों में स्नातक होने जा रही है? कृपया मुझे बताएं ताकि इसे ठीक से ट्रैक किया जा सके और स्प्रेडशीट में जोड़ा जा सके। 1.15 समावेशन के लिए एक केईपी को भी मिलाना होगा। धन्यवाद!

एक बार कोडिंग शुरू हो जाने पर, कृपया इस अंक में सभी प्रासंगिक k/k PRs को सूचीबद्ध करें ताकि उन्हें ठीक से ट्रैक किया जा सके।

यह बीटा स्टेज में रहेगा। 1.15 . में सत्यापन, रूपांतरण और ओपनएपीआई प्रकाशन पर काम हो रहा है

1.15 . के लिए प्रासंगिक केईपी के लिंक के साथ अद्यतन विवरण

अरे, @liggitt @ deads2k @jpbetz @sttts मैं v1.15 डॉक्स रिलीज़ शैडो हूं।

क्या इस एन्हांसमेंट (या v1.15 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या संशोधन) की आवश्यकता है?

बस एक दोस्ताना अनुस्मारक हम गुरुवार, 30 मई तक k/वेबसाइट (शाखा देव-1.15) के खिलाफ पीआर की तलाश कर रहे हैं। यह बहुत अच्छा होगा यदि यह पूर्ण दस्तावेज़ीकरण की शुरुआत है, लेकिन प्लेसहोल्डर पीआर भी स्वीकार्य है। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें! मैं

@deads2k @jpbetz @sttts @liggitt

बस एक दोस्ताना अनुस्मारक हम गुरुवार, 30 मई तक k/वेबसाइट (शाखा देव-1.15) के खिलाफ पीआर की तलाश कर रहे हैं। यह बहुत अच्छा होगा यदि यह पूर्ण दस्तावेज़ीकरण की शुरुआत है, लेकिन प्लेसहोल्डर पीआर भी स्वीकार्य है। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें! मैं

1.15 के लिए डॉक्स पीआर: https://github.com/kubernetes/website/pull/14583

@ deads2k क्या आप समस्या का विवरण अपडेट कर सकते हैं?

/मील का पत्थर v1.16
/चरण स्थिर

अरे, @liggitt @jpbetz @sttts मैं

क्या इस एन्हांसमेंट (या v1.16 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या संशोधन) की आवश्यकता है?

बस एक मित्रवत अनुस्मारक हम शुक्रवार, 23 अगस्त तक k/वेबसाइट (शाखा देव-1.16) के खिलाफ पीआर की तलाश कर रहे हैं। अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें!

@simonswine प्लेसहोल्डर पीआर https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts गुरुवार को कोड फ्रीज है। क्या कोई बकाया k/k PR है जो इसे स्थिर होने से रोकेगा? नियोजित 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 . में समीक्षा के लिए तैयार डॉक्स

v1.16.0 . में स्थिर के रूप में जारी

पोस्ट-जीए कार्य https://github.com/orgs/kubernetes/projects/28 . में ट्रैक किया गया

/बंद करे

@liggitt : इस मुद्दे को बंद करना।