कुबेरनेट्स / कुबेरनेट्स के साथ क्रॉस संदर्भ: अंक # 62822

अद्यतन के लिए धन्यवाद!

/असाइन @leblancd
/ तरह की सुविधा
/सिगरेट नेटवर्क
/ मील का पत्थर 1.11

@leblancd कोई डिज़ाइन दस्तावेज़ उपलब्ध है?

/cc @thockin @dcbw @luxas @kubernetes/sig-network-feature-requests

@idvoretskyi - अभी तक कोई डिज़ाइन दस्तावेज़ नहीं है, लेकिन हम जल्द ही एक पर सहयोग करना शुरू कर देंगे।

क्या इसका मतलब यह है कि Kubernetes Ingress डुअल-स्टैक को सपोर्ट करेगा?
क्या इसका मतलब यह है कि CNI (कैलिको) को डुअल स्टैक (उदाहरण के लिए BIRD और BIRD6 डिमन्स दोनों) चलाने की आवश्यकता होगी?

@ sb1975 - दोहरे ढेर प्रवेश समर्थन के संबंध में, यह कुछ ऐसा है जिसे हमें हैश आउट करने की आवश्यकता होगी, लेकिन यहां मेरे प्रारंभिक विचार हैं:

• दोहरी स्टैक प्रवेश समर्थन अधिकतर इस बात पर निर्भर करेगा कि आप किस प्रवेश नियंत्रक का उपयोग करते हैं (चाहे वह समर्थित है और इसे कैसे कार्यान्वित किया जाता है)। ड्यूल-स्टैक का समर्थन करने के लिए मौजूदा प्रवेश नियंत्रकों को शायद कुछ बदलावों की आवश्यकता होगी।
• मुझे उम्मीद है कि एक विशिष्ट प्रवेश नियंत्रक के लिए प्रवेश विन्यास नहीं बदलेगा (कॉन्फ़िगरेशन अभी भी एक एल 7 पते को एक सेवा नाम/सेवा पोर्ट पर मैप कर सकता है, जिसमें वी 4/वी 6 परिवार का कोई उल्लेख नहीं है)
• ऐसे मामले में जहां किसी सेवा में एंडपॉइंट पॉड्स होते हैं जो ड्यूल-स्टैक होते हैं, इनग्रेड कंट्रोलर (ओं) को पैकेट के परिवार के आधार पर मैप इनग्रेड पैकेट्स में बदलाव की आवश्यकता हो सकती है, यानी IPv4 इनग्रेड पैकेट्स को IPv4 एंडपॉइंट पर मैप करें, और IPv6 इनग्रेड पैकेट्स को मैप करें। एक IPv6 समापन बिंदु के लिए। भार-संतुलन भारोत्तोलन के प्रयोजनों के लिए, एक दोहरे-स्टैक समापन बिंदु को एकल समापन बिंदु लक्ष्य के रूप में गिना जाना चाहिए।

- हो सकता है कि हम V4/V6 परिवारों में एक प्रवेश नियंत्रक मानचित्र रखने के लिए भविष्य के समर्थन पर विचार करना चाहें (IPv6 बैकएंड में IPv4 पैकेट को मैप करें, और इसके विपरीत), लेकिन हमारा प्रारंभिक विकास सख्त दोहरे-स्टैक (अर्थात अलग, स्वतंत्र) के लिए होगा ढेर)।

केलिको और अन्य CNI प्लगइन्स के बारे में:

• सीएनआई प्लगइन्स दोहरे ढेर मोड में चलाने के लिए है, तो एक क्लस्टर परिदृश्य दोहरे ढेर की आवश्यकता नहीं है की
• ड्यूल-स्टैक समर्थन के लिए संभवतः विभिन्न CNI प्लगइन्स में बदलाव की आवश्यकता होगी, लेकिन उस काम को इस Kubernetes मुद्दे के दायरे से बाहर माना जाता है (हम Kubernetes को किसी भी मनमाने ड्यूल-स्टैक प्लगइन के लिए काम करने पर ध्यान केंद्रित कर रहे हैं, शायद ब्रिज प्लगइन का उपयोग कर रहे हैं) एक संदर्भ), और सीएनआई कार्य अलग-अलग मामला-दर-मामला आधार पर किया जाएगा।
• कैलिको के लिए विशेष रूप से, मैं एक विशेषज्ञ नहीं हूं, लेकिन मेरा मानना ​​​​है कि आईपीवी 4 और आईपीवी 6 दोनों मार्गों को संभालने के लिए एक एकल बर्ड डिमन को कॉन्फ़िगर किया जा सकता है (यहां "टेम्पलेट बीजीपी" खोजें: http://bird.network.cz/?get_doc&v= 20&f=पक्षी-3.html#ss3.1)। उस ने कहा, हालांकि कैलिको पहले से ही पॉड पर दोहरे स्टैक पते का समर्थन करता है, दोनों परिवारों के लिए बीजीपी रूटिंग काम करने के लिए आवश्यक बदलाव हो सकते हैं।

@leblancd : तो यहाँ परिदृश्य है:

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

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

• जब आप बाहर से क्यूब सेवाओं तक पहुंचने का प्रयास करते हैं, तो आपके डीएनएस नियंत्रक को प्रवेश नियंत्रक के लिए ए और एएएए डीएनएस रिकॉर्ड के साथ सेवा का समाधान करना चाहिए। प्रवेश नियंत्रक तक पहुंचने के लिए ए बनाम एएएए रिकॉर्ड का उपयोग करना आपके क्लाइंट/ऐप की पसंद होगी। तो प्रवेश नियंत्रक के लिए बाहरी पहुंच दोहरे ढेर होगी।
• एनजीआईएनएक्स इनग्रेड कंट्रोलर पर, एनजीआईएनएक्स तब एल7 यूआरएल (आईपीवी4 या आईपीवी6 पैकेट में अनुरोध की परवाह किए बिना) को देखेगा और उस बैलेंस को अपस्ट्रीम एंडपॉइंट पर लोड करेगा। यदि प्रवेश नियंत्रक लोड बैलेंसर को ipv6=on के साथ कॉन्फ़िगर किया गया है (जो कि डिफ़ॉल्ट है, तो https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load देखें) -बैलेंसिंग-यूजिंग-डीएनएस), और सर्विस एंडपॉइंट डुअल-स्टैक हैं, तो अपस्ट्रीम कॉन्फ़िगरेशन में प्रत्येक डुअल-स्टैक एंडपॉइंट के लिए IPv4 और IPv6 दोनों प्रविष्टियां होनी चाहिए। जैसा कि डिज़ाइन किया गया है, NGINX लोड बैलेंसर IPv4 प्रविष्टि और IPv6 प्रविष्टि को एक समापन बिंदु के लिए अलग सर्वर के रूप में मानता कर सकता है , यदि उसके लिए कोई कॉन्फिग नॉब है?), ताकि लोड बैलेंसिंग IPv4-only एंडपॉइंट पर हो। या , हो सकता है कि NGINX लोड बैलेंसर को IPv4 पते से कनेक्शन और उसके संबंधित IPv6 पते के कनेक्शन को समान समापन बिंदु पर 2 लोड के रूप में मानने के लिए संशोधित किया जा सकता है।

