GA में Amazon EKS विंडोज़ में बग हैं, लेकिन यह सबसे तेज़ है

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

मुझे पता है कि विंडोज़ कंटेनर एक लोकप्रिय विषय नहीं हैं, और बहुत कम लोग उनका उपयोग करते हैं, लेकिन मैंने फिर भी इस लेख को लिखने का फैसला किया, क्योंकि कुबेरनेट्स और विंडोज़ पर हैबे पर कुछ लेख थे और अभी भी ऐसे लोग हैं।

शुरू

यह सब तब शुरू हुआ जब हमारी कंपनी में सेवाओं को कुबेरनेट्स में स्थानांतरित करने का निर्णय लिया गया, जो कि 70% विंडोज़ और 30% लिनक्स है। इस उद्देश्य के लिए, AWS EKS क्लाउड सेवा को संभावित विकल्पों में से एक माना गया था। 8 अक्टूबर, 2019 तक, AWS EKS विंडोज़ सार्वजनिक पूर्वावलोकन में था, मैंने इसके साथ शुरुआत की, कुबेरनेट्स का पुराना 1.11 संस्करण वहां इस्तेमाल किया गया था, लेकिन मैंने इसे वैसे भी जांचने का फैसला किया और देखा कि यह क्लाउड सेवा किस स्तर पर थी, क्या यह काम कर रही थी बिल्कुल, जैसा कि यह निकला, नहीं, पॉड्स को हटाने के अलावा इसमें एक बग था, जबकि पुराने पॉड्स ने विंडोज़ वर्कर नोड के समान सबनेट से आंतरिक आईपी के माध्यम से प्रतिक्रिया देना बंद कर दिया था।

इसलिए, उसी EC2 पर कुबेरनेट्स पर अपने स्वयं के क्लस्टर के पक्ष में AWS EKS के उपयोग को छोड़ने का निर्णय लिया गया, केवल हमें CloudFormation के माध्यम से सभी संतुलन और HA का वर्णन स्वयं करना होगा।

अमेज़ॅन ईकेएस विंडोज़ कंटेनर समर्थन अब आम तौर पर उपलब्ध है

मार्टिन बीबी द्वारा | 08 अक्टूबर 2019 को

इससे पहले कि मेरे पास अपने क्लस्टर के लिए क्लाउडफॉर्मेशन में एक टेम्पलेट जोड़ने का समय होता, मैंने यह समाचार देखा अमेज़ॅन ईकेएस विंडोज़ कंटेनर समर्थन अब आम तौर पर उपलब्ध है

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

ईकेएस क्लस्टर को वर्तमान वीपीसी और सबनेट में एकीकृत करना

सभी स्रोतों में, घोषणा के साथ-साथ दस्तावेज़ीकरण के ऊपर दिए गए लिंक में, क्लस्टर को या तो मालिकाना eksctl उपयोगिता के माध्यम से या CloudFormation + kubectl के माध्यम से तैनात करने का प्रस्ताव दिया गया था, केवल अमेज़ॅन में सार्वजनिक सबनेट का उपयोग करने के साथ-साथ एक निर्माण भी किया गया था। नए क्लस्टर के लिए अलग वीपीसी।

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

मेरे मामले में, यह रास्ता चुना गया था, मैंने मौजूदा वीपीसी का उपयोग किया, नए क्लस्टर के लिए केवल 2 सार्वजनिक सबनेट और 2 निजी सबनेट जोड़े, बेशक, दस्तावेज़ीकरण के अनुसार सभी नियमों को ध्यान में रखा गया था अपना Amazon EKS क्लस्टर VPC बनाएं.

एक शर्त यह भी थी: ईआईपी का उपयोग करते हुए सार्वजनिक सबनेट में कोई कार्यकर्ता नोड नहीं।

eksctl बनाम क्लाउडफॉर्मेशन

मैं तुरंत आरक्षण कर दूंगा कि मैंने क्लस्टर को तैनात करने के दोनों तरीकों को आजमाया, दोनों ही मामलों में तस्वीर एक जैसी थी।

मैं केवल eksctl का उपयोग करके एक उदाहरण दिखाऊंगा क्योंकि यहां कोड छोटा होगा। Eksctl का उपयोग करके, क्लस्टर को 3 चरणों में तैनात करें:

1. हम स्वयं क्लस्टर + लिनक्स वर्कर नोड बनाते हैं, जो बाद में सिस्टम कंटेनर और उसी दुर्भाग्यपूर्ण वीपीसी-नियंत्रक को होस्ट करेगा।

eksctl create cluster 
--name yyy 
--region www 
--version 1.14 
--vpc-private-subnets=subnet-xxxxx,subnet-xxxxx 
--vpc-public-subnets=subnet-xxxxx,subnet-xxxxx 
--asg-access 
--nodegroup-name linux-workers 
--node-type t3.small 
--node-volume-size 20 
--ssh-public-key wwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami auto 
--node-private-networking

