GA मा Amazon EKS Windows मा बगहरू छन्, तर सबैभन्दा छिटो छ

शुभ दिउँसो, म तपाइँसँग विन्डोज कन्टेनरहरूको लागि AWS EKS (इलास्टिक कुबर्नेट्स सेवा) सेवा सेटअप र प्रयोग गर्ने मेरो अनुभव साझा गर्न चाहन्छु, वा बरु यसलाई प्रयोग गर्ने असम्भवताको बारेमा, र AWS प्रणाली कन्टेनरमा फेला परेको बग, तीहरूको लागि। जो विन्डोज कन्टेनरहरूको लागि यो सेवामा रुचि राख्छन्, कृपया बिरालो अन्तर्गत।

मलाई थाहा छ कि विन्डोज कन्टेनरहरू लोकप्रिय विषय होइनन्, र थोरै मानिसहरूले तिनीहरूलाई प्रयोग गर्छन्, तर मैले अझै पनि यो लेख लेख्ने निर्णय गरें, किनकि कुबर्नेट्स र विन्डोजमा हब्रेमा केही लेखहरू थिए र त्यहाँ अझै पनि त्यस्ता व्यक्तिहरू छन्।

Начало

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

त्यसकारण, एउटै EC2 मा kubernetes मा हाम्रो आफ्नै क्लस्टरको पक्षमा AWS EKS को प्रयोग त्याग्न निर्णय गरियो, केवल हामीले CloudFormation मार्फत सबै सन्तुलन र HA आफैंलाई वर्णन गर्नुपर्नेछ।

Amazon EKS विन्डोज कन्टेनर समर्थन अब सामान्यतया उपलब्ध छ

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

मेरो आफ्नै क्लस्टरको लागि CloudFormation मा टेम्प्लेट थप्ने समय हुनु अघि, मैले यो समाचार देखेँ Amazon EKS विन्डोज कन्टेनर समर्थन अब सामान्यतया उपलब्ध छ

निस्सन्देह, मैले मेरो सबै कामलाई अलग राखें र तिनीहरूले GA को लागि के गरे, र सार्वजनिक पूर्वावलोकनको साथ सबै कुरा कसरी परिवर्तन भयो भनेर अध्ययन गर्न थाले। हो, AWS, राम्रो भयो, संस्करण १.१४ मा विन्डोज वर्कर नोडका लागि छविहरू अद्यावधिक गरियो, साथै क्लस्टर आफैं, संस्करण १.१४ EKS मा, अब विन्डोज नोडहरूलाई समर्थन गर्दछ। मा सार्वजनिक पूर्वावलोकन द्वारा परियोजना github तिनीहरूले यसलाई कभर गरे र भने अब आधिकारिक कागजातहरू यहाँ प्रयोग गर्नुहोस्: EKS विन्डोज समर्थन

हालको VPC र सबनेटहरूमा EKS क्लस्टरलाई एकीकृत गर्दै

सबै स्रोतहरूमा, घोषणामा माथिको लिङ्कमा साथै कागजातहरूमा, यो क्लस्टरलाई या त स्वामित्व eksctl उपयोगिता मार्फत वा CloudFormation + kubectl मार्फत, Amazon मा सार्वजनिक सबनेटहरू प्रयोग गरेर, साथै सिर्जना गर्ने प्रस्ताव गरिएको थियो। नयाँ क्लस्टरको लागि अलग VPC।

यो विकल्प धेरैका लागि उपयुक्त छैन; पहिलो, एउटा छुट्टै VPC भनेको यसको लागत + तपाईंको हालको VPC मा पियरिङ ट्राफिकको अतिरिक्त लागत हो। AWS मा आफ्नै बहु AWS खाताहरू, VPC, सबनेटहरू, मार्ग तालिकाहरू, ट्रान्जिट गेटवे र यस्तै अन्यसँग पहिले नै तयार पूर्वाधार भएकाहरूले के गर्नुपर्छ? अवश्य पनि, तपाइँ यो सबै तोड्न वा पुन: गर्न चाहनुहुन्न, र तपाइँले नयाँ EKS क्लस्टरलाई हालको सञ्जाल पूर्वाधारमा एकीकृत गर्न आवश्यक छ, अवस्थित VPC प्रयोग गरेर र विभाजनको लागि, क्लस्टरको लागि नयाँ सबनेटहरू सिर्जना गर्नुहोस्।

मेरो मामलामा, यो बाटो रोजिएको थियो, मैले अवस्थित VPC प्रयोग गरें, नयाँ क्लस्टरको लागि केवल 2 सार्वजनिक सबनेटहरू र 2 निजी सबनेटहरू थपे, अवश्य पनि, कागजात अनुसार सबै नियमहरू ध्यानमा राखिएको थियो। आफ्नो Amazon EKS क्लस्टर VPC सिर्जना गर्नुहोस्.

त्यहाँ एउटा शर्त पनि थियो: EIP प्रयोग गरेर सार्वजनिक सबनेटहरूमा कुनै कार्यकर्ता नोडहरू।

