@enisoc @dchen1107 @fejta @thockin @kow3ns @derekwaynecarr ने इस ट्रैकिंग मुद्दे को खोला ताकि हम चर्चा कर सकें।

/ असाइन करें

@derekwaynecarr मैंने अगले सप्ताह की सिग-नोड मीटिंग के लिए आवश्यक क्यूबलेट परिवर्तनों में से कुछ स्कोपिंग की है, मुझे विश्वास है कि परिवर्तन केवल kuberuntime पैकेज में आवश्यक हैं, विशेष रूप से kuberuntime_manager.go in और kuberuntime_container.go ।

kuberuntime_manager.go आप शटडाउन ट्रिगरिंग को लागू करने के लिए computePodActions को संशोधित कर सकते हैं (जब सभी गैर-साइडकार स्थायी रूप से बाहर निकल गए हों तो साइडकार को मार दें), और पहले साइडकार को शुरू करें।

kuberuntime_container.go आप साइडकार को अंतिम रूप से समाप्त करने और प्रीस्टॉप हुक भेजने के लिए killContainersWithSyncResult को संशोधित कर सकते हैं (प्रीस्टॉप हुक बिट थोड़ा बहस योग्य था, यह तय नहीं किया गया था कि यह किया जाना चाहिए या नहीं। @ थॉकिन के पास एक अच्छा मुद्दा था कि आप उस व्यवहार को प्रोत्साहित क्यों नहीं करना चाहते हैं, टिप्पणी देखें)।

अगर आप चाहते हैं कि मैं और जांच करूं तो मुझे बताएं।

@ kow3ns चर्चा मेरे लिए अधिक मायने

cc @ जोसेफ-इरविंग

प्रस्ताव में कहा गया है कि इनिट कंटेनर चलने के बाद ही साइडकार चलते हैं। लेकिन क्या होगा यदि उपयोग-मामले में इनिट कंटेनर चलाने से पहले/पहले साइडकार चलाने की आवश्यकता होती है। उदाहरण के लिए, यदि आप साइडकार के रूप में चल रहे प्रॉक्सी के माध्यम से पॉड के ट्रैफ़िक को रूट करना चाहते हैं (जैसा कि इस्तियो में है), तो आप शायद चाहते हैं कि प्रॉक्सी जगह पर रहे, जबकि इनिट कंटेनर चलने की स्थिति में इनिट कंटेनर स्वयं नेटवर्क कॉल करता है।

@luksa मुझे लगता है कि किसी बिंदु पर init चरण में चलने वाले

इस केईपी पर अपडेट करें:
मैंने इस बारे में sig-node से @derekwaynecarr और @ dchen1107 दोनों से बात की है और उन्होंने प्रस्ताव के बारे में कोई बड़ी चिंता व्यक्त नहीं की है। मैं कार्यान्वयन विवरण के आसपास कुछ प्रारंभिक नोट्स जोड़कर और चर्चा के दौरान सामने आए कुछ बिंदुओं को स्पष्ट करते हुए केईपी के लिए एक पीआर बढ़ाऊंगा।

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

@ जोसेफ-इरविंग वास्तव में, न तो बूलियन और न ही containerLifecycle: Sidecar उचित भविष्य की एक्स्टेंसिबिलिटी के लिए उपयुक्त हैं। इसके बजाय, containerLifecycle जैसे एक ऑब्जेक्ट होना चाहिए, deployment.spec.strategy के साथ, type: Sidecar । यह हमें फिर अतिरिक्त क्षेत्रों को पेश करने की अनुमति देगा। "पॉड के पूरे जीवनकाल के लिए साइडकार" समाधान के लिए, इसे इन पंक्तियों के साथ व्यक्त किया जाएगा:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

विरोध के रूप में

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

कृपया मेरे बुरे नामकरण को क्षमा करें - मुझे आशा है कि नाम विचार व्यक्त करते हैं।

लेकिन उस दृष्टिकोण के साथ एक समस्या है जहां हम containerLifecycle से pod.spec.containers । अर्थात्, साइडकार्स का होना गलत है जो pod.spec.containers अंतर्गत निर्दिष्ट init कंटेनरों के समानांतर चलते हैं। इसलिए यदि आप वास्तव में इसे इनिट कंटेनरों तक विस्तारित करने में सक्षम होना चाहते हैं, तो आपको एक वैकल्पिक समाधान खोजना चाहिए - एक जो आपको उच्च स्तर पर कंटेनरों को साइडकार के रूप में चिह्नित करने की अनुमति देगा - अर्थात pod.spec.containers या pod.spec.initContainers , लेकिन pod.spec.sidecarContainers जैसा कुछ, जो मुझे लगता है कि आप पहले ही चर्चा कर चुके हैं, लेकिन खारिज कर दिया। इनिट कंटेनर समस्या निश्चित रूप से इन पंक्तियों के साथ समाधान की मांग करती है।

@luksa आप केवल एक init कंटेनर को साइडकार के रूप में चिह्नित करने की अनुमति देकर init समस्या को हल कर सकते हैं और इसे init कंटेनरों के साथ चला सकते हैं। जैसा कि मैं इसे समझता हूं, समस्या यह है कि इनिट कंटेनरों को कभी-कभी साइडकार्स की आवश्यकता होती है, जो एक कंटेनर की आवश्यकता से अलग होता है जो पॉड के पूरे जीवनकाल के लिए चलता है।

pod.spec.sidecarContainers साथ समस्या यह है कि यह कहीं अधिक जटिल परिवर्तन है, टूलिंग को अद्यतन करने की आवश्यकता होगी और क्यूबलेट को कंटेनरों के दूसरे सेट का समर्थन करने के लिए बहुत सारे संशोधन की आवश्यकता होगी। वर्तमान प्रस्ताव कहीं अधिक विनम्र है, यह केवल वही है जो पहले से मौजूद है।

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

मैं चाहूंगा कि आप प्रस्ताव को अंतिम रूप देते समय init-sidecars को ध्यान में रखें। संक्षेप में, आप "साइडकार" की अवधारणा को k8s में पेश कर रहे हैं (पहले, हमारे पास मूल रूप से केवल कंटेनरों का एक सेट था जो सभी समान थे)। अब आप वास्तविक साइडकार पेश कर रहे हैं, इसलिए आईएमएचओ, आपको वास्तव में इसे अच्छी तरह से सोचना चाहिए और एक बहुत ही महत्वपूर्ण साइडकार उपयोग-मामले को खारिज नहीं करना चाहिए।

मुझे इसे लागू करने में मदद करने में खुशी होगी। इसके बिना, इस्तियो इनिट कंटेनरों को अपनी सुविधाएँ प्रदान नहीं कर सकता (वास्तव में, इस्तियो चलाने वाले एक ठीक से सुरक्षित कुबेरनेट्स क्लस्टर में, इनिट कंटेनर पूरी तरह से _any_ सेवा से बात करने की क्षमता खो देते हैं)।

https://github.com/kubernetes/enhancements/pull/841 में कार्यान्वयन चर्चा के संबंध में, मैंने इस प्रस्ताव के लिए एक बुनियादी PoC युक्त WIP PR खोला है https://github.com/kubernetes/kubernetes/pull /75099. यह सिर्फ एक पहला मसौदा है और स्पष्ट रूप से सही नहीं है लेकिन बुनियादी कार्यक्षमता काम करती है और आपको आवश्यक परिवर्तन की मात्रा का अंदाजा देती है।

सीसी @ एनिसोक

मैंने एक छोटा वीडियो एक साथ रखा है जिसमें दिखाया गया है कि वर्तमान में PoC कैसे व्यवहार करता है https://youtu.be/4hC8t6_8bTs। इसे क्रिया में देखना इसके बारे में पढ़ने से बेहतर हो सकता है।
अस्वीकरण: मैं एक समर्थक youtuber नहीं हूँ।

मैंने दो नए पीआर खोले हैं:

• https://github.com/kubernetes/enhancements/pull/918 ग्रेजुएशन क्राइटेरिया, वर्जन स्क्यू, अपग्रेड/डाउनग्रेड के बारे में है
• https://github.com/kubernetes/enhancements/pull/919 एपीआई कार्यान्वयन पर निर्णय लेना है

किसी भी विचार या सुझाव की बहुत सराहना की जाएगी।

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

एक ठोस उदाहरण एक Django ऐप कंटेनर के साथ एक पॉड हो सकता है, सेवा पंजीकरण के लिए एक कॉन्सल साइडकार और डेटाबेस से कनेक्शन प्रबंधित करने के लिए एक pgbouncer साइडकार हो सकता है। जब पॉड समाप्त हो जाता है, तो मैं चाहता हूं कि कॉन्सल साइडकार को पहले रोका जाए (इसलिए पॉड पर कोई और ट्रैफ़िक नहीं भेजा जाता है), फिर ऐप कंटेनर (आदर्श रूप से एक छोटी छूट अवधि के बाद), और फिर pgbouncer साइडकार। वर्तमान प्रस्ताव ऐप <-> pgbouncer कंटेनर निर्भरता को संभालने के लिए बहुत अच्छा लग रहा है, लेकिन उस मामले को पकड़ने के लिए पर्याप्त अभिव्यक्तिपूर्ण प्रतीत नहीं होता है जहां मैं प्राथमिक कंटेनर _before_ एक साइडकार को फाड़ना चाहता हूं।

@currankaushik , आपके द्वारा वर्णित परिदृश्य में आप संभावित रूप से प्री-स्टॉप हुक का उपयोग कर सकते हैं ताकि कॉन्सल कंटेनर को शटडाउन के लिए तैयार किया जा सके और आपको रूटिंग अनुरोधों को रोक दिया जा सके (मान लीजिए कि यह ऐसा कुछ समर्थन कर सकता है)। कंटेनरों की समाप्ति शुरू होने से पहले पूर्व स्टॉप हुक साइडकार्स को भेजे जाएंगे।

इसके लिए प्रेरणा यह थी कि istio जैसे प्रॉक्सी साइडकार एक ऐसी स्थिति में प्रवेश कर सकते हैं, जहां वे आपके लिए ट्रैफ़िक को रूट नहीं कर रहे हैं, लेकिन आपके एप्लिकेशन के समाप्त होने और बंद होने तक ट्रैफ़िक को बाहर जाने दे रहे हैं।

अच्छा लगता है, धन्यवाद @ जोसेफ-इरविंग। तो बस उच्च स्तर पर मेरी समझ की पुष्टि करने के लिए: प्री-स्टॉप हुक पहले साइडकार्स को भेजे जाएंगे, उसके बाद गैर-साइडकार्स को प्री-स्टॉप हुक, गैर-साइडकार्स को SIGTERM, और फिर (सभी गैर-साइडकार्स के बाहर निकलने के बाद) ) साइडकार्स के लिए SIGTERM? डिजाइन प्रस्ताव (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) इसका मतलब लगता है, लेकिन यह भी कहता है:

प्रीस्टॉप हुक एक ही समय में साइडकार्स और कंटेनरों में भेजे जाएंगे।

@currankaushik हाँ आपने जो वर्णन किया है वह इच्छित व्यवहार है।

आपके द्वारा उद्धृत की गई पंक्ति को फिर से लिखने की आवश्यकता है। मुझे इस बारे में कुछ गलतफहमियां थीं कि जब मैंने इसे लिखा था तो कंटेनरों को प्रेस्टॉप हुक कैसे भेजे गए थे। इस पर ध्यान दिलाने के लिए धन्यवाद।

@ जोसेफ-इरविंग क्या यह सुविधा 1.15 के लिए अल्फा समावेशन को लक्षित कर रही है?

@ kacole2 हाँ यह योजना है, यह मानते हुए कि हम https://github.com/kubernetes/enhancements/pull/919 और परीक्षण योजना सहमत हो गई https://github.com/kubernetes/enhancements/pull/951 मुझे लगता है कि हमें पूरी तरह से तैयार होना चाहिए।

/मील का पत्थर v1.15
/स्टेज अल्फा

