ध्यान दें कि हमें अन्य प्रकार की सेवाओं से अलग करने के लिए शायद सेवा का नाम बदलकर lbservice या कुछ ऐसा करना चाहिए।

इसके भाग के रूप में, मैं कोर एपिसर्वर से सर्विस ऑब्जेक्ट्स को हटा दूंगा और अन्य लोड बैलेंसर्स, जैसे HAProxy और nginx के उपयोग की सुविधा प्रदान करूंगा।

यह अच्छा होगा यदि किसी सेवा की तार्किक परिभाषा (क्वेरी और/या वैश्विक नाम) को कई तरीकों से उपयोग/विशिष्ट किया जा सके - बुनियादी ढांचे के माध्यम से स्थापित एक साधारण लोड बैलेंसर के रूप में, nginx जैसे अधिक फीचर पूर्ण लोड बैलेंसर के रूप में या इन्फ्रास्ट्रक्चर द्वारा भी हैप्रोक्सी की पेशकश की जाती है, एक क्वेरी करने योग्य समापन बिंदु के रूप में एक इंटीग्रेटर मतदान/प्रतीक्षा कर सकता है (GET /services/foo -> {समापन बिंदु: [{होस्ट, पोर्ट}, ...]}), या मेजबानों के लिए उपलब्ध जानकारी के रूप में स्थानीय लोड बैलेंसरों को बेनकाब करने के लिए। जाहिर है कि ये कई अलग-अलग उपयोग के मामले हो सकते हैं और इस तरह अपने स्वयं के संसाधनों में विभाजित हो सकते हैं, लेकिन तंत्र से अलग इरादे (एक एलबी के तहत एकीकृत) निर्दिष्ट करने के लिए कुछ लचीलापन होने से रिकेट्स की एक विस्तृत श्रृंखला को संतुष्ट करना आसान हो जाता है।

@smarterclayton मैं नीति और तंत्र को अलग करने से सहमत हूं।

आदिम हमें चाहिए:

1. एक लेबल चयनकर्ता द्वारा पहचाने गए सेट को मतदान/देखने की क्षमता। सुनिश्चित नहीं है कि अभी तक कोई समस्या दर्ज की गई है।
2. पॉड आईपी पतों को क्वेरी करने की क्षमता (#385)।

यह अन्य नामकरण/खोज तंत्र और/या लोड बैलेंसर्स के साथ लिखने के लिए पर्याप्त होगा। फिर हम कोर के ऊपर एक उच्च-स्तरीय परत बना सकते हैं जो एक साधारण एपीआई के साथ सामान्य पैटर्न को बंडल करती है।

@ bgrant0607 द्वारा वर्णित दो आदिम क्या इस मुद्दे को खुला रखने लायक है? या क्या और विशिष्ट मुद्दे हैं जिन्हें हम दर्ज कर सकते हैं?

मुझे नहीं लगता कि ज़ूकीपर हल हो गया है - क्योंकि आपको प्रत्येक कंटेनर में अद्वितीय पहचानकर्ता की आवश्यकता है। मैं _थिंक_ आप इसे 3 अलग प्रतिकृति नियंत्रकों (प्रति उदाहरण एक) या प्रतिकृति नियंत्रक पर एक मोड के साथ कर सकते हैं।

सेवा डिजाइन मुझे लगता है कि ब्रायन नोट्स के रूप में कुछ चर्चा के योग्य है। वर्तमान में यह एक लेबल क्वेरी के साथ एक्सपोजर के लिए एक तंत्र (सभी कंटेनरों में पर्यावरण चर) के साथ एक बुनियादी ढांचा अमूर्त (स्थानीय प्रॉक्सी) जोड़ता है। एज प्रॉक्सी के लिए समान रूप से मान्य उपयोग केस है जो L7 होस्ट/पथ लेता है और उन्हें एक लेबल क्वेरी के साथ संतुलित करता है, साथ ही साथ http(s) और वेब सॉकेट जैसे प्रोटोकॉल का समर्थन करता है। इसके अलावा, सेवाओं में आज 60k बैकएंड की एक कठिन पैमाने की सीमा है, जो पूरे क्लस्टर (आवंटित आईपी की राशि) में साझा की जाती है। एक मिनियन पर एक स्थानीय प्रॉक्सी चलाना संभव होना चाहिए जो केवल उन सेवाओं को प्रॉक्सी करता है जिन्हें उस होस्ट पर कंटेनर की आवश्यकता होती है, और बाहरी बंदरगाह के बारे में जानने वाले कंटेनरों से बचने के लिए भी। यदि आवश्यक हो तो हम इस चर्चा को #494 पर ले जा सकते हैं।

फिक्स्ड प्रतिकृति के साथ सिंगलटन सेवाओं और गैर-ऑटो-स्केल्ड सेवाओं की समस्या से निपटना, जैसे कि मास्टर-स्लेव प्रतिकृति डेटाबेस, निश्चित-आकार के सहकर्मी समूहों (जैसे, आदि, ज़ूकीपर), आदि के साथ की-वैल्यू स्टोर।

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

प्रस्ताव: हमें कार्डिनल सेवाओं नामक सेवा का एक नया स्वाद बनाना चाहिए, जो केवल एक के बजाय एन आईपी पते को मैप करता है। कार्डिनल सेवाएं अपने लेबल चयनकर्ता द्वारा लक्षित एन इंस्टेंस को इन आईपी पतों का एक स्थिर असाइनमेंट निष्पादित करेंगी (यानी, एक निर्दिष्ट एन, न कि केवल कई लक्ष्य मौजूद हैं)। एक बार हमारे पास DNS ( #1261, #146 ) हो जाने पर, यह दिए गए उपसर्ग के आधार पर अनुमानित DNS नाम निर्दिष्ट करेगा, जिसमें प्रत्यय 0 से N-1 होगा। असाइनमेंट को एनोटेशन या लक्षित पॉड्स के लेबल में रिकॉर्ड किया जा सकता है।

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

विभिन्न प्रकार के लोड संतुलन के बारे में कुछ चर्चा सेवाओं v2 डिज़ाइन: #1107 में हुई।

मास्टर इलेक्शन के लिए अलग से इश्यू फाइल करूंगा।

/cc @smarterclayton @thockin

असाइनमेंट को कुछ पर्यावरण मानकीकरण तंत्र (लगभग निश्चित रूप से) के माध्यम से पॉड्स में ले जाना होगा।

आदि उदाहरण के लिए, मैं बनाउंगा:

• प्रतिकृति नियंत्रक कार्डिनैलिटी 1: 1 पॉड, स्थिर भंडारण मात्रा की ओर इशारा करते हुए A
• प्रतिकृति नियंत्रक कार्डिनैलिटी 2: 1 पॉड, स्थिर भंडारण मात्रा की ओर इशारा करते हुए बी
• प्रतिकृति नियंत्रक कार्डिनैलिटी 3: 1 पॉड, स्थिर भंडारण मात्रा की ओर इशारा करते हुए C
• पॉड्स की ओर इशारा करते हुए कार्डिनल सर्विस 'आदि'

यदि पॉड 2 मर जाता है, तो प्रतिकृति नियंत्रक 2 इसकी एक नई प्रति बनाता है और इसे वॉल्यूम बी में फिर से जोड़ता है। कार्डिनल सेवा 'आदि' जानता है कि वह पॉड नया है, लेकिन यह कैसे पता चलता है कि यह कार्डिनैलिटी 2 होना चाहिए (जो संग्रहीत डेटा से आता है) वॉल्यूम बी पर)?

3 प्रतिकृति नियंत्रकों के बजाय, एक शार्डिंग नियंत्रक क्यों नहीं, जो
निर्णय लेते समय "kubernetes.io/ShardIndex" जैसे लेबल को देखता है। अगर
आप 3-तरफा शार्डिंग चाहते हैं, यह 0, 1, 2 इंडेक्स के साथ 3 पॉड बनाता है। मुझे ऐसा लगता है
इसे पहले भी मार गिराया गया था, लेकिन मैं इसके कारण हुई परेशानी को फिर से नहीं बना सकता
मेरा सिर।

उपयोगकर्ताओं पर उस बोझ को डालना गलत लगता है यदि यह अपेक्षाकृत है
सामान्य परिदृश्य।

क्या आपको लगता है कि यह मायने रखता है अगर किसी दिए गए पॉड के लिए नाममात्र का आईपी बदल जाता है
सेट में असंबंधित परिवर्तन? उदाहरण के लिए:

समय 0 पर, पॉड्स (ए, बी, सी) आईपी के साथ एक कार्डिनल सेवा बनाते हैं
10.0.0.{1-3} क्रमशः

समय 1 पर, पॉड बी को होस्ट करने वाला नोड मर जाता है

समय 2 पर, प्रतिकृति नियंत्रक बी ड्राइविंग एक नया पॉड डी बनाता है

समय 3 पर, कार्डिनल सेवा आईपी के 10.0.0 के साथ (ए, सी, डी) में बदल जाती है।{1-3}
क्रमश

एनबी: पॉड सी का "स्थिर आईपी" सेट होने पर 10.0.0.3 से 10.0.0.2 में बदल गया
सदस्यता बदली। मुझे उम्मीद है कि यह दौड़ने के लिए बुरा काम करेगा
सम्बन्ध।

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

गुरु, 2 अक्टूबर 2014 को सुबह 10:17 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

असाइनमेंट को कुछ के माध्यम से पॉड्स में ले जाना होगा
पर्यावरण मानकीकरण तंत्र (लगभग निश्चित रूप से)।

आदि उदाहरण के लिए, मैं बनाउंगा:

• प्रतिकृति नियंत्रक कार्डिनैलिटी 1: 1 पॉड, स्थिर की ओर इशारा करते हुए
  भंडारण मात्रा ए
• प्रतिकृति नियंत्रक कार्डिनैलिटी 2: 1 पॉड, स्थिर की ओर इशारा करते हुए
  भंडारण मात्रा बी
• प्रतिकृति नियंत्रक कार्डिनैलिटी 3: 1 पॉड, स्थिर की ओर इशारा करते हुए
  भंडारण मात्रा सी
• पॉड्स की ओर इशारा करते हुए कार्डिनल सर्विस 'आदि'

यदि पॉड 2 मर जाता है, तो प्रतिकृति नियंत्रक 2 इसकी एक नई प्रति बनाता है और
इसे वॉल्यूम बी में दोबारा जोड़ता है। कार्डिनल सर्विस 'आदि' जानता है कि वह पॉड है
नया, लेकिन यह कैसे पता चलता है कि यह कार्डिनैलिटी 2 होना चाहिए (जो कि . से आता है)
वॉल्यूम बी पर संग्रहीत डेटा)?

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

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

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

सबसे पहले, मेरा इरादा इसे तेज करने के बारे में नहीं था - यह # 1064 है। आइए शार्पिंग चर्चाओं को वहां ले जाएं। हमने शार्किंग के लिए एक समान तंत्र का उपयोग करने की कोशिश करने के कई मामले देखे हैं, और हमने निष्कर्ष निकाला है कि यह शार्डिंग को लागू करने का सबसे अच्छा तरीका नहीं है।

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

तीसरा, मैं सहमत हूं कि हमें इस पर विचार करने की आवश्यकता है कि यह टिकाऊ डेटा प्रस्ताव (#1515) -- @erictune के साथ कैसे इंटरैक्ट करेगा।

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

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

छठा, प्रतिकृति नियंत्रक की जगह "शार्डिंग कंट्रोलर" के साथ समस्या यह है कि मैं छवि/पर्यावरण प्रबंधन से भूमिका असाइनमेंट को अलग करना चाहता हूं। मैं प्रतिकृति नियंत्रक को उत्तरार्द्ध प्रदान करने के रूप में देखता हूं (देखें https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564)।

टिकाऊ डेटा के मामले में, #1515 के अनुसार:

1. टिकाऊ पॉड्स के लिए, यह प्रस्ताव सिर्फ काम करेगा। टिकाऊ पॉड के लिए असाइनमेंट स्थिर होगा।
2. अलग डेटा ऑब्जेक्ट के लिए, कार्डिनल सेवा को डेटा ऑब्जेक्ट के लिए प्रबंधन भूमिका असाइनमेंट की भी आवश्यकता होगी, और पॉड्स को भूमिका असाइनमेंट को तब तक स्थगित करना होगा जब तक कि उनका डेटा से मिलान नहीं हो जाता। मुझे लगता है कि यह सीधा होगा।

/सीसी @erictune

मुझे लगता है कि आप बातचीत को आसान बनाने की कोशिश कर रहे थे, लेकिन मुझे यकीन नहीं है कि यह काम कर गया।

पुन: शार्डिंग - मूल रूप से "विशिष्ट पहचान के साथ प्रतिकृतियों का एक सेट" नहीं है?

पुन: 1 प्रतिकृति नियंत्रक - हमारे पास आज सूचकांक निर्दिष्ट करने वाला प्रतिकृति नियंत्रक नहीं है। मुझे नहीं लगता कि हम ऐसा चाहते हैं, है ना?

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

नहीं, स्थिर, विशिष्ट पहचान प्रदान करना न तो आवश्यक है और न ही शार्किंग के लिए पर्याप्त है। विवरण के लिए #1064 देखें, जिसे मैंने अभी वहां जोड़ा है।

नहीं, हम नहीं चाहते कि प्रतिकृति नियंत्रक सूचकांकों को नियत करे। मैंने जानबूझकर प्रस्तावित किया कि कार्डिनल सेवाएं इसके बजाय ऐसा करती हैं।

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

संभावित पहचान दृष्टिकोण: कंटेनर में एक गैर-निरंतर आईपी उपनाम बनाएं और DNS कार्यान्वयन में रिवर्स DNS लुकअप प्रदान करें।

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

यदि सेवा प्रबंधक कुछ राज्य को इससे अलग रखने को तैयार है
वर्तमान में, हम केवल उन मैपिंग को याद कर सकते हैं जो पहले बनाए गए थे
और उनका सम्मान करने की कोशिश करें।

गुरु, 2 अक्टूबर 2014 पर 8:59 प्रधानमंत्री पर bgrant0607 [email protected] लिखा है:

संभावित पहचान दृष्टिकोण: में एक गैर-निरंतर IP उपनाम बनाएँ
कंटेनर और DNS कार्यान्वयन में रिवर्स DNS लुकअप प्रदान करते हैं।

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

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

पुनः। मैपिंग को याद करते हुए, मैं सहमत हूं -- https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787 देखें।

हालाँकि, मुझे नहीं पता कि यह उस टिप्पणी से कैसे प्रासंगिक है जिसका आपने उत्तर दिया था।

गिटहब और ईमेल मिश्रण नहीं करते हैं। माफ़ करना

गुरु, 2 अक्टूबर 2014 पर 9:39 प्रधानमंत्री पर bgrant0607 [email protected] लिखा है:

पुनः। मैपिंग को याद करते हुए, मैं सहमत हूं -- #260 देखें (टिप्पणी)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

हालाँकि, मुझे नहीं पता कि यह उस टिप्पणी से कैसे प्रासंगिक है जिसका आपने उत्तर दिया था।

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

टिम ने "नाममात्र" का सुझाव दिया, जिससे मैं सहमत हूं कि यह एक बेहतर फिट है।

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

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

----- वास्तविक सन्देश -----

टिम ने "नाममात्र" का सुझाव दिया, जिससे मैं सहमत हूं कि यह एक बेहतर फिट है।

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

मुझे दो समस्याएं दिखाई देती हैं:

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

ऐसा लगता है कि भूमिका असाइनमेंट एक नियंत्रक है जो एपिसर्वर और शेड्यूलर के बीच वर्कफ़्लो चरण के रूप में बैठता है। इसका तात्पर्य किसी प्रकार के परिवर्तन या टेम्प्लेट के ओवरराइड से भी है, जैसे कि भूमिका असाइनमेंट के बिना टेम्प्लेट का कोई मतलब नहीं है।

शार्द नियंत्रक इस समस्या के एक प्रकार की तरह लगता है, बस अधिक जटिल भूमिका असाइनमेंट के लिए।

प्रति उदाहरण एक सेवा के साथ ज़ूकीपर चलाने का उदाहरण: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

तो मुझे पता है कि यह एक लंबा पुराना धागा है, लेकिन यह मेरे निकट और प्रिय विषय को हिट करता है ;-)

बशर्ते सिस्टम गैर-नामांकित "नाममात्र-सेवाओं" के रिकॉर्ड को स्काईडएनएस पर आगे बढ़ा सके और उस सेवा का उपयोग करने वाले पॉड्स में ईएनवी इंजेक्शन के रूप में नामों का उपयोग कर सके, क्या अन्य सीमाएं हैं?

यह ZK के मामले में थोड़ा अजीब लग सकता है जहां कोरम में प्रत्येक तत्व अन्य तत्वों का उपयोग करेगा, जैसे:
zk1 उपयोग करता है: zk2, zk3
zk2 उपयोग करता है: zk1, zk3
zk3 उपयोग करता है: zk1, zk2

लेकिन सिद्धांत रूप में यह सही काम करना चाहिए? बशर्ते हम नाममात्र सेवाओं के लिए रिवर्स रिकॉर्ड जोड़ सकते हैं।

@ bgrant0607 क्या मुझे कुछ याद आ रहा है?

यह थोड़ा अजीब हो जाता है जब अन्य एप्लिकेशन इसके द्वारा प्रदान की जाने वाली समग्र सेवा का उपयोग करना चाहते हैं। (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc आप काम करेगा अगर zk1, zk2, और zk3 सेवाओं थे, कम से कम एक बार मल्टी पोर्ट सेवाओं का समर्थन कर रहे प्रस्ताव क्या।

हाँ, यहाँ एक बदसूरत है, यद्यपि।

एक रनिंग पॉड नहीं जानता कि कौन सी सेवाएं "सामने" हैं। जैसे एक सेवा दी
एक बैकएंड उदाहरण के लिए, सेवा का उपयोग करने के लिए उपयोग किए जाने वाले वीआईपी को किसके द्वारा जाना जाता है
बैकएंड (जब तक कि यह सेवा को जानकर उस जानकारी की तलाश नहीं करता)
नाम)। मामूली सेवा (एन) में, आपके पास एन बैकएंड और एन वीआईपी (और .) होंगे
संभावित रूप से एन डीएनएस नाम या एन-पता नाम), लेकिन बैकएंड अभी भी होगा
अपने स्वयं के वीआईपी नहीं जानते। वे DNS नामों के पूल का निरीक्षण कर सकते हैं, लेकिन
पता नहीं (जांच किए बिना) कौन स्वयं है। इससे आपका ZK
वीआईपी का उपयोग करने के लिए कठिन मामला (अभी भी वीआईपी को देखा जा सकता है)।

विकल्प:

1) 1 सेवा (एन) स्थापित करें और प्रत्येक उदाहरण स्वयं के लिए सभी वीआईपी की जांच करें

2) एन सेवा (1) इंस्टेंस सेट करें और लेबल और cmdline फ़्लैग का उपयोग करें
मैन्युअल रूप से इंडेक्स असाइन करें, प्रत्येक ZK बैकएंड को DNS नाम (प्राथमिकता) से अवगत कराएं
एक दूसरे के ZK बैकएंड

3) लेबल चयनकर्ताओं के लिए DNS करें, ZK प्रतिकृति सेट को DNS नाम असाइन करें,
आशा है कि ग्राहक DNS का सही उपयोग करेंगे

