GA ۾ Amazon EKS ونڊوز ۾ بگ آهن، پر تيز ترين آهي

صبح جو سلام، مان توهان سان ونڊوز ڪنٽينرز لاءِ AWS EKS (لچڪدار ڪبرنيٽس سروس) سروس کي ترتيب ڏيڻ ۽ استعمال ڪرڻ ۾ پنهنجو تجربو حصيداري ڪرڻ چاهيان ٿو، يا بلڪه ان کي استعمال ڪرڻ جي ناممڪن بابت، ۽ AWS سسٽم ڪنٽينر ۾ مليل بگ، انهن لاءِ. جيڪي ونڊوز ڪنٽينرز لاءِ هن خدمت ۾ دلچسپي رکن ٿا، مهرباني ڪري ٻلي هيٺان.

مون کي خبر آهي ته ونڊوز ڪنٽينر هڪ مشهور موضوع نه آهن، ۽ ٿورا ماڻهو انهن کي استعمال ڪن ٿا، پر مون اڃا تائين اهو مضمون لکڻ جو فيصلو ڪيو آهي، ڇاڪاڻ ته ڪيبرنيٽس ۽ ونڊوز تي Habré تي ڪجهه مضمون هئا ۽ اڃا به اهڙا ماڻهو آهن.

شروعات

اهو سڀ ڪجهه شروع ٿيو جڏهن اسان جي ڪمپني ۾ خدمتن کي ڪبرنيٽس ڏانهن منتقل ڪرڻ جو فيصلو ڪيو ويو، جيڪو 70٪ ونڊوز ۽ 30٪ لينڪس آهي. هن مقصد لاء، AWS EKS ڪلائوڊ سروس کي ممڪن اختيارن مان هڪ سمجهيو ويو. 8 آڪٽوبر 2019 تائين، AWS EKS ونڊوز پبلڪ پريويو ۾ هئي، مون ان سان شروعات ڪئي، ڪبرنيٽس جو پراڻو 1.11 ورزن اتي استعمال ڪيو ويو، پر مون ان کي هر صورت ۾ چيڪ ڪرڻ جو فيصلو ڪيو ۽ ڏسان ته هي ڪلائوڊ سروس ڪهڙي مرحلي ۾ آهي، ڇا اهو ڪم ڪري رهيو آهي. بلڪل، جيئن اهو نڪتو، نه، اهو پوڊز کي هٽائڻ جي اضافي سان گڏ هڪ بگ هو، جڏهن ته پراڻن ونڊوز ورڪر نوڊ وانگر ساڳئي سب نيٽ کان اندروني ip ذريعي جواب ڏيڻ بند ڪيو.

تنهن ڪري، اهو فيصلو ڪيو ويو ته AWS EKS استعمال ڪرڻ جي حق ۾ اسان جي پنهنجي ڪلستر جي حق ۾ ساڳي EC2 تي ڪبرنيٽس تي، صرف اسان کي سڀني توازن ۽ HA پاڻ کي CloudFormation ذريعي بيان ڪرڻو پوندو.

Amazon EKS ونڊوز ڪنٽينر سپورٽ هاڻي عام طور تي دستياب آهي

پاران مارٽن بيبي | 08 آڪٽوبر 2019 تي

ان کان اڳ جو مون وٽ وقت هجي ته منهنجي پنهنجي ڪلستر لاءِ CloudFormation ۾ ٽيمپليٽ شامل ڪيو، مون اها خبر ڏٺي Amazon EKS ونڊوز ڪنٽينر سپورٽ هاڻي عام طور تي دستياب آهي

يقينن، مون پنهنجو سڀ ڪم هڪ طرف رکي ڇڏيو ۽ اهو مطالعو ڪرڻ شروع ڪيو ته انهن GA لاءِ ڇا ڪيو، ۽ پبلڪ پريويو سان سڀ ڪجهه ڪيئن بدلجي ويو. ها، AWS، تمام سٺو، ونڊوز ورڪر نوڊ لاءِ ورجن 1.14 تائين تصويرون اپڊيٽ ڪيون، گڏوگڏ ڪلسٽر پاڻ، ورجن 1.14 EKS ۾، هاڻي ونڊوز نوڊس کي سپورٽ ڪري ٿو. پروجيڪٽ پاران پبلڪ پريويو تي گيتب انهن ان کي ڍڪي ڇڏيو ۽ چيو ته هاڻي هتي سرڪاري دستاويز استعمال ڪريو: EKS ونڊوز سپورٽ