@ जोसेफ-इरविंग कुबेरनेट्स 1.15 एन्हांसमेंट फ़्रीज़ 4/30/2019 है। Kubernetes 1.15 मील के पत्थर में शामिल होने के लिए, KEPs को उचित परीक्षण योजनाओं और स्नातक मानदंड के साथ "कार्यान्वयन योग्य" स्थिति में होना आवश्यक है। कृपया इस केईपी को समावेशन मानदंड का पालन करने के लिए आवश्यक कोई भी पीआर सबमिट करें। यदि यह 1.15 मील के पत्थर से फिसल जाता है, तो कृपया हमें बताएं ताकि हम उचित ट्रैकिंग परिवर्तन कर सकें।

@mrbobbytables दुर्भाग्य से इसे लागू करने योग्य राज्य में लाने के लिए खोले गए

कोई चिंता नहीं। इतनी जल्दी प्रतिक्रिया देने और हमें बताने के लिए धन्यवाद!
/ मील का पत्थर स्पष्ट

कृपया ध्यान रखें, यह केईपी इस्तियो के लिए बहुत महत्वपूर्ण है!

यह समन्वित बूटस्ट्रैप/शटडाउन (अक्का क्लस्टर, लैगोम इत्यादि) के साथ सर्विस फ्रेमवर्क का उपयोग करके सभी परियोजनाओं के लिए एक शो स्टॉपर है, साथ में istio सर्विस मेष देखें ।

cc @jroper

@ जोसेफ-इरविंग देर से टिप्पणी के बारे में चिल्लाते हैं, लेकिन मुझे डिज़ाइन दस्तावेज़ में निम्नलिखित नहीं दिख रहा है, और मैं सोच रहा था कि इनका इच्छित व्यवहार क्या है:

यदि हम साइडकार की विफलता देखते हैं, तो क्या हम हमेशा उन्हें पुनः आरंभ करते हैं यदि मुख्य कंटेनर समाप्त नहीं होता है (पॉड में पुनरारंभ नीति की अवहेलना)? यह उपयोगी होगा क्योंकि साइडकार प्रॉक्सी, लोड बैलेंसिंग, हाउस कीपिंग रोल के रूप में काम करता था, और इससे कोई फर्क नहीं पड़ता कि यह दो बार विफल हो जाता है जब तक कि मुख्य कंटेनर काम करना जारी रख सके

इसके अलावा, पॉड चरण की गणना करते समय, यदि सभी मुख्य कंटेनर सफल हो गए, और साइडकार विफल हो गया (जो बहुत सामान्य है जैसे कि साइडकार SIGTERM को नहीं पकड़ता है तो रिटर्न कोड 143 या कुछ और जैसा होगा), क्या पॉड चरण अभी भी "सफल" है?

@ zhan849 वर्तमान में साइडकार कंटेनर पॉड पुनरारंभ नीति का पालन करते हैं और पॉड चरण की गणना करते समय गिना जाता है जैसे कि Succeeded ।

हमने इस प्रक्रिया में काफी पहले इस पर बहस की थी लेकिन सामान्य भावना यह थी कि हमें जितना संभव हो सके सामान्य कंटेनर से अलग होना चाहिए, केवल तभी ऐसा करना चाहिए जब यह वर्णित उपयोग के मामलों को सक्षम बनाता है।

पॉड चरण के संबंध में: मैं तर्क दूंगा कि कुबेरनेट्स में चलने वाले सभी एप्लिकेशन SIGTERM (विशेष रूप से साइडकार) को संभालना चाहिए, लेकिन कभी-कभी आप यह भी जानना चाहेंगे कि क्या आपके साइडकार खराब तरीके से बाहर निकले हैं और यह पॉड चरण में परिलक्षित होना चाहिए, उस जानकारी को छिपाने से भ्रम की स्थिति पैदा हो सकती है।

पुनरारंभ नीति के लिए, ऐसा लगता है कि यह एक मुद्दा होगा यदि पुनरारंभ नीति कभी नहीं होती है और आपकी साइडकार दुर्घटनाग्रस्त हो जाती है। मुझे यकीन नहीं है कि अगर उन्हें पॉड रीस्टार्ट पॉलिसी से अलग करने की जटिलता इसके लायक है, खासकर जब कुछ लोग चाहते हैं कि उनके साइडकार पॉड रीस्टार्ट पॉलिसी का पालन करें।

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

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

@ जोसेफ-इरविंग हमारे पास कुछ सरल साइड कार इम्प्लांट हैं जो कुछ तात्कालिक जरूरतों के लिए आंतरिक रूप से चल रहे हैं (हमने योगदान नहीं दिया क्योंकि यह समुदाय में पहले से ही प्रगति पर है), और यहां हमने जो सीखा है।

पॉड चरण के बारे में:

1. कंटेनर मौजूद स्थिति पहले से ही pod.status.containerStatuses में दिखाई दे रही है, इसलिए हम जानकारी नहीं खोते हैं। इसके अलावा, चूंकि साइडकार का एक बड़ा उपयोग केस जॉब में है (या कभी भी रन-टू-फिनिश पॉड्स जैसे कि क्यूबफ्लो में), सार्थक वर्कलोड केवल मुख्य कंटेनर पर लागू किया जाएगा और यदि पॉड चरण को साइडकार विफलता के कारण विफल के रूप में चिह्नित किया गया है , इसके परिणामस्वरूप अनावश्यक पुन: प्रयास होंगे और अन्य भ्रामक परिणाम होंगे जैसे कि कार्य विफल होना, आदि।

2. हालांकि यह साइडकार के लिए SIGTERMs को संभालने के लिए आदर्श है, उत्पादन में, बहुत सारे साइडकार हो सकते हैं जो केवल ओपनसोर्स सॉफ़्टवेयर पर बनाए गए हैं और वे SIGTERM को अच्छी तरह से नहीं संभाल रहे हैं, जिनमें kube-proxy , postfix , rsyslogd , और कई अन्य (और यहां तक ​​​​कि अगर SIGTERM को संभाला जाता है, गैर-पकड़ने योग्य SIGKILL के लिए, यह निश्चित रूप से 0 नहीं होगा)

पुनरारंभ नीति के संबंध में (यह बहस योग्य हो सकता है लेकिन साइडकार सख्ती से पुनरारंभ करें नीति उत्पादन में यथार्थवादी नहीं है):

1. जब मुख्य कंटेनर अभी भी "ऑनफेलर" सेट करके चल रहे हों, तो साइडकार को पुनरारंभ करने के लिए मजबूर करना एक विकल्प नहीं है क्योंकि यह विफल मुख्य कंटेनरों को पुनरारंभ करेगा और नौकरी स्तर की पुनर्प्रयास सीमा के साथ भ्रमित कर रहा है।

2. आमतौर पर साइडकार्स को संभालते समय, मुख्य कंटेनरों में साइडकार अनुपलब्ध के लिए बहुत सारे रिट्री लॉजिक्स होते हैं, और ये समुदाय के पास स्पष्ट कंटेनर स्टार्ट ऑर्डर के साथ साइड कार सपोर्ट से पहले किए जाते हैं। इस तरह के ऐतिहासिक त्रुटि प्रबंधन को इसके दायरे को देखते हुए बदलना बहुत आसान नहीं है। साइडकार को पुनरारंभ नहीं करने से मुख्य कंटेनर लटक जाएंगे और पुनः प्रयास करेंगे

3. ऊपरी स्तर के नियंत्रकों को विफलताओं का प्रचार करने से सुलह की श्रृंखला शुरू हो जाएगी और बहुत सी एपीआई कॉल्स ताकि त्रुटियों की अनावश्यक वृद्धि कुबेरनेट्स को कम स्केलेबल बना सके।
   एक अधिक विशिष्ट उदाहरण: यदि किसी कार्य के मुख्य कंटेनर अभी भी चल रहे हैं और साइडकार विफल हो जाता है, तो साइडकार को पुनरारंभ करने से केवल 1 PATCH पॉड स्थिति संचालन होगा और अधिकतम 1 ईवेंट संबंधित API कॉल होगा। लेकिन अगर पॉड को पूरी तरह से विफल करने से जॉब का समाधान हो जाएगा, और अधिक हायर लेवल कंट्रोलर जैसे कि क्रोनजॉब और अन्य सीआरडी और कई बार एपीआई कॉल हो सकते हैं।

यह भी देखना चाहते हैं कि क्या अन्य लोगों ने भी इसी तरह के मुद्दों को देखा है (/cc @ kow3ns )

क्या यह परिवर्तन https://github.com/kubernetes/community/pull/2342 में वांछित व्यवहार को शामिल करेगा, जैसे कि यदि कोई साइडकार विफल?

@JacobHenner वर्तमान में इस

@ जोसेफ-इरविंग सिर्फ हमारे निहितार्थ को साझा करने के लिए जो आपके संदर्भ के लिए उपर्युक्त नुकसान को संबोधित करते हैं (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar) चूंकि हमारा लक्ष्य आधिकारिक समर्थन की प्रतीक्षा करना है, हम कोशिश करते हैं इस कमिटमेंट में बदलाव को यथासंभव स्थानीय रखने के लिए।

तो एक नौकरी पुनरारंभ नीति के लिए == कभी नहीं, 1 मुख्य कंटेनर के साथ, 1 खराब साइडकार जो लगातार दुर्घटनाग्रस्त हो जाता है, 1 अच्छा साइडकार जो चलता रहता है, पॉड स्थिति इस तरह दिखेगी जब मुख्य कंटेनर उपरोक्त इम्प्लांट से बाहर निकलता है।

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

मैं आम तौर पर सहमत हूं कि एक साइडकार केईपी को कार्यान्वयन योग्य स्थिति में जाने से पहले पॉड चरण को ध्यान में रखना चाहिए और नीति को पुनरारंभ करना होगा। मुझे परवाह नहीं है कि यह केईपी है या नहीं, लेकिन मैं सामान्य रूप से @ zhan849 के तर्कों से सहमत हूं और इसे यहां निपटाया जाना चाहिए।

धन्यवाद @smarterclayton !
@ जोसेफ-इरविंग हमें बताएं कि क्या कुछ और है जो आप चाहते हैं कि हम अभ्यास में साइडकार के साथ साझा करें।

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

मैं इस फीडबैक को वापस सिग-ऐप्स/सिग-नोड पर ले जाऊंगा और देखूंगा कि वे क्या सोचते हैं। सिग-नोड विशेष रूप से साइडकार्स को यथासंभव सामान्य कंटेनरों के करीब रखने के लिए उत्सुक थे, अगर @ dchen1107 इसमें झंकार करना चाहते हैं तो इसकी सराहना की जाएगी।

परीक्षण योजना https://github.com/kubernetes/enhancements/pull/951 और API डिज़ाइन https://github.com/kubernetes/enhancements/pull/919 PR को अब मिला दिया गया है।

मैंने केईपी को लागू करने योग्य के रूप में चिह्नित करने के लिए https://github.com/kubernetes/enhancements/pull/1109 खोला है, एक बार जब हर कोई इससे खुश हो जाता है तो हमें 1.16 में अल्फा के रूप में इसके लिए विकास शुरू करने में सक्षम होना चाहिए।

इस केप को लागू करने योग्य के रूप में चिह्नित किया गया है, इसलिए मैं इसे अगले सप्ताह से 1.16 में लाने के लिए पीआर बढ़ाऊंगा!

मैंने एपीआई को लागू करने के लिए https://github.com/kubernetes/kubernetes/pull/79649 उठाया है, मेरे पास क्यूबलेट परिवर्तनों के लिए एक अलग पीआर होगा।

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

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

माइलस्टोन तिथियां एन्हांसमेंट फ़्रीज़ 7/30 और कोड फ़्रीज़ 8/29 हैं।

धन्यवाद।

@ जोसेफ-इरविंग यदि आप इसे लागू करने के लिए कुछ अतिरिक्त लोगों को चाहते हैं/चाहते हैं, तो मुझे इस लैंडिंग में बहुत दिलचस्पी है, इसलिए मुझे हाथ उधार देने में खुशी हो रही है।