eksctl बनाम CloudFormation

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

म eksctl प्रयोग गरेर मात्र उदाहरण देखाउनेछु किनकि यहाँ कोड छोटो हुनेछ। eksctl प्रयोग गरेर, क्लस्टरलाई 3 चरणहरूमा प्रयोग गर्नुहोस्:

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

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

अवस्थित VPC मा डिप्लोय गर्नको लागि, केवल तपाईंको सबनेटहरूको आईडी निर्दिष्ट गर्नुहोस्, र eksctl ले VPC आफै निर्धारण गर्नेछ।

तपाइँको कार्यकर्ता नोडहरू निजी सबनेटमा मात्र तैनात गरिएको छ भनी सुनिश्चित गर्न, तपाइँले नोडग्रुपको लागि --node-private-networking निर्दिष्ट गर्न आवश्यक छ।

2. हामी हाम्रो क्लस्टरमा vpc-कन्ट्रोलर स्थापना गर्छौं, जसले त्यसपछि हाम्रा कार्यकर्ता नोडहरू प्रशोधन गर्नेछ, नि:शुल्क आईपी ठेगानाहरूको संख्या, साथै उदाहरणमा ENI हरूको संख्या, थप्दै र हटाउने।

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

3. तपाईंको प्रणाली कन्टेनरहरू vpc-कन्ट्रोलर सहित तपाईंको लिनक्स कार्यकर्ता नोडमा सफलतापूर्वक सुरु गरिसकेपछि, विन्डोज कार्यकर्ताहरूसँग अर्को नोडसमूह सिर्जना गर्न बाँकी छ।

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

तपाईंको नोड सफलतापूर्वक तपाईंको क्लस्टरमा जडान भएपछि र सबै कुरा ठीक छ जस्तो देखिन्छ, यो तयार स्थितिमा छ, तर होइन।

vpc-नियन्त्रकमा त्रुटि

यदि हामीले विन्डोज वर्कर नोडमा पोडहरू चलाउने प्रयास गर्छौं भने, हामीले त्रुटि प्राप्त गर्नेछौं:

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 मा हाम्रो उदाहरण यस्तो देखिन्छ:

र यो यस्तो हुनुपर्छ:

यसबाट यो स्पष्ट छ कि vpc-नियन्त्रकले कुनै कारणले आफ्नो भाग पूरा गरेन र उदाहरणमा नयाँ IP ठेगानाहरू थप्न सकेन ताकि पोडहरूले तिनीहरूलाई प्रयोग गर्न सकून्।

vpc-नियन्त्रक पोडको लगहरू हेरौं र यो हामीले देख्छौं:

kubectl लग -एन कुबे-प्रणाली

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.

गुगलमा खोजीहरूले केहि पनि निम्त्याउन सकेन, किनकि स्पष्ट रूपमा कसैले पनि त्यस्तो बग समातेको थिएन, वा यसमा कुनै मुद्दा पोष्ट गरेको थिएन, मैले पहिले आफैं विकल्पहरू सोच्नुपर्‍यो। दिमागमा आएको पहिलो कुरा यो थियो कि शायद vpc-नियन्त्रकले ip-10-xxx.ap-xxx.compute.internal लाई समाधान गर्न सक्दैन र यसमा पुग्न सक्दैन र त्यसैले त्रुटिहरू देखा पर्दछ।

हो, वास्तवमा, हामी VPC मा अनुकूलन DNS सर्भरहरू प्रयोग गर्छौं र, सिद्धान्तमा, हामी Amazon सर्भरहरू प्रयोग गर्दैनौं, त्यसैले यो ap-xxx.compute.internal डोमेनको लागि फर्वार्डिङ पनि कन्फिगर गरिएको थिएन। मैले यो विकल्पको परीक्षण गरें, र यसले नतिजा ल्याउन सकेन, सायद परीक्षण सफा थिएन, र त्यसैले, अगाडि, प्राविधिक सहयोगसँग कुराकानी गर्दा, मैले उनीहरूको विचारमा झुकेँ।

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

यसबाहेक, यदि तपाईंले —node-private-networking प्रयोग नगरी सार्वजनिक सबनेटमा कार्यकर्ता नोड तैनाथ गर्नुभयो भने, यो नोड तुरुन्तै vpc-नियन्त्रकद्वारा अद्यावधिक गरिएको थियो र सबै कुरा घडीको काम जस्तै काम गर्थे।

त्यहाँ दुई विकल्प थिए:

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

AWS इन्जिनियरहरु संग संचार

पोर्टलमा टिकट सिर्जना गरिसकेपछि, मैले गल्तीले वेब - इमेल वा समर्थन केन्द्र मार्फत मलाई जवाफ दिन रोजें, यो विकल्प मार्फत उनीहरूले तपाईंलाई केही दिन पछि जवाफ दिन सक्छन्, मेरो टिकटको गम्भीरता - प्रणाली बिग्रिएको तथ्यको बावजुद। <12 घण्टा भित्र प्रतिक्रियाको मतलब, र व्यापार समर्थन योजनामा ​​24/7 समर्थन भएकोले, मैले सबै भन्दा राम्रोको लागि आशा गरें, तर यो सधैं जस्तै भयो।

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