موجوده VPC ۽ سبنيٽس ۾ EKS ڪلستر کي ضم ڪرڻ

سڀني ذريعن ۾، اعلان تي مٿي ڏنل لنڪ ۾ ۽ گڏوگڏ دستاويزن ۾، اها تجويز ڪئي وئي هئي ته ڪلستر کي يا ته Proprietary eksctl يوٽيلٽي ذريعي يا CloudFormation + kubectl ذريعي، صرف Amazon ۾ عوامي سبنيٽس استعمال ڪندي، انهي سان گڏ هڪ ٺاهڻ. نئين ڪلستر لاءِ الڳ VPC.

ھي اختيار گھڻن لاءِ موزون نه آھي؛ پھريائين، ھڪ الڳ وي پي سي جو مطلب آھي اضافي خرچن لاءِ ان جي قيمت + پيئرنگ ٽريفڪ توھان جي موجوده وي پي سي ڏانھن. انهن کي ڇا ڪرڻ گهرجي جن وٽ AWS ۾ اڳ ۾ ئي تيار ٿيل انفراسٽرڪچر آهي انهن جي پنهنجي هڪ کان وڌيڪ AWS اڪائونٽس، VPC، سب نيٽس، روٽ ٽيبل، ٽرانزٽ گيٽ وي وغيره؟ يقينا، توهان نٿا چاهيو ته اهو سڀ ڪجهه ٽوڙڻ يا ٻيهر ڪرڻ، ۽ توهان کي نئين EKS ڪلستر کي موجوده نيٽ ورڪ انفراسٽرڪچر ۾ ضم ڪرڻ جي ضرورت آهي، موجوده VPC استعمال ڪندي ۽، الڳ ڪرڻ لاء، سڀ کان وڌيڪ ڪلستر لاء نوان سب نيٽ ٺاهي.

منهنجي صورت ۾، هي رستو چونڊيو ويو آهي، مون موجوده VPC استعمال ڪيو، صرف 2 عوامي سبنيٽس ۽ 2 نجي سبنيٽس شامل ڪيا ويا نئين ڪلستر لاء، يقينا، سڀني ضابطن کي حساب ۾ ورتو ويو دستاويز جي مطابق پنهنجو Amazon EKS ڪلستر VPC ٺاهيو.

اتي پڻ ھڪڙي شرط ھئي: EIP استعمال ڪندي عوامي ذيلي نيٽ ورڪ ۾ ڪوبه ڪم ڪندڙ نوڊس.

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 for nodegroup.

2. اسان پنهنجي ڪلسٽر ۾ وي پي سي-ڪنٽرولر انسٽال ڪريون ٿا، جيڪو پوءِ اسان جي ورڪر نوڊس کي پروسيس ڪندو، مفت IP پتي جي تعداد کي ڳڻائيندو، ان سان گڏ مثال تي ENIs جو تعداد، انھن کي شامل ڪرڻ ۽ ختم ڪرڻ.

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

توھان جي نوڊ ڪاميابيءَ سان توھان جي ڪلسٽر سان ڳنڍڻ کان پوءِ ۽ سڀ ڪجھ ٺيڪ ٿيڻ لڳي، اھو تيار حالت ۾ آھي، پر نه.

وي پي سي ڪنٽرولر ۾ غلطي

جيڪڏهن اسان ونڊوز ورڪر نوڊ تي پوڊ هلائڻ جي ڪوشش ڪنداسين، اسان کي غلطي ملندي:

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 ايڊريس شامل نه ڪري سگهيو ته جيئن پوڊس انهن کي استعمال ڪري سگهن.

اچو ته وي پي سي-ڪنٽرولر پوڊ جي لاگن کي ڏسو ۽ اھو اھو آھي جيڪو اسان ڏسون ٿا:

kubectl لاگ -n kube-سسٽم

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 استعمال ڪرڻ کان سواءِ هڪ ورڪر نوڊ کي پبلڪ سب نيٽ تي لڳايو، ته اهو نوڊ فوري طور تي وي پي سي-ڪنٽرولر طرفان اپڊيٽ ڪيو ويو ۽ هر شي ڪلاڪ ورڪ وانگر ڪم ڪيو.