4) कुबेरनेट्स एंडपॉइंट्स को सिंक करने वाले प्रत्येक ZK के साथ kube2zk ब्रिज चलाएं ->
ZK विन्यास

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

रिवर्स डीएनएस के लिए - मुझे यकीन नहीं है कि मैं इसकी भूमिका देखता हूं? मैं उसके खिलाफ नहीं
इसका समर्थन करना (यानी @bketelsen से इसका समर्थन करने के लिए कहें :) लेकिन मुझे नहीं लगता कि
यहां लागू होता है। ट्रैफ़िक कभी भी सेवा IP से "से" नहीं आता है।

टिम

शनिवार, 7 मार्च, 2015 को रात 8:56 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

@timothysc https://github.com/timothysc आप जो प्रस्ताव देते हैं वह काम करेगा अगर
zk1, zk2, और zk3 सेवाएं थीं, कम से कम एक बार बहु-पोर्ट सेवाएं हैं
का समर्थन किया।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) इस प्रस्ताव की तरह लगता है।

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

8 मार्च 2015 को सुबह 11:06 बजे टिम हॉकिन नोटिफिकेशन @github.com ने लिखा:

हाँ, यहाँ एक बदसूरत है, यद्यपि।

एक रनिंग पॉड नहीं जानता कि कौन सी सेवाएं "सामने" हैं। जैसे एक सेवा दी
एक बैकएंड उदाहरण के लिए, सेवा का उपयोग करने के लिए उपयोग किए जाने वाले वीआईपी को किसके द्वारा जाना जाता है
बैकएंड (जब तक कि यह सेवा को जानकर उस जानकारी की तलाश नहीं करता)
नाम)। मामूली सेवा (एन) में, आपके पास एन बैकएंड और एन वीआईपी (और .) होंगे
संभावित रूप से एन डीएनएस नाम या एन-पता नाम), लेकिन बैकएंड अभी भी होगा
अपने स्वयं के वीआईपी नहीं जानते। वे DNS नामों के पूल का निरीक्षण कर सकते हैं, लेकिन
पता नहीं (जांच किए बिना) कौन स्वयं है। इससे आपका ZK
वीआईपी का उपयोग करने के लिए कठिन मामला (अभी भी वीआईपी को देखा जा सकता है)।

विकल्प:

1) 1 सेवा (एन) स्थापित करें और प्रत्येक उदाहरण स्वयं के लिए सभी वीआईपी की जांच करें

2) एन सेवा (1) इंस्टेंस सेट करें और लेबल और cmdline फ़्लैग का उपयोग करें
मैन्युअल रूप से इंडेक्स असाइन करें, प्रत्येक ZK बैकएंड को DNS नाम (प्राथमिकता) से अवगत कराएं
एक दूसरे के ZK बैकएंड

3) लेबल चयनकर्ताओं के लिए DNS करें, ZK प्रतिकृति सेट को DNS नाम असाइन करें,
आशा है कि ग्राहक DNS का सही उपयोग करेंगे

4) कुबेरनेट्स एंडपॉइंट्स को सिंक करने वाले प्रत्येक ZK के साथ kube2zk ब्रिज चलाएं ->
ZK विन्यास

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

रिवर्स डीएनएस के लिए - मुझे यकीन नहीं है कि मैं इसकी भूमिका देखता हूं? मैं उसके खिलाफ नहीं
इसका समर्थन करना (यानी @bketelsen से इसका समर्थन करने के लिए कहें :) लेकिन मुझे नहीं लगता कि
यहां लागू होता है। ट्रैफ़िक कभी भी सेवा IP से "से" नहीं आता है।

टिम

शनिवार, 7 मार्च, 2015 को रात 8:56 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

@timothysc https://github.com/timothysc आप जो प्रस्ताव देते हैं वह काम करेगा अगर
zk1, zk2, और zk3 सेवाएं थीं, कम से कम एक बार बहु-पोर्ट सेवाएं हैं
का समर्थन किया।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

फिर मुझे इस विचार को थोड़ा और लिखने के लिए कुछ समय देना होगा।

रविवार, 8 मार्च, 2015 को सुबह 10:25 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

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

8 मार्च 2015 को पूर्वाह्न 11:06 बजे टिम होकिन नोटिफिकेशन @github.com
लिखा था:

हाँ, यहाँ एक बदसूरत है, यद्यपि।

एक रनिंग पॉड नहीं जानता कि कौन सी सेवाएं "सामने" हैं। जैसे दिया गया
सेवा
एक बैकएंड उदाहरण के लिए, सेवा का उपयोग करने के लिए उपयोग किए जाने वाले वीआईपी ज्ञात नहीं हैं
द्वारा
बैकएंड (जब तक कि यह सेवा को जानकर उस जानकारी की तलाश नहीं करता)
नाम)। मामूली सेवा (एन) में, आपके पास एन बैकएंड और एन वीआईपी होंगे
(तथा
संभावित रूप से एन डीएनएस नाम या एन-पता नाम), लेकिन बैकएंड होगा
फिर भी
अपने स्वयं के वीआईपी नहीं जानते। वे DNS नामों के पूल का निरीक्षण कर सकते हैं, लेकिन
पता नहीं (जांच किए बिना) कौन स्वयं है। इससे आपका ZK
वीआईपी का उपयोग करने के लिए कठिन मामला (अभी भी वीआईपी को देखा जा सकता है)।

विकल्प:

1) 1 सेवा (एन) स्थापित करें और प्रत्येक उदाहरण स्वयं के लिए सभी वीआईपी की जांच करें

2) एन सेवा (1) इंस्टेंस सेट करें और लेबल और cmdline फ़्लैग का उपयोग करें
मैन्युअल रूप से इंडेक्स असाइन करें, प्रत्येक ZK बैकएंड को DNS (प्राथमिकता) से अवगत कराएं
नाम
एक दूसरे के ZK बैकएंड

3) लेबल चयनकर्ताओं के लिए DNS करें, ZK प्रतिकृति सेट को DNS नाम असाइन करें,
आशा है कि ग्राहक DNS का सही उपयोग करेंगे

4) कुबेरनेट्स एंडपॉइंट्स को सिंक करने वाले प्रत्येक ZK के साथ kube2zk ब्रिज चलाएं
->
ZK विन्यास

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

रिवर्स डीएनएस के लिए - मुझे यकीन नहीं है कि मैं इसकी भूमिका देखता हूं? मैं उसके खिलाफ नहीं
इसका समर्थन करना (यानी @bketelsen से इसका समर्थन करने के लिए कहें :) लेकिन मुझे नहीं लगता कि
यहां लागू होता है। ट्रैफ़िक कभी भी सेवा IP से "से" नहीं आता है।

टिम

शनिवार, 7 मार्च, 2015 को रात 8:56 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

@timothysc https://github.com/timothysc जो आप प्रस्तावित करते हैं वह काम करेगा
अगर
zk1, zk2, और zk3 सेवाएं थीं, कम से कम एक बार बहु-पोर्ट सेवाएं हैं
का समर्थन किया।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: रिवर्स DNS, चलो बस अपने हाथों को

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

