GA मधील Amazon EKS Windows मध्ये बग आहेत, परंतु ते सर्वात वेगवान आहे

शुभ दुपार, विंडोज कंटेनर्ससाठी AWS EKS (इलॅस्टिक कुबर्नेट्स सर्व्हिस) सेवा सेट अप करण्याचा आणि वापरण्याचा माझा अनुभव, किंवा त्याऐवजी वापरण्याची अशक्यता आणि AWS सिस्टम कंटेनरमध्ये आढळलेल्या बगबद्दल, मला तुमच्यासोबत शेअर करायचे आहे. ज्यांना विंडोज कंटेनर्ससाठी या सेवेमध्ये स्वारस्य आहे, कृपया मांजरीच्या खाली.

मला माहित आहे की विंडोज कंटेनर हा लोकप्रिय विषय नाही आणि काही लोक त्यांचा वापर करतात, परंतु तरीही मी हा लेख लिहिण्याचा निर्णय घेतला, कारण कुबर्नेट्स आणि विंडोजवर हॅब्रेवर दोन लेख होते आणि अजूनही असे लोक आहेत.

Начало

आमच्या कंपनीतील सेवा 70% Windows आणि 30% Linux असलेल्या kubernetes वर स्थलांतरित करण्याचा निर्णय घेतल्यावर हे सर्व सुरू झाले. या उद्देशासाठी, AWS EKS क्लाउड सेवा संभाव्य पर्यायांपैकी एक मानली गेली. 8 ऑक्टोबर 2019 पर्यंत, AWS EKS विंडोज पब्लिक प्रिव्ह्यूमध्ये होती, मी त्यापासून सुरुवात केली, कुबर्नेट्सची जुनी 1.11 आवृत्ती तिथे वापरली गेली होती, पण तरीही मी ती तपासण्याचे ठरवले आणि ही क्लाउड सेवा कोणत्या टप्प्यावर आहे, ती कार्यरत आहे की नाही हे पाहण्याचा निर्णय घेतला. अजिबात, जसे हे दिसून आले की, नाही, त्यात पॉड्स काढून टाकण्याच्या व्यतिरिक्त एक बग होता, तर जुन्यांनी विंडोज वर्कर नोडच्या समान सबनेटवरून अंतर्गत आयपीद्वारे प्रतिसाद देणे थांबवले.

म्हणून, त्याच EC2 वरील कुबर्नेट्सवरील आमच्या स्वतःच्या क्लस्टरच्या बाजूने AWS EKS चा वापर सोडून देण्याचा निर्णय घेण्यात आला, फक्त आम्हाला क्लाउडफॉर्मेशनद्वारे सर्व संतुलन आणि HA चे वर्णन करावे लागेल.

Amazon EKS Windows कंटेनर सपोर्ट आता सामान्यतः उपलब्ध आहे

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

माझ्या स्वतःच्या क्लस्टरसाठी CloudFormation मध्ये टेम्पलेट जोडण्याची वेळ येण्यापूर्वी, मी ही बातमी पाहिली Amazon EKS Windows कंटेनर सपोर्ट आता सामान्यतः उपलब्ध आहे

अर्थात, मी माझे सर्व काम बाजूला ठेवले आणि त्यांनी GA साठी काय केले आणि सार्वजनिक पूर्वावलोकनाने सर्वकाही कसे बदलले याचा अभ्यास करण्यास सुरुवात केली. होय, AWS, चांगले केले, विंडोज वर्कर नोडसाठी आवृत्ती 1.14, तसेच क्लस्टर स्वतः, EKS मधील आवृत्ती 1.14 वर प्रतिमा अद्यतनित केल्या, आता विंडोज नोड्सला समर्थन देते. येथे सार्वजनिक पूर्वावलोकनाद्वारे प्रकल्प github त्यांनी ते झाकून टाकले आणि आता अधिकृत कागदपत्रे येथे वापरा: ईकेएस विंडोज सपोर्ट

सध्याच्या VPC आणि सबनेटमध्ये EKS क्लस्टर समाकलित करणे