اتي ٻه اختيار هئا:

1. ان کي ڇڏي ڏيو ۽ انتظار ڪريو جيستائين ڪو هن بگ کي AWS ۾ بيان ڪري ۽ اهي ان کي درست ڪن، ۽ پوءِ توهان محفوظ طور تي AWS EKS ونڊوز استعمال ڪري سگهو ٿا، ڇاڪاڻ ته اهي صرف GA ۾ جاري ڪيا ويا آهن (هن مضمون لکڻ جي وقت ۾ 8 ڏينهن گذري ويا آهن)، ڪيترائي شايد هوندا. مون وانگر ساڳيو رستو وٺو.
2. AWS سپورٽ ڏانهن لکو ۽ انهن کي هر جڳهه کان لاگس جي مڪمل گروپ سان مسئلي جو خلاصو ٻڌايو ۽ انهن کي ثابت ڪيو ته انهن جي خدمت ڪم نه ڪندي جڏهن توهان جي VPC ۽ سب نيٽ استعمال ڪندي، اهو ڪنهن به شيء لاء ناهي ته اسان وٽ ڪاروبار سپورٽ آهي، توهان کي استعمال ڪرڻ گهرجي. اهو گهٽ ۾ گهٽ هڪ ڀيرو :)

AWS انجنيئرن سان رابطو

پورٽل تي ٽڪيٽ ٺاهي، مون غلطي سان مون کي ويب - اي ميل يا سپورٽ سينٽر ذريعي جواب ڏيڻ جو انتخاب ڪيو، هن آپشن ذريعي اهي توهان کي ڪجهه ڏينهن بعد جواب ڏئي سگھن ٿا، ان حقيقت جي باوجود ته منهنجي ٽڪيٽ جي شدت - سسٽم خراب ٿي وئي، جنهن مطلب <12 ڪلاڪن اندر جواب، ۽ جيئن ته ڪاروباري سپورٽ پلان 24/7 سپورٽ آهي، مون کي بهترين جي اميد هئي، پر اهو هميشه وانگر نڪتو.

منهنجي ٽڪيٽ جمعي کان سومر تائين اڻ تفويض رهجي وئي، پوءِ مون فيصلو ڪيو ته انهن ڏانهن ٻيهر لکان ۽ چيٽ جوابي آپشن چونڊيو. ٿوري دير انتظار ڪرڻ کان پوءِ، مون سان ملڻ لاءِ هرشد ماڌو کي مقرر ڪيو ويو، ۽ پوءِ شروع ٿيو.

اسان ان سان مسلسل 3 ڪلاڪ آن لائن ڊيبگ ڪيو، لاگز کي منتقل ڪرڻ، AWS ليبارٽري ۾ ساڳئي ڪلستر کي ترتيب ڏيڻ، مسئلي کي نقل ڪرڻ لاء، منهنجي حصي تي ڪلستر کي ٻيهر ٺاهڻ، ۽ ائين ئي، اسان وٽ صرف هڪ شيء آهي جيڪا اسان وٽ آئي آهي. لاگن مان اهو واضح هو ته ريزول AWS اندروني ڊومين نالن تي ڪم نه ڪري رهيو هو، جنهن بابت مون مٿي لکيو هو، ۽ هرشاد ماڌو مون کي فارورڊنگ ٺاهڻ لاءِ چيو، مبينا طور تي اسان ڪسٽم ڊي اين ايس استعمال ڪندا آهيون ۽ اهو مسئلو ٿي سگهي ٿو.

اڳتي وڌڻ

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

ائين ئي ڪيو ويو، ڏينهن ختم ٿي ويو، هرشاد ماڌو واپس لکيو ته ان کي چيڪ ڪريو ۽ اهو ڪم ڪرڻ گهرجي، پر نه، قرارداد ڪجهه به مدد نه ڪئي.