किसी मौजूदा वीपीसी पर तैनात करने के लिए, बस अपने सबनेट की आईडी निर्दिष्ट करें, और eksctl स्वयं वीपीसी निर्धारित करेगा।

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

2. हम अपने क्लस्टर में वीपीसी-नियंत्रक स्थापित करते हैं, जो फिर हमारे कार्यकर्ता नोड्स को संसाधित करेगा, मुफ्त आईपी पते की संख्या की गणना करेगा, साथ ही उदाहरण पर ईएनआई की संख्या, उन्हें जोड़ और हटा देगा।

eksctl utils install-vpc-controllers --name yyy --approve

3. आपके सिस्टम कंटेनर आपके लिनक्स वर्कर नोड पर वीपीसी-कंट्रोलर सहित सफलतापूर्वक लॉन्च होने के बाद, जो कुछ बचा है वह विंडोज़ वर्कर्स के साथ एक और नोडग्रुप बनाना है।

eksctl create nodegroup 
--region www 
--cluster yyy 
--version 1.14 
--name windows-workers 
--node-type t3.small 
--ssh-public-key wwwwwwwwww 
--nodes 1 
--nodes-min 1 
--nodes-max 2 
--node-ami-family WindowsServer2019CoreContainer 
--node-ami ami-0573336fc96252d05 
--node-private-networking

जब आपका नोड आपके क्लस्टर से सफलतापूर्वक कनेक्ट हो गया है और सब कुछ ठीक लग रहा है, तो यह तैयार स्थिति में है, लेकिन नहीं।

वीपीसी-नियंत्रक में त्रुटि

यदि हम विंडोज़ वर्कर नोड पर पॉड्स चलाने का प्रयास करते हैं, तो हमें त्रुटि मिलेगी:

NetworkPlugin cni failed to teardown pod "windows-server-iis-7dcfc7c79b-4z4v7_default" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address]

यदि हम गहराई से देखें, तो हम देखते हैं कि AWS में हमारा उदाहरण इस तरह दिखता है:

और यह इस प्रकार होना चाहिए:

इससे यह स्पष्ट है कि वीपीसी-नियंत्रक ने किसी कारण से अपना हिस्सा पूरा नहीं किया और इंस्टेंस में नए आईपी पते नहीं जोड़ सका ताकि पॉड्स उनका उपयोग कर सकें।

आइए वीपीसी-नियंत्रक पॉड के लॉग देखें और यही हम देखते हैं:

कुबेक्टल लॉग -एन क्यूब-सिस्टम

I1011 06:32:03.910140       1 watcher.go:178] Node watcher processing node ip-10-xxx.ap-xxx.compute.internal.
I1011 06:32:03.910162       1 manager.go:109] Node manager adding node ip-10-xxx.ap-xxx.compute.internal with instanceID i-088xxxxx.
I1011 06:32:03.915238       1 watcher.go:238] Node watcher processing update on node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.200423       1 manager.go:126] Node manager failed to get resource vpc.amazonaws.com/CIDRBlock  pool on node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxxx
E1011 06:32:08.201211       1 watcher.go:183] Node watcher failed to add node ip-10-xxx.ap-xxx.compute.internal: failed to find the route table for subnet subnet-0xxx
I1011 06:32:08.201229       1 watcher.go:259] Node watcher adding key ip-10-xxx.ap-xxx.compute.internal (0): failed to find the route table for subnet subnet-0xxxx
I1011 06:32:08.201302       1 manager.go:173] Node manager updating node ip-10-xxx.ap-xxx.compute.internal.
E1011 06:32:08.201313       1 watcher.go:242] Node watcher failed to update node ip-10-xxx.ap-xxx.compute.internal: node manager: failed to find node ip-10-xxx.ap-xxx.compute.internal.

Google पर खोज करने से कुछ भी हासिल नहीं हुआ, क्योंकि जाहिर तौर पर अभी तक किसी ने भी ऐसा बग नहीं पकड़ा था, या इस पर कोई मुद्दा पोस्ट नहीं किया था, मुझे पहले खुद ही विकल्पों के बारे में सोचना पड़ा। पहली बात जो दिमाग में आई वह यह थी कि शायद वीपीसी-नियंत्रक आईपी-10-xxx.ap-xxx.compute.internal को हल नहीं कर सकता है और उस तक नहीं पहुंच सकता है और इसलिए त्रुटियां होती हैं।

हां, वास्तव में, हम वीपीसी में कस्टम डीएनएस सर्वर का उपयोग करते हैं और, सिद्धांत रूप में, हम अमेज़ॅन का उपयोग नहीं करते हैं, इसलिए इस ap-xxx.compute.internal डोमेन के लिए अग्रेषण भी कॉन्फ़िगर नहीं किया गया था। मैंने इस विकल्प का परीक्षण किया, और यह परिणाम नहीं लाया, शायद परीक्षण साफ नहीं था, और इसलिए, आगे, तकनीकी सहायता के साथ संवाद करते समय, मैं उनके विचार के आगे झुक गया।