सर्व स्त्रोतांमध्ये, घोषणेवरील वरील लिंकमध्ये तसेच दस्तऐवजीकरणामध्ये, क्लस्टर एकतर मालकीच्या eksctl युटिलिटीद्वारे किंवा CloudFormation + kubectl द्वारे तैनात करण्याचा प्रस्ताव होता, फक्त Amazon मध्ये सार्वजनिक सबनेट वापरून, तसेच एक तयार नवीन क्लस्टरसाठी वेगळे VPC.

हा पर्याय अनेकांसाठी योग्य नाही; प्रथम, स्वतंत्र VPC म्हणजे त्याच्या खर्चासाठी अतिरिक्त खर्च + तुमच्या सध्याच्या VPC वरील रहदारी. ज्यांच्याकडे आधीच AWS मध्ये स्वतःची एकाधिक AWS खाती, VPC, सबनेट्स, रूट टेबल, ट्रान्झिट गेटवे इत्यादींसह तयार पायाभूत सुविधा आहेत त्यांनी काय करावे? अर्थात, तुम्ही हे सर्व खंडित करू इच्छित नाही किंवा पुन्हा करू इच्छित नाही आणि तुम्हाला नवीन EKS क्लस्टर सध्याच्या नेटवर्क इन्फ्रास्ट्रक्चरमध्ये समाकलित करणे आवश्यक आहे, विद्यमान VPC वापरून आणि वेगळे करण्यासाठी, क्लस्टरसाठी जास्तीत जास्त नवीन सबनेट तयार करा.

माझ्या बाबतीत, हा मार्ग निवडला गेला, मी विद्यमान व्हीपीसी वापरला, नवीन क्लस्टरसाठी फक्त 2 सार्वजनिक सबनेट आणि 2 खाजगी सबनेट जोडले, अर्थातच, सर्व नियम दस्तऐवजीकरणानुसार विचारात घेतले गेले. तुमचा Amazon EKS क्लस्टर VPC तयार करा.

एक अट देखील होती: ईआयपी वापरून सार्वजनिक सबनेटमध्ये कोणतेही कार्यकर्ता नोड नाहीत.

eksctl vs 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-कंट्रोलर स्थापित करतो, जे नंतर आमच्या कार्यकर्ता नोड्सवर प्रक्रिया करेल, विनामूल्य IP पत्त्यांची संख्या मोजेल, तसेच उदाहरणावर 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.

Google वरील शोधांमुळे काहीही घडले नाही, कारण वरवर पाहता कोणीही अद्याप असा बग पकडला नव्हता किंवा त्यावर कोणतीही समस्या पोस्ट केली नव्हती, मला प्रथम स्वतः पर्यायांचा विचार करावा लागला. पहिली गोष्ट जी मनात आली ती म्हणजे कदाचित vpc-कंट्रोलर ip-10-xxx.ap-xxx.compute.internal चे निराकरण करू शकत नाही आणि त्यापर्यंत पोहोचू शकत नाही आणि त्यामुळे त्रुटी उद्भवतात.

होय, खरंच, आम्ही VPC मध्ये सानुकूल DNS सर्व्हर वापरतो आणि तत्त्वतः, आम्ही Amazon वापरत नाही, त्यामुळे या ap-xxx.compute.internal डोमेनसाठी फॉरवर्डिंग देखील कॉन्फिगर केलेले नाही. मी या पर्यायाची चाचणी केली, आणि त्याचा परिणाम झाला नाही, कदाचित चाचणी स्वच्छ नव्हती आणि म्हणूनच, पुढे, तांत्रिक समर्थनाशी संवाद साधताना, मी त्यांच्या कल्पनेला बळी पडलो.

प्रत्यक्षात कोणतीही कल्पना नसल्यामुळे, सर्व सुरक्षा गट eksctl द्वारेच तयार केले गेले होते, त्यामुळे त्यांच्या सेवाक्षमतेबद्दल कोणतीही शंका नाही, मार्ग तक्ते देखील योग्य आहेत, nat, dns, कार्यकर्ता नोड्ससह इंटरनेट प्रवेश देखील होता.

शिवाय, तुम्ही —node-private-networking न वापरता सार्वजनिक सबनेटवर वर्कर नोड तैनात केल्यास, हा नोड त्वरित vpc-कंट्रोलरद्वारे अद्यतनित केला जातो आणि सर्वकाही घड्याळाच्या कामाप्रमाणे कार्य करते.