हाय @ kacole2 यह 1.16 के लिए अल्फा को लक्षित कर रहा है,
इसके लिए एकमात्र पीआर वर्तमान में एपीआई के लिए कुबेरनेट्स/कुबेरनेट्स#79649 है

@mhuxtable मैं जल्द ही क्यूबलेट परिवर्तनों के लिए पीआर बढ़ाऊंगा, बस कुछ चीजों को खत्म कर दूंगा, मैं उस पर एक नज़र डालने में कुछ मदद की सराहना करता हूं। जब इसे उठाया जाएगा तो मैं इसे यहां लिंक करूंगा।

मैंने https://github.com/kubernetes/kubernetes/pull/80744 खोला है जो क्यूबलेट परिवर्तनों को लागू करता है।

कृपया ध्यान दें कि कुबेरनेट्स/कुबेरनेट्स#79649 (एपीआई) अभी भी खुला है, इसलिए इस पीआर में इसके कमिट हैं, जिससे यह बड़ा लगता है। मैंने इसे कमिट में तोड़ दिया है कि प्रत्येक एक अलग कार्यक्षमता को लागू करता है, इसलिए इसे इस तरह से समीक्षा करना आसान होना चाहिए।

मैंने इसके लिए सभी परीक्षण मामलों को पूरा नहीं किया है, लेकिन कार्य कार्यान्वयन का पहला मसौदा तैयार किया गया है, इसलिए मैं चाहता हूं कि लोग एक नज़र डालें।

सीसी @ kacole2

@ जोसेफ-इरविंग

मैं v1.16 डॉक्स शैडो में से एक हूं।
क्या इस एन्हांसमेंट (या v1.16 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या मौजूदा दस्तावेज़ों में संशोधन) की आवश्यकता है? यदि नहीं, तो क्या आप कृपया 1.16 एन्हांसमेंट ट्रैकर शीट को अपडेट कर सकते हैं (या मुझे बताएं और मैं ऐसा करूंगा)

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

हाय @daminisatya , हाँ इसके लिए डॉक्स के अपडेट की आवश्यकता होगी, मैंने प्लेसहोल्डर पीआर के रूप में https://github.com/kubernetes/website/pull/15693 उठाया है।
मुझे यह जानने में दिलचस्पी होगी कि क्या डॉक्स को कहां जाना चाहिए, इस पर किसी की कोई राय है, मैंने अभी के लिए content/en/docs/concepts/workloads/pods/pod-lifecycle.md में कुछ डाल दिया है।

कोड फ़्रीज़ से पहले एक सप्ताह से भी कम समय के साथ, यह बहुत कम संभावना है कि यह इसे 1.16 में बनाने में सक्षम होगा।
हमारे पास अभी भी दो अपेक्षाकृत बड़े खुले PRs Kubernetes/kubernetes#80744 और Kubernetes/kubernetes#79649 हैं जिन्हें कोई भी समीक्षा प्राप्त करने के लिए संघर्ष करना पड़ा है।
उम्मीद है कि इन्हें देखने के लिए अगले रिलीज चक्र में और अधिक समीक्षक बैंडविड्थ होंगे।

/ असाइन करें

क्या यह एक साइडकार लिखने की अनुमति दे सकता है जो मांग पर वास्तविक सेवा शुरू कर सकता है (और इसे नष्ट कर सकता है)?

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

@Ciantic ऑपरेटर फ्रेमवर्क के साथ आप वह और भी बहुत कुछ कर सकते हैं। जरा देखो तो

@janosroden मैंने देखा, लेकिन यह समझना बहुत मुश्किल लगता है कि मैं चल रही सेवाओं को शून्य स्केलेबल तक कैसे

समस्या यह नहीं है कि ओसिरिस , केडा या नेटिव जैसे विकल्प उपलब्ध नहीं हैं। मैंने पिछले एक की कोशिश की, लेकिन यह 8Gb मेमोरी को हॉग करता है, यह कहना मुश्किल है कि यह उस समय 'सर्वर रहित' है।

समस्या यह है कि उनमें से अधिकतर कार्यान्वयनों को एक नए संसाधनों आदि की आवश्यकता होती है। यह सोचना बहुत आसान है ताकि कोई एक साइडकार इंजेक्ट कर सके जो पूरे जीवन चक्र को नियंत्रित कर सके (मांग पर शुरू करने और पुनरारंभ करने सहित) ताकि यह सेवा को केवल से परे नियंत्रित कर सके वहाँ बैठे।

यह क्यों फायदेमंद होगा? यह कम उपयोग और कम स्मृति स्थितियों में वास्तव में उपयोगी है, उदाहरण के लिए रास्पबेरी पाई के साथ k3s, या शौक परियोजनाओं के लिए डिजिटल महासागर छोटी बूंद। हम में से कई लोगों के पास बहुत सारी वेब सेवाएं हैं जिन्हें हर समय चलने की आवश्यकता नहीं है, केवल एक साइडकार होना जो उन्हें मांग पर जगा सकता है, पर्याप्त होगा।

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

इसके आसपास काम करने के लिए, आपको प्रारंभिक कनेक्शन प्राप्त करने और k8s के लिए एक नया पॉड अनुरोध करने के लिए स्वयं के एक पॉड की आवश्यकता होती है, इसे स्पिन करने के लिए प्रतीक्षा करें, फिर इसे ट्रैफ़िक भेजें। मुझे लगता है कि इस मामले में साइडकार कंटेनर एन्हांसमेंट की आवश्यकता नहीं है। मुझे लगता है कि आपको k8s के लिए xinetd जैसा कुछ और चाहिए।

अरे वहाँ @ जोसेफ-इरविंग - 1.17 संवर्द्धन यहाँ नेतृत्व करते हैं। मैं चेक इन करना चाहता था और देखना चाहता था कि क्या आपको लगता है कि यह एन्हांसमेंट 1.17 में अल्फा में स्नातक होगा?

वर्तमान रिलीज शेड्यूल है:

• सोमवार, सितंबर 23 - रिलीज़ चक्र शुरू होता है
• मंगलवार, अक्टूबर 15, ईओडी पीएसटी - एन्हांसमेंट फ़्रीज़
• गुरुवार, नवंबर 14, ईओडी पीएसटी - कोड फ़्रीज़
• मंगलवार, 19 नवंबर - डॉक्स को पूरा किया जाना चाहिए और उनकी समीक्षा की जानी चाहिए
• सोमवार, 9 दिसंबर - कुबेरनेट्स 1.17.0 जारी किया गया

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

धन्यवाद!

हाय @mrbobbytables , यह मानते हुए कि हम 1.17 में अल्फा में स्नातक होने की योजना के समय में सब कुछ समीक्षा कर सकते हैं।

वर्तमान खुले पीआर हैं:
https://github.com/kubernetes/kubernetes/pull/79649 - API परिवर्तन
https://github.com/kubernetes/kubernetes/pull/80744 - क्यूबलेट परिवर्तन

आपको किसी और चीज़ की ज़रुरत हो तो मुझे बताएं!

महान! धन्यवाद @ जोसेफ-इरविंग मैं जानकारी को ट्रैकिंग शीट में जोड़ दूंगा

@ जोसेफ-इरविंग

मैं v1.17 डॉक्स शैडो में से एक हूं।
क्या इस एन्हांसमेंट (या v1.17 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या मौजूदा दस्तावेज़ों में संशोधन) की आवश्यकता है? यदि नहीं, तो क्या आप कृपया 1.17 एन्हांसमेंट ट्रैकर शीट को अपडेट कर सकते हैं (या मुझे बताएं और मैं ऐसा करूंगा)

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

धन्यवाद!

हाय @ VineethReddy02 हाँ इसके लिए दस्तावेज़ीकरण की आवश्यकता होगी, प्लेसहोल्डर पीआर यहाँ है https://github.com/kubernetes/website/pull/17190

मैंने केईपी https://github.com/kubernetes/enhancements/pull/1344 को अद्यतन करने के लिए एक पीआर उठाया है यह कुछ चर्चा पर आधारित है जो हम कार्यान्वयन पीआर में कर रहे थे https://github.com/kubernetes/kubernetes/pull /80744.

मैं किसी भी टिप्पणी की सराहना करता हूँ

अरे @ जोसेफ-इरविंग 1.17 एन्हांसमेंट शैडो यहाँ! मैं यह देखने के लिए आपसे संपर्क कर रहा हूं कि यह वृद्धि कैसी चल रही है।

एन्हांसमेंट टीम वर्तमान में ट्रैकिंग शीट में Kubernetes/kubernetes#79649 और Kubernetes/kubernetes#80744 को ट्रैक कर रही है। क्या कोई अन्य k/k PR हैं जिन्हें भी ट्रैक करने की आवश्यकता है?

साथ ही, एक और मित्रवत अनुस्मारक कि हम जल्दी से कोड फ़्रीज़ (14 नवंबर) के करीब पहुंच रहे हैं।

हाय @annajung , हाँ, वे ही एकमात्र

हाय @ जोसेफ-इरविंग, कल 1.17 रिलीज चक्र के लिए कोड फ्रीज है । ऐसा लगता है कि k/k PR को मर्ज नहीं किया गया है। हम 1.17 ट्रैकिंग शीट में इस एन्हांसमेंट को At Risk रूप में चिह्नित कर रहे हैं।

क्या आपको लगता है कि 14 (गुरुवार) की ईओडी द्वारा सभी आवश्यक पीआर का विलय कर दिया जाएगा? उसके बाद, केवल रिलीज-ब्लॉकिंग मुद्दों और पीआर को अपवाद के साथ मील के पत्थर में अनुमति दी जाएगी।

हाय @annajung , दुर्भाग्य से यह बहुत कम संभावना है कि वे कोड-फ्रीज से पहले विलय होने जा रहे हैं। हमने इस रिलीज़ चक्र में बहुत प्रगति की है, इसलिए उम्मीद है कि हम उन्हें 1.18 में जल्दी मर्ज कर सकते हैं।

अरे @ जोसेफ-इरविंग अपडेट के लिए धन्यवाद। मैं तदनुसार माइलस्टोन को अपडेट करूंगा और इस एन्हांसमेंट को 1.18 के लिए आस्थगित के रूप में चिह्नित करूंगा। शुक्रिया!

/मील का पत्थर v1.18

अरे @ जोसेफ-इरविंग। 1.18 संवर्द्धन यहाँ लीड 👋 .

1.18 रिलीज़ कल शुरू हुई, इसलिए मैं यह देखने के लिए पहुँच रहा हूँ कि क्या आप 1.18 रिलीज़ में इसे उतारने की योजना बना रहे हैं? मुझे लगता है कि कोड फ्रीज के कारण यह 1.17 चूक गया। 1.18 में चीज़ें कैसी दिख रही हैं? मैं देख रहा हूं कि पीआर अभी भी खुले हैं।

धन्यवाद!

हाय @jeremyrickard ,

हाँ योजना इसे 1.18 रिलीज़ में प्राप्त करने की है।