RC जिसने अपने द्वारा बनाए गए प्रत्येक पॉड के लिए एक अद्वितीय लेबल (सदस्य = #) लागू किया, और N प्रतिकृतियों तक एक अनुक्रम बनाने की कोशिश करता है, और फिर एक हेडलेस सेवा जिसने "सदस्य" लेबल के प्रत्येक मान के लिए A और CNAME नाम बनाया (# .service.namespace.local), जहां रूट उन सभी service.namespace.local -> राउंड रॉबिन -> 1.service.namespace.local, 2.service.namespace.local स्थानीय लगता है।

हम उन अलग-अलग डीएनएस लेबल के लिए सख्त पॉड आईपी का उपयोग कर सकते हैं। हर एक के लिए नकली आईपी बनाना महंगा हो जाता है और कंटेनर किसी को अपना आईपी नहीं भेज पाएगा।

----- वास्तविक सन्देश -----

@thockin re: रिवर्स डीएनएस, चलो बस अपने हाथों को
मांग।

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: रिवर्स DNS - यह रिवर्स DNSing क्या है? का स्रोत-आईपी
सम्बन्ध? इनमें से कोई भी क्यूब में काम नहीं करता है। सेवाओं के माध्यम से कनेक्शन हैं
प्रॉक्सी, इसलिए स्रोत-आईपी पहले स्थान पर काम नहीं करता है (ठीक किया जा सकता है)।

मैं ZK नहीं जानता - क्या आप बता सकते हैं कि वे उल्टा करके क्या हासिल करने की कोशिश कर रहे हैं
डीएनएस? यह एक बहुत ही नाजुक धारणा की तरह लगता है।

सोम, 9 मार्च, 2015 को सुबह 9:05 बजे, टिमोथी सेंट क्लेयर नोटिफिकेशन @github.com
लिखा था:

@thockin https://github.com/thockin re: रिवर्स DNS, लेट्स जस्ट वेव
हमारे हाथों के बारे में और इसे एक आवश्यकता पर विचार करें।

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

मुझे लगता है कि मेरा अनुभव (और शायद टिम का) यह है कि आज क्लस्टर किए गए अधिकांश सॉफ़्टवेयर निम्नलिखित की अपेक्षा करते हैं:

• प्रत्येक नोड की एक स्थिर पहचान होती है
• वह पहचान एक DNS नाम है
• अंतर्निहित पहचान का IP स्थिर होना आवश्यक नहीं है
• नोड अपनी स्थिर पहचान (डीएनएस) या अपने सार्वजनिक आईपी द्वारा अन्य नोड्स में खुद को पहचानने की अपेक्षा करता है
• क्लस्टर किए गए सॉफ़्टवेयर में से कुछ को उम्मीद है कि जिस नोड पर क्लाइंट पहुंचता है उसका आईपी उस आईपी से मेल खाता है जो क्लस्टर में दूसरों को खुद की घोषणा कर सकता है और उस आईपी के लिए पहुंच योग्य हो सकता है।

----- वास्तविक सन्देश -----

@timothysc re: रिवर्स DNS - यह रिवर्स DNSing क्या है? का स्रोत-आईपी
सम्बन्ध? इनमें से कोई भी क्यूब में काम नहीं करता है। सेवाओं के माध्यम से कनेक्शन हैं
प्रॉक्सी, इसलिए स्रोत-आईपी पहले स्थान पर काम नहीं करता है (ठीक किया जा सकता है)।

मैं ZK नहीं जानता - क्या आप बता सकते हैं कि वे उल्टा करके क्या हासिल करने की कोशिश कर रहे हैं
डीएनएस? यह एक बहुत ही नाजुक धारणा की तरह लगता है।

सोम, 9 मार्च, 2015 को सुबह 9:05 बजे, टिमोथी सेंट क्लेयर नोटिफिकेशन @github.com
लिखा था:

@thockin https://github.com/thockin re: रिवर्स DNS, लेट्स जस्ट वेव
हमारे हाथों के बारे में और इसे एक आवश्यकता पर विचार करें।

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

सोम, 9 मार्च, 2015 दोपहर 12:49 बजे, क्लेटन कोलमैन
सूचनाएं @

RC जो अपने द्वारा बनाए गए प्रत्येक पॉड के लिए एक अद्वितीय लेबल (सदस्य = #) लागू करता है, और एक क्रम बनाने की कोशिश करता है
एन प्रतिकृतियां, और फिर एक हेडलेस सेवा जिसने "सदस्य" के प्रत्येक मान के लिए ए और सीएनएन नाम बनाया
लेबल (#.service.namespace.local), जहां रूट उन सभी service.namespace.local -> Round . परोसता है
रॉबिन -> 1.service.namespace.local, 2.service.namespace.local स्थानीय लगता है।

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

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

समस्या यह है कि "मनमाने ढंग से टोकन" को कैसे चालू किया जाए?
कुछ सार्थक।

हम उन अलग-अलग डीएनएस लेबल के लिए सख्त पॉड आईपी का उपयोग कर सकते हैं। हर एक के लिए नकली आईपी बनाना महंगा हो जाता है और कंटेनर किसी को अपना आईपी नहीं भेज पाएगा।

मैंने कोशिश नहीं की है, लेकिन मैं शर्त लगाता हूं कि हम नाममात्र सेवाओं को पूर्ण SNAT कर सकते हैं
और DNAT क्योंकि वे 1:1 हैं। यह स्थिर होने का एक तरीका होगा
प्रति-पॉड आईपी माइग्रेट करने योग्य आईपी के बिना।

----- वास्तविक सन्देश -----

@thockin re: रिवर्स डीएनएस, चलो बस अपने हाथों को
मांग।

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

अपस्ट्रीम तैरना मेरे लिए दूर की बात है - यदि पर्याप्त ऐप्स वास्तव में DNS से ​​अपेक्षा करते हैं
इस तरह से काम करें, हम इसे इस तरह से काम कर सकते हैं।

स्केच:

एक प्रतिकृति नियंत्रक बनाना R एक DNS नाम "$R.rc" बनाता है जो कि है
पॉड आईपी का पूल जो उस आरसी के "अंडर" हैं। प्रत्येक पॉड P को एक DNS नाम मिलता है
"$ पी। $ आर.आरसी"। लेकिन पी क्या है? यह सरल सूचकांक हो सकते हैं, लेकिन इसमें
हमें आंतरिक रूप से जोर से काटा। यह GenerateName जैसे यादृच्छिक तार हो सकते हैं,
लेकिन उन्हें पॉड डेथ/रीस्टार्ट से बचना होगा (और शायद पॉड होस्टनाम चाहिए
मिलान?)।

मंगलवार, 10 मार्च, 2015 को सुबह 7:59 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

मुझे लगता है कि मेरा अनुभव (और शायद टिम का) यह है कि अधिकांश क्लस्टर
सॉफ्टवेयर आज निम्नलिखित की अपेक्षा करता है:

• प्रत्येक नोड की एक स्थिर पहचान होती है
• वह पहचान एक DNS नाम है
• अंतर्निहित पहचान का IP स्थिर होना आवश्यक नहीं है
• नोड खुद को अन्य नोड्स के लिए अपने स्थिर द्वारा पहचानने की अपेक्षा करता है
  पहचान (डीएनएस) या इसका सार्वजनिक आईपी
• कुछ संकुल सॉफ्टवेयर क्लाइंट से नोड के आईपी की अपेक्षा करते हैं
  एक आईपी से मेल खाने के लिए उस तक पहुंचता है, यह खुद को दूसरों को घोषित कर सकता है
  क्लस्टर और उस आईपी के लिए पहुंच योग्य।

----- वास्तविक सन्देश -----

@timothysc re: रिवर्स DNS - यह रिवर्स DNSing क्या है? का स्रोत-आईपी
सम्बन्ध? इनमें से कोई भी क्यूब में काम नहीं करता है। सेवाओं के माध्यम से कनेक्शन हैं
प्रॉक्सी, इसलिए स्रोत-आईपी पहले स्थान पर काम नहीं करता है (ठीक किया जा सकता है)।

मैं ZK नहीं जानता - क्या आप बता सकते हैं कि वे उल्टा करके क्या हासिल करने की कोशिश कर रहे हैं
डीएनएस? यह एक बहुत ही नाजुक धारणा की तरह लगता है।

सोम, 9 मार्च, 2015 को सुबह 9:05 बजे, टिमोथी सेंट क्लेयर <
सूचनाएं@github.com>
लिखा था:

@thockin https://github.com/thockin re: रिवर्स DNS, लेट्स जस्ट वेव
हमारे हाथों के बारे में और इसे एक आवश्यकता पर विचार करें।

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

मुझे पसंद है कि DNS को RC के बजाय नाममात्र की सेवाओं से जोड़ा जा रहा है।

आंतरिक रूप से सरल सूचकांकों के साथ दर्द बिंदु क्या था? पी> 5000?

----- वास्तविक सन्देश -----

अपस्ट्रीम तैरना मेरे लिए दूर की बात है - यदि पर्याप्त ऐप्स वास्तव में DNS से ​​अपेक्षा करते हैं
इस तरह से काम करें, हम इसे इस तरह से काम कर सकते हैं।

स्केच:

एक प्रतिकृति नियंत्रक बनाना R एक DNS नाम "$R.rc" बनाता है जो कि है
पॉड आईपी का पूल जो उस आरसी के "अंडर" हैं। प्रत्येक पॉड P को एक DNS नाम मिलता है
"$ पी। $ आर.आरसी"। लेकिन पी क्या है? यह सरल सूचकांक हो सकते हैं, लेकिन इसमें
हमें आंतरिक रूप से जोर से काटा। यह GenerateName जैसे यादृच्छिक तार हो सकते हैं,
लेकिन उन्हें पॉड डेथ/रीस्टार्ट से बचना होगा (और शायद पॉड होस्टनाम चाहिए
मिलान?)।

मंगलवार, 10 मार्च, 2015 को सुबह 7:59 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

मुझे लगता है कि मेरा अनुभव (और शायद टिम का) यह है कि अधिकांश क्लस्टर
सॉफ्टवेयर आज निम्नलिखित की अपेक्षा करता है:

• प्रत्येक नोड की एक स्थिर पहचान होती है
• वह पहचान एक DNS नाम है
• अंतर्निहित पहचान का IP स्थिर होना आवश्यक नहीं है
• नोड खुद को अन्य नोड्स के लिए अपने स्थिर द्वारा पहचानने की अपेक्षा करता है
  पहचान (डीएनएस) या इसका सार्वजनिक आईपी
• कुछ संकुल सॉफ्टवेयर क्लाइंट से नोड के आईपी की अपेक्षा करते हैं
  एक आईपी से मेल खाने के लिए उस तक पहुंचता है, यह खुद को दूसरों को घोषित कर सकता है
  क्लस्टर और उस आईपी के लिए पहुंच योग्य।

----- वास्तविक सन्देश -----

@timothysc re: रिवर्स DNS - यह रिवर्स DNSing क्या है? का स्रोत-आईपी
सम्बन्ध? इनमें से कोई भी क्यूब में काम नहीं करता है। सेवाओं के माध्यम से कनेक्शन हैं
प्रॉक्सी, इसलिए स्रोत-आईपी पहले स्थान पर काम नहीं करता है (ठीक किया जा सकता है)।

मैं ZK नहीं जानता - क्या आप बता सकते हैं कि वे उल्टा करके क्या हासिल करने की कोशिश कर रहे हैं
डीएनएस? यह एक बहुत ही नाजुक धारणा की तरह लगता है।

सोम, 9 मार्च, 2015 को सुबह 9:05 बजे, टिमोथी सेंट क्लेयर <
सूचनाएं@github.com>
लिखा था:

@thockin https://github.com/thockin re: रिवर्स DNS, लेट्स जस्ट वेव
हमारे हाथों के बारे में और इसे एक आवश्यकता पर विचार करें।

ZK इसके बिना टूट जाएगा, जैसा कि कई अन्य वितरित सिस्टम होंगे।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 से स्पेशल-केसिंग 1:1 वीआईपी। मुझे लगता है कि यह एक सामान्य मामला होने जा रहा है।

मैं अभी भी DNS मैपिंग को गतिशील रूप से बदलने के बारे में चिंतित हूं। मैं एक ऐसा दृष्टिकोण पसंद करूंगा जिसके लिए इसकी आवश्यकता नहीं थी।

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

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

@smarterclayton सरल सूचकांक पैमाने के कारण समस्याग्रस्त नहीं हैं। यह मॉडल के कारण है। कुछ मिनट पहले की मेरी टिप्पणियाँ देखें। सरल सूचकांक जाने का रास्ता हैं यदि उन्हें गतिशील रूप से पॉड और आरसी पहचान से स्वतंत्र रूप से असाइन किया जा सकता है।

यह देखते हुए कि समस्याओं में से एक सिस्टम-उन्मुख धारणाएं हैं, क्या यहां लिनक्स हमारे लिए कुछ कर सकता है? उदाहरण के लिए, क्या हम वीआईपी सेवा के लिए कंटेनर में एक आईपी उपनाम या कुछ ऐसा बना सकते हैं?

हे लोगों,

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

मंगलवार, 10 मार्च 2015 अपराह्न 3:56 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

यह देखते हुए कि समस्याओं में से एक प्रणाली-उन्मुख धारणा है, क्या वहाँ है
यहाँ कुछ Linux हमारे लिए क्या कर सकता है? उदाहरण के लिए, क्या हम एक आईपी बना सकते हैं?
सेवा वीआईपी के लिए कंटेनर में उपनाम या कुछ ऐसे?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

मैं अगले दो दिनों में जेब से बाहर हूँ - अगले हफ्ते यह है।

10 मार्च 2015 को रात 11:33 बजे टिम हॉकिन नोटिफिकेशन @github.com ने लिखा:

हे लोगों,

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

मंगलवार, 10 मार्च 2015 अपराह्न 3:56 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

यह देखते हुए कि समस्याओं में से एक प्रणाली-उन्मुख धारणा है, क्या वहाँ है
यहाँ कुछ Linux हमारे लिए क्या कर सकता है? उदाहरण के लिए, क्या हम एक आईपी बना सकते हैं?
सेवा वीआईपी के लिए कंटेनर में उपनाम या कुछ ऐसे?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

+1 अगले सप्ताह के लिए, शायद एक hangout।

संबंधित विषयों के पॉप अप होने के कारण इस थ्रेड को फिर से पोक कर रहा हूं (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, #6393)।

1. हम अलग-अलग पॉड्स को नेटवर्क पहचान (डीएनएस नाम और/या आईपी पते) कैसे निर्दिष्ट करते हैं, जो सिंगलटन या नाममात्र सेट का हिस्सा हो सकता है?
2. हम पॉड के भीतर कंटेनरों को पहचान कैसे देते हैं?

क्या हमें hangout शेड्यूल करना चाहिए, या साप्ताहिक सामुदायिक hangout का उपयोग करना चाहिए?

इसके अलावा https://github.com/openshift/mongodb/pull/14 जिसे हम प्रोटोटाइप बनाना शुरू कर रहे हैं सदस्यता सेट आरंभीकरण के लिए एक सामान्य पैटर्न क्या होगा (कुछ हम या तो एक कंटेनर, या पुस्तकालय में डाल सकते हैं, या ...)

@danmcp @mfojtik

----- वास्तविक सन्देश -----

संबंधित विषयों के पॉप अप होने के कारण इस धागे को फिर से पोक कर रहा हूं
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393)।

1. हम नेटवर्क पहचान (डीएनएस नाम और/या आईपी पते) को कैसे असाइन करते हैं
   अलग-अलग पॉड, जो सिंगलटन या नाममात्र सेट का हिस्सा हो सकते हैं?
2. हम पॉड के भीतर कंटेनरों को पहचान कैसे देते हैं?

क्या हमें hangout शेड्यूल करना चाहिए, या साप्ताहिक सामुदायिक hangout का उपयोग करना चाहिए?

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, उस पहेली का एक टुकड़ा मास्टर चुनाव #1542 है।

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

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

ध्यान दें कि एक सेवा आईपी को एक कंटेनर में संचार करने की समस्या एक बाहरी आईपी को एक वीएम से संचार करने के समान है: https://cloud.google.com/compute/docs/networking। GCE बाहरी पतों को आंतरिक पतों में/से अनुवादित करता है, और बाहरी पतों को मेटाडेटा सर्वर के माध्यम से संप्रेषित किया जाता है: http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip । एडब्ल्यूएस समान है: http://169.254.169.254/latest/meta-data/public-ipv4 ।

@smarterclayton मैंने मोंगो प्रोटोटाइप पीआर को अपडेट किया: https://github.com/openshift/mongodb/pull/17

यह अब एक शॉट पॉड का उपयोग कर रहा है जो रेप्लिकासेट को इनिशियलाइज़ करता है

पुनः। इस तंत्र को प्रतिकृति/शार्द नियंत्रक से बांधना:

प्रतिकृति नियंत्रकों और/या पॉड ऑब्जेक्ट नामों के लिए DNS नामों की कोशिश करना एक इन-प्लेस अपडेट मॉडल को बाध्य करता है। एक पूरी तरह से अलग तरह के "इन-प्लेस" रोलिंग अपडेट को लागू करने की आवश्यकता होगी, जबकि किसी तरह एक ही नियंत्रक के साथ एक साथ कई टेम्पलेट्स का समर्थन करना। इसका मतलब यह भी होगा कि कुछ प्रकार के अपडेट (नए होस्ट में जाने सहित) करने के लिए, पॉड्स को हटाना होगा और फिर उन्हीं नामों के साथ फिर से बनाना होगा, जो उस दृष्टिकोण की तुलना में डाउनटाइम बढ़ाएगा जहां हम एक नया जोड़ते हैं एक पुराने को दूर ले जाने से पहले फली।

टोकन पूल विचार बहुत अच्छा लगता है। मुझे लगता है कि इसे आरसी से अलग करने की जरूरत है।

इसे एक उच्च-स्तरीय नियंत्रक के साथ जोड़ा जा सकता है, अगर हम एक को जोड़ना चाहते हैं। #1743 और/या #503 पर आगे टिप्पणी करेंगे।

इसे वास्तव में #1743 में प्रस्तावित परिनियोजन नियंत्रक से नहीं जोड़ा जाना चाहिए। यह कई स्वतंत्र रिलीज़ ट्रैक के परिदृश्य के लिए काम नहीं करेगा, न ही उस स्थिति में जहां कोई अपने रोलआउट को एक अलग तंत्र के साथ नियंत्रित करना चाहता था, जैसे कि प्रस्तावित नाम-स्वैपिंग रोलिंग अपडेट। इसी तरह के कारणों से, मैं DNS नामों को पॉड/आरसी/डीसी ऑब्जेक्ट नामों से नहीं जोड़ूंगा।

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

पॉड में कंटेनरों तक पहचान के संचार की सुविधा के लिए (जैसे कि env. var. प्रतिस्थापन के माध्यम से # 2316 में चर्चा की गई), यह पॉड पर एक फ़ील्ड सेट करने के लिए उपयोगी होगा जब भूमिका को उपसंसाधन के माध्यम से असाइन/अनअसाइन किया गया था। यह स्थायित्व के मुद्दे को भी संबोधित कर सकता है।

हमें DNS स्कीमा में नाममात्र के उदाहरणों के लिए स्थान आरक्षित करना चाहिए -- #6666.

मैं खरीद सकता था कि हम पॉड आईपी का उपयोग करने की कोशिश कर सकते हैं और केवल नाममात्र उदाहरणों के लिए डीएनएस को रीमैप कर सकते हैं, प्रति https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406।

साथ ही, मैंने इसे फरवरी में 1.0 मील के पत्थर से हटा दिया (हालांकि रोडमैप.एमडी नहीं), लेकिन #6393 में चर्चा से पता चलता है कि इसे वापस जोड़ा जा सकता है।

@thockin द्वारा
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

हाँ, मानक नाम टूल के माध्यम से "मैं कौन हूँ" वास्तव में आसान बना देगा।

10 अप्रैल 2015 को रात 8:11 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com ने लिखा:

@thockin द्वारा
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

/ सदस्यता लें

मुझे यकीन नहीं है कि मैं अब यहां की आवश्यकताओं को समझता हूं।

सेवाओं और पॉड्स के बीच एक अंतर्निहित एन-टू-एम संबंध है
प्रणाली का डिजाइन। रिवर्स डीएनएस जैसी चीजें आम तौर पर प्राप्त होने की उम्मीद करती हैं
एकल प्रतिक्रिया: पॉड का IP दिया गया है, एक विहित नाम प्राप्त करें। लिखा हुआ हर दस्तावेज़
DNS के बारे में कहते हैं "एकाधिक रिवर्स रिकॉर्ड वापस न करें"। चूंकि एक पॉड हो सकता है
एन सेवाओं में, यह एकल प्रतिक्रिया वास्तव में सेवा से संबंधित नहीं हो सकती है। हम
एक विहित नाम का उल्टा लुकअप कर सकता है और फिर उस पर एक TXT लुकअप कर सकता है
"आप किन सेवाओं के अधीन हैं" के लिए नाम, लेकिन इसे बनाए रखना कठिन है और है
अनिवार्य रूप से वैसे भी एक कस्टम प्रोटोकॉल।

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

इसलिए मुझे यकीन नहीं है कि हम इसके साथ क्या करना चाहते हैं, संख्या सीमित करने से कम
सेवाओं का एक पॉड "अंडर" हो सकता है, जो भयानक लगता है।

व्यवहार संबंधी आवश्यकताएं क्या हैं? हम क्या हासिल करने की कोशिश कर रहे हैं। हम
डीएनएस और हेडलेस सेवाओं के साथ सरल सेट सेमेन्टिक्स प्रदान कर सकता है। यह है कि
पर्याप्त? यदि नहीं, तो क्यों?

हम चरम पर जा सकते हैं और SNAT/DNAT पॉड्स में iptables नियम सेट कर सकते हैं a
सेवा ताकि वे सभी एक दूसरे को वीआईपी पर देखें। जैसे पॉड्स का एक सेट दिया गया
(P1, P2, P3) उन्हें VIP (V1, V2, V3) मिलेगा। P1 से V2 तक का ट्रैफ़िक
V1 आदि से आते प्रतीत होते हैं। ग्राहक V तक पहुंचेंगे{1,2,3}। पर क्या
क्या वह समस्या हल करता है, वास्तव में? यह स्थिर आईपी देता है लेकिन यह नहीं है a
हेडलेस सेवाओं के लिए सामान्य समस्या?

मंगलवार, अप्रैल 21, 2015 दोपहर 2:17 बजे, डेविड ओपेनहाइमर < सूचनाएं @github.com

लिखा था:

/ सदस्यता लें

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

लक्ष्य बहुत ठोस था। वास्तविक क्लस्टर सिस्टम में ऐसे सदस्य होते हैं जिनकी "पहचान" होती है जो नोड विफलताओं की उपस्थिति में निरंतर होने की उम्मीद है। वह पहचान एक स्थायी डिस्क या "नाम" से जुड़ी हो सकती है, लेकिन अन्य सिस्टम की पहचान का नाम बदल नहीं सकता है।

उदाहरण, ज़ूकीपर की प्रति नोड पहचान है। क्लस्टर सदस्यता में वह पहचान स्थिर रहनी चाहिए - दो पॉड हो सकते हैं जो सोचते हैं कि वे होस्ट 1 हैं, लेकिन अगर होस्ट 1 चला जाता है तो होस्ट 435 इसे प्रतिस्थापित नहीं कर सकता है। उस पॉड के लिए एक पुन: उपयोग की जाने वाली लगातार डिस्क हो सकती है जो एक स्थान से दूसरे स्थान पर जाती है, लेकिन जब ऐसा होता है तो पॉड को उस पहचान को परिभाषित करने में सक्षम होना पड़ता है। लेकिन हमें इसे # असाइन करने का एक तरीका चाहिए।

मुझे संदेह है कि जिस तरह से मैं नाममात्र सेवाओं के बारे में सोचता हूं वह हमेशा मौजूदा सॉफ़्टवेयर को छोटी (3/5/7) सदस्यता के साथ सक्षम करने के बारे में है, न कि पूरी तरह से लचीला बहु सौ उपयोग केस। शायद हमें उस उपयोग के मामले को इस चर्चा से अलग कर देना चाहिए।

22 अप्रैल, 2015 को, 1:59 पूर्वाह्न पर, टिम हॉकिन नोटिफिकेशन @github.com ने लिखा:

मुझे यकीन नहीं है कि मैं अब यहां की आवश्यकताओं को समझता हूं।

सेवाओं और पॉड्स के बीच एक अंतर्निहित एन-टू-एम संबंध है
प्रणाली का डिजाइन। रिवर्स डीएनएस जैसी चीजें आम तौर पर प्राप्त होने की उम्मीद करती हैं
एकल प्रतिक्रिया: पॉड का IP दिया गया है, एक विहित नाम प्राप्त करें। लिखा हुआ हर दस्तावेज़
DNS के बारे में कहते हैं "एकाधिक रिवर्स रिकॉर्ड वापस न करें"। चूंकि एक पॉड हो सकता है
एन सेवाओं में, यह एकल प्रतिक्रिया वास्तव में सेवा से संबंधित नहीं हो सकती है। हम
एक विहित नाम का उल्टा लुकअप कर सकता है और फिर उस पर एक TXT लुकअप कर सकता है
"आप किन सेवाओं के अधीन हैं" के लिए नाम, लेकिन इसे बनाए रखना कठिन है और है
अनिवार्य रूप से वैसे भी एक कस्टम प्रोटोकॉल।

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

इसलिए मुझे यकीन नहीं है कि हम इसके साथ क्या करना चाहते हैं, संख्या सीमित करने से कम
सेवाओं का एक पॉड "अंडर" हो सकता है, जो भयानक लगता है।

व्यवहार संबंधी आवश्यकताएं क्या हैं? हम क्या हासिल करने की कोशिश कर रहे हैं। हम
डीएनएस और हेडलेस सेवाओं के साथ सरल सेट सेमेन्टिक्स प्रदान कर सकता है। यह है कि
पर्याप्त? यदि नहीं, तो क्यों?

हम चरम पर जा सकते हैं और SNAT/DNAT पॉड्स में iptables नियम सेट कर सकते हैं a
सेवा ताकि वे सभी एक दूसरे को वीआईपी पर देखें। जैसे पॉड्स का एक सेट दिया गया
(P1, P2, P3) उन्हें VIP (V1, V2, V3) मिलेगा। P1 से V2 तक का ट्रैफ़िक
V1 आदि से आते प्रतीत होते हैं। ग्राहक V तक पहुंचेंगे{1,2,3}। पर क्या
क्या वह समस्या हल करता है, वास्तव में? यह स्थिर आईपी देता है लेकिन यह नहीं है a
हेडलेस सेवाओं के लिए सामान्य समस्या?

मंगलवार, अप्रैल 21, 2015 दोपहर 2:17 बजे, डेविड ओपेनहाइमर < सूचनाएं @github.com

लिखा था:

/ सदस्यता लें

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

किसी प्रकार का नियंत्रक पॉड्स पर कुछ फ़ील्ड को गतिशील रूप से सेट/अनसेट कर सकता है। इसे सिर्फ पॉड और न ही आरसी पहचान के साथ जोड़ा जा सकता है। नेटवर्क पहचान को पॉड या आरसी पहचान से जोड़ना पूरी तरह टूट गया है।

मैं सामान्य या हेडलेस सेवाओं के लिए रिवर्स डीएनएस लुकअप काम करने की कोशिश नहीं करता, और मुझे नहीं लगता कि प्रति पॉड अधिकतम एक नाममात्र सेवा लागू करना अनुचित है - जिसमें अन्य प्रकार की सेवाओं को सीमित करने की आवश्यकता नहीं है .

कई DNS सीमाएं हैं जिन्हें हम लंबे समय तक आगे बढ़ाना चाहते हैं (कैश अमान्यता, लंबे मतदान के लिए समर्थन, आदि)। एकाधिक पीटीआर रिकॉर्ड शायद उस सूची में जोड़ा गया एक और आइटम है।

दूसरा विकल्प यह है कि हम नाममात्र सेवा के प्रत्येक पॉड को एक सेवा आईपी दे सकते हैं और फिर उत्पन्न होने वाली समस्याओं को हल कर सकते हैं।

----- वास्तविक सन्देश -----

किसी प्रकार का नियंत्रक पॉड्स पर कुछ फ़ील्ड को गतिशील रूप से सेट/अनसेट कर सकता है। यह
बस फली और न ही आरसी पहचान के साथ भ्रमित नहीं किया जा सकता है। नेटवर्क पहचान बांधना
पॉड या आरसी पहचान पूरी तरह टूट गई है।

मैं सामान्य या हेडलेस के लिए रिवर्स डीएनएस लुकअप काम करने की कोशिश नहीं करूंगा
सेवाएं, और मुझे नहीं लगता कि अधिकतम एक नाममात्र का थोपना अनुचित है
सेवा प्रति पॉड -- जिसमें अन्य प्रकार की सेवाओं को सीमित करने की आवश्यकता नहीं है
सब।

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

दूसरा विकल्प यह है कि हम प्रत्येक पॉड को एक सेवा आईपी दे सकते हैं
नाममात्र की सेवा और फिर पैदा होने वाली समस्याओं का समाधान।

इनमें से बहुत सी सेवाओं की अपेक्षा है कि उनके पास जो आईपी है (उनका नाम) उस आईपी से जुड़ता है जिससे वे जुड़ते हैं - इसलिए यदि वे 172.1.1.1 को एक्स से जुड़ते हैं, तो एक्स 172.1.1.1 सोचता है। यह सब सॉफ्टवेयर नहीं है, लेकिन इसमें से कुछ है। आमतौर पर यह एक DNS नाम है, जिसका अर्थ है कि आईपी नीचे बदल सकता है।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

मुझे डर है कि यह सब अभी भी मेरे लिए थोड़ा सा सार है।

वास्तविक संकुल तंत्र में ऐसे सदस्य होते हैं जिनकी एक "पहचान" होती है, जो है
नोड विफलताओं की उपस्थिति में निरंतर होने की उम्मीद है। वो पहचान
एक स्थायी डिस्क या "नाम" से जुड़ा हो सकता है, लेकिन नाम the
अन्य प्रणालियों की पहचान नहीं बदल सकती है।

यह कोई आवश्यकता नहीं है। यह इतना अस्पष्ट है कि इसे लागू नहीं किया जा सकता।

उदाहरण, ज़ूकीपर की प्रति नोड पहचान है। वो पहचान रहनी चाहिए
क्लस्टर सदस्यता में स्थिर

एक पहचान क्या है? एक आईपी पता? सॉफ़्टवेयर को एक स्ट्रिंग फ़्लैग पास किया गया?
और एनवी वर? एक zk प्रक्रिया कैसे सीखती है कि उसकी अपनी पहचान क्या है?

किसी प्रकार का नियंत्रक पॉड्स पर कुछ फ़ील्ड को गतिशील रूप से सेट/अनसेट कर सकता है

जो उन पॉड्स को पुनरारंभ करने के लिए ट्रिगर करेगा, और अभी भी जवाब नहीं देता है
पॉड को बताने के लिए कौन से फ़ील्ड, कौन से मूल्य और कौन से तर्क का प्रश्न है?

मैं कमांडलाइन झंडे में एनोटेशन का विस्तार करने जैसा कुछ देख सकता था
(जैसे हम env vars के साथ चर्चा कर रहे हैं) या सिर्फ env vars में। उदाहरण के लिए
नियंत्रक एनोटेशन लिखता है ["zookeeper.com/index"] = 9, हम कनवर्ट करते हैं
$.metatdata["zookeeper.com/index"] ZK_INDEX env में। लेकिन मैं इसे बना रहा हूं
ऊपर, मैंने कोई ठोस मांग नहीं देखी है जो कहती है कि वास्तव में ज़ूकीपर क्या है (या
जो कुछ भी) की जरूरत है।

मुझे नहीं लगता कि अधिकतम एक नाममात्र की सेवा लागू करना अनुचित है
प्रति पॉड

मुझे लगता है कि इस तरह के प्रतिबंधों को लागू करना मुश्किल होगा। सिस्टम तो है
शिथिल युग्मित और async कि इन सीमाओं को थोपना इससे भी बुरा हो सकता है
सिर्फ समस्याओं का समाधान।

हम नाममात्र सेवा के प्रत्येक पॉड को एक सेवा आईपी दे सकते हैं

यहीं से हमने शुरुआत की थी, लेकिन...

इनमें से बहुत सी सेवाओं की अपेक्षा है कि उनके पास जो आईपी है (उनका नाम)
वे जिस आईपी से जुड़ते हैं, उसका समाधान करता है - इसलिए यदि वे 172.1.1.1 को एक्स से जुड़ते हैं,
तब X सोचता है कि यह 172.1.1.1 है।

सेवा आईपी इसे संतुष्ट नहीं करते हैं, जब तक कि हम कुछ और गहराई से नहीं करते जैसे
मैंने SNAT/DNAT के साथ उल्लेख किया है। और यहां तक ​​कि इसमें वास्तविक कमियां हैं।

मैं गर्दन में दर्द बनने की कोशिश नहीं कर रहा हूं, बस इतना है कि हमारे पास बहुत कम है
रनअप में 1.0 का समय, और यहाँ ऐसा कुछ भी नहीं है जो पर्याप्त रूप से स्पष्ट हो
यहां तक ​​कि प्रूफ-ऑफ-कॉन्सेप्ट, ठीक से लागू तो बहुत कम।

मैं ठीक वही बताने की कोशिश कर रहा हूं जो हम अनुभव करना चाहते हैं ताकि मैं देख सकूं
हम क्या लागू कर सकते हैं। DNS के बार-बार संदर्भों को देखते हुए, मैं पकड़ रहा हूँ
जब तक मुझे पता नहीं चल जाता कि यहां क्या हो रहा है, तब तक DNS रीवर्क बंद करें।

बुधवार, 22 अप्रैल, 2015 को सुबह 10:12 बजे, क्लेटन कोलमैन नोटिफिकेशन @github.com
लिखा था:

----- वास्तविक सन्देश -----

किसी प्रकार का नियंत्रक कुछ फ़ील्ड को गतिशील रूप से सेट/अनसेट कर सकता है
फली यह
बस फली और न ही आरसी पहचान के साथ भ्रमित नहीं किया जा सकता है। नेटवर्क बांधना
पहचान
पॉड या आरसी पहचान पूरी तरह टूट गई है।

मैं सामान्य या हेडलेस के लिए रिवर्स डीएनएस लुकअप काम करने की कोशिश नहीं करूंगा
सेवाएं, और मुझे नहीं लगता कि अधिकतम एक को थोपना अनुचित है
नाममात्र
सेवा प्रति पॉड -- जिसमें अन्य प्रकार की सेवाओं को सीमित करने की आवश्यकता नहीं है
सब।

कई DNS सीमाएँ हैं जिन्हें हम लंबे समय तक आगे बढ़ाना चाहेंगे
दौड़ना
(कैश अमान्यकरण, लंबे मतदान के लिए समर्थन, आदि)। एकाधिक पीटीआर
अभिलेख
शायद उस सूची में सिर्फ एक और आइटम जोड़ा गया है।

दूसरा विकल्प यह है कि हम प्रत्येक पॉड को एक सेवा आईपी दे सकते हैं
नाममात्र की सेवा और फिर पैदा होने वाली समस्याओं का समाधान।

इनमें से बहुत सी सेवाएं उम्मीद करती हैं कि उनके पास जो आईपी है (उनका नाम) हल हो जाएगा
वे जिस IP से कनेक्ट होते हैं - इसलिए यदि वे 172.1.1.1 को X से कनेक्ट होते हैं, तो X
172.1.1.1 सोचता है। यह सब सॉफ्टवेयर नहीं है, लेकिन इसमें से कुछ है। आमतौर पर यह
एक DNS नाम हालांकि, जिसका अर्थ है कि आईपी नीचे बदल सकता है।

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

अधिकांश मल्टी-पोर्ट उदाहरण क्लस्टर सिस्टम हैं। उदाहरण के लिए:
ZK : कॉन्फ़िगरेशन फ़ाइल में हल करने योग्य होस्टनाम या IP पता, साथ ही फ़ाइल में एक "id" (यानी, एक अनुक्रमणिका: 1, 2, 3, ...)

हमें कुछ डीबी को भी देखना चाहिए।

हम जो कुछ भी करते हैं वह हर चीज के लिए काम नहीं करेगा। हमें बस मीठी जगह खोजने की जरूरत है।

----- वास्तविक सन्देश -----

मुझे डर है कि यह सब अभी भी मेरे लिए थोड़ा सा सार है।

वास्तविक संकुल तंत्र में ऐसे सदस्य होते हैं जिनकी एक "पहचान" होती है, जो है
नोड विफलताओं की उपस्थिति में निरंतर होने की उम्मीद है। वो पहचान
एक स्थायी डिस्क या "नाम" से जुड़ा हो सकता है, लेकिन नाम the
अन्य प्रणालियों की पहचान नहीं बदल सकती है।

यह कोई आवश्यकता नहीं है। यह इतना अस्पष्ट है कि इसे लागू नहीं किया जा सकता।

उदाहरण, ज़ूकीपर की प्रति नोड पहचान है। वो पहचान रहनी चाहिए
क्लस्टर सदस्यता में स्थिर

एक पहचान क्या है? एक आईपी पता? सॉफ़्टवेयर को एक स्ट्रिंग फ़्लैग पास किया गया?
और एनवी वर? एक zk प्रक्रिया कैसे सीखती है कि उसकी अपनी पहचान क्या है?

किसी प्रकार का नियंत्रक पॉड्स पर कुछ फ़ील्ड को गतिशील रूप से सेट/अनसेट कर सकता है

जो उन पॉड्स को पुनरारंभ करने के लिए ट्रिगर करेगा, और अभी भी जवाब नहीं देता है
पॉड को बताने के लिए कौन से फ़ील्ड, कौन से मूल्य और कौन से तर्क का प्रश्न है?

मैं कमांडलाइन झंडे में एनोटेशन का विस्तार करने जैसा कुछ देख सकता था
(जैसे हम env vars के साथ चर्चा कर रहे हैं) या सिर्फ env vars में। उदाहरण के लिए
नियंत्रक एनोटेशन लिखता है ["zookeeper.com/index"] = 9, हम कनवर्ट करते हैं
$.metatdata["zookeeper.com/index"] ZK_INDEX env में। लेकिन मैं इसे बना रहा हूं
ऊपर, मैंने कोई ठोस मांग नहीं देखी है जो कहती है कि वास्तव में ज़ूकीपर क्या है (या
जो कुछ भी) की जरूरत है।

मुझे नहीं लगता कि अधिकतम एक नाममात्र की सेवा लागू करना अनुचित है
प्रति पॉड

मुझे लगता है कि इस तरह के प्रतिबंधों को लागू करना मुश्किल होगा। सिस्टम तो है
शिथिल युग्मित और async कि इन सीमाओं को थोपना इससे भी बुरा हो सकता है
सिर्फ समस्याओं का समाधान।

हम नाममात्र सेवा के प्रत्येक पॉड को एक सेवा आईपी दे सकते हैं

यहीं से हमने शुरुआत की थी, लेकिन...

इनमें से बहुत सी सेवाओं की अपेक्षा है कि उनके पास जो आईपी है (उनका नाम)
वे जिस आईपी से जुड़ते हैं, उसका समाधान करता है - इसलिए यदि वे 172.1.1.1 को एक्स से जुड़ते हैं,
तब X सोचता है कि यह 172.1.1.1 है।

सेवा आईपी इसे संतुष्ट नहीं करते हैं, जब तक कि हम कुछ और गहराई से नहीं करते जैसे
मैंने SNAT/DNAT के साथ उल्लेख किया है। और यहां तक ​​कि इसमें वास्तविक कमियां हैं।

मैं गर्दन में दर्द बनने की कोशिश नहीं कर रहा हूं, बस इतना है कि हमारे पास बहुत कम है
रनअप में 1.0 का समय, और यहाँ ऐसा कुछ भी नहीं है जो पर्याप्त रूप से स्पष्ट हो
यहां तक ​​कि प्रूफ-ऑफ-कॉन्सेप्ट, ठीक से लागू तो बहुत कम।

मैं ठीक वही बताने की कोशिश कर रहा हूं जो हम अनुभव करना चाहते हैं ताकि मैं देख सकूं
हम क्या लागू कर सकते हैं। DNS के बार-बार संदर्भों को देखते हुए, मैं पकड़ रहा हूँ
जब तक मुझे पता नहीं चल जाता कि यहां क्या हो रहा है, तब तक DNS रीवर्क बंद करें।

मुझे लगता है कि यह बुद्धिमानी है, हमें ज्ञात उदाहरणों के एक सेट को हल करने के लिए विशेष रूप से समय देना चाहिए। हमारे पास 3 हैं जो हम ठोस उदाहरणों (मोंगोडीबी प्रतिकृति सेट, ज़ूकीपर, माइस्क्ल मास्टर/स्लेव) के साथ-साथ क्यूब/उदाहरणों में मौजूदा उदाहरणों के लिए लाभ उठा सकते हैं। शायद वस्तुओं को हैश करने के लिए एक कार्य सत्र, असफल समस्याओं पर सीमाएं निर्धारित करें, जो बचा है उसे पहचानें।

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

बैच जॉब की कुछ अलग आवश्यकताएं होती हैं, इसलिए मैं इसे अलग रखना चाहूंगा।

ज़ूकीपर का उदाहरण: https://github.com/openshift/origin/pull/1965

नाममात्र की सेवा के उदाहरण की जरूरत है https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

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

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

.. और हम कर रहे हैं।

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

प्रत्येक शार्क के लिए एक अद्वितीय सेवा/पोर्ट बनाकर और प्रतिकृतियों के साथ एक प्रतिकृति नियंत्रक चलाकर इसे अभी नकली किया जा सकता है: 1 लेकिन इस तरह "हाथ से" बड़ी संख्या में शार्क को प्रबंधित करना थोड़ा बेकार है।

कुबेरनेट्स में इसे लागू करने का एक प्राकृतिक तरीका हो सकता है:

• पॉड्स को अपने स्वयं के शार्ड इंडेक्स (पूर्णांक) और शार्क की कुल संख्या देने के लिए अतिरिक्त पर्यावरण चर मिलते हैं (या शायद इसे डाउनवर्ड एपीआई के माध्यम से संवाद करते हैं?)
• प्रतिकृति नियंत्रकों को "शार्ड्स" गिनती मिलती है (डिफ़ॉल्ट: 1), और "प्रतिकृति" का अर्थ "प्रत्येक शार्क के भीतर प्रतिकृतियां" (डिफ़ॉल्ट: 1) है। प्रतिकृतियों के सेट को सिकोड़ते समय, उन्हें अंत से मारना चाहिए (शार्क इंडेक्स को सन्निहित रखने के लिए)। नोट बदलने के लिए "शार्ड्स" को अपने "कुल शार्क" env var को अपडेट करने के लिए नियंत्रित पॉड्स के रोलिंग पुनरारंभ की आवश्यकता होगी (अच्छा, आप इसे तुरंत नहीं चाहते हैं)।
• सेवाओं को एक समान "शार्क" गणना मिलती है जो नियमित चयनकर्ता के साथ-साथ एक अंतर्निहित "शार्क इंडेक्स" चयनकर्ता के लिए बंदरगाहों की एक संगत श्रेणी को मानचित्रित करती है।
• पॉड SERVICE_PORT (या कुछ नए env var?) + शार्प इंडेक्स ऑफ़सेट का उपयोग करके अन्य शार्क ढूंढ सकते हैं।

ध्यान दें कि जब शार्प = 1 वर्तमान व्यवहार में इनायत से घटता है।

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

जैसा कि मैंने पहले उल्लेख किया है कि यह स्थिर कार्य असाइनमेंट के साथ बैच नौकरियों का समर्थन करने के लिए हमें क्या करने की आवश्यकता है (जिसे मैं यहां "टाइप 1" कह रहा था: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment से निकटता से संबंधित है। -97622142 )

यदि हमने RC (या कुछ नया जोड़ा) को बदल दिया है, तो हमें अन्य सुविधाओं को संरेखित करने की आवश्यकता है, विशेष रूप से परिनियोजन कैसे फिट बैठता है:

मैं इसके लिए रोलिंग अपडेट कैसे करूं:

1. एक नियमित आरसी
2. एक PerNodeController
3. एक कटा हुआ आरसी
4. एक बैच की नौकरी?

हम या तो तैनाती को लागू करना चाहते हैं जब तक कि हमारे पास उनमें से प्रत्येक के लिए एक स्ट्रॉ मैन न हो, क्योंकि मेरा मानना ​​​​है कि एक तैनाती जो केवल एक साधारण आरसी के खिलाफ काम करती है, में कुछ समस्याएं होती हैं।

----- वास्तविक सन्देश -----

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

जैसा कि मैंने पहले उल्लेख किया है कि यह इस बात से निकटता से संबंधित है कि हमें क्या करने की आवश्यकता है
स्थिर कार्य असाइनमेंट के साथ बैच नौकरियों का समर्थन करें (जिसे मैं "टाइप 1" कह रहा था
यहां:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

हमने 1.0 के लिए इसे (और स्वचालित रूप से उत्पन्न लगातार वॉल्यूम दावे) को प्राथमिकता नहीं देना चुना है क्योंकि कई वर्कअराउंड हैं, जैसे कि एक सेवा बनाना, आरसी, और प्रति उदाहरण लगातार वॉल्यूम दावा।

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

प्रति-नोड/डिमन नियंत्रक: अच्छा बिंदु। सघन रूप से निर्दिष्ट सूचकांक उस मामले के लिए खराब मॉडल हैं। उदाहरण के लिए, जब कोई नोड स्थायी रूप से चला जाता है, तो आप क्या करते हैं? सूचकांक विरल हो जाते हैं। मेरा सुझाव है कि हम इसका समर्थन नहीं करते हैं।

बैच नौकरियां: जैसा कि #1624 में चर्चा की गई है, हम वर्तमान में चल रहे पॉड्स के बजाय पूर्णता के आधार पर इंडेक्स असाइन करना चाहते हैं।

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

असाइनमेंट को एकल प्रतिकृति नियंत्रक द्वारा संचालित नहीं किया जा सकता है। यह बस काम नहीं करता है। प्रतिकृति नियंत्रक टिकाऊ इकाइयां नहीं हैं, और हम उम्मीद करते हैं कि कैनरी, रोलिंग अपडेट, एकाधिक रिलीज ट्रैक, एकाधिक क्लस्टर इत्यादि के लिए प्रति सेवा एकाधिक आरसी होंगे। यहां तक ​​​​कि प्रस्तावित परिनियोजन ऑब्जेक्ट (# 1743) में भी सही दायरा नहीं है .

असाइनमेंट के लिए 3 विकल्प हैं:

1. एक विशेष प्रकार की सेवा के साथ सहयोगी असाइनमेंट। सेवा का बिल्कुल सही दायरा है। (हमें अंततः क्षेत्रीय सेवाओं की भी आवश्यकता होगी।) यह नियमित सेवाओं और हेडलेस सेवाओं के बीच एक संकर की तरह होगा। जब मैंने मूल रूप से इस तंत्र का प्रस्ताव रखा था तो मैंने यही कल्पना की थी। असाइनमेंट को एंडपॉइंट में रिकॉर्ड किया जाएगा। एंडपॉइंट्स और/या हेडलेस-जैसे डीएनएस सभी साथियों की गणना करने के स्पष्ट तरीके होंगे।
2. एक नई प्रकार की वस्तु बनाएं जो सेवा के समान हो, लेकिन केवल नाममात्र की सेवाओं के लिए। असाइनमेंट को रिकॉर्ड करने के लिए हमें एक नई वस्तु की भी आवश्यकता होगी। यह हमारी एपीआई सतह का अनावश्यक रूप से विस्तार करेगा, आईएमओ।
3. "धक्का" के बजाय "खींचें"। नोड बाधाओं (चयनकर्ता) या प्रस्तावित एंटी-एफ़िनिटी तंत्र (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529) में से एक के साथ भी, पॉड्स को एक स्पष्ट नियंत्रक के बिना होस्ट करने के लिए शेड्यूल किया गया है। यह भी सेवा वीआईपी असाइनमेंट के समान है। हम नाममात्र की सेवाओं के लिए भी कुछ ऐसा ही कर सकते हैं। एक पॉड (या पॉड टेम्प्लेट) उस इंडेक्स पूल को निर्दिष्ट करेगा जिससे वह एक इंडेक्स असाइन करना चाहता था। सामान्य सेवाओं के विपरीत, हम यह उम्मीद नहीं करते हैं कि पॉड्स को अलग-अलग पूल से कई इंडेक्स असाइन करने की आवश्यकता होगी। असाइनमेंट पॉड स्पेक में रिकॉर्ड किया जाएगा।
4. पेशेवरों: उपयोगकर्ताओं के लिए सरल। किसी अन्य वस्तु की आवश्यकता नहीं है। उपयोगकर्ताओं द्वारा असाइनमेंट की अनुमति देता है।
5. विपक्ष: अन्य प्रकार की सेवाओं से अलग।

पीवीसी असाइनमेंट आदर्श रूप से उसी मॉडल का उपयोग करेगा।

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

अन्य बातें:

1. साथियों को सूचकांक/पहचान कैसे संप्रेषित करें। DNS स्पष्ट उत्तर है।
2. पॉड में कंटेनरों को इंडेक्स/पहचान कैसे संप्रेषित करें। पर्यावरण चर, रिवर्स DNS, ... असाइन किया गया इंडेक्स गतिशील रूप से नहीं बदलने वाला है, हालांकि पॉड के मौजूद रहने पर DNS बाइंडिंग को बदला जा सकता है। मैं एक ऐसा तंत्र चुनना चाहता हूं जो अनुप्रयोगों को पहले से ही अन्य वातावरण में काम करने की उम्मीद है, और व्यापक डाउनवर्ड एपीआई चर्चा (# 386) के साथ, मैं कुछ अनुप्रयोगों को कुबेरनेट्स-विशिष्ट पर्यावरण चर के लिए नहीं करना चाहता, लेकिन नया EnvVarSource और env var प्रतिस्थापन (#7936) इससे बचने में मदद करेगा।

आपने जो कुछ कहा, मैं उससे असहमत हूं, लेकिन आइए 1.0 के बाद तक इस चर्चा को जारी रखने की प्रतीक्षा करें।

एक प्रश्न पूछने के लिए इस पुराने सूत्र को पुनर्जीवित करना। क्या प्रतिकृति नियंत्रक नामकरण नीति में कोई रुचि है? विशेष रूप से नाममात्र नामकरण जैसा कि ऊपर चर्चा की गई है, जहां इस प्रतिकृति नियंत्रक द्वारा नियंत्रित सभी पॉड्स में प्रत्यय संख्या होगी, जैसे कि 0001, 0002 ....

एक उदाहरण उपयोग मामला एक nginx लोड बैलेंसर है जो डोमेन नामों द्वारा पॉड्स के इन सेटों की ओर इशारा करता है। इसलिए जैसे ही पॉड आते हैं और जाते हैं, डोमेन नाम हमेशा xxx-0001 से xxx-000N तक तय होने की उम्मीद है।

@ravigadde कृपया इस मुद्दे पर मेरी पिछली टिप्पणी पढ़ें: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

एक RabbitMQ कंटेनर सेटअप करने का प्रयास करते समय इस समस्या में भाग गया। खरगोश की दृढ़ता मेजबाननाम पर निर्भर करती है, इसलिए परिवर्तनीय होस्टनाम होने का मतलब है कि आप कंटेनर पुनरारंभ पर मैनेशिया डेटाबेस खो देते हैं।

छवि कॉन्फ़िगरेशन (होस्टनाम सीधे और खरगोश), ईएनवी चर, और डाउनवर्ड एपीआई के साथ उपाय करने का प्रयास किया। समस्या को हल करने के लिए कोई भी प्राप्त करने में सक्षम नहीं था - खरगोश अभी भी उत्पन्न पॉड नाम उठाता है। @mikedanese के सुझाव के अनुसार प्रतिकृति नियंत्रक का उपयोग करने से स्विच करके अस्थायी रूप से हल करना।

अगर मैं सही ढंग से समझूं, तो खरगोश-खरगोश उदाहरण में

RabbitMQ सिस्टम के वर्तमान होस्टनाम का उपयोग करके डेटाबेस निर्देशिका को नाम देता है। यदि होस्टनाम बदलता है, तो एक नया खाली डेटाबेस बनाया जाता है। डेटा हानि से बचने के लिए एक निश्चित और हल करने योग्य होस्टनाम सेट करना महत्वपूर्ण है।

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

या स्टार्टअप पर होस्टनाम डीआईआर को स्थिर स्थान पर सिमलिंक करें

11 जुलाई 2015 को शाम 5:26 बजे, माइक डैनीस नोटिफिकेशन @github.com ने लिखा:

अगर मैं सही ढंग से समझूं, तो Rabbitmq पॉड (प्रतिकृति के साथ बनाया गया
नियंत्रक) क्लेरी-खरगोश में
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
उदाहरण पॉड विफलता पर डेटा खो देगा, भले ही डेटा a . पर संग्रहीत हो
लगातार डिस्क। Rabbitmq दस्तावेज़ से:

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

इसके लिए अभी कोई अच्छा समाधान नहीं है, लेकिन आप एक पॉड बना सकते हैं (नहीं .)
एक आरसी के लिए बाध्य) एक माइग्रेटेबल लगातार डिस्क के साथ, चेतावनी पॉड होने के कारण
कुछ विफलताओं के मामलों में मैन्युअल रूप से पुनर्निर्धारित करने की आवश्यकता होगी। वह है
होस्टनाम को स्थिर रखने का एकमात्र तरीका मैं सोच सकता हूं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

यह एक उदाहरण है कि क्यों होस्टनाम पॉड नाम से नहीं लिया जाना चाहिए -- #4825

इसे थोड़ा सा किक देने के लिए:

कई मूलभूत समस्याएं हैं जिन्हें हल करने की आवश्यकता है:

1. कुछ घटकों को प्रति पॉड एक विशिष्ट पहचान की आवश्यकता होती है जो डिस्क पर उनके भंडारण से जुड़ी होती है
   
   
   
   1. एक और शिकन के रूप में, उनमें से कुछ (कुछ मामलों में ज़ूकीपर) को हल करने योग्य और मेल खाने के लिए होस्टनाम की आवश्यकता होती है
   
   
2. कुछ घटक जिन्हें स्केल आउट किया गया है उन्हें लगातार भंडारण की आवश्यकता होती है जो प्रति पॉड अलग होती है (पॉड्स पीवीसी को इंगित करते हैं जो प्रति पॉड भिन्न होते हैं, पहचान से बंधे होते हैं)
   
   
   
   1. कभी-कभी उन संस्करणों को बड़े पैमाने पर मांग पर बनाया जाना चाहिए
   
   
   2. कभी-कभी उन वॉल्यूम को पूल से पुन: उपयोग किया जाना चाहिए और फिर से नहीं बनाया जाना चाहिए
   
   
3. कुछ घटक हजारों उदाहरणों तक बढ़ सकते हैं, जहां व्यक्तिगत आवंटित पहचान को ट्रैक करना अव्यावहारिक हो जाता है
   
   
   
   1. नाममात्र के लिए अधिकांश उपयोग शायद पॉड के 2-7 उदाहरणों के बीच होंगे (सबसे वर्तमान स्केलेबल डीबी, सबसे तेज मल्टी-मास्टर सेटअप)
   
   
4. कुछ घटक अपने स्वयं के मास्टर चुनाव को लागू नहीं करना चाहते हैं, लेकिन मंच को किसी एक पहचान को मनमाना बनाकर प्रबंधित करने दें (पहचान 1 मास्टर बन जाती है)
5. जब हम इन समस्याओं को हल करते हैं, तब भी उपयोगकर्ताओं को पॉड्स (तैनाती के माध्यम से) में परिवर्तन करने और यह सुनिश्चित करने की आवश्यकता होगी कि कोई भी पहचान या तो संरक्षित है या फिर से आवंटित की गई है।

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

मैं 1a, 1b और 2a से सहमत हूं। 2 बी एक अलग समस्या की तरह लगता है, हालांकि शायद समाधान उसी पैटर्न का पुन: उपयोग कर सकता है।

मुझे लगता है कि स्केल (3) मुख्य रूप से सुझाव देता है कि एक सेवा और आरसी प्रति उदाहरण का हमारा समाधान पर्याप्त नहीं है, हालांकि मैं क्लाउड-नेटिव बनाम नॉट के बीच के अंतर से सहमत हूं।

मास्टर चुनाव (4) को अलग से संबोधित किया जा सकता है।

(5) से भी सहमत हैं।

मुझे लगता है कि इस बिंदु पर अधिकांश डिज़ाइन आवश्यकताएं स्पष्ट हैं।

शेष डिजाइन प्रश्न:

I. वीआईपी आवंटित करें या आईपी को बदलने की अनुमति दें? इसके साथ घनिष्ठ रूप से जुड़ा हुआ है कि क्या कंटेनरों को लिनक्स के माध्यम से अपने स्वयं के आईपी खोजने में सक्षम होना चाहिए या नहीं, क्योंकि वीआईपी वर्तमान में सिस्टम के माध्यम से खोजने योग्य नहीं हैं। मुझे लगता है कि उन्हें अपने आईपी खोजने में सक्षम होने की आवश्यकता है, लेकिन नीचे की ओर एपीआई का उपयोग कर सकते हैं, जैसे पॉड आईपी (# 12595)। आईपी ​​को बदलने की अनुमति देना (पॉड आईपी का उपयोग करने के कारण) डीएनएस टीटीएल और कैशिंग "बग" के कारण आईपी के परिवर्तन की दर की एक सीमा का तात्पर्य है। कुछ बिंदु पर, हम पॉड आईपी को माइग्रेट करने योग्य बनाना चाहते हैं, हालांकि (#3949), इसलिए आईपी बदलना हमेशा के लिए नहीं होगा।

द्वितीय. पुश (पॉड्स तक) बनाम पुल (पॉड्स से)। सेवाएँ और RC जानबूझकर पॉड्स से शिथिल रूप से जुड़े हुए हैं, और इसलिए दोनों "पुश" मॉडल का उपयोग करते हैं। नाममात्र सेवाएं अधिक आंतरिक रूप से पॉड पहचान से जुड़ी होंगी (हालांकि स्थायी रूप से नहीं - पॉड्स को बदला जा सकता है)। नतीजतन, मुझे पुश मॉडल के लिए कम प्रेरणा दिखाई देती है। आवंटन के अन्य मामले, जैसे शेड्यूलिंग, और esp। अनन्य बाध्यकारी, जैसे लगातार वॉल्यूम लगातार वॉल्यूम के लिए दावा करता है, एक अनुरोध/एक मॉडल, उर्फ ​​​​"पुल" का उपयोग करें। वर्तमान में यही वह मॉडल है जिसका मैं नाममात्र की सेवाओं के पक्ष में हूं।

(I) पर किसी की राय है?

मास्टर चुनाव #1542 है, और एचए कार्यान्वयन के हिस्से के रूप में चर्चा की जा रही है (उदाहरण के लिए, #12884)।

मुझे नहीं पता कि पुश एंड पुल से आपका क्या मतलब है।

मैंने इस मुद्दे के अधिकांश भाग को फिर से पढ़ लिया है, और मुझे विश्वास है कि एक भी नहीं है
उपाय। हमें पुल बनाने के लिए सुविधाओं के एक परिवार की आवश्यकता होगी
इस प्रकार के ऐप्स।

मैं स्वयंसिद्ध से शुरू कर रहा हूं कि एक बार एक पॉड चल रहा है तो आप वास्तव में नहीं कर सकते हैं
एक रनिंग पॉड बदलें। इसके कुछ अपवाद हैं (जैसे वर्चुअल
फाइल सिस्टम सामग्री) लेकिन चीजें जो मायने रखती हैं (env vars, IP,
hostname) आप जो कुछ भी शुरू करते हैं उसके साथ फंस जाते हैं।

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

मैं बस एक धारा-चेतना करने जा रहा हूं और देखता हूं कि क्या बदबू नहीं आती है।

आइडिया 1: थिंगपूल और पैच।

एक नया एपीआई ऑब्जेक्ट या ऐसा कुछ परिभाषित करें जो आपको के पूल को परिभाषित करने देता है
चीज़ें। एक चीज़ क्या है? ए थिंग एक स्ट्रिंग है (या शायद एक JSON ब्लॉब) कि
एक प्रगणित प्रकार है। आप चीज़ों और उन चीज़ों का एक पूल बना सकते हैं
आपके उपयोग करने के लिए हैं। चीज़ों के प्रकारों में VUIDs (होस्टनाम), स्ट्रिंग्स, VIPs शामिल हैं।

एक नया एपीआई निर्माण परिभाषित करें जिसे संचालन बनाने के लिए पारित किया जा सकता है - a
पैच एक पैच उस वस्तु को पैच करने का निर्देश है जिसे किया जा रहा है
बनाया था। पैच विकल्पों में से एक "थिंगपूल से आवंटित" है।

इन्हें एक साथ रखने के लिए:

थिंगपूल को परिभाषित करें {meatadata.name: my-quorum-hostnames, टाइप करें: VUID,
स्वत: उत्पन्न: 5, } // 5 मान्य VUIDs का एक पूल बनाता है

RC को परिभाषित करें {प्रतिकृति: 5 ...}

RC के क्रिएट (POST) में भी एक पैच भेजें: { क्या:
"podTemplate.spec.containers[*].metadata.VUID", पूल: "my-quorum-hostnames"
}

POST ऑपरेशन पैच को RC पर लागू करेगा - एक VUID आवंटित करना
थिंगपूल से प्रति कंटेनर। जब भी कोई पॉड मारा जाता है और फिर से बनाया जाता है,
VUID को पूल में वापस कर दिया जाता है और अगले पॉड को शुरू करने के लिए इसे मिल जाएगा।

आप इसका उपयोग स्ट्रिंग्स ("0" से "99") और स्टिक का एक पूल बनाने के लिए कर सकते हैं
एक env var में। आप इसका उपयोग वीआईपी के पूल को आवंटित करने के लिए कर सकते हैं और
फिर उन वीआईपी को पॉड्स को असाइन करें (एक नई सुविधा होगी - टिकाऊ पॉड
आईपी ​​- सुनिश्चित नहीं है कि यह कैसे पैमाने पर होगा :) आप का एक पूल उत्पन्न कर सकते हैं
PersistentVolumeClaim नाम और प्रत्येक पॉड द्वारा उपयोग किए जाने वाले दावे की मात्रा को पैच करें।

यह विचार कई मायनों में अपूर्ण है, लेकिन मुझे लगता है कि यह सबसे अच्छी तरह से पकड़ लेता है
पॉड्स के एक सेट को एकमुश्त परिभाषित किए बिना पॉड्स के एक सेट का विचार।

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

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

मंगलवार, अगस्त 18, 2015 को शाम 7:28 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

मैं 1a, 1b और 2a से सहमत हूं। 2बी एक अलग समस्या की तरह लगता है, हालांकि
शायद समाधान उसी पैटर्न का पुन: उपयोग कर सकता है।

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

मास्टर चुनाव (4) को अलग से संबोधित किया जा सकता है।

(5) से भी सहमत हैं।

मुझे लगता है कि इस बिंदु पर अधिकांश डिज़ाइन आवश्यकताएं स्पष्ट हैं।

शेष डिजाइन प्रश्न:

I. वीआईपी आवंटित करें या आईपी को बदलने की अनुमति दें? इससे घनिष्ठ रूप से जुड़ा हुआ है कि क्या
कंटेनरों को लिनक्स के माध्यम से अपने स्वयं के आईपी खोजने में सक्षम होना चाहिए या नहीं,
चूंकि वीआईपी वर्तमान में सिस्टम के माध्यम से खोजने योग्य नहीं हैं। मुझे लगता है कि वे करते हैं
अपने आईपी को खोजने में सक्षम होने की जरूरत है, लेकिन नीचे की ओर एपीआई का उपयोग कर सकते हैं, जैसे
पॉड आईपी के साथ (#12595 https://github.com/kubernetes/kubernetes/pull/12595)।
आईपी ​​को बदलने की अनुमति देना (पॉड आईपी का उपयोग करने के कारण) दर की एक सीमा का तात्पर्य है
डीएनएस टीटीएल और कैशिंग "बग" के कारण आईपी में बदलाव। किसी मोड़ पर, हम
पॉड आईपी को माइग्रेट करने योग्य बनाने का भी इरादा है, हालांकि (#3949
https://github.com/kubernetes/kubernetes/issues/3949), इसलिए आईपी बदल रहा है
हमेशा के लिए नहीं होगा।

द्वितीय. पुश (पॉड्स तक) बनाम पुल (पॉड्स से)। सेवाएं और आरसी हैं
जानबूझकर ढीले ढंग से फली के साथ युग्मित, और इसलिए दोनों "पुश" का उपयोग करते हैं
नमूना। नाममात्र सेवाएं अधिक आंतरिक रूप से पॉड पहचान से जुड़ी होंगी
(हालांकि स्थायी रूप से नहीं - पॉड्स को बदला जा सकता है)। नतीजतन, मैं देखता हूँ
पुश मॉडल के लिए कम प्रेरणा। आवंटन के अन्य मामले, जैसे
शेड्यूलिंग, और esp। एक्सक्लूसिव बाइंडिंग, जैसे कि लगातार वॉल्यूम का दावा
लगातार वॉल्यूम, एक अनुरोध/एक मॉडल, उर्फ ​​​​"पुल" का उपयोग करें। वह वर्तमान में है
नाममात्र सेवाओं के लिए मैं जिस मॉडल का समर्थन करता हूं।

(I) पर किसी की राय है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

जैसा कि आप इसके बारे में सोचते हैं, शायद मेरा मतलब मास्टर इलेक्शन से नहीं था - इससे भी ज्यादा
कार्यक्षमता का निर्माण करते समय जहां उदाहरणों के एक सेट को प्रारंभ करने की आवश्यकता होती है
(स्पष्ट रूप से समन्वय के बिना) केवल वह उदाहरण है जो सोचता है कि यह है
"1" अन्य पॉड्स से बात करना आमतौर पर एक क्लस्टर को बूटस्ट्रैप करने के लिए पर्याप्त होता है। एक
उदाहरण मोंगोडब है जहां आपको प्रतिकृति सेट शुरू करने की आवश्यकता है - यदि पॉड्स
जो सोचते हैं कि वे "2" या "3" आरंभ कर रहे हैं, आप उन मामलों में प्राप्त कर सकते हैं जहां आप
एक विभाजन शुरू करें। लेकिन "1" हर बार सुरक्षित रूप से स्वयं को आरंभ कर सकता है, और फिर
अन्य सदस्यों को जोड़ने का प्रयास करें (जिनके पास लगातार स्थिति है जिसका वे उपयोग कर सकते हैं
निर्धारित करें कि क्या वे पहले से ही क्लस्टर का हिस्सा हैं)। निर्भर करना
पहचान सेवा द्वारा प्रदान की गई गारंटी आपको वास्तव में नहीं मिल सकती है
सफल क्लस्टर, लेकिन आपको बाहर एक अलग पॉड बनाने की ज़रूरत नहीं है
अपनी सेवा शुरू करें (हालाँकि यह या तो भयानक नहीं है)।

मंगलवार, अगस्त 18, 2015 अपराह्न 11:59 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

मास्टर चुनाव है #1542
https://github.com/kubernetes/kubernetes/issues/1542 , और किया जा रहा है
हा कार्यान्वयन के भाग के रूप में चर्चा की गई (उदाहरण के लिए, #12884
https://github.com/kubernetes/kubernetes/pull/12884)।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

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

जैसा कि @thockin संकेत दे रहा है, मुझे लगता है कि हम अनावश्यक रूप से यहां कई समान-लेकिन-अलग-अलग विशेषताओं का सामना कर रहे हैं - और हम k8s स्तर पर कड़ाई से आवश्यक से अधिक शामिल कर रहे हैं।

मैं ऊपर वर्णित दो अलग-अलग उपयोग के मामले देखता हूं - सत्य के स्रोत से भिन्न:

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

मुझे लगता है कि ये अलग हैं और इन्हें अलग तरह से वर्णित किया जाना चाहिए (हालांकि वे वास्तविक चल रहे पॉड के समान मेटाडेटा पेश कर सकते हैं)।

चर्चा में संसाधन बाड़ लगाने और एकल-पहुंच गारंटी भी शामिल है। Afaics, _only_ मामला जहां इसे k8s के भीतर करने की आवश्यकता होती है, दूरस्थ लगातार वॉल्यूम बढ़ रहा है (क्योंकि fs माउंट को कंटेनर के बाहर करने की आवश्यकता है), और यदि अंतर्निहित रिमोट वॉल्यूम सेवा नहीं करती है तो यह इत्यादि ताले के माध्यम से करना बहुत आसान है। टी पहले से ही आंतरिक रूप से बाड़ प्रदान करते हैं। वितरित लॉक सेवा (या आंतरिक रूप से लॉकिंग प्रदान करने वाली सेवाओं तक पहुंच) का उपयोग करके अन्य सभी मामलों को उपयोगकर्ता नौकरियों द्वारा स्वयं नियंत्रित किया जा सकता है। नौकरियों को अपने स्वयं के लॉकिंग करने के लिए कहने से सभी प्रकार के पैटर्न (निश्चित असाइनमेंट, अवसरवादी असाइनमेंट, "हॉट स्पेयर्स", आदि) और पहुंच से बाहर/पुनर्प्राप्ति रणनीतियों (कठिन असफल, जारी-के-अंतिम-ज्ञात, आदि) खुलते हैं।

मैं इस बग से सामान्य संसाधन बाड़ लगाने की सुविधा-अनुरोध को स्थानांतरित करने का सुझाव देता हूं (और हम k8s पर विभिन्न वितरित लॉकिंग सेवाओं को चलाने के लिए एक नुस्खा प्रदान करके केवल k8s द्वारा आगे की भागीदारी के बिना बाड़ लगाने को लागू करते हैं)।

बस एक रिमाइंडर: एक वीआईपी के पीछे _लॉट_ पोर्ट होते हैं। मैं सहमत हूं कि हम आईपी को माइग्रेट नहीं करना चाहते हैं क्योंकि यह बड़े पैमाने पर अंतर्निहित नेटवर्क पर कठिन लगता है, और नेटवर्क के लिए विफलता/पुनर्प्राप्ति किनारे के मामलों के दौरान अस्थायी डुप्लिकेट से निपटने के लिए अजीब लगता है। हालांकि, मुझे लगता है कि यह _is_ प्रत्येक शार्ड सदस्य के लिए एक अद्वितीय सेवा पोर्ट और प्रत्येक पॉड इंस्टेंस के लिए प्रॉक्सी डेटा असाइन करने के लिए काफी व्यवहार्य है - यहां तक ​​​​कि बहुत बड़ी नौकरियों के लिए भी। (यह सुझाव मान रहा है कि परदे के पीछे अभी भी वह दिशा है जिसे हम k8s के साथ जाना चाहते हैं - मैंने इस क्षेत्र के आसपास किसी भी हालिया चर्चा को नहीं रखा है)

पुश से, मेरा मतलब था कि एक अन्य संसाधन, जैसे सेवा या नियंत्रक, एक लेबल चयनकर्ता के माध्यम से पॉड्स के सेट की निगरानी करेगा और उन पर "चीजें" (समाधान योग्य DNS नाम, वीआईपी, पीवीसी) प्रदान करेगा।

खींचकर, मेरा मतलब था कि पॉड स्पष्ट रूप से एक "चीज" के आवंटन का अनुरोध करेगा, जो कि इसके बाद कुछ/बाइंडिंग के माध्यम से बाध्य होगा।

रनिंग पॉड को बदलने के बारे में: निर्माण के बाद पॉड को बदलना रनिंग कंटेनर के साथ पॉड को बदलने से अलग है। अनुसूचक async करता है। उदाहरण के लिए, आरंभीकरण। पॉडआईपी को भी देर से सौंपा गया है। #3585 में आम तौर पर चर्चा की गई।

इस बारे में कि क्या यह वास्तव में एक "सेवा" है या नहीं:

• पॉड्स के सेट में चीजों को आवंटित करने की आवश्यकता है
• थिंग (जैसे, डीएनएस नाम) को पॉड के संसाधन नाम से आंतरिक रूप से नहीं जोड़ा जाना चाहिए
• एक चीज़ को एक पॉड से दूसरे पॉड में स्थानांतरित करने की आवश्यकता होती है
• पॉड को "जानना" (या डाउनवर्ड एपीआई के माध्यम से पता लगाने में सक्षम होना चाहिए) इसे किस चीज (विशेष रूप से डीएनएस नाम और वीआईपी) को सौंपा गया था।
• एक चीज जिसका हमें समर्थन करने की आवश्यकता है वह है समाधान योग्य डीएनएस
• क्या हमें वीआईपी की जरूरत है मेरा एक उत्कृष्ट प्रश्न था। मैं वीआईपी का उपयोग नहीं करने के साथ ठीक हूं।
• यह आदर्श नहीं है, लेकिन उपयोगकर्ता डीएनएस और/या एंडपॉइंट्स के माध्यम से पीयर डिस्कवरी के लिए पूरे सेट को लक्षित करने वाली दूसरी, हेडलेस सेवा बना सकता है।

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

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

पुनः। env vars में जानकारी भरना: यह जॉब के लिए भी आया है। मैं जानकारी को एक एनोटेशन में भरना चाहता हूं और विशिष्ट एनोटेशन का अनुरोध करने में सक्षम होने के लिए डाउनवर्ड एपीआई का विस्तार करना चाहता हूं। मैं उपयोगकर्ताओं को केवल उन्हीं जानकारी का अनुरोध करने और env var नाम चुनने की अनुमति देना जारी रखना चाहता हूं।

पुनः। प्रत्येक इंस्टेंस के लिए अलग-अलग पोर्ट असाइन करना: यह कई लीगेसी ऐप्स के लिए काम नहीं करेगा, और हमारे सिस्टम डिज़ाइन के साथ भी संगत नहीं है।

पुनः। प्रिस्क्रिप्टिव: एन को चालू रखना प्रतिकृति नियंत्रक करता है।

पुनः। वर्णनात्मक: यह बिना सिर वाली सेवाएं हैं, जो पहले से मौजूद हैं।

पुनः। लॉकिंग: हां, यह लीज एपीआई है जो चल रहा है।

#6773 (पुश) और #12450 (पुल) में भंडारण प्रावधान पर चर्चा की जा रही है।

अब बहुत देर हो चुकी है, लेकिन मैं किसी तरह सोने के बाद प्रस्ताव बनाने के लिए समय निकालने की कोशिश करूंगा।

त्वरित अवलोकन: बिना सिर वाली सेवाएं वीआईपी को आवंटित नहीं करती हैं

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

और, टिकाऊ स्थानीय भंडारण मुद्दे प्रासंगिक हैं: #7562, #1515, #598

अधिक त्वरित अपडेट क्योंकि मैं ज्यादातर अन्य पीआर समीक्षा करता हूं:

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

पुनः। आवंटन/असाइनमेंट: मैं प्रतिकृति नियंत्रक, परिनियोजन, डेमन इत्यादि में अधिक टेम्पलेट प्रकार जोड़ने से बचना चाहता हूं, और मैं चाहता हूं कि स्टोरेज और नाम नियंत्रकों में आसानी से पॉड्स में माइग्रेट करने में सक्षम हों (यदि उपयोगकर्ता यही चाहता है)।

19 अगस्त, 2015 को पूर्वाह्न 1:04 बजे, एंगस लीस नोटिफिकेशन @github.com ने लिखा:

@smarterclayton https://github.com/smarterclayton यह एक तरफ है
नाममात्र सेवाओं की समस्या है, लेकिन यह बूटस्ट्रैप के लिए सुरक्षित नहीं है जैसा कि आप कर रहे हैं
वर्णन करना। यदि "1" को एक नई मशीन पर पुनः आरंभ किया जाता है और असमर्थ होता है
मौजूदा नोड्स तक पहुंचने के लिए, यह फिर से बूटस्ट्रैप होगा और अब आपके पास दो हैं
मोंगोडब के आधिकारिक होने का दावा। आपको नौकरी बदलने की जरूरत है
बूटस्ट्रैपिंग के बाद बूटस्ट्रैप की क्षमता को हटाने की परिभाषा है
पूर्ण।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

19 अगस्त 2015 को 1:35 पूर्वाह्न पर, एंगस लीस नोटिफिकेशन @github.com ने लिखा:

जैसा कि @thockin https://github.com/thockin का संकेत हो सकता है, मुझे लगता है
हम यहां अनावश्यक रूप से कई समान-लेकिन-भिन्न विशेषताओं का सामना कर रहे हैं

• और हम k8s स्तर पर आवश्यकता से अधिक शामिल कर रहे हैं।

मुझे ऊपर वर्णित दो अलग-अलग उपयोग के मामले दिखाई दे रहे हैं - स्रोत के अनुसार भिन्न
सच्चाई का:

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

मुझे लगता है कि ये अलग हैं और इन्हें अलग तरह से वर्णित किया जाना चाहिए (हालांकि

वे वास्तविक चल रहे पॉड के समान मेटाडेटा प्रस्तुत कर सकते हैं)।

चर्चा में संसाधन बाड़ लगाने और एकल-पहुंच को भी शामिल किया गया है
गारंटी। Afaics, _only_ मामला जहां इसे k8s . के भीतर करने की आवश्यकता है
(afaics) रिमोट वॉल्यूम बढ़ा रहा है - क्योंकि fs माउंट करने की जरूरत है
कंटेनर के बाहर। अन्य सभी मामलों को उपयोगकर्ता नौकरियों द्वारा नियंत्रित किया जा सकता है
स्वयं, एक वितरित लॉक सेवा का उपयोग करके (या उन सेवाओं तक पहुँच प्राप्त करना जो
आंतरिक रूप से लॉकिंग प्रदान करें)। नौकरियों को अपना खुद का लॉकिंग खोलने के लिए कहना
सभी प्रकार के पैटर्न (निश्चित असाइनमेंट, अवसरवादी असाइनमेंट, "हॉट
स्पेयर्स", आदि) और पहुंच से बाहर/वसूली की रणनीतियां (हार्ड फेल,
जारी-साथ-अंतिम-ज्ञात, आदि)।

मेरा सुझाव है कि सामान्य संसाधन बाड़ लगाने की सुविधा-अनुरोध को इसमें से हटा दें
बग (और हम केवल दौड़ने के लिए एक नुस्खा प्रदान करके बाड़ लगाना लागू करते हैं
k8s पर विभिन्न वितरित लॉकिंग सेवाएं बिना किसी और भागीदारी के
k8s ही)।

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

बस एक रिमाइंडर: एक वीआईपी के पीछे _लॉट_ पोर्ट होते हैं। मैं सहमत हूँ हम
IP को माइग्रेट नहीं करना चाहते क्योंकि यह अंतर्निहित नेटवर्क पर कठिन लगता है
बड़े पैमाने पर, और नेटवर्क के लिए अस्थायी डुप्लिकेट से निपटने के लिए अजीब
विफलता/वसूली बढ़त मामलों के दौरान। हालाँकि, मुझे लगता है कि यह _is_ काफी संभव है
प्रत्येक शार्क सदस्य को एक अद्वितीय सेवा पोर्ट और प्रत्येक को प्रॉक्सी डेटा असाइन करने के लिए
पॉड इंस्टेंस - यहां तक ​​​​कि बहुत बड़ी नौकरियों के लिए भी। (यह सुझाव मान रहा है
परदे के पीछे अभी भी वह दिशा है जिसे हम k8s के साथ जाना चाहते हैं - मैंने ऊपर नहीं रखा है
इस क्षेत्र के आसपास किसी भी हालिया चर्चा के साथ)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

@thockin के थिंगपूल + पैच विचार में थोड़ा सा मोड़:

साँचा: संसाधनों की सूची + पैरामीटर और प्रतिस्थापन। प्रेरणा के लिए https://github.com/openshift/origin/blob/master/pkg/template/api/types.go देखें। रेफरी #503, #1743, #4210, #6487।

टेम्पलेटपूल। मूल रूप से थिंगपूल। प्रतिकृति गणना के बजाय मांग पर टेम्पलेट के घनी अनुक्रमित उदाहरण उत्पन्न करता है।

मस्ती/स्थिरता के लिए: v2 प्रतिकृति नियंत्रक केवल पॉड्स के बजाय मनमाने टेम्पलेट्स को दोहरा सकता है। रेफरी # 170 (तरह)। हो सकता है कि आवश्यक न हो यदि सभी आवंटन पॉड प्रतिकृति द्वारा संचालित होते हैं।

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

@smarterclayton FYI जब आप इनलाइन टिप्पणियों के साथ ईमेल के माध्यम से उत्तर देते हैं, तो आपकी प्रतिक्रियाएँ जीमेल और

हाँ, gmail + github + iPhones में कुछ गड़बड़ है।

गुरु, अगस्त 20, 2015 अपराह्न 2:24 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

@smarterclayton https://github.com/smarterclayton FYI करें जब आप उत्तर दें
इनलाइन टिप्पणियों के साथ ईमेल के माध्यम से, आपके जवाब अपठनीय हैं, दोनों में
जीमेल और जीथब पर। जीमेल में, कोई लाइन ब्रेक नहीं है और जीथब में है
कोई उद्धरण उपसर्ग नहीं हैं, इसलिए आपकी प्रतिक्रिया को अलग करना मुश्किल है
पाठ उद्धृत किया जा रहा है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

आज हमने एक त्वरित बातचीत की, कुछ हाइलाइट्स:

ऐप्स के तीन वर्गों के बारे में बात की:

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

आज, आप N . होने से विशिष्ट पहचान और निरंतर मात्रा को हल कर सकते हैं
प्रतिकृति नियंत्रक, एन सेवाओं के साथ स्थिर आईपी पता। हम चाहेंगे
उन उपयोग मामलों में से कुछ के लिए एन आरसी और सेवाओं की आवश्यकता नहीं है।

हमने टिम और ब्रायन के सुझावों के बारे में बात की, किसी विशेष क्रम में नहीं:

• TemplatePool समस्याग्रस्त है क्योंकि रेप्लिकेटर के पास होना चाहिए
  संपूर्ण क्लस्टर में ऑब्जेक्ट बनाने का अधिकार, और जानना होगा
  जहां हर एपीआई समापन बिंदु है।
  
  
  
  • आपके पास तत्काल टेम्पलेट एंडपॉइंट हो सकता है, लेकिन फिर भी इसकी आवश्यकता है
    
    प्राधिकरण प्रतिनिधिमंडल की समस्या को हल करें (सेवा खातों के साथ?)
  
  
  • वस्तुओं का पता लगाना और अनुमति को प्रतिबंधित करना लंबी अवधि की चीजें हैं
  
  
• हमने जिस "पॉड आइडेंटिटी" उर्फ़ वीड फील्ड के बारे में बात की थी - वह तर्क दिया गया था
  और आम तौर पर इस बात से सहमत हैं कि इसे विश्व स्तर पर अद्वितीय होने की आवश्यकता नहीं है, केवल
  डोमेन के भीतर अद्वितीय है कि पॉड इसका उपयोग करने की अपेक्षा करता है।
  
  
  
  • एक काल्पनिक इंडेक्स असाइनर (विरल या सघन) उस मान को सेट कर सकता है
    
    निर्माण के बाद, और क्यूबलेट पॉड्स शुरू करने के लिए तब तक इंतजार कर सकता था जब तक कि उनके पास a
    
    पहचान (यह इंगित करने की आवश्यकता हो सकती है कि वे एक की प्रतीक्षा कर रहे हैं)
  
  
  • घने सूचकांक आम तौर पर साधारण चीजों के लिए उपयोगी होते हैं, लेकिन क्योंकि यह
    
    निर्माण के बाद है और क्यूबलेट से अलग किया गया है जो आपके पास अलग हो सकता है
    
    असाइनमेंट एल्गोरिदम के प्रकार (घने संख्यात्मक, सुसंगत हैश रिंग,
    
    यादृच्छिक, आदि)
  
  
• पॉड्स पर सरल टेम्प्लेटिंग शुरू करने के लिए एक अच्छी जगह की तरह लगता है, लेकिन हमें इसकी आवश्यकता है
  इसे हमारी मौजूदा टूल चेन के साथ इस तरह से सुसंगत बनाने के लिए
  इसे पूरी तरह से तोड़ दो
  
  
  
  • अन्य क्षेत्रों को टेम्प्लेट करने के लिए पहचान फ़ील्ड का उपयोग करें
  
  
• पॉड स्पेक पर एक होस्टनाम फ़ील्ड जोड़ें जिसे उपयोगकर्ता स्वयं सेट कर सकें और
  पहचान के साथ पैरामीटर करें
• एक हेडलेस सेवा को उनके द्वारा एंडपॉइंट के लिए डीएनएस प्रश्नों का उत्तर देने की अनुमति दें
  पहचान (समापन बिंदु नियंत्रक एक पॉड से पहचान को अमल में लाना है
  समापन बिंदुओं में) जो कुछ स्थिरता की गारंटी देता है
• किसी तरह लगातार वॉल्यूम के दावों को पैरामीटरयुक्त या परिवर्तित करने की अनुमति दें
  एक पूल से ड्रा करें (या पूल नियंत्रक सुनिश्चित करें कि प्रति वॉल्यूम एक वॉल्यूम है
  पहचान, या पहचान नियंत्रक पूल से ड्रा है), विचार की जरूरत है
• ऐसे उपकरण चाहिए जो पर्यावरण / डाउनवर्ड एपीआई को में बदलना आसान बनाते हैं
  config फ़ाइलें (ऑर्थोगोनल, लेकिन आसान होना चाहिए)
• अभी भी पैटर्न के बारे में कुछ चिंताएं

गुरु, अगस्त 20, 2015 अपराह्न 3:34 बजे, क्लेटन कोलमैन [email protected]
लिखा था:

हाँ, gmail + github + iPhones में कुछ गड़बड़ है।

गुरु, अगस्त 20, 2015 अपराह्न 2:24 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com
लिखा था:

@smarterclayton https://github.com/smarterclayton FYI करें जब आप उत्तर दें
इनलाइन टिप्पणियों के साथ ईमेल के माध्यम से, आपके जवाब अपठनीय हैं, दोनों में
जीमेल और जीथब पर। जीमेल में, कोई लाइन ब्रेक नहीं है और जीथब में है
कोई उद्धरण उपसर्ग नहीं हैं, इसलिए आपकी प्रतिक्रिया को अलग करना मुश्किल है
पाठ उद्धृत किया जा रहा है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

एक और मुद्दा: नाममात्र सेवाओं के सदस्यों के लिए टीएलएस प्रमाणपत्र

सामान्य रूप से सेवा के लिए टीएलएस प्रमाणपत्र भी एक अच्छी बात होगी (हस्ताक्षरित
क्लस्टर सीए द्वारा अनुरोध पर स्वचालित रूप से)।

थू, अगस्त 20, 2015 को शाम 5:19 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com ने लिखा:

एक और मुद्दा: नाममात्र सेवाओं के सदस्यों के लिए टीएलएस प्रमाणपत्र

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

हाँ: #11725

पुनः:

• पॉड स्पेक पर एक होस्टनाम फ़ील्ड जोड़ें जिसे उपयोगकर्ता स्वयं सेट कर सकें और
  पहचान के साथ पैरामीटर करें
• एक हेडलेस सेवा को उनके द्वारा एंडपॉइंट के लिए डीएनएस प्रश्नों का उत्तर देने की अनुमति दें
  पहचान (समापन बिंदु नियंत्रक एक पॉड से पहचान को अमल में लाना है
  समापन बिंदुओं में) जो कुछ स्थिरता की गारंटी देता है

मेरा मानना ​​है कि हम सहमत हैं कि डीएनएस को पॉड स्पेक्स पर सेट किए गए होस्टनाम का उपयोग करके समर्थित किया जाना चाहिए (जो कि उस कार्यक्षमता को जोड़ने के बाद उनकी पहचान द्वारा पैरामीटर किया जा सकता है), जैसे कि कंटेनरों द्वारा देखे गए होस्टनाम अन्य कंटेनरों द्वारा हल करने योग्य होंगे।

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

कुछ इस तरह:

Hostname string
Subdomain string

पॉडस्पेक में होस्टनेटवर्क के ऊपर।

हम होस्टनाम-आधारित डीएनएस केवल तभी डिलीवर करेंगे जब उप डोमेन सही प्रकार की सेवा के लिए मेल खाता हो। हम दोनों को एक ही फील्ड में स्मूच भी कर सकते हैं।

मुझे लगता है कि हमें इसके लिए अंक #4825 को फिर से तैयार करना चाहिए और किसी को इस पर काम करना चाहिए। यह बाकी की तुलना में कहीं अधिक ठोस और कम काम है।

किसी तरह लगातार वॉल्यूम के दावों को पैरामीटरयुक्त या परिवर्तित करने की अनुमति दें
एक पूल से ड्रा करें (या पूल नियंत्रक सुनिश्चित करें कि प्रति वॉल्यूम एक वॉल्यूम है
पहचान, या पहचान नियंत्रक पूल से ड्रा है), विचार की जरूरत है

मेरे विचार से दावों के बारे में दो बातें यहाँ मदद कर सकती हैं:

1. बाइंडिंग को 1:1 से 1:N . में बदलें
   
   
   
   1. बाध्यकारी संदर्भ के रूप में PVC.Spec.VolumeName से PVC.Spec.VolumeNames[]
   
   
2. PVC.Spec.Singelton बूलियन यह दर्शाता है कि क्या दावा साझा करने के लिए एक बार बाध्य होना चाहिए या दावे को कई बार बाध्य होने देना चाहिए।

एक आरसी आवश्यकतानुसार नए संस्करणों से जुड़ सकता है। मैं यह पता लगाऊंगा कि इसे बाइंडर में कैसे संभालना है।

सही वॉल्यूम का सही पॉड से मिलान करना अभी भी महत्वपूर्ण होगा।

आपको वॉल्यूम नामों के लिए पहचान का नक्शा रखना होगा।

शुक्र, अगस्त 21, 2015 अपराह्न 3:17 बजे, मार्क तुरांस्की नोटिफिकेशन @github.com
लिखा था:

किसी तरह लगातार वॉल्यूम के दावों को पैरामीटरयुक्त या परिवर्तित करने की अनुमति दें
एक पूल से ड्रा करें (या पूल नियंत्रक सुनिश्चित करें कि प्रति वॉल्यूम एक वॉल्यूम है
पहचान, या पहचान नियंत्रक पूल से ड्रा है), विचार की जरूरत है

मेरे विचार से दावों के बारे में दो बातें यहाँ मदद कर सकती हैं:

1. बाइंडिंग को 1:1 से 1:N . में बदलें
   
   
   
   1. PVC.Spec.VolumeName to PVC.Spec.VolumeNames[] बाइंडिंग के रूप में
      
      संदर्भ
   
   
2. PVC.Spec.Singelton बूलियन जो दर्शाता है कि क्या दावा बाध्य होना चाहिए
   एक बार साझा करने के लिए या दावे को कई बार बाध्य करने की अनुमति दें।

एक आरसी आवश्यकतानुसार नए संस्करणों से जुड़ सकता है। मैं समझूंगा कि इसे कैसे संभालना है
बांधने की मशीन में।

सही वॉल्यूम का सही पॉड से मिलान करना अभी भी महत्वपूर्ण होगा।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

शुक्रवार, 21 अगस्त 2015 को दोपहर 12:56 बजे, ब्रायन ग्रांट नोटिफिकेशन @github.com ने लिखा:

उपडोमेन सेट करने के लिए, हमें पॉड को बताना होगा कि किस सेवा ने इसे लक्षित किया है,
स्पष्ट रूप से या परोक्ष रूप से। स्पष्ट का नुकसान यह है कि इसे और अधिक की आवश्यकता है
विन्यास गोंद / टेम्पलेटिंग। निहित का नुकसान यह है कि यह होगा
सिस्टम में ढीले युग्मन के साथ हमारे सामने आने वाली चुनौतियों के लिए प्रवण: निर्माण-
आदेश दौड़ और असंगति, 1-से-1 प्रवर्तन कठिनाइयाँ, आदि। मैं झुकता हूँ
स्पष्ट की ओर। हमें सिर्फ क्रॉस-रेफरेंस स्कोपिंग को बेहतर बनाने पर काम करना चाहिए।

आइए स्पष्ट करें - यदि हम उपडोमेन सेट नहीं करते हैं, तो हम उपयोगकर्ताओं को प्रदान नहीं कर सकते
उनके अपने होस्टनाम। अगर हम सबडोमेन सेट करते हैं, तो हमें ऐसा करना होगा a
वह तरीका जो अद्वितीय-काफी है (DNS स्थान में, जिसका वर्तमान में अर्थ है पार
नामस्थान)। उपडोमेन को सेवा का नाम बनाना है
पर्याप्त अद्वितीय।

हमारे डीएनएस (एक टीएलडी) की कुछ सीमाओं को देखते हुए, यह
वास्तविक रूप से इसका अर्थ है कि हम उपयोगकर्ताओं को दो DNS_LABEL फ़ील्ड देते हैं - होस्टनाम
और नाममात्र का सेट। एक ठोस उदाहरण के लिए:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

इसका परिणाम पॉड देखने में होगा:

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

और DNS foo.bar.my-app.nom.cluster.local लिए A और PTR रिकॉर्ड पेश कर रहा है

यह हमारी वर्तमान DNS संरचना से एक स्तर अधिक गहरा है, लेकिन मुझे लगता है
हमारे वर्तमान एनडॉट्स = 5 में इसे शामिल किया गया है। वैकल्पिक रूप से, हम कह सकते हैं कि a
नेमस्पेस उपनाम है, और इसे अद्वितीय असाइन करने के लिए उपयोगकर्ताओं पर वापस डाल दें
नामस्थान में होस्टनाम। DNS परिणाम होगा
foo.my-app.pod.cluster.local जो सेवाओं को प्रतिबिंबित करता है। हम भी कर सकते थे
सेवाओं में वैकल्पिक होस्टनाम फ़ील्ड जोड़कर उन्हें और अधिक समान बनाएं।

हम होस्टनाम-आधारित डीएनएस केवल तभी डिलीवर करेंगे, जब सबडोमेन उससे मेल खाएगा
सही प्रकार की सेवा। हम दोनों को एक ही फील्ड में स्मूच भी कर सकते हैं।

इसका मेरा सबसे कम पसंदीदा हिस्सा यह है कि पॉड घोषित कर रहा है "मैं हिस्सा हूँ
सेवा 'बार'" (उपरोक्त उदाहरण में)। सामने। एक प्राथमिकता।

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

मुझे लगता है कि हमें इसके लिए अंक #4825 को फिर से तैयार करना चाहिए और किसी को इस पर काम करना चाहिए। यह बाकी की तुलना में कहीं अधिक ठोस और कम काम है।

यह निश्चित रूप से कुछ ऐसा है जो तुरंत शुरू हो सकता है, लेकिन (उनके लिए
घर पर निम्नलिखित के साथ) यह सिर्फ पॉड को लागू करने का तंत्र है
पहचान, पहचान के सेट के प्रबंधन की नीति नहीं।

शुक्र, 21 अगस्त, 2015 को अपराह्न 3:17 बजे, मार्क तुरांस्की नोटिफिकेशन @github.com ने लिखा:

मेरे विचार से दावों के बारे में दो बातें यहाँ मदद कर सकती हैं:

1. बाइंडिंग को 1:1 से 1:N . में बदलें

यहीं से मैंने शुरुआत की थी, लेकिन...

शुक्र, अगस्त 21, 2015 अपराह्न 12:38 पर, क्लेटन कोलमैन
सूचनाएं @

आपको वॉल्यूम नामों के लिए पहचान का नक्शा रखना होगा।

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

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

हमारे पास पॉड्स के दो या तीन सेवाओं के अंतर्गत होने के कई उदाहरण हैं, एक के लिए
प्रसार, एक जोखिम के लिए, और एक परीक्षण जोखिम के लिए।

पहचान के संबंध में, डेमॉन नियंत्रक द्वारा बनाए गए प्रत्येक पॉड को एक पहचान सौंपी जानी चाहिए जो नोड पहचान और नियंत्रक पहचान से ली गई है। यह एक ऐसा मामला हो सकता है जहां पहचान स्पष्ट है (होस्ट वाई पर पॉड एक्स की पहचान एफ (वाई) है) और डेमॉन जिम्मेदारी का हिस्सा है।

@smarterclayton समूह के सदस्यों की एक स्थिर, आदेशित सूची बनाए रखने के लिए यहां एक आम (लेकिन सार्वभौमिक नहीं) की आवश्यकता है। यह कैसे काम कर सकता है जब पहचान उस नोड से जुड़ी होती है जिस पर पॉड निर्धारित होता है?

डेमॉन नियंत्रक _only_ की पहचान उस नोड के संदर्भ में है जो पॉड है
चलते रहना। प्रतिकृति नियंत्रक और सेवाएं अलग हैं। डेमन
नियंत्रक कहता है "इनमें से प्रत्येक नोड पर चलने में से एक होना चाहिए"। वहां
पॉड के नोड के अलावा कोई अन्य पहचान नहीं हो सकती है।

शुक्र, 11 सितंबर, 2015 पूर्वाह्न 1:13 बजे, एंगस लीस नोटिफिकेशन @github.com
लिखा था:

@smarterclayton https://github.com/smarterclayton तो एक आम (लेकिन नहीं
सार्वभौमिक) यहां समूह की एक स्थिर, क्रमबद्ध सूची बनाए रखने की आवश्यकता है
सदस्य मुझे लगता है कि इसका तात्पर्य है कि पहचान _not_ से बंधी होनी चाहिए
नोड जिस पर पॉड शेड्यूल किया जाना है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

@smarterclayton आह, यह मुद्दा स्पष्ट रूप से मूल सुविधा अनुरोध से कुछ अधिक में बदल गया है - मैं यहां जो बनाने की कोशिश कर रहा था उस पर खो गया हूं, इसलिए मैं शोर जोड़ना जारी रखने के बजाय वापस आ जाऊंगा ...

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

ऐसा हो सकता है कि डेमॉन कंट्रोलर द्वारा चलाए जाने वाले पॉड्स की पहचान "स्पष्ट" हो (डेमन कंट्रोलर नोड्स के एक सेट पर काम करता है, RC पॉड्स के सेट पर काम करता है)।

पहचान की एक आवश्यकता यह है कि यह सेट में अद्वितीय हो। क्या हम उस विशिष्टता को सुनिश्चित करने के लिए पॉड नेम और पॉड नेम जनरेशन का लाभ उठा सकते हैं? उदाहरण के लिए, RC यादृच्छिक नाम उत्पन्न करते हैं। क्या एक आरसी पॉड्स के लिए एक नियतात्मक फैशन में नाम उत्पन्न कर सकता है जो उसके द्वारा चुने गए पॉड्स के सेट के आधार पर होता है?

एक RC पर विचार करें जो a=b लेबल वाले पॉड्स का चयन करता है। बनाने के लिए अगले पॉड की गणना करने के लिए, उसे पॉड्स लाने होंगे और उन्हें एक गिनती में कम करना होगा। क्या होगा यदि हम इसे एक अद्वितीय नाम सेट में कम कर दें, और फिर आरसी ने उस सेट के भीतर एक नाम पीढ़ी पैटर्न का पालन करने का प्रयास किया? दो आरसी जो ओवरलैप नहीं करते हैं, लेकिन एक सर्विस लेबल में पॉड्स बनाते हैं, वे अद्वितीय नाम उत्पन्न करने में असमर्थ होंगे (वे एक नाम के लिए लड़ सकते हैं, लेकिन यह निहित है)। हटाए जाने के बाद नामों का पुन: उपयोग किया जा सकता है

फिर पॉड में लगातार वॉल्यूम पॉड नाम के आधार पर पीवीसी का उपयोग कर सकते हैं। एक पीवीसी पूलर यह सुनिश्चित कर सकता है कि आरसी के देखे गए पूल के लिए पर्याप्त दावे हैं। डेमॉन नियंत्रक एक नोड नाम के लिए नियतात्मक नाम चुन सकता है। हम कुछ पैटर्न के आधार पर किसी सेवा में DNS नामों को पॉड नामों से भी तार-तार कर सकते हैं।

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

मतलब ऊपर "नामों का मनाया पूल"। एंडपॉइंट डीएनएस हैशपॉडनाम.ept.service.namespace.svc.cluster.local होगा। हमारे पास एंडपॉइंट पर पहले से ही पॉड नाम है, इसलिए हमें कुछ भी जोड़ने की जरूरत नहीं है।

https://github.com/kubernetes/contrib/tree/master/service-loadbalancer से संबंधित है जो इस मुद्दे के समाधान को एक संभावित अगले पुनरावृत्ति के रूप में प्रस्तावित करता है

हम यहां डेमॉनसेट की चर्चा क्यों कर रहे हैं? इसे # 12893, IMO द्वारा हल किया गया था।

@smarterclayton आइए पॉड नामों से पहचान प्राप्त करने की पुनरीक्षा न करें, न ही पहचान प्रदान करने के लिए आरसी का उपयोग करें। उन दृष्टिकोणों की समस्याओं पर यहां चर्चा की गई: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

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

ऐसा लगता है कि बोर्ग टास्क इंडेक्स एब्स्ट्रैक्शन जैसी किसी चीज की उपयोगिता _कुछ निश्चित मामलों के लिए_ आती रहती है और यह मेरे लिए स्पष्ट नहीं है कि हम इसे एक विकल्प के रूप में क्यों नहीं पेश कर सकते हैं।

डेमनसेट मुझे नहीं लगता कि वितरित फाइल सिस्टम स्टोरेज केस हल करता है
(ग्लस्टर) जहां प्रत्येक मेजबान को फिर से जुड़ने के लिए एक सुसंगत पहचान की आवश्यकता होती है
क्लस्टर। मैं और खोदूंगा लेकिन मुझे लगता है कि इसे अभी भी कुछ चाहिए
#260 की आवश्यकता - मुझे नहीं पता कि यदि आप पुनः संलग्न करते हैं तो होस्टनाम पर्याप्त है या नहीं
एक नए उदाहरण पर एक होस्ट डिस्क। शायद मुझे समझ नहीं आया कि डेमनसेट क्या है
प्रदान किया गया और #12893 वितरित किया गया, लेकिन मुझे नहीं लगता कि a . के लिए यह समस्या है
सिस्टम होस्ट जो डिस्क का पुन: उपयोग करना चाहता है।

बुधवार, 16 सितंबर, 2015 को दोपहर 12:22 बजे, ब्रायन ग्रांट सूचनाएं @github.com
लिखा था:

@smarterclayton https://github.com/smarterclayton आइए फिर से न
पॉड नामों से पहचान प्राप्त करना, न ही पहचान सौंपने के लिए आरसी का उपयोग करना।
उन दृष्टिकोणों की समस्याओं पर यहां चर्चा की गई: #260 (टिप्पणी)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

एक ठोस उदाहरण के रूप में, एक आदि क्लस्टर की कल्पना करें। इसमें 7 उदाहरण हैं, और 7
मात्रा. मैं चाहता हूँ (तर्क के लिए), नाम और खंड वगैरह-1
etcd-7 और etcd-pvc-1 के माध्यम से etc-pvc-7 के माध्यम से।

एक रोलिंग परिनियोजन में MaxUnavailable 90% (या equiv), MaxSurge 0% है। यह
पुराने RC को घटाता है, और नए RC को बढ़ाता है। पुरानी आरसी शान से
आदि -5 हटाता है। यह तुरंत प्रभावी आरसी सेट से बाहर हो जाता है। नई
RC etcd-5 (सेट गैप के अवलोकन द्वारा) बनाने की कोशिश करता है। यह प्राप्त करता है a
"पहले से मौजूद अपवाद"। यह इसे बैकऑफ़ और आवश्यकता के रूप में मानता है। एक बार
etcd-5 वास्तव में चला गया है, यह आगे बढ़ने में सक्षम है। एक बार etcd-5 तैयार हो जाने पर, DC
अगले चरण पर जाता है।

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

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

बुधवार, 16 सितंबर, 2015 को दोपहर 12:39 बजे, क्लेटन कोलमैन [email protected]
लिखा था:

डेमनसेट मुझे नहीं लगता कि वितरित फाइल सिस्टम स्टोरेज केस हल करता है
(ग्लस्टर) जहां प्रत्येक मेजबान को फिर से जुड़ने के लिए एक सुसंगत पहचान की आवश्यकता होती है
क्लस्टर। मैं और खोदूंगा लेकिन मुझे लगता है कि इसे अभी भी कुछ चाहिए
#260 की आवश्यकता - मुझे नहीं पता कि यदि आप पुनः संलग्न करते हैं तो होस्टनाम पर्याप्त है या नहीं
एक नए उदाहरण पर एक होस्ट डिस्क। शायद मुझे समझ नहीं आया कि डेमनसेट क्या है
प्रदान किया गया और #12893 वितरित किया गया, लेकिन मुझे नहीं लगता कि a . के लिए यह समस्या है
सिस्टम होस्ट जो डिस्क का पुन: उपयोग करना चाहता है।

बुधवार, 16 सितंबर, 2015 को दोपहर 12:22 बजे, ब्रायन ग्रांट सूचनाएं @github.com
लिखा था:

@smarterclayton https://github.com/smarterclayton आइए फिर से न
पॉड नामों से पहचान प्राप्त करना, न ही पहचान सौंपने के लिए आरसी का उपयोग करना।
उन दृष्टिकोणों की समस्याओं पर यहां चर्चा की गई: #260 (टिप्पणी)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

जो चीज इस समस्या को मेरे लिए कठिन बनाती है, वह नामों का एक स्थिर अद्वितीय पूल या पीडी के पूल का उपयोग नहीं कर रहा है। समस्या एक ही समय में दोनों कर रही है। और यदि आप इसे बढ़ाते हैं, तो कल्पना में किसी भी पहचानकर्ता के बारे में इस तरह क्यों नहीं जोड़ा जा सकता है?

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

यह मुद्दा लटका हुआ है और मुझे डर है कि हमें विश्लेषण पक्षाघात मिल गया है।

काश हमारे पास अन्य पूलिंग उपयोग के मामलों के अधिक उदाहरण होते। मैंने सोचा था कि ग्लस्टर
अलग होगा लेकिन यह सिर्फ एक और संस्करण है
cassandra/etcd/mongo/zookeeper "मैं एक वॉल्यूम का पुन: उपयोग करना चाहता हूं और मुझे इसकी आवश्यकता है
याद रखें कि मैंने कहा था कि मैं पहले कौन था। हमारे पास वास्तव में कोई भूमिका आधारित नहीं है (I .)
पहले एन पॉड समन्वयक और अगले एम कार्यकर्ता बनाना चाहते हैं) उदाहरण
लाभ उठाने के लिए।

बुधवार, 16 सितंबर, 2015 को दोपहर 12:46 बजे, टिम होकिन सूचनाएं @github.com
लिखा था:

जो चीज इस समस्या को मेरे लिए कठिन बनाती है, वह स्थिर नहीं पैदा कर रही है
नामों का अनूठा पूल या पीडी के पूल का उपयोग करना। समस्या दोनों पर कर रही है
उसी समय। और अगर आप इसे आगे बढ़ाते हैं, तो किसी के बारे में क्यों नहीं
कल्पना में पहचानकर्ता इस तरह जमा किया जा सकता है?

जितना मुझे पता है (ज्यादातर सेकेंड हैंड) पैक्ड इंडेक्स वाले मुद्दे, I
लगता है कि वे रहने योग्य हो सकते हैं (विशेषकर यदि हम डेविड के सुझाव के अनुसार करते हैं और बनाते हैं
उन्हें अन्य सुविधाओं के साथ परस्पर अनन्य)। लेकिन साथ ही, जितना अधिक मैं स्टू करता हूँ
यह, जितना कम मैं पैच विचार से नफरत करता हूं, कुछ मूर्खों ने अप-थ्रेड पोस्ट किया।

यह मुद्दा लटका हुआ है और लटका हुआ है और मुझे डर है कि हमें विश्लेषण मिल गया है
पक्षाघात।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

डेमॉनसेट:

12893 होस्ट नेटवर्किंग का उपयोग करते समय पॉड होस्टनाम को नोड के होस्टनाम पर सेट करता है, जो कि डेमनसेट के लिए उपयोग करने के लिए पूरी तरह से उचित है, क्योंकि ये अन्यथा होस्टपोर्ट का उपयोग करेंगे, वैसे भी।

इसके अलावा, इरादा डेमॉनसेट को नोड नियंत्रक के साथ एकीकृत करना है ताकि निहित अनिश्चितकालीन क्षमा #1574 प्रदान किया जा सके, और सामान्य रूप से नोड्स के लिए शेड्यूलिंग सक्षम होने से पहले "शेड्यूलिंग" को सक्षम किया जा सके। निहित प्राथमिकता भी उचित हो सकती है।

क्लस्टर स्टोरेज सिस्टम के लिए, मैं कल्पना कर सकता हूं कि प्रत्येक होस्ट पर अतिरिक्त डिस्क का प्रावधान है जो केवल स्टोरेज सिस्टम द्वारा होस्टपाथ के माध्यम से एक्सेस किया जाता है - उनका उपयोग डॉकर द्वारा नहीं किया जाएगा और न ही खालीडिर द्वारा।

पहचान के संबंध में, मुझे यहां प्रस्ताव में कोई समस्या नहीं दिखाई दे रही है: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

यह मुद्दा मुख्य रूप से पर्याप्त प्राथमिकता, आईएमओ की कमी के कारण लटका हुआ है।

क्लेटन पर रिफ़ करने के लिए (या शायद वही बातें कहने के लिए लेकिन डम्बर):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

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

यह पूरी तरह से सामान्य नहीं है (आप किसी भी यादृच्छिक क्षेत्र को पूल नहीं कर सकते हैं) लेकिन हम आवश्यकतानुसार अधिक पहचान-जागरूक विकल्प जोड़ सकते हैं

मुझे लगता है कि अगर हम इस पर पसंद की गई एक युक्ति को पकड़ लेते हैं, तो यह जल्द से जल्द पूरा हो सकता है।

यहां तक ​​​​कि एक कल्पना लिखने में भी समय लगता है।

IdentityPool/VolumePool के संबंध में, हमने बहुत पहले ही तय कर लिया था कि कई पूल काम नहीं करेंगे।

1.1 कोड-पूर्ण समय सीमा शुक्रवार है। क्या हम कृपया अभी ऐसा नहीं कर सकते?

यह भी संबंधित: # 170। यह सिर्फ पॉड टेम्प्लेट को विभाजित करने का प्रस्ताव करता है, लेकिन अगर हम एक टेम्प्लेटिंग स्कीम के लिए जाते हैं (जिसे मैं दृढ़ता से पैच पर पसंद करता हूं), तो हमें उन पर एक साथ विचार करना चाहिए।

मैंने कम से कम डिजाइन को v1.2-उम्मीदवार पर रखा।

क्षमा करें, मैं अपने स्केच में स्पष्ट नहीं था - RC (या IC?) की एक अवधारणा है
प्राथमिक पूल या index. एक बार जब एक पॉड को IC में एक इंडेक्स सौंपा जाता है, तो
अनुक्रमणिका का उपयोग सभी पूल-केंद्रित क्षेत्रों में अनुक्रमणित करने के लिए किया जाता है।

यदि हम टेम्प्लेट को विभाजित करते हैं, तो मुझे लगता है कि यह धारणा है कि RC नहीं कर सकता
टेम्पलेट को म्यूट करें। यह थोड़ा पेचीदा है।

मैं इस सप्ताह इस बारे में बात करना बंद कर दूंगा। यह बस my . में चला गया
इनबॉक्स और मैं इस विचार को चबा रहा था ...

मंगलवार, 15 सितंबर, 2015 को रात 10:09 बजे, ब्रायन ग्रांट सूचनाएं @github.com
लिखा था:

यहां तक ​​​​कि एक कल्पना लिखने में भी समय लगता है।

IdentityPool/VolumePool के संबंध में, हमने पहले ही एक लंबा समय तय कर लिया है
पहले कि कई पूल काम नहीं करेंगे।

1.1 कोड-पूर्ण समय सीमा शुक्रवार है। क्या हम कृपया अभी ऐसा नहीं कर सकते?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

हाँ, कुछ ऐसी बातें थीं जिनसे हमारी ओर से चर्चा शुरू हुई।
ग्राहक समस्याएँ कोई रिलीज़ प्रक्रिया नहीं होने की प्रतीक्षा करती हैं।

बुधवार, 16 सितंबर, 2015 पूर्वाह्न 1:14 बजे, टिम हॉकिन नोटिफिकेशन @github.com
लिखा था:

क्षमा करें, मैं अपने स्केच में स्पष्ट नहीं था - RC (या IC?) की एक अवधारणा है
प्राथमिक पूल या index. एक बार जब एक पॉड को IC में एक इंडेक्स सौंपा जाता है, तो
अनुक्रमणिका का उपयोग सभी पूल-केंद्रित क्षेत्रों में अनुक्रमणित करने के लिए किया जाता है।

यदि हम टेम्प्लेट को विभाजित करते हैं, तो मुझे लगता है कि यह धारणा है कि RC नहीं कर सकता
टेम्पलेट को म्यूट करें। यह थोड़ा पेचीदा है।

मैं इस सप्ताह इस बारे में बात करना बंद कर दूंगा। यह बस my . में चला गया
इनबॉक्स और मैं इस विचार को चबा रहा था ...

मंगलवार, 15 सितंबर, 2015 को रात 10:09 बजे, ब्रायन ग्रांट सूचनाएं @github.com
लिखा था:

यहां तक ​​​​कि एक कल्पना लिखने में भी समय लगता है।

IdentityPool/VolumePool के संबंध में, हमने पहले ही एक लंबा समय तय कर लिया है
पहले कि कई पूल काम नहीं करेंगे।

1.1 कोड-पूर्ण समय सीमा शुक्रवार है। क्या हम कृपया ऐसा नहीं कर सकते?
अभी?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

चर्चा सभी आईपी नंबरों और पॉड्स के बारे में है, लेकिन मोंगो और ज़ुकीपर के साथ मेरे अनुभव में आईपी को पॉड्स अप्रासंगिक रहना चाहिए (पालतू जानवर नहीं बनना चाहिए)। लगातार _वॉल्यूम_ को नाममात्र की संख्या की आवश्यकता होती है क्योंकि यह वॉल्यूम अन्य 'वॉल्यूम' के आईपी नंबर को रिकॉर्ड करता है। जो भी पॉड उस वॉल्यूम को मापता है उसे किसी भी तरह उस रिकॉर्ड किए गए आईपी नंबर का उपयोग करने में सक्षम होना चाहिए। वॉल्यूम पालतू है ...

एक DNS नाम जो वॉल्यूम के लिए समय में स्थिर है और वॉल्यूम को मापने वाले पॉड को असाइन किया गया है, मुझे लगता है कि यह एक लंबा सफर तय करेगा।

Mongo & ZK में पहनावा सदस्यता बदलने के लिए हमेशा कस्टम कोड चलाने की आवश्यकता होगी और मुझे उम्मीद है कि यह अधिकांश अन्य पहनावाओं के लिए समान होगा। तो प्रतिकृति नियंत्रक गलत नाम है, इन पालतू जानवरों को एक सदस्य जहाज नियंत्रक की अधिक आवश्यकता है। एक सदस्य जहाज नियंत्रक प्रारंभिक सेटअप को संभालने में सक्षम होना चाहिए और फिर पहनावा में वृद्धिशील परिवर्तन करना चाहिए, और अंत में इसे बंद कर देना चाहिए।

माउंटेड वॉल्यूम के आधार पर एक निरंतर DNS नाम को देखते हुए और कस्टम कोड के साथ पहनावा सदस्यता को संभालने की संभावना से मुझे लगता है कि इस प्रकार के सिस्टम को संभालना संभव हो सकता है।

हां, पॉड आईपी एक शॉर्ट टर्म हैक है।

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

हमें अभी भी यह सुनिश्चित करने की आवश्यकता है कि पहनावा से परे कोई उपयोग का मामला नहीं है
यहां ओवरलैप करता है (सुझाए गए एक को नहीं सुना है) और फिर प्राप्त करने का प्रयास करें a
ठोस प्रस्ताव जो न्यूनतम और उचित लगता है। टिम मुझे लगता है कि है
संक्षेप में कहा गया है कि हाल ही में यहाँ।

23 सितंबर 2015 को पूर्वाह्न 11:33 बजे पीटर क्रिएन्स नोटिफिकेशन @github.com ने लिखा:

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

एक DNS नाम जो एक वॉल्यूम के लिए समय में स्थिर है और एक पॉड को असाइन किया गया है
मुझे लगता है कि वॉल्यूम एक लंबा रास्ता तय करेगा।

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

माउंटेड वॉल्यूम और संभावना के आधार पर एक निरंतर DNS नाम दिया गया
कस्टम कोड के साथ पहनावा सदस्यता को संभालना संभव बनाना चाहिए
मुझे लगता है कि इस प्रकार की प्रणालियों को संभालें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/गुनगुनाहट

आप मौजूदा क्षमताओं का उपयोग करते हुए https://hub.docker.com/r/elevy/zookeeper/ पर कुबेरनेट्स के तहत एक ZK क्लस्टर स्थापित करने का एक उदाहरण पा सकते हैं

@smarterclayton @thockin

कुछ दिन पहले बाइक से ऑफिस जाते समय विचार:

मैं वर्तमान में इसे एक पेटसेट नियंत्रक, या शायद शार्डसेट नियंत्रक के रूप में सोच रहा हूं, अगर लोग इसके बारे में इस तरह से सोचना चाहते हैं, जैसा कि शुरुआत में चर्चा की गई थी: https://github.com/kubernetes/kubernetes/issues/260# निर्गम टिप्पणी -57671926।

जिस मामले को हम संबोधित करने का प्रयास कर रहे हैं वह यह है कि एन समान पालतू जानवर हैं, लेकिन वे अभी भी पालतू जानवर हैं - वे कवक नहीं हैं।

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

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

जितना मुझे यह विचार पसंद है, मुझे नहीं लगता कि बॉटम-अप पहचान आवंटन काम करने वाला है। पूल में आवंटित पहचानों को वापस करने के साथ बहुत अधिक दौड़ की स्थिति बनाम नई पहचान आवंटित करना। नौकरी के साथ RabbitMQ के उपयोग की खोज करते समय @erictune जैसी कई समस्याएं

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

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

हमें अंततः स्थानीय भंडारण के बारे में कुछ करने की आवश्यकता होगी, लेकिन मुझे लगता है कि इसे अलग किया जा सकता है।

और फिर ऊपर उल्लिखित होस्टनाम और हेडलेस सेवा परिवर्तन, यहाँ:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

अभी एक प्रस्ताव पर काम कर रहे हैं, जल्द ही एक मसौदा तैयार किया जाएगा।

प्रस्ताव https://github.com/kubernetes/kubernetes/pull/18016 पर है

... तो हम पेटसेट के साथ कहां हैं?

मैं Kubernetes के शीर्ष पर HA डेटाबेस समाधान बना रहा हूँ। कुछ, विशेष रूप से सिंगल-मास्टर डेटाबेस को एंडपॉइंट वाली सेवाओं की आवश्यकता होती है जो उन पॉड्स की घटनाओं के आधार पर विशेष पॉड्स को मैप करते हैं। उदाहरण के लिए:

1. सर्विस "पोस्टग्रेज" रेप्लिकासेट में सभी पॉड्स के लिए राउंड-रॉबिन मैप करता है, लेकिन सर्विस "पोस्टग्रेज-मास्टर" मैप्स केवल एक पॉड के लिए।
2. मास्टर पॉड मर जाता है।
3. फेलओवर होता है। विफलता के भाग के रूप में, नया मास्टर एपीआई के माध्यम से क्यूब-मास्टर को पोस्टग्रेज-मास्टर सेवा को "हथियाने" के लिए अपडेट करता है।
4. जब यह ऐसा करता है, तो पोस्टग्रेज-मास्टर के सभी पूर्व कनेक्शन समाप्त हो जाते हैं।

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

@ncdc क्या इसके लिए v1.3 में सब कुछ किया गया है? यह स्पष्ट नहीं है क्योंकि प्रस्ताव का विलय नहीं हुआ है और कुछ अन्य पीआर कुछ समय के लिए इसका उल्लेख नहीं कर रहे हैं।

@bprashanth ^

हम e2es उतार रहे हैं और उदाहरणों पर काम करना जारी रख रहे हैं। यह अल्फा में है
अब, लेकिन प्रस्ताव अल्फा फीडबैक का पहला दौर लेने जा रहा है
विलय से पहले।

19 मई 2016 को सुबह 10:25 बजे, ब्रैंडन फिलिप्स ने नोटिफिकेशन @github.com
लिखा था:

@ncdc https://github.com/ncdc क्या इसके लिए v1.3 में सब कुछ किया गया है? यह है
अस्पष्ट है क्योंकि प्रस्ताव का विलय नहीं किया गया है और अन्य पीआर नहीं हैं
थोड़ी देर के लिए इसका जिक्र करते हुए।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

मुझे इसके लिए डॉक्स कहां मिल सकते हैं? मैं डेटाबेस-विफलता उपयोग मामले के लिए इसका परीक्षण करना चाहता हूं।

आह हा, बस हमें एक पोस्टग्रेज विशेषज्ञ की जरूरत है :)

उदाहरण के लिए https://github.com/kubernetes/contrib/pull/921 देखें, मैं पालतू जानवर के रूप में [पसंद का db] प्रोटोटाइप करने के बारे में किसी भी प्रश्न का उत्तर दे सकता हूं। हमारे पास "ऐप्स/स्टेटफुल" लेबल के तहत स्केच का एक गुच्छा है (उदाहरण: https://github.com/kubernetes/kubernetes/issues/23790, @philips एक आदि उदाहरण बहुत अच्छा होगा)। मैंने अभी तक डॉक्स नहीं लिखे हैं, 1.3 के अंतिम कुछ हफ्तों (शुक्रवार को कोड पूरा होने के बाद भी रिलीज होने के लिए अभी भी 5 सप्ताह) की ओर ऐसा करेंगे।

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

आपको एक त्वरित समीक्षा देने के लिए पेटसेट आज आपको लगातार नेटवर्क पहचान (डीएनएस, होस्ट नाम) देता है जो नेटवर्क माउंटेड वॉल्यूम से मेल खाता है, और गारंटी देता है। इसलिए यदि आप replicas: 3 साथ एक पेटसेट बनाते हैं, तो आपको यह मिलेगा:
शासी सेवा: *.galear.default.svc.cluster.local
mysql-0 - वॉल्यूम0
mysql-1 - वॉल्यूम 1: तब तक शुरू नहीं होता जब तक 0 चल रहा हो और तैयार हो
mysql-2 - वॉल्यूम 2: 0 तक शुरू नहीं होता है, 1 तैयार चल रहा है

पॉड्स गवर्निंग सर्विस के तहत डाले गए एसआरवी रिकॉर्ड को देखकर सेवा की खोज के लिए डीएनएस का उपयोग कर सकते हैं। यह सरल पॉड यही करता है: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62। इसलिए यदि आप उपरोक्त उदाहरणों की तरह एक init कंटेनर के माध्यम से पीयर-फाइंडर का उपयोग करते हैं, तो mysql-1 तब तक शुरू नहीं होगा जब तक कि init कंटेनर DNS में (mysql-1, mysql-0) नहीं देखता, और उपयुक्त कॉन्फिगरेशन लिखता है।

वॉल्यूम डायनेमिक प्रोविज़नर (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md) द्वारा प्रोविज़न किए जाते हैं, इसलिए यदि आपके पास एक नहीं है आपके क्लस्टर में चल रहा है, लेकिन सिर्फ प्रोटोटाइप बनाना चाहते हैं, आप बस खालीडिर का उपयोग कर सकते हैं। "डेटा-गुरुत्वाकर्षण" (https://github.com/kubernetes/kubernetes/issues/7562) मामला अभी तक काम नहीं करता है, लेकिन अंततः होगा।

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

मेरे पास एक प्रहरी है, यह सेवा विफलता है जो मेरी इच्छा से अधिक जटिल है। परीक्षण करेंगे, धन्यवाद!

मुझे आदि का समर्थन करने की भी आवश्यकता है, इसलिए मेरे भविष्य में बहुत सारे परीक्षण हो सकते हैं।

@ncdc इसके लिए अल्फा कोड की क्या स्थिति है? मैं परीक्षण/कार्यान्वयन शुरू करना चाहता हूं। हमें यहां वास्तव में जल्द ही एक कैसेंड्रा क्लस्टर तैनात करने की आवश्यकता है। मैं इसे मौजूदा कोडबेस के साथ कर सकता हूं लेकिन पेटसेट सामान का परीक्षण करना अच्छा होगा।

यदि आप HEAD . से निर्माण करते हैं तो आप इसे प्राप्त कर सकते हैं

@bprashanth मुख्य रेपो में विलीन हो गया? बहुत बहुत शुक्रिया। करूंगा।

https://github.com/kubernetes/contrib/tree/master/pets

एनोटेशन स्ट्रिंग्स में एम्बेडेड yaml? ओह, आउच :(। धन्यवाद हालांकि, एक कैसेंड्रा सेट बनाने की जांच करेगा।

वह जेसन है। यह एक GA ऑब्जेक्ट (पॉड्स में init कंटेनर) में जोड़ा गया एक अल्फा फीचर है।
@chrislovecnm कैसेंड्रा पर काम कर रहा है, शायद उसे इंतजार करना चाहता है।

@paralin यहाँ वह है जिस पर मैं काम कर रहा हूँ। दस्तावेज करने और इसे अभी k8s रेपो में लाने का समय नहीं है, लेकिन यह दीर्घकालिक योजना है। https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra मेरे लिए स्थानीय रूप से, HEAD पर काम कर रहा है।

डेमो में नवीनतम सी* छवि अच्छी तरह से काम करती है।

हमारे पास अधिक दस्तावेज़ीकरण के लिए खुला मुद्दा है। पलक झपकना, कुरेदना @bprashanth

etcd क्लस्टर के साथ पेटसेट उदाहरण [1]।

[1] https://github.com/kubernetes/contrib/pull/1295

समीक्षा समाप्त करने के बाद प्रस्ताव दस्तावेज़ पर डिज़ाइन आस्क को कैप्चर करना सुनिश्चित करें

30 जून 2016 को पूर्वाह्न 1:25 बजे जन चालौपका नोटिफिकेशन @github.com ने लिखा:

etcd क्लस्टर के साथ पेटसेट उदाहरण [1]।

[1] कुबेरनेट्स/कॉन्ट्रिब#1295
https://github.com/kubernetes/contrib/pull/1295

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

पेटसेट डॉक्स https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md और https://github.com/kubernetes/kubernetes.github हैं। io/tree/release-1.3/docs/user-guide/petset/bootstrapping , मैं इस मुद्दे को बंद करने और एक नया खोलने की योजना बना रहा हूं जो चलती पेटसेट को बीटा में संबोधित करता है जब तक कि कोई आपत्ति न करे

https://github.com/kubernetes/kubernetes/issues/28718