मदद करने और इसमें शामिल होने के लिए, इसकी बहुत सराहना की जाएगी! हम ड्यूल-स्टैक पर ईमानदारी से काम करना शुरू करने वाले हैं (सीआई को केवल आईपीवी6 के लिए काम करने में काम में थोड़ा विलंब हुआ है)। मैं जल्द ही एक विशिष्ट (Google Doc या KEPs WIP doc) के लिए एक रूपरेखा के साथ आने की उम्मीद कर रहा हूं, और समीक्षा करने और शायद कुछ अनुभाग लिखने में मदद की तलाश कर रहा हूं। हमें निश्चित रूप से आधिकारिक दस्तावेज़ीकरण (डिज़ाइन कल्पना से परे) और दोहरे-स्टैक E2E परीक्षणों को परिभाषित करने और लागू करने में भी मदद की आवश्यकता होगी। कुछ क्षेत्रों में जो मैं अभी भी डिजाइन के लिए थोड़ा सा स्केची हूं, उनमें शामिल हैं:

• स्वास्थ्य / जीवंतता / तत्परता जांच कैसे प्रभावित होती है या दोहरे ढेर से कैसे नियंत्रित होती है
• क्या नेटवर्क नीतियों पर असर पड़ेगा?
• लोड बैलेंसर की चिंता?
• क्लाउड प्रदाता प्लगइन चिंताएं?
• L3/L4 प्रवेश की चिंता?
  यदि आपने इनमें से किसी के बारे में सोचा है, तो शायद आप उन अनुभागों में मदद कर सकते हैं?

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

/ मील का पत्थर 1.12

@leblancd / @caseydavenport - मैं यहाँ बहुत चर्चा और एक मील का पत्थर परिवर्तन देख रहा हूँ।
क्या इसे 1.11 मील के पत्थर से खींचा जाना चाहिए?

@justaugustus - हां, इसे 1.12 पर ले जाया जाना चाहिए। क्या मुझे रिलीज़ स्प्रैडशीट में एक पंक्ति को हटाने की ज़रूरत है, या इसे बदलने के लिए मुझे कुछ करने की ज़रूरत है?

@leblancd मैंने इसे कवर कर लिया है। अनुसरण करने के लिए धन्यवाद! :)

@leblancd @kubernetes/sig-network-feature-requests --

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

यदि ऐसा है, तो कृपया सुनिश्चित करें कि यह समस्या निम्नलिखित सभी सूचनाओं के साथ अप-टू-डेट है:

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

निम्नलिखित सेट करें:

• विवरण
• समनुदेशिती
• लेबल:
  
  
  
  • स्टेज/{अल्फा, बीटा, स्थिर}
  
  
  • हस्ताक्षर/*
  
  
  • प्रकार/विशेषता
  
  

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

इसके अलावा, कृपया निम्नलिखित प्रासंगिक समय सीमा से अवगत रहें:

• डॉक्स की समय सीमा (ओपन प्लेसहोल्डर पीआर): 8/21
• टेस्ट केस फ्रीज: 8/28

कृपया सुनिश्चित करें कि सुविधाओं के लिए सभी पीआर में प्रासंगिक रिलीज़ नोट भी शामिल हैं।

खुश शिपिंग!

/cc @justaugustus @ kacole2 @robertsandoval @

@leblancd --
फीचर फ्रीज आज है। क्या आप इसे Kubernetes 1.12 में बीटा में स्नातक करने की योजना बना रहे हैं?
यदि हां, तो क्या आप सुनिश्चित कर सकते हैं कि सब कुछ अप-टू-डेट है, इसलिए मैं इसे 1.12 फ़ीचर ट्रैकिंग स्प्रेडशीट में शामिल कर सकता हूँ?

हाय @justaugustus - बीटा स्थिति को कुबेरनेट्स 1.13 में खिसकना होगा। हम डिजाइन केईपी (https://github.com/kubernetes/community/pull/2254) पर (यद्यपि धीमी) प्रगति कर रहे हैं, और हम सीआई परीक्षण पीआर के साथ फिर से जुड़ने के करीब पहुंच रहे हैं, लेकिन कुबेरनेट्स 1.12 लक्ष्य थोड़ा आशावादी था।

मैं ऊपर दिए गए विवरण/सारांश को आपके द्वारा पहले मांगी गई जानकारी से अपडेट कर दूंगा। आपके धैर्य के लिए धन्यवाद।

/निकालें-चरण अल्फा
/चरण बीटा

कोई चिंता नहीं, @leblancd। अद्यतन के लिए धन्यवाद!

नमस्ते, @justaugustus @leblancd

मैंने अभी अपडेट पढ़ा है कि दोहरी स्टैक के लिए बीटा 1.13 पर ले जाया गया है। 1.13 की अपेक्षित रिलीज की तारीख क्या है? हम वास्तव में दोहरे स्टैक समर्थन की तलाश कर रहे हैं। यह हमारे उत्पाद के लिए कंटेनरों में जाने का निर्णय है।

@ navjotsingh83 - मुझे नहीं लगता कि कुबेरनेट्स 1.13 की रिलीज की तारीख पक्की हो गई है। मुझे कुबेरनेट्स रिलीज़ दस्तावेज़ीकरण में सूचीबद्ध 1.13 दिखाई नहीं दे रहा है।

@navjotsingh83 @leblancd 1.13 रिलीज शेड्यूल प्रकाशित हो चुकी है ।. यह 15 नवंबर को कोड फ्रीज के साथ एक छोटा रिलीज चक्र है। क्या आपको लगता है कि इस सुविधा को बीटा में बदलने के लिए पर्याप्त समय है। क्या आप कृपया इस मुद्दे को अपने आत्मविश्वास के स्तर से अपडेट कर सकते हैं, कोड, परीक्षण और डॉक्स पूरा होने के मामले में क्या लंबित है?

एसआईजी नेटवर्क बैठक में चर्चा के अनुसार, हालांकि इस सुविधा पर 1.13 में काफी काम किया जाएगा, लेकिन 1.13 में बीटा में जाने की उम्मीद नहीं है। तदनुसार मील का पत्थर हटा रहा है।

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

@ kacole2 इसे 1.13 एन्हांसमेंट स्प्रेडशीट से हटाने के लिए

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

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

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

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

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

@leblancd IPv4/IPv6 के लिए क्लस्टर के किनारे पर एक कार्रवाई करना चाहता था:

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

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

@KevinAtDesignworx यदि एज-डुअल-स्टैक लेकिन आंतरिक ipv6-only दृष्टिकोण अभी भी एक कंटेनर के अंदर से बाहरी ipv4 अनुरोधों तक पहुंच सकता है (यानी curl -v 93.184.216.34 -H "Host: example.com" ), मुझे वास्तव में लगता है कि यह सबसे अच्छा तरीका है। यदि आपका बुनियादी ढांचा ipv6 का उपयोग कर सकता है, तो संगतता कारणों के लिए किनारे को छोड़कर ipv4 का उपयोग क्यों करें। हालांकि, अगर इस दृष्टिकोण का मतलब है कि मैं अपने क्लस्टर के अंदर से केवल ipv4 का उपयोग करके विरासत वेबसाइटों तक नहीं पहुंच सकता, तो मुझे अब इतना यकीन नहीं है।

अच्छी तरह से 464XLAT है इसलिए ipv6 केवल कंटेनर के अंदर ही व्यवहार्य होगा।

@KevinAtDesignworx - यदि आपके परिदृश्य में एक प्रवेश नियंत्रक का उपयोग करना काम करेगा, तो बाहर से दोहरे-स्टैक संचालन के लिए एक NGINX प्रवेश नियंत्रक को कॉन्फ़िगर करना संभव है (क्लस्टर के अंदर एकल-परिवार के लिए प्रॉक्सी): https://github.com/leblancd/ kube-v6# -a- दोहरी-स्टैक-प्रवेश-नियंत्रक-पर-एक-ipv6-केवल-kubernetes-क्लस्टर स्थापित करना

प्रवेश नियंत्रकों को प्रत्येक नोड पर होस्ट नेटवर्क पर चलाने की आवश्यकता होगी, इसलिए नियंत्रकों को एक डेमोंसेट (प्रत्येक नोड पर एक प्रवेश नियंत्रक) के रूप में स्थापित करने की आवश्यकता होगी। यह मानता है:

• आपके नोड ड्यूल-स्टैक हैं (पॉड्स और सेवाओं के एकल-परिवार होने के विपरीत)
• प्रत्येक नोड पर आपके /etc/hosts में IPv6 प्रविष्टियाँ हैं, और उस नोड के होस्टनाम के लिए केवल IPv6 प्रविष्टियाँ (कोई IPv4 पते नहीं) हैं।

यह क्लस्टर के अंदर V6 क्लाइंट से बाहरी IPv4-only सर्वर से कनेक्शन के लिए NAT64/DNS64 के अतिरिक्त होगा।

स्टेटलेस NAT46 भी एक विकल्प है, लेकिन मैंने ऐसा करने की कोशिश नहीं की है, इसलिए मेरे पास इसके लिए कोई कॉन्फिग गाइड नहीं है।

@leblancd 1.15 के लिए यहां कोई काम करने की योजना है? ऐसा लगता है कि इस बिंदु पर भी अभी तक एक केईपी स्वीकार नहीं किया गया है। धन्यवाद!

@leblancd IPv4/IPv6 के लिए क्लस्टर के किनारे पर एक कार्रवाई करना चाहता था:

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

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

एक कंटेनर के अंदर से (जो केवल ipv6 है) एक कर्ल अनुरोध भेज रहा है (यानी कर्ल -v 93.184.216.34 -H "होस्ट: example.com") क्लस्टर के बाहर। मुझे लगता है कि यह अज्ञात गंतव्य या पहुंचने योग्य गंतव्य की त्रुटि देगा, जब तक कि मेजबान पर कोई आईपीवी 4 मार्ग मौजूद न हो जहां कंटेनर मौजूद हो।

@ GeorgeGuo2018 अगर k8s DNS64/NAT64 को लागू करेगा तो यह काम करेगा। यह बहुत हद तक इस बात पर निर्भर करता है कि k8s 464xlat/plat समाधानों में कितनी दूर तक जाएगा और एज राउटर आदि पर क्या संभालने की आवश्यकता होगी ...

वास्तव में मुझे लगता है कि यह डेमॉनसेट/परिनियोजन का उपयोग करके संभव होगा जो क्यूब-सिस्टम नेमस्पेस के अंदर होस्ट नेटवर्किंग और तायगा का उपयोग करता है ताकि आंतरिक DNS64 नेटवर्क के बाहर जाने के लिए तायगा का उपयोग करे।

मेरे लिए समाधान की तरह लगता है।

हम आंतरिक रूप से IPv6-only नेटवर्क चलाते हैं और NAT64/DNS64 हमारे लिए काफी अच्छा काम करता है। कुछ पुराने सामानों के लिए जहां कोई IPv6 समर्थन बिल्कुल नहीं था, हम सीधे clatd का उपयोग कर रहे थे जहां इसकी आवश्यकता थी। (हमारे मामले में सीधे वीएम पर।)

@ kacole2 - मैं चाहूंगा कि यह 1.15 के लिए ट्रैक किया जाए। मैं निम्नलिखित पीआर विलय के लिए काम कर रहा हूँ - https://github.com/kubernetes/enhancements/pull/808

विशेष रूप से 1.15 के लिए हम निम्नलिखित के लिए समर्थन जोड़ेंगे:

• एपीआई प्रकार संशोधन
  
  
  
  • कुबेरनेट्स प्रकार
  
  
  • सीआरआई प्रकार
  
  
• डुअल-स्टैक पॉड नेटवर्किंग (मल्टी-आईपी पॉड)
• कुबेनेट बहु-परिवार का समर्थन

मील का पत्थर ट्रैकिंग के लिए cc @caseydavenport ^

@ kacole2 केईपी अब विलय हो गया है। मुझे बताएं कि अगर कुछ और है तो हमें इसे 1.15 . में ट्रैक करने की आवश्यकता है

अरे @leblancd @lachie83 बस एक दोस्ताना अनुस्मारक हम गुरुवार, 30 मई तक k/वेबसाइट (शाखा देव

@ kacole2 केईपी अब विलय हो गया है। मुझे बताएं कि अगर कुछ और है तो हमें इसे 1.15 . में ट्रैक करने की आवश्यकता है

@ lachie83 नमस्ते,

@ kacole2 केईपी अब विलय हो गया है। मुझे बताएं कि अगर कुछ और है तो हमें इसे 1.15 . में ट्रैक करने की आवश्यकता है

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

@leblancd k8s.io dev-1.15 के खिलाफ प्लेसहोल्डर पीआर गुरुवार 30 मई को होने वाला है।

@leblancd k8s.io dev-1.15 के खिलाफ प्लेसहोल्डर पीआर गुरुवार 30 मई को होने वाला है।

क्या मैं इस बात पर विचार कर सकता हूं कि रिलीज़-1.15 में डुअल-स्टैक समर्थन उपलब्ध होगा?

@ GeorgeGuo2018 यह अभी भी 1.15 के लिए एन्हांसमेंट शीट पर है, लेकिन केवल एन्हांसमेंट लीड @ kacole2 आपको उस पर बेहतर विवरण प्रदान कर सकता है।

नमस्ते @lachie83 @leblancd। कोड फ्रीज गुरुवार, मई 30th 2019 @ EOD PST है । रिलीज़ में जाने वाले सभी एन्हांसमेंट परीक्षण सहित कोड-पूर्ण होने चाहिए, और दस्तावेज़ पीआर खुले होने चाहिए।

कृपया सभी मौजूदा k/k PRs को सूचीबद्ध करें ताकि उन्हें फ्रीज में जाने पर ट्रैक किया जा सके। यदि PR को फ़्रीज़ द्वारा मर्ज नहीं किया जाता है, तो यह सुविधा 1.15 रिलीज़ चक्र के लिए खिसक जाएगी। मील के पत्थर में केवल रिलीज-अवरोधक मुद्दों और पीआर की अनुमति दी जाएगी।

मुझे कुबेरनेट्स/कुबेरनेट्स # 62822 मूल पोस्ट में दिखाई दे रहा है जो अभी भी खुला है। क्या अन्य पीआर भी हैं जिनका हम विलय होने की उम्मीद कर रहे हैं?

यदि आप जानते हैं कि यह फिसल जाएगा, तो कृपया उत्तर दें और हमें बताएं। धन्यवाद!

@simplytunde - सिर की सराहना करें। मैं इस सप्ताह डॉक्स पीआर को एक साथ लाने पर काम कर रहा हूं।

@ GeorgeGuo2018 - यह एक बहु-रिलीज़ KEP होने जा रहा है। हम 1.15 में चरण 1 लैंडिंग की योजना बना रहे हैं। कृपया अधिक विस्तार के लिए केईपी में कार्यान्वयन योजना पर एक नज़र डालें - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -योजना।

@simplytunde - मैंने एक WIP https://github.com/kubernetes/website/pull/14600 के साथ यहां प्रारंभिक प्लेसहोल्डर डॉक्स पीआर बनाया है

@ kacole2 पिंग के लिए धन्यवाद। मैंने k/k PR के साथ 1.15 एन्हांसमेंट स्प्रैडशीट को अपडेट किया है जिसे हम ट्रैक कर रहे हैं (https://github.com/kubernetes/kubernetes/pull/73977) ड्राफ्ट डॉक्स PR (https://github.com/) के साथ कुबेरनेट्स/वेबसाइट/पुल/14600)। कोड फ्रीज होने से पहले हम इस पीआर को मर्ज करने के लिए अभी भी ट्रैक पर हैं। LMK अगर मुझे कुछ और याद आ रहा है

@ kacole2 @claurence और रिलीज टीम के साथ चर्चा के बाद हमने इसे 1.15 मील के पत्थर से हटाने का फैसला किया है। कृपया आगे बढ़ें और इसे हटा दें और स्प्रैडशीट को उपयुक्त के रूप में अपडेट करें। अब तक आपकी सभी सहायता के लिए धन्यवाद।

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

@simplytunde मैंने डॉक्स पीआर पर भी टिप्पणी की है। क्या आप कृपया सुनिश्चित कर सकते हैं कि इसे 1.15 मील के पत्थर से भी हटा दिया गया है?

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

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

धन्यवाद।

https://github.com/kubernetes/dns/issues/315 DNS सेवा खोज विनिर्देश में IPv6 / AAAA को

@ lachie83 अगर यह 1.16 में स्नातक किया जाएगा यह ट्रैक करने के लिए किसी भी विचार @leblancd?

@evillgenius75 @kacole2 इसे 1.16 में ट्रैक करने की आवश्यकता है। यह फीचर अल्फा स्टेट में होगा। हम चरण 1 और चरण 2 को लागू करेंगे जैसा कि केईपी में परिभाषित किया गया है 1.16

ट्रैकिंग केईपी

• https://github.com/kubernetes/enhancements/pull/808

मर्ज किए गए k/k PRs (वर्तमान में मास्टर में 1.16 में होगा)

• [विलय] चरण 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [विलय] चरण 1 e2e परीक्षण - https://github.com/kubernetes/kubernetes/pull/78801
• [विलय] चरण 1 e2e परीक्षण सफाई - https://github.com/kubernetes/kubernetes/pull/80001
• चरण 2 सेवाएं/समापन बिंदु - https://github.com/kubernetes/kubernetes/pull/79386
• चरण 2 क्यूब-प्रॉक्सी - https://github.com/kubernetes/kubernetes/pull/79576

एसोसिएटेड पीआर

• IPv6 के लिए समर्थन https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• चरण 1 दस्तावेज़ - टूलिंग उदाहरणों को अंतिम रूप देने के बाद फिर से खोल दिया जाएगा - https://github.com/kubernetes/website/pull/14600
• [विलय] सफाई - नोड dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• क्लस्टर सीडर के लिए कई मास्क आकारों का समर्थन करें -
• डुअलस्टैक के लिए E2e प्रो जॉब https://github.com/kubernetes/test-infra/pull/12966

अरे, @leblancd मैं

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

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

@simplytunde यहाँ डॉक्स पीआर है - https://github.com/kubernetes/website/pull/16010

@lachie83 फ्रेंडली रिमाइंडर कोड 1.16 के लिए फ्रीज गुरुवार 8/29 को है। (जैसे कि आप उसे नहीं जानते थे)। ऐसा लगता है कि ये पीआर अभी भी बकाया हैं:
चरण 2 सेवाएं/समापन बिंदु - कुबेरनेट्स/कुबेरनेट्स#79386
चरण 2 क्यूब-प्रॉक्सी - कुबेरनेट्स/कुबेरनेट्स#79576

संबद्ध:
क्लस्टर सीडर के लिए कई मास्क आकारों का समर्थन करें - कुबेरनेट्स/कुबेरनेट्स#79993
डुअलस्टैक कुबेरनेट्स/टेस्ट-इन्फ्रा#12966 . के लिए E2e प्रो जॉब

हाय @ lachie83 @leblancd ऐसा लगता है जैसे https://github.com/kubernetes/kubernetes/pull/79576 और https://github.com/kubernetes/kubernetes/pull/79993 कोड फ्रीज से पहले विलय नहीं हुआ और यह नहीं है टाइड मर्ज पूल में । यह सुविधा v1.16 से टकराने वाली है। यदि आप अभी भी इसे 1.16 रिलीज़ का हिस्सा बनाना चाहते हैं, तो कृपया एक अपवाद दर्ज करें

@ kacole2 प्रतिक्रिया में देरी के लिए क्षमा याचना। प्राथमिक पीआर ट्रैकिंग कर रहे थे https://github.com/kubernetes/kubernetes/pull/79386। जहां तक ​​Kubernetes/kubernetes#79576 का सवाल है, हमने इसे 1.17 तक टालने का निर्णय लिया और इसके बजाय https://github.com/kubernetes/kubernetes/pull/82091 (सिग-नेटवर्क के साथ समझौते में) पर ध्यान केंद्रित किया, जो समान चरण 2 लक्ष्यों को पूरा करता है। केईपी में रखा गया था। इस रिलीज में अन्य संबंधित पीआर को ट्रैक किया गया था https://github.com/kubernetes/kubernetes/pull/80485 जो भी मर्ज किया गया है। Kubernetes/kubernetes#79993 को भी 1.17 . पर स्थगित कर दिया गया है

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

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

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

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

धन्यवाद!

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

हाय बॉब। खोज लेने के लिए धन्यवाद। मैं अभी भी इस एन्हांसमेंट के चरण 3 की योजना बना रहा हूं जो एन्हांसमेंट को पूरा करने के लिए पूरा करेगा। यह एन्हांसमेंट अभी भी इस रिलीज़ के अंत में अल्फा में होगा लेकिन चरण 3 संबंधित कार्य होगा जो 1.17 के भाग के रूप में k/k में आएगा।

दोहरे स्टैक के लिए 1.17 के लिए उच्च स्तरीय डिलिवरेबल्स की सूची यहां दी गई है। मैं इस सूची को रिलीज के दौरान अपडेट करूंगा।

• IPtables डुअल-स्टैक प्रॉक्सीयर - https://github.com/kubernetes/kubernetes/pull/79576
• Pod.Status.PodIPs के लिए डाउनवर्ड एपीआई समर्थन - https://github.com/kubernetes/kubernetes/pull/83123
• e2e एक सीएनआई प्लगइन का परीक्षण करें
• होस्टफ़ाइल परिवर्तन (होस्टनाम के लिए IPv6 पता /etc/hosts जोड़ने की आवश्यकता है) - https://github.com/kubernetes/kubernetes/pull/83123
• काइंड डुअल-स्टैक - https://github.com/kubernetes-sigs/kind/pull/692
• e2e सुइट अपडेट करें -
• समापन बिंदु टुकड़ा समर्थन
• Kubeadm के लिए डुअल-स्टैक समर्थन - https://github.com/kubernetes/kubeadm/issues/1612

बहुत सराहना की, कृपया धन्यवाद @ lachie83 ❤️ मैं आगे

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

@mrbobbytables मैंने सिग-नेटवर्क के माध्यम से योजना को संप्रेषित करने के बाद पीआर भी जोड़ा है। केईपी अभी भी implementable स्थिति में है और ये परिवर्तन विशेष रूप से 1.17 के हिस्से के रूप में नियोजित कार्य का दस्तावेजीकरण कर रहे हैं।

किसी बिंदु पर, मैं यह सुनिश्चित करना चाहता हूं कि https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ IPv6 DNS को कवर करता है। https://github.com/kubernetes/website/issues/15434 ट्रैक जो बदलते हैं; एक क्रॉस-रेफरेंस नोट करने के लिए यहां इसका उल्लेख करना।

चरण 2 e2e परीक्षण जोड़ने के लिए KEP अपडेट किया गया - https://github.com/kubernetes/enhancements/pull/1311

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

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

@lachie83

चूंकि हम 8 नवंबर को डॉक्स प्लेसहोल्डर पीआर समय सीमा के करीब पहुंच रहे हैं। कृपया k/वेबसाइट dev-1.17 शाखा के विरुद्ध एक प्राप्त करने का प्रयास करें।

अरे वहाँ @ lachie83 , मुझे पता है कि आप टैब
कोड फ्रीज बस कोने के आसपास है (14 नवंबर)। चीजें कैसी दिख रही हैं? क्या इससे पहले सब कुछ विलय होने की राह पर है?

धन्यवाद!

अरे @mrbobbytables! पिंग के लिए धन्यवाद। हम 1.17 में उतरने के लिए निम्नलिखित पीआर को ट्रैक कर रहे हैं। इस बदलाव से जुड़े एक या दो और पीआर भी हो सकते हैं। इन परिवर्तनों के लिए दस्तावेज़ों की आवश्यकता होगी। मैं एक प्लेसहोल्डर डॉक्स पीआर बढ़ाऊंगा

• क्यूब-प्रॉक्सी iptables मोड के लिए ड्यूलस्टैक समर्थन पीआर/82462
• डुअलस्टैक डाउनवर्ड एपीआई पीआर/82462
• ipvs मेटाप्रोक्सियर एंडपॉइंटस्लाइस सपोर्ट पीआर/84089 जोड़ें
• क्यूब-कंट्रोलर-मैनेजर पीआर/79993 में एकाधिक नोड सीडीआर मास्क की अनुमति दें

@irvifa - यहां प्लेसहोल्डर डॉक्स पीआर है। https://github.com/kubernetes/website/pull/17457

कूल थैंक्स @lachie83

@ lachie83 कल 1.17 रिलीज चक्र के लिए कोड फ्रीज है। ऐसा लगता है कि k/k PR को अभी तक मर्ज नहीं किया गया है। हम इसे 1.17 एन्हांसमेंट ट्रैकिंग शीट में जोखिम के रूप में चिह्नित कर रहे हैं।
क्या आपको लगता है कि 14 तारीख (गुरुवार) की ईओडी में इनका विलय कर दिया जाएगा? उस बिंदु के बाद, केवल रिलीज-अवरुद्ध मुद्दों और पीआर को अपवाद के साथ मील के पत्थर में अनुमति दी जाएगी।

धन्यवाद बॉब - मैं आज सिग-नेटवर्क के साथ इस पर चर्चा करूंगा और एक अपडेट प्रदान करूंगा।

अरे @mrbobbytables। यहां पीआर की एक सूची दी गई है जिसे हम आज ईओडी द्वारा विलय करने पर काम कर रहे हैं और सिग-नेटवर्क द्वारा अनुमोदित किया गया है।

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

शेष पीआर के 1.18 - https://github.com/kubernetes/kubernetes/pull/82462 पर पेन्ट किए जाने की संभावना है।

@mrbobbytables सिर्फ इस बात की पुष्टि कर रहा है कि ऊपर बताए गए सभी

बढ़िया, धन्यवाद @ lachie83!

और यह लाइव है! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

हम 1.18 में इस एन्हांसमेंट को बीटा में स्थानांतरित करने की योजना बना रहे हैं। इस पीआर के साथ केईपी में एन्हांसमेंट ग्रेजुएशन मानदंड और परीक्षण योजनाएं पाई जा सकती हैं - https://github.com/kubernetes/enhancements/pull/1429

/ मील का पत्थर 1.18

@ लची 83 : प्रदान किया गया मील का पत्थर इस भंडार के लिए मान्य नहीं है। इस भंडार में मील के पत्थर: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

मील का पत्थर साफ़ करने के लिए /milestone clear का उपयोग करें।

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

हम 1.18 में इस एन्हांसमेंट को बीटा में स्थानांतरित करने की योजना बना रहे हैं। इस पीआर के साथ केईपी में एन्हांसमेंट ग्रेजुएशन मानदंड और परीक्षण योजनाएं पाई जा सकती हैं - #1429

अपडेट @lachie83 के लिए धन्यवाद, मैंने इसे 1.18 स्प्रेडशीट में ट्रैक किए गए के रूप में चिह्नित किया है!

1.18 में उतरने के काम के हिस्से के रूप में कृपया निम्नलिखित पीआर को ट्रैक करें। https://github.com/kubernetes/kubernetes/pull/82462

ट्रैकिंग के लिए अन्य संबंधित पीआर जोड़ना:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

धन्यवाद @ लची 83!

हाय @ lachie83 , क्या आपके पास कोई अन्य पीआर है जिसे हमें उपर्युक्त लोगों के अलावा अन्य ट्रैक करना चाहिए?

हैलो, @lachie83 @leblancd - मैं 1.18 रिलीज टीम पर एक डॉक्स छाया हूं।

क्या 1.18 के लिए नियोजित इस एन्हांसमेंट कार्य के लिए किसी नए दस्तावेज़ या मौजूदा दस्तावेज़ों में संशोधन की आवश्यकता है?

यदि नहीं, तो क्या आप कृपया 1.18 एन्हांसमेंट ट्रैकर शीट को अपडेट कर सकते हैं (या मुझे बताएं और मैं ऐसा करूंगा)

यदि दस्तावेज़ अपडेट की आवश्यकता है, तो याद दिलाएं कि k/वेबसाइट (शाखा देव-1.18) के विरुद्ध प्लेसहोल्डर पीआर शुक्रवार, 28 फरवरी तक देय हैं।

अगर आपका कोई प्रश्न हैं, तो मुझे से पूछें!

अगर कोई v1.18 के लिए IPV6 या डुअल-स्टैक सामग्री का दस्तावेजीकरण करने में मदद चाहता है, तो मुझे एक कुहनी से हलका धक्का दें। मैं मदद करने में सक्षम हो सकता हूं।

अरे @ लची 83 ,

ऐसा लगता है कि Kubernetes-sigs/kind#692 अभी तक विलय नहीं हुआ है। क्या यह आपके बीटा ग्रेजुएशन के लिए महत्वपूर्ण है?

अरे @jeremyrickard @sethmccombs हमें इस पीआर को देखते हुए इसे स्नातक से बीटा तक खींचना होगा https://github.com/kubernetes/kubernetes/pull/86895। जब तक हमारे पास आगे बढ़ने का कोई उचित तरीका नहीं है, मुझे नहीं लगता कि इसे 1.18 . के लिए बीटा में स्थानांतरित करना बुद्धिमानी है

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

@lachie83 अपडेट के लिए धन्यवाद। मैंने इस एन्हांसमेंट को माइलस्टोन से हटा दिया है। १.१९ को इसके लिए तत्पर हैं। :)

मैं पुष्टि करना चाहता हूं कि ड्यूलस्टैक एन्हांसमेंट की स्थिति 1.18 में alpha में बनी हुई है। मैं वर्तमान में 1.19 में पूरा किए जाने वाले कार्य का आकलन करने के लिए समुदाय के साथ काम कर रहा हूं। यह संभावना है कि यह वृद्धि अभी भी 1.19 में अल्फा स्थिति में रहेगी, हालांकि मैं पुष्टि करना चाहता हूं। मैं 1.18 दस्तावेज़ों में एन्हांसमेंट स्थिति को दर्शाने के लिए दस्तावेज़ों को अद्यतन करने पर भी कार्रवाई करूँगा।

यदि वेबसाइट पर ऐसे पृष्ठ हैं जो ड्यूल-स्टैक कुबेरनेट्स को बीटा के रूप में दिखाते हैं, तो कृपया उन्हें k/वेबसाइट के विरुद्ध प्राथमिकता/महत्वपूर्ण-जल्द बग के रूप में दर्ज करें।

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

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

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

यदि वेबसाइट पर ऐसे पृष्ठ हैं जो ड्यूल-स्टैक कुबेरनेट्स को बीटा के रूप में दिखाते हैं, तो कृपया उन्हें k/वेबसाइट के विरुद्ध प्राथमिकता/महत्वपूर्ण-जल्द बग के रूप में दर्ज करें।

@sftim मैंने 1.17 और 1.18 में रिलीज लेबलिंग को संबोधित करने के लिए दो

@palnabarun हम 1.19 रिलीज समय सीमा में ड्यूलस्टैक केईपी को अपडेट करने के लिए काम कर रहे हैं, हालांकि वर्तमान में हमें नहीं लगता है कि हम 1.19 रिलीज में कोड परिवर्तन करेंगे। हमारे पास पहले से किए जा चुके कार्य के साथ एक अवरोधन समस्या है (धन्यवाद इसे alpha स्थिति में रखने के लिए)। अवरुद्ध समस्या https://github.com/kubernetes/kubernetes/pull/86895 है। हम इसे फॉलो केईपी अपडेट https://github.com/kubernetes/enhancements/pull/1679 के माध्यम से संबोधित करने की योजना बना रहे हैं, लेकिन प्रस्तावित बदलाव पर आम सहमति बनने में समय लगेगा। इस स्तर पर ड्यूलस्टैक एन्हांसमेंट alpha स्थिति में रहेगा जब तक कि हम वर्तमान कार्यान्वयन के साथ इस अवरोधन मुद्दे को संबोधित नहीं करते हैं। चीजें आगे बढ़ने पर मैं अपडेट प्रदान करूंगा।

धन्यवाद, अपडेट के लिए लैची। मैं सभी प्रयासों की सराहना करता हूं! :थोड़ा_मुस्कुराता_चेहरा:

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

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

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

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

हम चाहते हैं कि इस वृद्धि को 1.20 में ट्रैक किया जाए। इसे अद्यतन केप के अनुसार अल्फा अवस्था में फिर से लागू किया जाएगा - https://github.com/kubernetes/enhancements/pull/1679। कार्यान्वयन के लिए कृपया निम्नलिखित पीआर को ट्रैक करें - https://github.com/kubernetes/kubernetes/pull/91824। हम 1.20 रिलीज चक्र में समीक्षा को पूरा करने और पीआर को जल्दी मर्ज करने की योजना बना रहे हैं।

घर पर खेलने वालों के लिए 17 सितंबर की SIG नेटवर्क मीटिंग में चर्चा के अनुसार बीटा स्थिति में नवीनतम डुअल-स्टैक ग्रेजुएशन:

• क्यूबलेट डुअल-स्टैक स्वास्थ्य-जांच अस्पष्टता को हल करना चाहिए; https://github.com/kubernetes/enhancements/pull/1975 . के माध्यम से
• मौजूदा ड्यूल-स्टैक सेवाओं पीआर (सक्रिय समीक्षा के तहत) को समाप्त और मर्ज करना होगा; https://github.com/kubernetes/kubernetes/pull/91824 . के माध्यम से
• डुअल-स्टैक नोड आईपी के व्यवहार को अंतिम रूप देना चाहिए; https://github.com/kubernetes/enhancements/pull/1665 . के माध्यम से
• यह निर्धारित करना चाहिए कि सेवा के Spec.LoadBalancerIPs फ़ील्ड के लिए क्या (यदि कोई हो) परिवर्तन आवश्यक हैं

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

@dcbw अपडेट के लिए बहुत-बहुत धन्यवाद (क्षमा करें, मैं कॉल नहीं कर सका)। क्या इसे 1.20 में बीटा में बढ़ाने या केवल अल्फा में रहने के लिए समझ में आता है? अगर हम बीटा में जाना चाहते हैं तो क्या केईपी में स्नातक मानदंड अभी भी समझ में आता है कि यह एक पुन: कार्यान्वयन है https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -दोहरी-स्टैक। एमडी#स्नातक -मानदंड

@dcbw अपडेट के लिए बहुत-बहुत धन्यवाद (क्षमा करें, मैं कॉल नहीं कर सका)। क्या इसे 1.20 में बीटा में बढ़ाने या केवल अल्फा में रहने के लिए समझ में आता है? अगर हम बीटा में जाना चाहते हैं तो क्या केईपी में स्नातक मानदंड अभी भी समझ में आता है कि यह एक पुन: कार्यान्वयन है https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -दोहरी-स्टैक। एमडी#स्नातक -मानदंड

हालांकि, यह वास्तव में एक पुन: कार्यान्वयन नहीं है। पिछले सभी कार्य अभी भी मान्य हैं और आवश्यक अंतिम परिवर्तनों को अंतिम रूप देने के लिए 1.20 में कार्य इसके शीर्ष पर निर्माण कर रहा है जिनकी पहचान की गई है। सिग-नेटवर्क चर्चा की मेरी व्याख्या यह है कि @dcbw पोस्ट की गई सूची शेष ज्ञात मुद्दों का समूह है जिसे स्नातक स्तर की पढ़ाई के लिए हल करने की आवश्यकता है।

नमस्ते,

1.20 एन्हांसमेंट्स लीड यहां, मैं इसे ट्रैक के रूप में सेट करने जा रहा हूं, अगर कुछ भी बदलता है तो कृपया मुझे अपडेट करें :)

एक अनुस्मारक के रूप में एन्हांसमेंट फ़्रीज़ 6 अक्टूबर है।

एक नोट के रूप में केईपी एक पुराने प्रारूप का उपयोग कर रहा है जिसे हमने अपडेट किया है: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

श्रेष्ठ,
कर्स्टन

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

नमस्ते, @russellb -

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

https://github.com/kubernetes/kubernetes/pull/91824 में एपीआई परिवर्तनों को देखते हुए, पर्याप्त अलग है कि 1.20 के लिए दोहरे-स्टैक को अल्फा के रूप में चिह्नित करने से आवश्यक साबित होने वाले किसी भी पुन: कार्यान्वयन के लिए जगह की अनुमति मिल जाएगी। मुझे पता है कि हम सभी बीटा के लिए उत्सुक हैं, लेकिन आइए पहले पीआर को +9,319 −3,261 साथ लैंड करें और धूल को जमने दें। :)

Kubernetes/kubernetes#91824 में API परिवर्तनों को देखते हुए, यह काफी अलग है कि 1.20 के लिए दोहरे स्टैक को अल्फा के रूप में चिह्नित करने से आवश्यक साबित होने वाले किसी भी पुन: कार्यान्वयन के लिए जगह मिल जाएगी। मुझे पता है कि हम सभी बीटा के लिए उत्सुक हैं, लेकिन आइए पहले पीआर को +9,319 −3,261 साथ लैंड करें और धूल को जमने दें। :)

@bridgetkromhout हाँ, हमें API तत्परता के बारे में कोई निर्धारण करने से पहले https://github.com/kubernetes/kubernetes/pull/91824 पर उतरना होगा। मुझे वास्तव में उम्मीद है कि हम ASAP कर सकते हैं।

नमस्ते,

1.20 यहाँ वृद्धि छाया

चूंकि यह संवर्द्धन 1.20 में होने वाला है, कृपया इन महत्वपूर्ण आगामी तिथियों को ध्यान में रखें:
शुक्रवार, 6 नवंबर: सप्ताह 8 - डॉक्स प्लेसहोल्डर पीआर समय सीमा
गुरुवार, नवंबर १२: सप्ताह ९ - कोड फ़्रीज़

एक अनुस्मारक के रूप में, कृपया अपने सभी k/k PR के साथ-साथ डॉक्स PR को इस मुद्दे से लिंक करें ताकि हम उन्हें ट्रैक कर सकें।

शुक्रिया!

हाय @kinarashah @kikisdeliveryservice - मैंने सिग-नेटवर्क कॉल पर पुष्टि की है कि हमें 1.20 के लिए इसे अल्फा में पुनर्वर्गीकृत करने की आवश्यकता है। यह एक पूर्ण पुन: कार्यान्वयन है जिसे अल्फा चरण में सोखने और परीक्षण करने के लिए समय चाहिए।

नमस्ते @ lachie83 , 1.20 डॉक्स यहाँ छाया।

क्या 1.20 के लिए नियोजित इस एन्हांसमेंट कार्य के लिए किसी नए दस्तावेज़ या मौजूदा दस्तावेज़ों में संशोधन की आवश्यकता है?

यदि ऐसा है, तो कृपया k/website रेपो में dev-1.20 शाखा के विरुद्ध पीआर खोलने के लिए यहां दिए गए चरणों करें । यह पीआर इस समय सिर्फ एक प्लेसहोल्डर हो सकता है और इसे 6 नवंबर से पहले बनाया जाना चाहिए।

रिलीज़ के लिए दस्तावेज़ों की आवश्यकता से स्वयं को परिचित कराने के लिए दस्तावेज़ीकरण पर भी एक नज़र डालें।

शुक्रिया!

धन्यवाद @ reylejano-rxm - हमने कुबेरनेट्स/वेबसाइट खोली है#24725

नमस्ते @lachie83

डॉक्स पीआर बनाने के लिए धन्यवाद!

कृपया महत्वपूर्ण आगामी तिथियों को ध्यान में रखें:

• शुक्रवार, 6 नवंबर: सप्ताह 8 - डॉक्स प्लेसहोल्डर पीआर की समय सीमा हो गई !
• गुरुवार, नवंबर १२: सप्ताह ९ - कोड फ़्रीज़
• सोमवार, 23 नवंबर: सप्ताह 11 - डॉक्स पीआर समीक्षा के लिए तैयार

एक अनुस्मारक के रूप में, कृपया अपने सभी k/k PR के साथ-साथ डॉक्स PR को इस मुद्दे से लिंक करें ताकि रिलीज़ टीम ट्रैक कर सके।

हाय @kinarashah @kikisdeliveryservice - मैंने सिग-नेटवर्क कॉल पर पुष्टि की है कि हमें 1.20 के लिए इसे अल्फा में पुनर्वर्गीकृत करने की आवश्यकता है। यह एक पूर्ण पुन: कार्यान्वयन है जिसे अल्फा चरण में सोखने और परीक्षण करने के लिए समय चाहिए।

अरे @lachie83

उपर्युक्त को देखते हुए, मुझे लगता है कि यह अभी भी अल्फा के लिए है जैसा है? मुझे कोई बकाया पीआर नहीं दिख रहा है जिसे मर्ज करने की आवश्यकता है/काम पहले ही विलय कर दिया गया था।

_बस एक अनुस्मारक कि कोड फ़्रीज़ 2 दिनों में गुरुवार, 12 नवंबर को आ रहा है। सभी पीआर को उस तिथि तक मर्ज कर दिया जाना चाहिए, अन्यथा एक अपवाद की आवश्यकता

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

नमस्ते, @kikisdeliveryservice - हाँ, IPv4/IPv6 डुअल-स्टैक समर्थन (

यहाँ इस वृद्धि के लिए हमारे पास प्रगति है:

1) कोड https://github.com/kubernetes/kubernetes/pull/91824 से मर्ज किया गया है - 1.20 के लिए अल्फा होगा
2) उस कोड परिवर्तन को कवर करने वाले दस्तावेज़ अपडेट https://github.com/kubernetes/website/pull/24725/ में हैं - समीक्षा की गई और देव-1.20 शाखा में विलय कर दिया गया

क्या 1.20 के लिए कुछ और आवश्यक है जिसे हमने इस एन्हांसमेंट पर पूरा नहीं किया है?

@bridgetkromhout स्पष्ट अपडेट के लिए धन्यवाद, आप सब ठीक हैं!

ऐसा लगता है कि LoadBalancerIP में ServiceSpec अभी तक दोहरे स्टैक कार्यान्वयन का हिस्सा नहीं है। क्या इसका समर्थन करने की कोई योजना है या क्या मैंने इसे याद किया?

हाय @chenwng - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -डुअल - बैलेंसर -ऑपरेशन।

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

@chenwng दोहरे स्टैक क्लस्टर में LoadBalancerIPs लिए एक KEP पर काम किया जा रहा है - https://github.com/kubernetes/enhancements/pull/1992

जानकारी के लिए धन्यवाद, @aramase , @lachie83 ।