एपीआई पीआर (https://github.com/kubernetes/kubernetes/pull/79649) को थॉकिन से एक समीक्षा मिली, दूसरे दिन, उसके पास कुछ बिंदु थे लेकिन एक बार उन पर ध्यान दिए जाने के बाद हम उस पीआर को बंद कर देंगे और इसमें शामिल होंगे (https://github.com/kubernetes/kubernetes/pull/80744) ताकि हम एपीआई और कार्यान्वयन को एक साथ मर्ज कर सकें।

क्यूबलेट पीआर के लिए (https://github.com/kubernetes/kubernetes/pull/80744) इसकी अभी समीक्षा करने की जरूरत है, मुझे उम्मीद है कि हम इस चक्र की समीक्षा करने के लिए कुछ सिग-नोड बैंडविड्थ प्राप्त कर सकते हैं।

अपडेट के लिए धन्यवाद @ जोसेफ-इरविंग

इसे ट्रैकिंग शीट में जोड़ा गया!

पार्टी में देर से आने के लिए खेद है। यह सामान्य मामलों के लिए एक महत्वपूर्ण सुधार है। लेकिन ऐसा लगता है कि एक अधिक उन्नत मामले को कवर नहीं किया गया है।

साइडकार के एक मामले पर विचार करें जो लॉग निर्यात करता है जो इस्तियो साइडकार पर भी निर्भर करता है। यदि इस्तियो साइडकार पहले बंद हो जाता है, तो कुछ संवेदनशील लॉग निर्यात नहीं हो सकते हैं।

कंटेनरों में स्पष्ट निर्भरता को परिभाषित करने के लिए एक अधिक सामान्य दृष्टिकोण होगा। भले ही वे साइडकार हों या नहीं।

इसके बजाय आप ऐसी एपीआई परिभाषा के बारे में क्या सोचते हैं:

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

@ रूबेनहक जो वास्तव में जल्दी गन्दा हो जाता है। आगे बढ़ने के लिए निर्भरता के स्पष्ट होने के लिए क्या संतुष्ट होना चाहिए? शुरू और तैयार के बीच अक्सर एक अंतर होता है जो मुझे लगता है कि निर्भर करता है कि वास्तव में उस एपीआई को संबोधित नहीं किया जाएगा।

@ kfox1111 प्रस्तावित डिज़ाइन कैसे निर्धारित करता है कि साइडकार शुरू हो गया है और मुख्य कंटेनर को लॉन्च करने के लिए तैयार है? मेरे द्वारा प्रस्तावित एकमात्र अंतर यह है कि कंटेनरों को "साइडकार" के रूप में चिह्नित करने के बजाय निर्भरता को परिभाषित करने के अधिक सामान्य तरीके का उपयोग करना है।

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

हैलो @ जोसेफ-इरविंग मैं v1.18 डॉक्स शैडो में से एक हूं।
क्या इस एन्हांसमेंट (या v1.18 के लिए नियोजित कार्य) के लिए किसी नए दस्तावेज़ (या मौजूदा दस्तावेज़ों में संशोधन) की आवश्यकता है? यदि नहीं, तो क्या आप कृपया 1.18 एन्हांसमेंट ट्रैकर शीट को अपडेट कर सकते हैं (या मुझे बताएं और मैं ऐसा करूंगा)

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

हाय @irvifa मैंने यहां एक प्लेसहोल्डर पीआर बनाया है https://github.com/kubernetes/website/pull/19046

हाय @ जोसेफ-इरविंग आपकी त्वरित प्रतिक्रिया के लिए धन्यवाद!

@ रूबेनहक - मैं @ kfox1111 से सहमत हूं कि निर्भरता का पूरा ग्राफ होने से बहुत जल्दी गड़बड़ हो सकती है। पॉड स्पेक में कंटेनरों को क्रम में शुरू करने और फिर उन्हें उल्टे क्रम में (एक स्टैक की तरह) फाड़ने के बारे में क्या? यह लागू करने के लिए बहुत आसान होगा, और अधिकांश सामान्य ऑर्डरिंग उपयोग-मामलों को शामिल करता है जिनके बारे में मैं सोच सकता हूं।

@rgulewich , क्या आप थोड़ा और विस्तार कर सकते हैं, वास्तव में क्या गड़बड़ हो सकती है? ग्राफ से आदेश प्राप्त करना एक तुच्छ कार्य है, विशेष रूप से इस तथ्य पर विचार करते हुए कि कोई भी समझदार ऑपरेटर 15 से अधिक साइडकार (पहले से ही एक खिंचाव) नहीं चलाएगा।

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

@ रूबेनहक कंटेनरों के निर्भरता क्रम में एक चक्र हो सकता है, k8s/kubelet चक्र को तोड़ने का निर्णय कैसे लेता है और यह तय करता है कि कंटेनरों को शुरू/बंद करने का क्या आदेश है? ज़ोर से सोचना शायद यह एक एपीआई पक्ष सत्यापन हो सकता है।

अरे @ जोसेफ-इरविंग,

केवल एक मित्रवत अनुस्मारक है कि 1.18 के लिए कोड फ़्रीज़ 05 मार्च, 2020 है ।

जैसे ही हम कोड फ्रीज की ओर ट्रैक करते हैं, कृपया इस एन्हांसमेंट को स्नातक करने की दिशा में काम कर रहे किसी भी पीआर को सूचीबद्ध/लिंक करें!

अरे @jeremyrickard ,

ट्रैक करने के लिए जनसंपर्क है https://github.com/kubernetes/kubernetes/pull/80744
इस पीआर में एपीआई परिवर्तन शामिल हैं, लेकिन समीक्षा समाप्त होने के बाद उपरोक्त पीआर में विलय हो जाएगा https://github.com/kubernetes/kubernetes/pull/79649

@ रूबेनहक कंटेनरों के निर्भरता क्रम में एक चक्र हो सकता है, k8s/kubelet चक्र को तोड़ने का निर्णय कैसे लेता है और यह तय करता है कि कंटेनरों को शुरू/बंद करने का क्या आदेश है? ज़ोर से सोचना शायद यह एक एपीआई पक्ष सत्यापन हो सकता है।

@bjhaid , एपीआई पक्ष सत्यापन कर सकता है। लूप डिटेक्शन एक रेखीय समय जटिलता के साथ एक तुच्छ एल्गोरिथम है (ठीक डीएफएस ट्रैवर्सल की तरह)।

साइडकार इंजेक्शन के बाद भी सत्यापन को फिर से चलाने की आवश्यकता हो सकती है।

मैं इस बारे में थोड़ी देर के लिए सोच रहा था ... निर्भरता वाले अधिकांश मुद्दे वास्तव में उबालते हैं मुझे लगता है कि सेवा जाल के लिए। (शायद कोई अन्य उदाहरण के बारे में सोच सकता है)

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

लेकिन initContainers आदर्श रूप से सेवा जाल का भी उपयोग करने में सक्षम होना चाहिए।

लेकिन initContainers को अन्य साइडकार कंटेनरों में प्रवेश करने की आवश्यकता हो सकती है।

जबकि हम init कंटेनर, साइडकार कंटेनर और नियमित कंटेनरों को शामिल करते हुए किसी प्रकार की जटिल निर्भरता प्रणाली को डिज़ाइन कर सकते हैं, हो सकता है कि हमारे पास केवल दो वर्ग के साइडकार हों? नियमित साइडकार्स, और नेटवर्क साइडकार्स?

नेटवर्क साइडकार्स सभी को शुरुआत में ही तैयार हो जाना चाहिए। सेवा जाल परदे के पीछे यहाँ जाओ।
init कंटेनर क्रम में आगे चलते हैं।
साइडकार सभी शुरू होते हैं और तैयार हो जाते हैं। इसमें ऑथ प्रॉक्सी, लॉगर इत्यादि जैसे सामान शामिल हो सकते हैं।
नियमित कंटेनर शुरू होते हैं और तैयार हो जाते हैं।

फाड़ना उल्टा है।

क्या यह निर्भरता के मुद्दे को खत्म कर देगा, जबकि अभी भी सभी मुद्दों को हल करते हुए सेवा मेश कंटेनर ऑर्डरिंग के साथ प्रतीत होता है? मैं ऐसा सोच रहा हूँ?

@ kfox1111 , वॉल्ट अब लगाता है । यह किस वर्ग में फिट होना चाहिए? इसके अलावा, मामले के आधार पर, तिजोरी सेवा जाल, या दूसरी तरफ निर्भर हो सकती है।

मैं बस इतना कह रहा हूं कि इस तरह की डिजाइन अंततः 10 साइडकार वर्गों में फैल जाएगी। इस तरह के दृष्टिकोण का अर्थ है कि चीजों को कैसे चलाना चाहिए, इस पर और भी मजबूत राय। लोग कक्षाओं के साथ हैकिंग शुरू कर देंगे, बस आदेश को प्राप्त करने के लिए एप्लिकेशन लॉन्च करने की आवश्यकता होगी।

यदि उन वर्गों का एकमात्र उद्देश्य आदेश को परिभाषित करना है, तो स्पष्ट रूप से ऐसा क्यों नहीं किया जाता है?

आपके प्रश्न का उत्तर देते हुए, जबकि इस तरह के डिज़ाइन में कुछ उपयोग के मामले शामिल होंगे, यह अन्य मामलों जैसे वॉल्ट साइडकार्स, लॉगिंग साइडकार्स आदि में मदद नहीं करता है। यह पहले से ही मूल सुविधा के रीडिज़ाइन के लिए एक प्रस्ताव है। चूंकि यह दूसरा प्रयास है, इसलिए इस बार इसे ठीक करना उचित है।

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

यदि हम किसी फ़ील्ड को कंटेनर में पेश करते हैं तो क्या होगा?

    // +optional
    Priority int

यह फ़ील्ड एक ही प्रकार के कंटेनरों (साइडकार, सामान्य) के बीच प्रभावी है।
साइडकार कंटेनरों के लिए, उच्च प्राथमिकता वाले साइडकार कंटेनर को पहले तत्काल/आखिरी बार फाड़ा जाएगा।

@tedyu , निर्भरता में "प्राथमिकता" की तुलना में अधिक मेटाडेटा और मूल्य है। निर्भरता दिए गए प्राथमिकता क्रम का उत्पादन करने के लिए c++ कोड की 30 लाइनें लगती हैं https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ । दूसरा रास्ता संभव नहीं है।

एक अन्य लाभ यह है कि निर्भरता ग्राफ को देखते हुए कुछ कंटेनरों को एक ही समय में शुरू किया जा सकता है।
निम्नलिखित उदाहरण में: "ए -> बी, बी -> सी, डी -> सी" कंटेनर बी और डी को एक ही समय में शुरू किया जा सकता है यदि सी को प्रारंभ किया जाता है। मैं यह नहीं कह रहा हूं कि कार्यान्वयन को इसका समर्थन करना है, लेकिन कम से कम यह बहुत मूल्यवान हो सकता है यदि एपीआई ऐसी परिभाषा की अनुमति देता है।

पूर्णांक प्राथमिकता अच्छी तरह से काम नहीं करेगी - लोग सभी प्रकार की भिन्न, गैर-मानकीकृत संख्याओं का उपयोग करेंगे जैसा कि वे CSS z-index संपत्ति (जैसे -9999 ) के साथ करते हैं।

@ रूबेनहक इस बिंदु पर आप जो सुझाव दे रहे हैं वह मूल रूप से इस
यदि आप इस तरह की सुविधा के बारे में भावुक हैं, तो मेरा सुझाव है कि आप अपना स्वयं का केईपी बनाएं और इसे विभिन्न एसआईजी के पास ले जाकर उनकी प्रतिक्रिया प्राप्त करें।

एक निर्भरता ग्राफ के विचार पर विस्तार से चर्चा की गई जब यह प्रस्ताव 2018 में वापस शुरू हुआ, निष्कर्ष इस बात पर एकमत था कि हालांकि यह कुछ और उपयोग के मामलों को सक्षम करेगा, वे पर्याप्त उपयोग के मामले नहीं थे और अतिरिक्त जटिलता इसके लायक नहीं थी।

मुझे लगता है कि आप जो वर्णन कर रहे हैं उसे लागू करने के लिए आवश्यक परिवर्तन की डिग्री को कम करके आंका जा रहा है। लेकिन अगर यह उतना ही सरल है जितना आपको लगता है, तो आप कुबेरनेट्स में काम करने के लिए अपनी खुद की अवधारणा का सबूत बना सकते हैं और अपने मामले को मजबूत करने में मदद करने के लिए एसआईजी को पेश कर सकते हैं।

यह केईपी अभी तक एक जीए सुविधा नहीं है, अगर आपका केईपी स्वीकृत और कार्यान्वित हो जाता है तो हम इसे हटा सकते हैं। वे अभी तक परस्पर अनन्य नहीं हैं।

यह परिवर्तन प्रत्येक उपयोग के मामले के लिए सही समाधान नहीं हो सकता है, लेकिन यह नाटकीय रूप से अधिकांश के लिए अनुभव में सुधार करता है और मुझे लगता है कि कार्यान्वयन के बारे में एक और वर्ष के लिए बहस करने के लिए इसे विलय करने से बेहतर होगा।

अगर आपका केईपी स्वीकृत और लागू हो जाता है तो हम इसे हटा सकते हैं। वे अभी तक परस्पर अनन्य नहीं हैं।

क्या वे _ever_ परस्पर अनन्य होंगे?

मैं खुद से पूछ रहा हूं कि क्या इस सुविधा का मूल्य _यहां तक ​​​​कि अगर_ अधिक स्पष्ट कंटेनर स्टार्टअप/शटडाउन ऑर्डरिंग (जो मुझे लगता है कि बहुत अच्छा होगा) भविष्य में एक और एन्हांसमेंट के माध्यम से सक्षम है ... और मैं हां सोच रहा हूं।

कोई भी स्टार्टअप / शटडाउन ऑर्डर, जो कि कंटेनर के वर्गीकरण द्वारा init, साइडकार, या "नियमित" के रूप में अलग रखा गया है, ये वर्गीकरण _other_ को भी व्यक्त करते हैं, और यकीनन कंटेनर के वांछित व्यवहार के असंबंधित पहलुओं को व्यक्त करते हैं, है ना?

उदाहरण के लिए, यह restartPolicy != Always (एक पॉड जो एक नौकरी को लागू करता है, शायद) के साथ एक पॉड में उपयोगी है, कि साइडकार के रूप में नामित कंटेनरों का एक पूर्ण राज्य में प्रवेश करने वाले पॉड पर कोई असर नहीं पड़ता है।

@ kfox1111 , वॉल्ट अब लगाता है । यह किस वर्ग में फिट होना चाहिए? इसके अलावा, मामले के आधार पर, तिजोरी सेवा जाल, या दूसरी तरफ निर्भर हो सकती है।

हमने सीएसआई अल्पकालिक ड्राइवरों के माध्यम से काम किया ताकि तिजोरी जैसी चीजों को साइडकार्स/इनिट कंटेनरों की आवश्यकता न हो। मेरा मानना ​​है कि काम में एक वॉल्ट ड्राइवर है।

हालांकि खालीडिर के साथ नियमित साइडकार ऐसा लगता है कि यह एक साइडकार के लिए फिट होगा जिसे नेटवर्क साइडकार्स का उपयोग करने की आवश्यकता है?

@ जोसेफ-इरविंग, मैं किसी भी तरह से इस केईपी को अंदर जाने से रोकने की कोशिश नहीं कर रहा था। मुझे पता है कि आपने इसे लगभग 2 साल पहले शुरू किया था और बहुत सारे लोग इसके जारी होने की प्रतीक्षा कर रहे हैं।

क्या आपके पास निर्भरता ग्राफ से संबंधित पूर्व चर्चा का लिंक है?

अरे @ जोसेफ-इरविंग,

अनुकूल अनुस्मारक कि हम 05 मार्च 2020 को कोड फ़्रीज़ होने पर बहुत तेज़ी से बंद हो रहे हैं। ऐसा नहीं लगता है कि आपके पीआर अभी तक मर्ज हो गए हैं, क्या आप अभी भी ऐसा महसूस कर रहे हैं कि आप इस एन्हांसमेंट के लिए कोड फ्रीज करने की राह पर हैं?

अरे @jeremyrickard , एपीआई समीक्षा (https://github.com/kubernetes/kubernetes/pull/79649) मूल रूप से की जाती है। हम उस पीआर को बंद कर देंगे और पूरी तरह से कार्यान्वयन पीआर में आगे बढ़ेंगे ताकि यह सभी (एपीआई और कार्यान्वयन) एक पीआर में विलय हो सके।

कार्यान्वयन पीआर (https://github.com/kubernetes/kubernetes/pull/80744) की पूरी तरह से समीक्षा की गई है, इसलिए मैं अंतिम अनुमोदन के लिए एक सिग-नोड अनुमोदक प्राप्त करने का प्रयास कर रहा हूं।

क्या यह कोड फ्रीज के लिए समय पर होता है, यह कहना मेरे लिए कुछ कठिन है, यह इस बात पर बहुत निर्भर है कि मैं समय पर कुछ अनुमोदनकर्ताओं का ध्यान आकर्षित करता हूं या नहीं।

इसे कोड फ्रीज द्वारा देखना अच्छा लगेगा। यह इस्तियो के https://github.com/istio/istio/issues/7136 के समाधान को सरल और बेहतर दोनों बना देगा।

इस पर कोई आंदोलन 1.18 में हो रहा है? तेजी से चलने वाली नौकरियों के साथ अपेक्षित रूप से काम करने के लिए istio sidecars के लिए आवश्यक लगता है।

मैंने कई तरह से सिग-नोड अनुमोदनकर्ताओं तक पहुंचने की कोशिश की है लेकिन मुझे कोई प्रतिक्रिया नहीं मिली है। इसलिए मैं बहुत आशावादी नहीं हूं कि यह इसे 1.18 कर देगा।

@ जोसेफ-इरविंग #pr-reviews स्लैक चैनल इन मामलों के लिए बनाया गया था। क्या आपने इसकी कोशिश की? यह जनसंपर्क समीक्षाओं पर आगे बढ़ने का एक तरीका है। (मैंने इसे वहां नहीं देखा)

अरे @ जोसेफ-इरविंग,

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

अरे @jeremyrickard ,

इन पीआर को 1.18 में मिलाने के संबंध में किसी ने मुझे जवाब नहीं दिया, इसलिए मुझे बहुत संदेह है कि ऐसा होगा।

हम 1.19 को टाल सकते हैं, लेकिन मुझे आश्चर्य हो रहा है कि क्या ऐसा करने का कोई मतलब है।
यह केईपी लगभग दो वर्षों से उड़ान में है (मूल अल्फा लक्ष्य 1.15 था), विचाराधीन पीआर लगभग 1 वर्ष से खुले हैं, उनके लिए कभी भी कोई "समीक्षक बैंडविड्थ" नहीं है।
मैंने विनम्रता से ईमेल किया है, सुस्त है, सिग-मीटिंग में गया है, और यहां तक ​​कि लोगों को व्यक्तिगत रूप से समीक्षा प्राप्त करने के लिए मिला है, फिर भी हमने बहुत कम प्रगति की है।
मेरे द्वारा प्राप्त की गई कोई भी समीक्षा केवल मामूली बदलावों का सुझाव देती है, ऐसा नहीं है कि बड़े पुनर्लेखन का अनुरोध किया गया है, पीआर मूल रूप से वही हैं जैसे वे एक साल पहले थे, बस थोड़ा और पॉलिश किया गया था।
मुझे नहीं पता कि मैं हर दिन आक्रामक रूप से लोगों को पिंग करना चाहता हूं जब तक कि वे मुझे जवाब न दें लेकिन यह वास्तव में ऐसा कुछ नहीं है जिसे करने में मैं सहज हूं।

मुझे लगता है कि समस्या यह है कि कोई भी वास्तव में इस सुविधा की परवाह नहीं करता है, मैं अकेला हूं जो इस सुविधा को आगे बढ़ा रहा है, एसआईजी में कोई भी इसे देखने में दिलचस्पी नहीं लेता है। अगर अल्फा में आने में दो साल लगते हैं, तो इसे बीटा/जीए में लाने में कितना समय लगेगा? (जैसा कि अधिकांश लोग वास्तव में इसका उपयोग कर सकते हैं)

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

हर बार जब हम इसमें देरी करते हैं, तो मुझे लगता है कि मैं बहुत से लोगों को निराश कर रहा हूँ, क्या यह सब मेरी गलती है? क्या कोड इतना भयानक है कि कोई टिप्पणी भी नहीं करेगा? क्या मैं इतना आक्रामक नहीं हूं कि ध्यान आकर्षित करने की कोशिश करूं?
मुझे बस ऐसा लगता है कि मैं इसे अपने दम पर नहीं कर सकता, और मैं इस मरे हुए घोड़े को पीटते हुए थोड़ा थक रहा हूँ।

मुझे लंबे शेख़ी के लिए खेद है (व्यक्तिगत रूप से जेरेमी या उस मामले के लिए व्यक्तिगत रूप से किसी के लिए निर्देशित नहीं), लेकिन यह मेरी आत्मा को लंबे समय से धीरे-धीरे खा रहा है।

निराशाजनक रूप से इस सुविधा को प्राप्त करने में व्यापक समुदाय और अंतिम उपयोगकर्ताओं से रुचि प्रतीत होती है, इसका कारण यह है कि मैंने इसे पहली जगह में देखा था, मैंने देखा कि यह एक मुद्दा था, एसआईजी से पूछ रहा था कि क्या वे इसे ठीक करने वाले थे, और वे ने कहा "हमारे पास क्षमता नहीं है, लेकिन हमें आपके ऐसा करने में खुशी होगी"।

@ जोसेफ-इरविंग इस पर। एक सक्रिय उपयोगकर्ता के रूप में, इस धागे को देख रहा हूं क्योंकि मुझे दिलचस्पी है (और मेरे दो सहयोगी भी हैं)। इस मुद्दे पर गतिविधि, पुल अनुरोध, सुस्त चैनल या सिग इस सुविधा में रुचि का सबसे अच्छा संकेतक नहीं हो सकता है।

@dims शायद आप कुछ प्रकाश डाल सकते हैं?

@thockin मैंने सुना है कि एक ~ साल पहले कुबेरनेट्स पॉडकास्ट में आपका साक्षात्कार लिया जा रहा था और आपने कुबेरनेट्स में योगदान करने के बारे में बात की थी। हो सकता है कि यह आप या कोई और पॉडकास्ट एपिसोड में हो, जिसने वास्तव में बुरा महसूस किया कि यह साइडकार केईपी इसे 1.16 पर नहीं बना पाया। खैर, ये रहें हम फिर से।

यह समस्या इस बात का एक प्रमुख उदाहरण प्रतीत होती है कि यदि आप उदाहरण के लिए कर्मचारी नहीं हैं तो योगदान करना कितना कठिन हो सकता है। Google, RedHat या अन्य बड़े खिलाड़ी।

मैंने स्लैक में भी इसकी समीक्षा करने में मदद के लिए कहा, लेकिन अभी बताया गया था कि @thockin द्वारा एक स्पष्ट पकड़ है, इसलिए मुझे यकीन नहीं है कि आगे का रास्ता भी है।

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

नेटवर्क साइडकार पर निर्भर किसी भी प्रकार की टोपोलॉजी चलाने वाला कोई भी कंटेनर स्टार्टअप/शटडाउन ऑर्डरिंग मुद्दों को मारने की संभावना है जो यह केईपी संभावित रूप से हल करेगा। इस टिकट पर "इस्तियो" के लिए Ctrl-F, और आपको कंटेनर ऑर्डरिंग से संबंधित परेशानियों का एक गुच्छा दिखाई देगा।

क्या यहाँ कोई इस्तियो अनुरक्षक हैं? बहुत सारे गोगलर्स हैं, और आंतरिक रूप से K8s लोगों के साथ कुछ और बोलबाला हो सकता है।

एक इस्तियो / K8s दुकान के रूप में, हम पूरी तरह से आपके लिए इसे प्राप्त करने के लिए तैयार हैं, @ जोसेफ-इरविंग! ❤️

अब तक साइडकार बनाने के लिए @ जोसेफ-इरविंग के लिए यश।

साइडकार जीवनचक्र प्रबंधन के लिए भी, किसी भी बैच की नौकरी के लिए इस सुविधा की आवश्यकता होगी या कुबेरनेट्स उनके लिए काम नहीं करता है, और इसीलिए हमने कोड समीक्षा और फीडबैक प्रदान करने में बहुत समय बिताया!

हम इस वजह से कुछ समय से k8s को फोर्क कर रहे हैं और हम वास्तव में इस तरह की महत्वपूर्ण सुविधा को आधिकारिक रूप से समर्थित देखने के लिए उत्सुक हैं।

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

@thockin यह ऊपर बताया गया है कि आपने इस पर स्पष्ट पकड़

Linkerd के बहुत सारे उपयोगकर्ता हैं जो इसका भी बेसब्री से इंतजार कर रहे हैं। वहाँ रुको @ जोसेफ-इरविंग, हम आपके लिए जड़ रहे हैं।

यकीन नहीं होता कि यहां बाकी सभी ने देखा, लेकिन कुछ खुदाई करने और एक क्यूबकॉन वीडियो देखने के बाद, मैंने पाया कि Lyft ने ऐसा ही कुछ किया था। यहाँ उनके कुबेरनेट्स के कांटे से उल्लिखित प्रतिबद्धता है: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

एक इस्तियो + कुबेरनेट्स दुकान के रूप में, हम भी इस सुविधा के लिए उत्सुकता से प्रतीक्षा कर रहे हैं। और तेजी से निराश हो रहा है कि यह रिलीज से रिलीज तक फिसल जाता है।

मैं एक संभावित istio उपयोगकर्ता हूं, लेकिन इस तरह की सुविधा की प्रतीक्षा के कारण थोड़ा सा अलग रखा गया है। हालांकि ऊपर की चर्चाओं के दौरान, मैं उन चीजों को देखता रहता हूं जो मुझे लगता है कि साइडकार फीचर अकेले यहां चर्चा की गई है, इस्तियो साइडकार के वर्कफ़्लो के साथ सभी समस्याओं को ठीक नहीं करेगा। हालांकि यह मदद कर सकता है। जो मुझे लगता है कि यह रुकने के कारण का हिस्सा है।

इस्तियो सीएनआई ड्राइवर का उपयोग करते समय साइडकार में इस्तियो चलाना कैसे काम करता है? मेरा मानना ​​​​है कि नेटवर्क तक पहुंचने की कोशिश कर रहे इनिट कंटेनर अभी भी ठीक से काम करने में विफल रहेंगे जैसा कि istio प्रलेखन में प्रलेखित है।

इसलिए मेरा सवाल ऊपर है कि क्या नेटवर्क साइडकार्स की अपनी चीज है।

यह समस्या इस बात का एक प्रमुख उदाहरण प्रतीत होती है कि यदि आप उदाहरण के लिए कर्मचारी नहीं हैं तो योगदान करना कितना कठिन हो सकता है। Google, RedHat या अन्य बड़े खिलाड़ी।

हा! जो आप नहीं जानते वह यह है कि वो लोग कभी-कभी फंस भी जाते हैं!

गंभीरता से, मुझे खेद है। मेरे पास बहाने हैं, लेकिन यह बेकार है इसलिए मैं परेशान नहीं करूंगा।

स्पष्टीकरण के लिए:
मैं यह नहीं कह रहा हूं कि दृष्टिकोण पर कुछ प्रतिक्रिया प्राप्त करने के लिए हमें इसे अल्फा के रूप में विलय नहीं करना चाहिए। सामान्य तौर पर मुझे लगता है कि यह ध्वनि है। मुझे लगता है कि सर्विस मेश जैसे उपयोग के मामलों में कुछ छेद हैं जिन्हें यह काफी कवर नहीं करता है। लेकिन यह इसे जल्द से जल्द प्राप्त करने से रोकने का एक कारण नहीं है, इसलिए हम अन्य सभी उपयोग के मामलों को ढूंढ सकते हैं जो इसे कवर नहीं करते हैं ताकि हम फीचर के बीटा संस्करण को सभी के लिए अच्छी तरह से काम कर सकें। आईएमओ के लिए अल्फा यही है।

मैं सिर्फ यह उल्लेख कर रहा हूं कि मैंने क्या किया, विशेष रूप से लोगों को उम्मीद है कि यह मौजूदा सेवा जाल मुद्दे के लिए एक चांदी की गोली होगी। मुझे नहीं लगता कि प्रस्तावित अल्फा पूरी तरह से उस विशेष मुद्दे को ठीक कर देगा। इसलिए अभी अपनी उम्मीदों को बहुत ज्यादा न बढ़ाएं। लेकिन कृपया, इस सुविधा को केवल इसलिए ब्लॉक न करें क्योंकि यह अभी तक सभी का समर्थन नहीं करती है।

मैंने एक अपवाद के लिए अनुरोध किया है, देखते हैं कि क्या हम इसे इसमें लाने का प्रयास कर सकते हैं:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

हो सकता है कि यह आप या कोई और [कुबेरनेट्स पॉडकास्ट] एपिसोड में था जिसने वास्तव में बुरा महसूस किया कि यह साइडकार केईपी इसे 1.16 तक नहीं पहुंचा पाया

कृपया एपिसोड 72 देखें 83, गाइनवेरे सेंगर के साथ । मैंने इस सप्ताह यह भी

क्या यहाँ कोई इस्तियो अनुरक्षक हैं? बहुत सारे गोगलर्स हैं, और आंतरिक रूप से K8s लोगों के साथ कुछ और बोलबाला हो सकता है।

@duderino और @howardjohn दोनों ने इस सूत्र पर पहले ही टिप्पणी कर दी है।

स्पष्ट होने के लिए हमें विलय की आवश्यकता है:
कुबेरनेट्स/कुबेरनेट्स#79649
कुबेरनेट्स/कुबेरनेट्स#80744

क्या कोई अन्य पीआर हैं जिन पर हमें नज़र रखनी चाहिए?

धन्यवाद!

• संवर्द्धन टीम

समर्थन के संदेश (सार्वजनिक या निजी तौर पर) पोस्ट करने वाले सभी लोगों को बहुत-बहुत धन्यवाद, जिसकी बहुत सराहना की गई ❤️

समुदाय के सदस्यों द्वारा इसे 1.18 में लाने का एक बहादुर प्रयास किया गया था, जिसमें रिलीज टीम भी शामिल थी, जिसने एक विस्तार अनुरोध स्वीकार कर लिया था, लेकिन अफसोस, इसे 1.19 तक स्थगित करने का निर्णय लिया गया है। आप इस टिप्पणी से शुरू होने वाली प्रासंगिक बातचीत देख सकते हैं: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034।

इसके 1.18 में नहीं आने के बावजूद, पिछले कुछ दिनों में इस पर बहुत अधिक ध्यान दिया गया है, इसलिए मुझे उम्मीद है कि यह गति 1.19 में आगे बढ़ेगी।

cc @jeremyrickard , @kikisdeliveryservice

बढ़िया सामान @ जोसेफ-इरविंग, ऐसा लगता है कि आपकी कुछ कुंठाएं सार्थक रही हैं और सुनी गई हैं। लगन के लिए धन्यवाद।

/मील का पत्थर v1.19

नमस्ते। हम में से एक समूह पिछले सप्ताह से इस विषय पर चर्चा कर रहा है।

सबसे पहले, यहाँ जो हुआ उसके लिए हम क्षमा चाहते हैं। हम इससे खुश नहीं हैं।

इस पीआर और संबंधित केईपी ने कई चीजें प्रकाश में लायी हैं जो परियोजना बेहतर कर सकती है। हम सामाजिक, प्रक्रियात्मक और तकनीकी चिंताओं को अलग करना चाहेंगे।

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

एक-दूसरे पर भरोसा करने में यह विश्वास करना शामिल है कि हम "नहीं" कह सकते हैं और यह भरोसा करना कि जब कोई "नहीं" कहता है, तो वे अच्छे कारणों से ऐसा कर रहे हैं। यह तकनीकी क्षेत्र एसआईजी तक फैला है, और हमें सिग-नोड पर दबाव नहीं डालना चाहिए, जो अंततः समस्याओं को हल करने वाले होंगे, नई सुविधाओं को स्वीकार करने के लिए वे अभी तक समर्थन के लिए सहज नहीं हैं.. यह विशेष रूप से टिम या डेरेक या क्लेटन के बारे में नहीं है, लेकिन सभी उच्च-स्तरीय अनुमोदनकर्ता और SIG लीड और "वरिष्ठ" योगदानकर्ता।

यह सुविधा केईपी के आसपास प्रक्रियात्मक अनिश्चितता का शिकार भी हुई। KEP समीक्षक के रूप में, क्या मैं एक कोड समीक्षक बनने के लिए बाध्य हूँ? एक कोड समीक्षक को सौंपने के लिए? या सिर्फ केईपी पढ़ने के लिए? जैसे ही केईपी जारी होता है, हम कैसे सुनिश्चित करते हैं कि एक चरवाहा रिलीज के एक विशेष अवधि में बजट में किए गए परिवर्तनों के सेट के लिए उपलब्ध है। यदि एक केईपी एसआईजी तक फैला है, तो हम एसआईजी के लिए बजट और समय कैसे आवंटित करते हैं? हमें इसे स्पष्ट करने की जरूरत है। हम केईपी प्रक्रिया में भूमिकाओं की परिभाषा को मजबूत करने के लिए कुछ केईपी परिवर्तन-प्रस्तावों (केईपी केईपी) पर काम करने जा रहे हैं।

तकनीकी रूप से, यह विशेषता समय और ध्यान दोनों का शिकार हुई। समीक्षकों ने इसकी समीक्षा करने के लिए पर्याप्त समय नहीं दिया, या यह उनके लिए पर्याप्त उच्च प्राथमिकता नहीं थी। आगे-पीछे की चर्चाओं में समय लगता है। परिस्थितियाँ और समस्या स्थान के बारे में हमारी समझ समय के साथ बदलती रहती है।

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

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

इस पीआर और संबद्ध केईपी के लिए इसका क्या अर्थ है? हम 100% निश्चित नहीं हैं। इसका शायद मतलब है कि हमें इसे अभी तक आगे नहीं बढ़ाना चाहिए।

डेरेक ने शटडाउन अनुक्रमण के बारे में कुछ चिंताएँ उठाईं। केईपी ने उन्हें अभी के लिए दायरे से बाहर बुलाया, लेकिन कुछ झिझक है। हम पहले से ही नोड शटडाउन पर ग्रेसफुल टर्मिनेशन का सम्मान नहीं करते हैं, और इसने कई उपयोगकर्ताओं को चौंका दिया है। यह केईपी की गलती नहीं है, लेकिन इसे "विघटनकारी परिस्थितियों" कहते हैं। यदि कोई अपने पॉड्स को "क्लीन अप" करने के लिए साइडकार का उपयोग करता है (उदाहरण के लिए कैश्ड लॉग को लॉगिंग सेवा में निकालने के लिए), तो वे शटडाउन के आसपास कुछ स्पष्ट और उपयोगी शब्दार्थ की अपेक्षा करेंगे, जिसकी यह केईपी गारंटी नहीं देता है।

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

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

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

धन्यवाद,
क्लेटन, डेविड, डॉन, डेरेक, जॉन, टिमो

कुछ आगे बढ़ने की कोशिश करने के लिए: डेरेक या डॉन - क्या कोई सिग-नोड है जो अधिक समग्र पॉड और कंटेनर जीवनचक्र के बारे में कुछ दिमागी तूफान करने के लिए समय निकाल सकता है?

@thockin इसे सिग-नोड एजेंडा में जोड़ देगा।

@thockin @derekwaynecarr टीएल क्या है; डॉ कि यह क्यों नहीं जा सका?

वन-लाइन एन्हांसमेंट विवरण: कंटेनरों को अब साइडकार के रूप में चिह्नित किया जा सकता है ताकि वे सामान्य कंटेनरों से पहले शुरू हो जाएं और अन्य सभी कंटेनरों के समाप्त होने के बाद बंद हो जाएं।

कुछ ऐसा लगता है जो सर्विस मेश साइडकार्स के इस नए युग में जीवन को आसान बना देगा।

इसके अलावा साइडकार्स मुख्य ऐप कंटेनर से पहले शुरू होने और मुख्य ऐप कंटेनर समाप्ति के बाद बंद होने के लिए कोई सिफारिशें आज?

... टीएल क्या है; डॉ के रूप में यह क्यों नहीं जा सका?

@nasemkullah https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 से...

इस पीआर और संबद्ध केईपी के लिए इसका क्या अर्थ है? हम 100% निश्चित नहीं हैं। इसका शायद मतलब है कि हमें इसे अभी तक आगे नहीं बढ़ाना चाहिए।

डेरेक ने शटडाउन अनुक्रमण के बारे में कुछ चिंताएँ उठाईं। केईपी ने उन्हें अभी के लिए दायरे से बाहर बुलाया, लेकिन कुछ झिझक है। हम पहले से ही नोड शटडाउन पर ग्रेसफुल टर्मिनेशन का सम्मान नहीं करते हैं, और इसने कई उपयोगकर्ताओं को चौंका दिया है। यह केईपी की गलती नहीं है, लेकिन इसे "विघटनकारी परिस्थितियों" कहते हैं। यदि कोई अपने पॉड्स को "क्लीन अप" करने के लिए साइडकार का उपयोग करता है (उदाहरण के लिए कैश्ड लॉग को लॉगिंग सेवा में निकालने के लिए), तो वे शटडाउन के आसपास कुछ स्पष्ट और उपयोगी शब्दार्थ की अपेक्षा करेंगे, जिसकी यह केईपी गारंटी नहीं देता है।

[...]

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

सम्मानपूर्वक, मैं इस बारे में उत्सुक हूं कि क्या कोई लीड इसे सुलझाने को प्राथमिकता देने की योजना बना रहा है। @ जोसेफ-इरविंग ने इसमें भारी मात्रा में काम किया और जो लोग उसके समाधान से खुश होंगे, वे उन लोगों से कुछ बेहतर समाधान सुनने के लिए उत्सुक हैं जिन्होंने इसे निक्स किया था।

कम से कम, हालांकि इसके कुछ पहलुओं के साथ कुछ दिक्कतें हैं, मुझे लगता है कि व्यवहार में कौन से मुद्दे दिखाई देंगे, यह जानने के लिए अल्फा के रूप में शामिल होना अभी भी उचित है। क्या हम इसका विलय करवा सकते हैं? मुद्दे इसे बीटा जाने से रोक सकते हैं, इसलिए मुझे नहीं लगता कि प्रारंभिक अल्फा बनने से पहले इसका सही होना महत्वपूर्ण है।

इसे सिग-नोड एजेंडा में जोड़ देगा।

@thockin @derekwaynecarr क्या इसकी वर्तमान स्थिति पर कोई अपडेट है? मैंने सिग-नोड मीटिंग नोट्स को देखा और इसके बारे में कुछ भी नहीं देखा।

इस धागे पर बड़ी संख्या में देव हैं जो इसे लागू करने में समय देने से अधिक खुश होंगे, क्योंकि कई उपयोग के मामलों के लिए यह महत्वपूर्ण है (केईपी में 2.5x के रूप में कई: +1: किसी भी अन्य केईपी के रूप में)। ऐसा करने के लिए हम क्या कर सकते हैं? इस क्षेत्र की स्थिरता के लिए पूर्वापेक्षाओं की एक सूची होने के बावजूद, भले ही यह पूरा करने के लिए कई रिलीज हो, हम सक्रिय रूप से काम करना शुरू कर सकते हैं, जहां से हम आज हैं, एक बड़ा सुधार होगा।

हाय @ जोसेफ-इरविंग @thockin @khenidak @kow3ns - 1.19 एन्हांसमेंट यहां लीड करें, मैं यह जांचना चाहता हूं कि क्या आपको लगता है कि यह एन्हांसमेंट 1.19 में स्नातक होगा?

रिलीज का यह हिस्सा पाने के लिए:

1. केईपी पीआर को लागू करने योग्य स्थिति में विलय किया जाना चाहिए
2. केईपी के पास परीक्षण योजनाएं होनी चाहिए
3. केईपी में स्नातक मानदंड होना चाहिए।

वर्तमान रिलीज शेड्यूल है:

• सोमवार, अप्रैल 13: सप्ताह 1 - रिलीज़ चक्र शुरू होता है
• मंगलवार, मई 19: सप्ताह 6 - एन्हांसमेंट फ़्रीज़
• गुरुवार, जून 25: सप्ताह 11 - कोड फ़्रीज़
• गुरुवार, 9 जुलाई: सप्ताह 14 - डॉक्स को पूरा किया जाना चाहिए और उनकी समीक्षा की जानी चाहिए
• मंगलवार, 4 अगस्त: सप्ताह 17 - Kubernetes v1.19.0 जारी किया गया

@palnabarun , इस टिप्पणी के अनुसार https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056, इस KEP को अनिश्चितकालीन होल्ड पर रखा गया है, इसलिए नहीं, यह 1.19 में स्नातक नहीं होगा।

धन्यवाद @ जोसेफ-इरविंग स्थिति को स्पष्ट करने के लिए। :+1:

तुम्हारे प्रयत्नों की प्रशंसा करता हूं!

हर कोई जो इसे प्राप्त करने के लिए उत्सुक है, और फिर से @ जोसेफ-इरविंग के लिए - मुझे इस स्थिति के लिए व्यक्तिगत रूप से बहुत खेद है। मुझे यह (या ऐसा ही कुछ) भी चाहिए, लेकिन तथ्य यह है कि सिग-नोड के पास अभी करने के लिए लोगों की तुलना में अधिक काम है, और वे इस पर विचार करने के लिए तैयार नहीं हैं।

यह बेकार है। मैं समझ गया। मैं वास्तव में करता हूं।

लोगों की मदद करने का सबसे अच्छा तरीका यह है कि सिग-नोड में कूदें और कोड-समीक्षाओं को लेकर अधिक क्षमता बनाने में मदद करें और ट्राइएज जारी करें, बग्स और परीक्षणों को ठीक करके, और एक ऐसे स्थान की ओर निर्माण करें जहां सिग-नोड विशेषज्ञों की अधिक क्षमता हो और ऐसा परिवर्तन करने का विश्वास।

सिग-नोड के पास अभी करने के लिए लोगों की तुलना में अधिक काम है

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

/ मील का पत्थर स्पष्ट

लोगों की मदद करने का सबसे अच्छा तरीका यह है कि सिग-नोड में कूदें और कोड-समीक्षाओं को लेकर अधिक क्षमता बनाने में मदद करें और ट्राइएज जारी करें, बग्स और परीक्षणों को ठीक करके, और एक ऐसे स्थान की ओर निर्माण करें जहां सिग-नोड विशेषज्ञों की अधिक क्षमता हो और ऐसा परिवर्तन करने का विश्वास।

@thockin क्या आप रिपॉजिटरी, मेलिंग लिस्ट, गाइड आदि जैसे लिंक प्रदान कर सकते हैं? इससे लोगों को यह जानने में मदद मिलेगी कि सिग-नोड के साथ प्रभावी ढंग से कैसे जुड़ना है। यह विशेष सुविधा अनुरोध 2 वर्ष से अधिक पुराना है और कोई समाधान दिखाई नहीं दे रहा है।

@ tariq1890 इस KEP को लिखने वाले लोगों ने सब कुछ ठीक किया है। उन्होंने कोई कसर नहीं छोड़ी है। यहाँ मुद्दा ठीक वैसा ही है जैसा @thockin ने कहा, वहाँ तकनीकी ऋण है जिसे हमें पहले ठीक करने की आवश्यकता है और इससे पहले कि हम इस पर विचार कर सकें, इसके लिए हाथों की आवश्यकता है। तो लोगों से यह पूछना है कि क्या करने की आवश्यकता है।

कृपया नवीनतम अपडेट यहां देखें: https://github.com/kubernetes/enhancements/pull/1874

@dims मुझे लगता है कि मुझे गलत समझा गया है। मेरे कहने का तात्पर्य यह है कि हमें कार्रवाई योग्य लक्ष्यों और लक्ष्यों की एक सूची की आवश्यकता है। यदि तकनीकी ऋण से निपटा जाना है, तो हम गिटहब मील का पत्थर बनाए रख सकते हैं या ओपी टिप्पणी में लंबित कार्रवाई वस्तुओं की बुलेटेड सूची प्रदान कर सकते हैं ताकि इस मुद्दे पर आने वाले लोगों को तुरंत पता चल सके कि क्या संबोधित किया जाना चाहिए।

मैं निश्चित रूप से इस केईपी को आगे बढ़ाने के साथ हस्ताक्षर/नोड करने के लिए अपनी मदद की पेशकश करने के लिए तैयार हूं, लेकिन यह नहीं जानता कि कैसे

@ tariq1890 विशिष्ट प्रश्न यहाँ है: "(अभी तक सबमिट नहीं किए गए KEP) क्यूबलेट नोड ग्रेसफुल शटडाउन पर पूर्वापेक्षाएँ" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

हमें इसे शुरू करने की जरूरत है। किसी को बिंदु लेना होगा और उसे आगे बढ़ाना होगा।

-- डिम्सो

तो इस मुद्दे में उन लोगों के लिए https://github.com/kubernetes/enhancements/pull/1874 को संक्षेप में प्रस्तुत
इसलिए यह निर्णय लिया गया है कि यह सुविधा तब तक आगे नहीं बढ़ेगी जब तक कि नोड समाप्ति का समाधान लागू नहीं किया जाता।
वर्तमान में यहां एक Google दस्तावेज़ है: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
जिसमें इस मुद्दे को लेकर काफी चर्चा है, लेकिन इसके लिए केईपी अभी जमा नहीं किया गया है।
अभी भी खुले प्रश्न हैं इसलिए इस पर टिप्पणी करना मददगार हो सकता है, मेरा मानना ​​​​है कि @bobbypage और @mrunalp इस प्रयास का नेतृत्व कर रहे हैं, इसलिए शायद वे किसी अन्य तरीके से साझा कर सकते हैं जिससे लोग इसे आगे बढ़ाने में सहायता कर सकें।

@ जोसेफ-इरविंग संक्षेप के लिए एक टन धन्यवाद। मुझे उम्मीद है कि इस एन्हांसमेंट पर सभी +ve ऊर्जा नियमित आधार पर सिग-नोड में सभी की अधिक भागीदारी का अनुवाद करती है, न कि सुविधाओं के लिए केवल एक बार। बहुत काम करना है और बहुत कम हाथ।

नमस्ते! इस केईपी के बारे में एक और टिप्पणी, हालांकि: मैंने पिछली एसआईजी-नोड मीटिंग्स में इस केईपी के बारे में कुछ बढ़त के मामले उठाए (23 जून यदि आप रिकॉर्डिंग देखना चाहते हैं) और हमने फैसला किया कि उस चर्चा को जारी रखने का उचित तरीका उन लोगों के बारे में पीआर खोल रहा है। मुद्दे इसलिए हम तय कर सकते हैं कि कैसे आगे बढ़ना सबसे अच्छा है।

मैं वर्तमान में उन मुद्दों और कुछ विकल्पों के बारे में बताने के लिए पीआर पर काम कर रहा हूं जिनके बारे में मैं सोच सकता हूं।

साथ ही, केईपी राज्य अब अनंतिम (कार्यान्वयन योग्य के बजाय) है, इसलिए इसकी समीक्षा की जा सकती है और इसे फिर से लागू करने के लिए सेट किया जा सकता है जब सभी लोग केईपी के साथ आगे बढ़ने के लिए सहज महसूस करते हैं।

मुझे लगता है कि इस मुद्दे में केवल यही जानकारी गायब थी। धन्यवाद!

@rata क्या आपने मुद्दों को संभालने के लिए उचित तरीके से मुद्दों/

@mattfarina यह पीआर है https://github.com/kubernetes/enhancements/pull/1913
इसमें केईपी में मौजूदा समस्याओं/किनारे के मामलों के कई प्रस्तावित समाधान शामिल हैं
इसमें कई विकल्पों का विवरण भी शामिल है जिन पर चर्चा की गई और जिनके खिलाफ निर्णय लिया गया, ताकि हमारे पास एक बेहतर लॉग हो कि कुछ निर्णय क्यों किए गए हैं।

मैं बहुत पसंद करूंगा कि साइडकार की कार्यक्षमता भी स्केलिंग को कवर करे:
आज, एचपीए स्केलिंग एक मीट्रिक (जैसे सीपीयू) पर आधारित है। यदि पॉड में एक से अधिक कंटेनर होते हैं, तो सभी कंटेनरों में औसत का उपयोग किया जाता है (जहाँ तक मुझे पता है)। साइडकार (ऐप + nginx आदि) वाले पॉड्स के लिए यह स्केलिंग फ़ंक्शन को सही ढंग से बनाना बहुत कठिन बनाता है। मैं उम्मीद कर रहा था कि कुबेरनेट्स में साइडकार कार्यान्वयन में एचपीए स्केलिंग के लिए उपयोग किए जाने वाले मीट्रिक के संदर्भ में पॉड में एक कंटेनर को "आधिकारिक" के रूप में चिह्नित करना शामिल होगा।

मैं बहुत पसंद करूंगा कि साइडकार की कार्यक्षमता भी स्केलिंग को कवर करे:

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

क्या किसी के पास इस मुद्दे के लिए वर्तमान समाधान, विशेष रूप से इस्तियो दूत साइडकार के मामले के लिए कोई संदर्भ है, या साझा करने के लिए बहुत दयालु हो सकता है?

मुझे इसमें शामिल एक संभावित समाधान याद है:

• एक कस्टम दूत छवि जो SIGTERM की उपेक्षा करती है।
• शटडाउन पर एप्लिकेशन कंटेनर के भीतर से दूत पर आह्वान/छोड़ना (नौकरी पूरा करने के समाधान के समान)

क्या किसी के पास इस मुद्दे के लिए वर्तमान समाधान, विशेष रूप से इस्तियो दूत साइडकार के मामले के लिए कोई संदर्भ है, या साझा करने के लिए बहुत दयालु हो सकता है?

हम उपयोगकर्ता के प्रोग्राम को लपेटने के लिए supervisor जैसी कस्टम डेमॉन छवि का उपयोग करते हैं। उपयोगकर्ताओं के कार्यक्रमों की स्वास्थ्य स्थिति (बाहर निकले या नहीं) को बताने के लिए डेमॉन एक विशेष पोर्ट को भी सुनेगा।

यहाँ उपाय है:

• बाइनरी को साझा वॉल्यूम में कॉपी करने के लिए डेमॉन छवि का उपयोग initContainers करना।
• हमारा CD उपयोगकर्ताओं के आदेश को हाईजैक कर लेगा, पहले डेमॉन को शुरू करने दें। फिर, दूत के तैयार होने तक डेमॉन उपयोगकर्ता के कार्यक्रम को चलाता है।
• साथ ही, हम preStop जोड़ते हैं, एक स्क्रिप्ट जो दूत के लिए डेमॉन के स्वास्थ्य की स्थिति की जांच करती रहती है।

नतीजतन, दूत के तैयार होने पर उपयोगकर्ता की प्रक्रिया शुरू हो जाएगी, और उपयोगकर्ताओं की प्रक्रिया समाप्त होने के बाद दूत बंद हो जाएगा।

यह एक जटिल समाधान है, लेकिन यह हमारे उत्पादन परिवेश में ठीक काम करता है।

विवरण में लिंक 404 . देता है

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

मुझे लगता है कि यह होना चाहिए:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

हाँ इसे https://github.com/kubernetes/enhancements/pull/1913 में स्थानांतरित किया गया था, मैंने लिंक अपडेट कर दिया है

क्या किसी के पास इस मुद्दे के लिए वर्तमान समाधान, विशेष रूप से इस्तियो दूत साइडकार के मामले के लिए कोई संदर्भ है, या साझा करने के लिए बहुत दयालु हो सकता है?

@shaneqld स्टार्टअप मुद्दों के लिए, istio समुदाय एक साथ आया काफी चतुर समाधान का जो मूल रूप से कंटेनर सूची में पहले कंटेनर के रूप में दूत लगाता है और एक postStart हुक कि चेक और दूत के लिए प्रतीक्षा तैयार होने के लिए कहते हैं। यह अवरुद्ध हो रहा है और अन्य कंटेनर यह सुनिश्चित करना शुरू नहीं कर रहे हैं कि दूत वहां है और ऐप कंटेनर शुरू करने से पहले तैयार है।

हमें इसे उस संस्करण में पोर्ट करना था जिसे हम चला रहे हैं लेकिन यह काफी सीधा है और अब तक के परिणामों से खुश हैं।

शटडाउन के लिए हम प्रीस्टॉप हुक के साथ 'समाधान' भी कर रहे हैं लेकिन एक मनमानी नींद जोड़ रहे हैं जो हमें उम्मीद है कि SIGTERM के साथ जारी रखने से पहले एप्लिकेशन को इनायत से बंद कर दिया जाएगा।

Related PR: https://github.com/kubernetes/enhancements/pull/1980

हाय @ जोसेफ-इरविंग @ थॉकिन और बाकी सभी: मुस्कान:

संवर्द्धन यहां लीड। मैं देख रहा हूं कि अभी भी एक टन की बातचीत चल रही है, लेकिन एक अनुस्मारक के रूप में, कृपया हमें 1.20 में शामिल करने के लिए किसी भी योजना के बारे में अपडेट रखें ताकि हम प्रगति को ट्रैक कर सकें।

धन्यवाद!
कर्स्टन

@kikisdeliveryservice आपको पोस्ट

क्या किसी के पास इस मुद्दे के लिए वर्तमान समाधान, विशेष रूप से इस्तियो दूत साइडकार के मामले के लिए कोई संदर्भ है, या साझा करने के लिए बहुत दयालु हो सकता है?

@shaneqld स्टार्टअप मुद्दों के लिए, istio समुदाय एक साथ आया काफी चतुर समाधान का जो मूल रूप से कंटेनर सूची में पहले कंटेनर के रूप में दूत लगाता है और एक postStart हुक कि चेक और दूत के लिए प्रतीक्षा तैयार होने के लिए कहते हैं। यह अवरुद्ध हो रहा है और अन्य कंटेनर यह सुनिश्चित करना शुरू नहीं कर रहे हैं कि दूत वहां है और ऐप कंटेनर शुरू करने से पहले तैयार है।

हमें इसे उस संस्करण में पोर्ट करना था जिसे हम चला रहे हैं लेकिन यह काफी सीधा है और अब तक के परिणामों से खुश हैं।

शटडाउन के लिए हम प्रीस्टॉप हुक के साथ 'समाधान' भी कर रहे हैं लेकिन एक मनमानी नींद जोड़ रहे हैं जो हमें उम्मीद है कि SIGTERM के साथ जारी रखने से पहले एप्लिकेशन को इनायत से बंद कर दिया जाएगा।

क्या आप कुछ अंतर्दृष्टि विस्तार से दिखा सकते हैं कि इन्हें कैसे करें? इस्तियो-प्रॉक्सी साइडकार में 'प्री-स्टॉप' जोड़ना कैसे प्राप्त करें? ऐसा लगता है कि इसे कुछ कस्टम कॉन्फ़िगरेशन की आवश्यकता है या कस्टम साइडकार का उपयोग करें। मुझे एक ही समस्या का सामना करना पड़ता है कि जब फली कम हो जाती है, तो मुख्य कंटेनर काम खत्म करने की कोशिश कर रहा है लेकिन यह शायद बाहर से कनेक्शन खो देता है क्योंकि इस्तियो-साइडकार सिगटरम के तुरंत बाद बंद हो गया। अभी मैं सिर्फ डिफ़ॉल्ट साइडकार इंजेक्शन का उपयोग करता हूं। शुक्रिया!

ठीक है इस धागे को हाईजैक किया जा रहा है। आइए विषय पर बने रहें, कृपया।

केवल एक सौम्य अनुस्मारक कि एन्हांसमेंट फ़्रीज़ अगले सप्ताह, मंगलवार, 6 अक्टूबर को है। उस समय तक केईपी को कार्यान्वयन योग्य चिह्नित करने के लिए अद्यतन करने की आवश्यकता होगी।

इसके अलावा केईपी एक पुराने प्रारूप का उपयोग कर रहा है, इसलिए अपडेट करना बहुत अच्छा होगा (एक बार जब आप विवरण को समाप्त कर लेंगे): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice शेष के लिए धन्यवाद। 1.20 में शामिल करने का निर्णय लिया तो करेंगे। धन्यवाद! :)

यह 1.20 का हिस्सा नहीं होगा। पिंगिंग के लिए बहुत बहुत धन्यवाद! :)

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

मैं इस प्रस्ताव को हाईजैक नहीं करना चाहता, लेकिन ऊपर की बातचीत के आधार पर, मुझे आश्चर्य है कि क्या यह अब तक मान्यता प्राप्त की तुलना में थोड़ा व्यापक/बड़ा मुद्दा है।

मैं इस मुद्दे के निम्नलिखित समाधानों की कल्पना कर सकता हूं -

1. एक नई कंटेनर इकाई "साइडकार कंटेनर" को परिभाषित करें जो "मुख्य कंटेनर" से पहले initContainers के बाद शुरू होता है, और "मुख्य कंटेनर" समाप्त होने के बाद समाप्त होता है (प्रति @ जोसेफ-इरविंग मूल प्रस्ताव)
2. एक अतिरिक्त फ़ील्ड को (1) पर परिभाषित करें जो सेट करता है कि "साइडकार कंटेनर" प्रति @luksa सुझाव पर initContainer(s) से पहले शुरू होता है या नहीं)।
3. व्यापक जाओ।

व्यक्तिगत रूप से, विकल्प (2) मेरी तत्काल समस्या का समाधान करता है ।

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

विकल्प (2) मेरी समस्या को भी हल करता है, लेकिन मैं और भी जटिल निर्भरता संरचनाओं की कल्पना कर सकता हूं जो एक पॉड/स्टेटफुलसेट/डेमनसेट/जो कुछ भी कंटेनर निर्भरताओं के डीएजी को एम्बेड करने के लिए कह सकते हैं - यह विकल्प है (3) मैं सोच रहा हूं।

बस सोच रहा था कि क्या इस मुद्दे को वास्तव में पॉड परिभाषा पर फिर से केंद्रित किया जाना चाहिए, कुछ और सामान्य बनाने की दृष्टि से? मैंने मूल रूप से एक रनलेवल सादृश्य के संदर्भ में सोचा था, लेकिन शायद एक एयरफ्लो जैसी डीएजी संरचना में व्यापक प्रयोज्यता होगी।

दूत को init कंटेनर के रूप में भी जोड़ने के बारे में क्या? इस तरह यह अन्य init कंटेनरों के लिए नेटवर्क प्रदान करेगा। जब init समाप्त हो जाएगा तो यह '0 से बाहर निकल जाएगा', और फिर नियमित दूत (init नहीं) पदभार संभालेगा

@michalzxc अगर मैं गलत नहीं हूं, तो init कंटेनरों को क्रमिक रूप से एक-एक करके निष्पादित किया जाता है, इसलिए वर्तमान में आपके पास किसी अन्य कंटेनर के बगल में init-container रूप में एक दूत नहीं हो सकता है।

नमस्ते!

इस स्थान पर साइडकार चर्चा जारी रही (मैंने सिग-नोड स्लैक, जीथब पीआर को अपडेट किया है जिसने इसे और कई मेलिंग सूचियां शुरू की हैं):
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

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

कृपया, इस वृद्धि के मुद्दे को विषय (और शायद बंद) पर रखें। उन जगहों पर बातचीत में शामिल होने के लिए आपका स्वागत है :)

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

कृपया @rata की पिछली टिप्पणी देखें https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
उन जगहों के लिए जहां आप चर्चा में योगदान दे सकते हैं।

यह दुर्भाग्यपूर्ण है कि इस केईपी पर किए गए सभी कार्यों का उपयोग नहीं किया जा रहा है, लेकिन लोगों का एक व्यापक समूह अब इन मुद्दों के बारे में सोच रहा है, इसलिए उम्मीद है कि वे जिस समाधान के साथ आएंगे वह सभी के लिए सबसे अच्छा होगा।
मैंने इसे प्राप्त करने की कोशिश में पहले ही दो साल से अधिक समय बिताया है, इसलिए मुझे लगता है कि यह मेरे लिए आगे बढ़ने का एक अच्छा समय है, @rata और अन्य इन पहलों का नेतृत्व करेंगे।

/बंद करे

@ जोसेफ-इरविंग: इस मुद्दे को बंद करना।