ان کان پوءِ 2 وڌيڪ انجنيئرن سان رابطو ٿيو، ھڪڙو رڳو چيٽ مان نڪري ويو، بظاھر ھو ھڪڙي پيچيده ڪيس کان ڊڄي ويو، ٻيو منهنجو ڏينھن وري ڊيبگنگ جي مڪمل چڪر تي گذريو، لاگ موڪلڻ، ٻنھي طرفن تي ڪلسٽر ٺاھيو، آخر هن چيو ته اهو سٺو آهي، اهو مون لاء ڪم ڪري ٿو، هتي آئون آهيان آئون سڀ ڪجهه قدم قدم تي سرڪاري دستاويزن ۾ ڪندس ۽ توهان ۽ توهان ڪامياب ٿيندا.

جنهن تي مون کيس شائستگي سان چيو ته ڇڏي وڃي ۽ منهنجي ٽڪيٽ ڪنهن ٻئي کي تفويض ڪري جيڪڏهن توهان کي خبر ناهي ته مسئلو ڪٿي ڳوليو.

مڪمل

ٽئين ڏينهن تي، مون کي هڪ نئون انجنيئر ارون بي مقرر ڪيو ويو، ۽ هن سان رابطي جي شروعات کان ئي اهو واضح ٿي ويو ته هي 3 اڳوڻو انجنيئر نه هئا. هن پوري تاريخ پڙهي ۽ فوري طور تي پي ايس 1 تي پنهنجي اسڪرپٽ استعمال ڪندي لاگ گڏ ڪرڻ لاءِ چيو، جيڪو هن جي گٿب تي هو. ان کان پوءِ وري ڪلسٽر ٺاهڻ، ڪمانڊ جا نتيجا ڪڍڻ، لاگ گڏ ڪرڻ جي سمورين ڪوششن جي پيروي ڪئي وئي، پر ارون بي مون کان پڇيل سوالن جو فيصلو ڪندي صحيح رخ ۾ هلي رهيو هو.

جڏهن اسان انهن جي vpc-ڪنٽرولر ۾ -stderrthreshold=debug کي فعال ڪرڻ جي نقطي تي پهتاسين، ۽ اڳتي ڇا ٿيو؟ يقينن اهو ڪم نٿو ڪري) پوڊ صرف هن اختيار سان شروع نٿو ٿئي، صرف -stderrthreshold=info ڪم ڪري ٿو.

اسان هتي ختم ڪيو ۽ ارون بي چيو ته هو ساڳيو غلطي حاصل ڪرڻ لاء منهنجي قدمن کي ٻيهر ڏيڻ جي ڪوشش ڪندو. ٻئي ڏينهن مون کي ارون بي جو جواب مليو، هن اهو ڪيس نه ڇڏيو، پر انهن جي وي پي سي-ڪنٽرولر جو جائزو وٺڻ وارو ڪوڊ ورتو ۽ اهو معلوم ڪيو ته اهو ڪٿي آهي ۽ اهو ڪم ڇو نٿو ڪري:

اهڙيء طرح، جيڪڏهن توهان پنهنجي VPC ۾ مکيه روٽ ٽيبل استعمال ڪريو ٿا، ته پوء ڊفالٽ طور تي ان کي ضروري سبنٽس سان لاڳاپيل نه آهي، جيڪي وي پي سي-ڪنٽرولر لاء تمام ضروري آهن، عوامي سب نيٽ جي صورت ۾، ان ۾ هڪ ڪسٽم روٽ ٽيبل آهي. جنهن جو تعلق آهي.

مينوئل روٽ ٽيبل لاءِ انجمن کي دستي طور شامل ڪرڻ سان ضروري سبنيٽس سان، ۽ نوڊگروپ کي ٻيهر ٺاھڻ سان، سڀ ڪجھ ٺيڪ ڪم ڪري ٿو.

مون کي اميد آهي ته ارون بي واقعي هن بگ کي EKS ڊولپرز کي رپورٽ ڪندو ۽ اسان وي پي سي-ڪنٽرولر جو هڪ نئون ورزن ڏسندا جتي هر شي دٻي کان ٻاهر ڪم ڪندي. في الحال جديد نسخو آهي: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
هي مسئلو آهي.

هر ڪنهن جي مهرباني جيڪو آخر تائين پڙهيو، هر شي کي جانچيو جيڪو توهان عمل ڪرڻ کان اڳ پيداوار ۾ استعمال ڪرڻ وارا آهيو.

جو ذريعو: www.habr.com