हामीले लगातार 3 घण्टाको लागि यसलाई अनलाइनसँग डिबग गर्यौं, लगहरू स्थानान्तरण गर्दै, समस्याको अनुकरण गर्न AWS प्रयोगशालामा एउटै क्लस्टर तैनाथ गर्ने, मेरो तर्फबाट क्लस्टर पुन: सिर्जना गर्ने, र यस्तै अन्य कुराहरू, हामी आइपुगेको एउटै कुरा हो। लगहरूमा यो स्पष्ट थियो कि resol ले AWS आन्तरिक डोमेन नामहरू काम गरिरहेको छैन, जुन मैले माथि लेखेको छु, र हर्षद माधवले मलाई फर्वार्डिङ सिर्जना गर्न भन्नुभयो, कथित रूपमा हामीले अनुकूलन DNS प्रयोग गर्छौं र यो समस्या हुन सक्छ।

फर्वार्ड गर्दै

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

त्यसै गरे, दिन सकियो।हर्षद माधवले फेरि जाँच गर्न लेखे र काम गर्नुपर्छ, तर अहँ, संकल्पले केही काम गरेन।

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

जसमा मैले उनलाई विनम्रताका साथ छोड्न र मेरो टिकटमा अरू कसैलाई नियुक्त गर्न भनें यदि तपाईंलाई समस्या कहाँ खोज्ने थाहा छैन भने।

समाप्त

तेस्रो दिन, नयाँ इन्जिनियर अरुण बी. मलाई नियुक्त गरियो, र उहाँसँग कुराकानीको सुरुदेखि नै यो पहिलेका 3 इन्जिनियरहरू होइनन् भनेर तुरुन्तै स्पष्ट भयो। उनले सम्पूर्ण इतिहास पढे र तुरुन्तै ps1 मा आफ्नै लिपि प्रयोग गरेर लगहरू सङ्कलन गर्न आग्रह गरे, जुन उसको गिथबमा थियो। क्लस्टरहरू सिर्जना गर्ने, कमाण्ड परिणामहरू आउटपुट गर्ने, लगहरू सङ्कलन गर्ने सबै पुनरावृत्तिहरूद्वारा यो फेरि पछ्याइएको थियो, तर अरूण बी मलाई सोधिएका प्रश्नहरूको न्याय गर्दै सही दिशामा अघि बढिरहेका थिए।

हामीले तिनीहरूको vpc-कन्ट्रोलरमा -stderrthreshold=debug सक्षम गर्ने बिन्दुमा कहिले पुग्यौं, र त्यसपछि के भयो? अवश्य पनि यसले काम गर्दैन) पोड केवल यो विकल्पको साथ सुरु हुँदैन, केवल -stderrthreshold=info काम गर्दछ।

हामीले यहाँ समाप्त गर्यौं र अरुण बीले भने कि उहाँले उही त्रुटि प्राप्त गर्न मेरो चरणहरू पुन: उत्पादन गर्ने प्रयास गर्नुहुन्छ। अर्को दिन मैले अरुण बी बाट प्रतिक्रिया प्राप्त गरे। उसले यो मामला छोडेन, तर तिनीहरूको vpc-नियन्त्रकको समीक्षा कोड लिए र यो कहाँ छ र किन काम गर्दैन भनेर पत्ता लगाए:

तसर्थ, यदि तपाइँ तपाइँको VPC मा मुख्य मार्ग तालिका प्रयोग गर्नुहुन्छ भने, तब पूर्वनिर्धारित रूपमा यसमा आवश्यक सबनेटहरूसँग सम्बद्धता छैन, जुन vpc-नियन्त्रकको लागि आवश्यक छ, सार्वजनिक सबनेटको मामलामा, योसँग अनुकूलन मार्ग तालिका छ। जसको एउटा संघ छ।

म्यानुअल रूपमा आवश्यक सबनेटहरूको साथ मुख्य मार्ग तालिकाको लागि संघहरू थपेर, र नोडसमूह पुन: सिर्जना गरेर, सबै कुरा पूर्ण रूपमा काम गर्दछ।

मलाई आशा छ कि अरुण B. ले यो बग वास्तवमा EKS विकासकर्ताहरूलाई रिपोर्ट गर्नेछ र हामी vpc-कन्ट्रोलरको नयाँ संस्करण देख्नेछौं जहाँ सबै कुरा बक्स बाहिर काम गर्नेछ। हाल नवीनतम संस्करण हो: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
यो समस्या छ।

अन्त्यमा पढ्ने सबैलाई धन्यवाद, कार्यान्वयन गर्नु अघि तपाईंले उत्पादनमा प्रयोग गर्न लाग्नुभएको सबै कुराको परीक्षण गर्नुहोस्।

स्रोत: www.habr.com