दोन पर्याय होते:

1. ते सोडून द्या आणि कोणीतरी AWS मध्ये या बगचे वर्णन करेपर्यंत प्रतीक्षा करा आणि त्यांनी त्याचे निराकरण करेपर्यंत, आणि नंतर तुम्ही AWS EKS Windows सुरक्षितपणे वापरू शकता, कारण ते नुकतेच GA मध्ये रिलीज झाले आहेत (हा लेख लिहिताना 8 दिवस उलटून गेले आहेत), बरेच जण कदाचित माझ्यासारखाच मार्ग अनुसरण करा.
2. AWS सपोर्टला लिहा आणि त्यांना सर्वत्र लॉगच्या संपूर्ण गुच्छासह समस्येचे सार सांगा आणि त्यांना हे सिद्ध करा की तुमची VPC आणि सबनेट वापरताना त्यांची सेवा कार्य करत नाही, आमच्याकडे व्यवसाय समर्थन आहे असे काही नाही, तुम्ही ते वापरावे. ते एकदा तरी :)

AWS अभियंत्यांसह संप्रेषण

पोर्टलवर तिकीट तयार केल्यावर, मी चुकून मला वेब - ईमेल किंवा समर्थन केंद्राद्वारे प्रतिसाद देणे निवडले, या पर्यायाद्वारे ते तुम्हाला काही दिवसांनी उत्तर देऊ शकतात, माझ्या तिकिटाची तीव्रता - प्रणाली बिघडलेली असूनही म्हणजे <12 तासांच्या आत प्रतिसाद, आणि व्यवसाय समर्थन योजनेला 24/7 सपोर्ट असल्याने, मला सर्वोत्कृष्ट अपेक्षा होती, परंतु ते नेहमीप्रमाणेच निष्पन्न झाले.

शुक्रवारपासून सोमवारपर्यंत माझे तिकीट न नियुक्त केले गेले, त्यानंतर मी त्यांना पुन्हा पत्र लिहिण्याचे ठरवले आणि चॅट प्रतिसाद पर्याय निवडला. थोडा वेळ वाट पाहिल्यानंतर हर्षद माधवची मला भेटायला नेमणूक झाली आणि मग सुरुवात झाली...

आम्ही सलग 3 तास ऑनलाइन डीबग केले, लॉग हस्तांतरित केले, समस्येचे अनुकरण करण्यासाठी AWS प्रयोगशाळेत समान क्लस्टर उपयोजित केले, माझ्या बाजूने क्लस्टर पुन्हा तयार करणे आणि असेच, आमच्याकडे फक्त एकच गोष्ट आली आहे नोंदीवरून हे स्पष्ट होते की रेझोल 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-कंट्रोलरचा पुनरावलोकन कोड घेतला आणि ते कुठे आहे आणि ते का काम करत नाही ते शोधले:

अशा प्रकारे, जर तुम्ही तुमच्या व्हीपीसीमध्ये मुख्य मार्ग सारणी वापरत असाल, तर डीफॉल्टनुसार त्यात आवश्यक सबनेटशी संबंध नाहीत, जे व्हीपीसी-कंट्रोलरसाठी आवश्यक आहेत, सार्वजनिक सबनेटच्या बाबतीत, त्यात सानुकूल मार्ग सारणी आहे. ज्याची एक संघटना आहे.

आवश्यक सबनेटसह मुख्य मार्ग सारणीसाठी व्यक्तिचलितपणे संघटना जोडून, ​​आणि नोडग्रुप पुन्हा तयार करून, सर्वकाही उत्तम प्रकारे कार्य करते.

मला आशा आहे की अरुण बी. खरोखरच या बगची EKS डेव्हलपरला तक्रार करेल आणि आम्हाला vpc-कंट्रोलरची नवीन आवृत्ती दिसेल जिथे सर्वकाही बॉक्सच्या बाहेर कार्य करेल. सध्या नवीनतम आवृत्ती आहे: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
ही समस्या आहे.

शेवटपर्यंत वाचलेल्या प्रत्येकाचे आभार, अंमलबजावणीपूर्वी तुम्ही उत्पादनात वापरणार असलेल्या प्रत्येक गोष्टीची चाचणी घ्या.

स्त्रोत: www.habr.com