चूँकि वास्तव में कोई विचार नहीं थे, सभी सुरक्षा समूह eksctl द्वारा ही बनाए गए थे, इसलिए उनकी सेवाक्षमता के बारे में कोई संदेह नहीं था, रूट टेबल भी सही थे, नेट, डीएनएस, वर्कर नोड्स के साथ इंटरनेट का उपयोग भी था।

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

दो विकल्प थे:

1. इसे छोड़ दें और तब तक प्रतीक्षा करें जब तक कोई AWS में इस बग का वर्णन न कर दे और इसे ठीक न कर दे, और तब आप सुरक्षित रूप से AWS EKS विंडोज़ का उपयोग कर सकते हैं, क्योंकि वे अभी-अभी GA में रिलीज़ हुए हैं (इस लेख को लिखने के समय 8 दिन बीत चुके हैं), कई लोग संभवतः ऐसा करेंगे मेरे जैसा ही मार्ग अपनाओ।
2. एडब्ल्यूएस समर्थन को लिखें और उन्हें हर जगह से लॉग के पूरे समूह के साथ समस्या का सार बताएं और उन्हें साबित करें कि आपके वीपीसी और सबनेट का उपयोग करते समय उनकी सेवा काम नहीं करती है, यह कुछ भी नहीं है कि हमारे पास व्यावसायिक समर्थन था, आपको इसका उपयोग करना चाहिए यह कम से कम एक बार :)

AWS इंजीनियरों के साथ संचार

पोर्टल पर टिकट बनाने के बाद, मैंने गलती से वेब - ईमेल या सहायता केंद्र के माध्यम से मुझे जवाब देना चुना, इस विकल्प के माध्यम से वे आपको कुछ दिनों के बाद जवाब दे सकते हैं, इस तथ्य के बावजूद कि मेरे टिकट में गंभीरता - सिस्टम ख़राब था, जो इसका मतलब था <12 घंटे के भीतर प्रतिक्रिया, और चूँकि व्यवसाय सहायता योजना में 24/7 समर्थन है, मुझे सर्वश्रेष्ठ की आशा थी, लेकिन यह हमेशा की तरह निकला।

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

हमने लगातार 3 घंटों तक इसके साथ ऑनलाइन डिबग किया, लॉग्स को स्थानांतरित किया, समस्या का अनुकरण करने के लिए एडब्ल्यूएस प्रयोगशाला में उसी क्लस्टर को तैनात किया, मेरी ओर से क्लस्टर को फिर से बनाया, और इसी तरह, केवल एक चीज जो हम तक पहुंची वह यह है कि लॉग से यह स्पष्ट था कि रिसोल AWS आंतरिक डोमेन नाम पर काम नहीं कर रहा था, जिसके बारे में मैंने ऊपर लिखा था, और हर्षद माधव ने मुझसे फ़ॉरवर्डिंग बनाने के लिए कहा, कथित तौर पर हम कस्टम DNS का उपयोग करते हैं और यह एक समस्या हो सकती है।

अग्रेषण

ap-xxx.compute.internal  -> 10.x.x.2 (VPC CIDRBlock)
amazonaws.com -> 10.x.x.2 (VPC CIDRBlock)

यही किया गया, दिन ख़त्म हो गया। हर्षद माधव ने इसे जांचने के लिए वापस लिखा और इसे काम करना चाहिए, लेकिन नहीं, समाधान से बिल्कुल भी मदद नहीं मिली।

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

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

अंतिम

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

हम उनके वीपीसी-कंट्रोलर में -stderrthreshold=debug को सक्षम करने के बिंदु पर कब पहुंचे, और आगे क्या हुआ? बेशक यह काम नहीं करता है) पॉड बस इस विकल्प से शुरू नहीं होता है, केवल -stderrthreshold=info काम करता है।

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

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

आवश्यक सबनेट के साथ मुख्य रूट तालिका के लिए मैन्युअल रूप से एसोसिएशन जोड़कर, और नोडग्रुप को फिर से बनाकर, सब कुछ पूरी तरह से काम करता है।

मुझे उम्मीद है कि अरुण बी वास्तव में ईकेएस डेवलपर्स को इस बग की रिपोर्ट करेंगे और हम वीपीसी-नियंत्रक का एक नया संस्करण देखेंगे जहां सब कुछ बॉक्स से बाहर काम करेगा। वर्तमान में नवीनतम संस्करण है: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
यह समस्या है.

अंत तक पढ़ने वाले सभी को धन्यवाद, कार्यान्वयन से पहले उत्पादन में आप जो कुछ भी उपयोग करने जा रहे हैं उसका परीक्षण करें।

स्रोत: www.habr.com