Amazon EKS Windows ใน GA มีข้อบกพร่อง แต่เป็นรุ่นที่เร็วที่สุด

สวัสดีตอนบ่าย ฉันต้องการแบ่งปันประสบการณ์ของฉันในการตั้งค่าและใช้บริการ AWS EKS (Elastic Kubernetes Service) สำหรับคอนเทนเนอร์ Windows หรือเกี่ยวกับความเป็นไปไม่ได้ในการใช้งาน และข้อบกพร่องที่พบในคอนเทนเนอร์ระบบ AWS สำหรับสิ่งเหล่านั้น ผู้ที่สนใจบริการนี้สำหรับคอนเทนเนอร์ Windows โปรดระบุภายใต้ cat

ฉันรู้ว่าคอนเทนเนอร์ของ Windows ไม่ใช่หัวข้อยอดนิยม และมีเพียงไม่กี่คนที่ใช้คอนเทนเนอร์เหล่านี้ แต่ฉันยังคงตัดสินใจเขียนบทความนี้ เนื่องจากมีบทความสองสามบทความเกี่ยวกับHabréเกี่ยวกับ kubernetes และ Windows และยังมีคนประเภทนี้อยู่

การเริ่มต้น

ทุกอย่างเริ่มต้นเมื่อมีการตัดสินใจย้ายบริการในบริษัทของเราไปยัง kubernetes ซึ่งก็คือ Windows 70% และ Linux 30% เพื่อจุดประสงค์นี้ บริการคลาวด์ AWS EKS ถือเป็นหนึ่งในตัวเลือกที่เป็นไปได้ จนถึงวันที่ 8 ตุลาคม 2019 AWS EKS Windows อยู่ในการแสดงตัวอย่างแบบสาธารณะ ฉันเริ่มต้นด้วยการใช้ kubernetes เวอร์ชัน 1.11 เก่าที่นั่น แต่ฉันตัดสินใจที่จะตรวจสอบต่อไปและดูว่าบริการคลาวด์นี้อยู่ในขั้นตอนใด ไม่ว่ามันจะทำงานหรือไม่ ปรากฎว่าไม่ มันมีข้อผิดพลาดด้วยการเพิ่มการลบพ็อดในขณะที่อันเก่าหยุดตอบสนองผ่าน IP ภายในจากซับเน็ตเดียวกันกับโหนดผู้ปฏิบัติงาน windows

ดังนั้นจึงมีการตัดสินใจที่จะละทิ้งการใช้ AWS EKS และหันมาใช้คลัสเตอร์ของเราเองบน kubernetes บน EC2 เดียวกัน มีเพียงเราเท่านั้นที่ต้องอธิบายการปรับสมดุลและ HA ทั้งหมดด้วยตนเองผ่าน CloudFormation

ขณะนี้การสนับสนุน Amazon EKS Windows Container พร้อมใช้งานทั่วไปแล้ว

โดย Martin Beeby | วันที่ 08 ต.ค. 2019

ก่อนที่ฉันจะมีเวลาเพิ่มเทมเพลตให้กับ CloudFormation สำหรับคลัสเตอร์ของฉันเอง ฉันเห็นข่าวนี้ ขณะนี้การสนับสนุน Amazon EKS Windows Container พร้อมใช้งานทั่วไปแล้ว

แน่นอน ฉันละทิ้งงานทั้งหมดของฉันและเริ่มศึกษาสิ่งที่พวกเขาทำเพื่อ GA และทุกสิ่งเปลี่ยนแปลงไปอย่างไรในการแสดงตัวอย่างแบบสาธารณะ ใช่ AWS ทำได้ดีมาก อัปเดตอิมเมจสำหรับโหนดผู้ปฏิบัติงาน windows เป็นเวอร์ชัน 1.14 รวมถึงตัวคลัสเตอร์เอง เวอร์ชัน 1.14 ใน EKS ตอนนี้รองรับโหนด windows แล้ว โครงการโดยการดูตัวอย่างสาธารณะที่ GitHub พวกเขาปกปิดมันและบอกว่าตอนนี้ใช้เอกสารอย่างเป็นทางการที่นี่: รองรับ EKS Windows

การรวมคลัสเตอร์ EKS เข้ากับ VPC และซับเน็ตปัจจุบัน

ในทุกแหล่งที่มา ในลิงก์ด้านบนของประกาศและในเอกสารประกอบ มีการเสนอให้ปรับใช้คลัสเตอร์ผ่านยูทิลิตี้ eksctl ที่เป็นกรรมสิทธิ์หรือผ่าน CloudFormation + kubectl หลังจากนั้น โดยใช้ซับเน็ตสาธารณะใน Amazon เท่านั้น รวมถึงการสร้าง แยก VPC สำหรับคลัสเตอร์ใหม่

ตัวเลือกนี้ไม่เหมาะสำหรับหลาย ๆ คน ประการแรก VPC ที่แยกต่างหากหมายถึงค่าใช้จ่ายเพิ่มเติมสำหรับต้นทุน + การรับส่งข้อมูลแบบเพียร์ไปยัง VPC ปัจจุบันของคุณ ผู้ที่มีโครงสร้างพื้นฐานสำเร็จรูปใน AWS พร้อมด้วยบัญชี AWS หลายบัญชี, VPC, ซับเน็ต, ตารางเส้นทาง, เกตเวย์การขนส่ง และอื่นๆ ของตนเองควรทำอย่างไร แน่นอนว่า คุณคงไม่อยากพังหรือทำซ้ำทั้งหมดนี้ และคุณต้องรวมคลัสเตอร์ EKS ใหม่เข้ากับโครงสร้างพื้นฐานเครือข่ายปัจจุบัน โดยใช้ VPC ที่มีอยู่ และสำหรับการแยก อย่างน้อยที่สุดก็ต้องสร้างซับเน็ตใหม่สำหรับคลัสเตอร์

ในกรณีของฉัน เลือกเส้นทางนี้ ฉันใช้ VPC ที่มีอยู่ เพิ่มเครือข่ายย่อยสาธารณะเพียง 2 รายการและเครือข่ายย่อยส่วนตัว 2 รายการสำหรับคลัสเตอร์ใหม่ แน่นอนว่ากฎทั้งหมดถูกนำมาพิจารณาตามเอกสารประกอบ สร้าง VPC คลัสเตอร์ Amazon EKS ของคุณ.

นอกจากนี้ยังมีเงื่อนไขหนึ่งข้อ: ไม่มีโหนดผู้ปฏิบัติงานในเครือข่ายย่อยสาธารณะที่ใช้ EIP

eksctl กับ CloudFormation

ฉันจะจองทันทีว่าฉันลองใช้ทั้งสองวิธีในการปรับใช้คลัสเตอร์ ในทั้งสองกรณีภาพก็เหมือนกัน

ฉันจะแสดงตัวอย่างโดยใช้ eksctl เท่านั้น เนื่องจากโค้ดที่นี่จะสั้นกว่า ใช้ eksctl ปรับใช้คลัสเตอร์ใน 3 ขั้นตอน:

1. เราสร้างคลัสเตอร์เอง + โหนดผู้ปฏิบัติงาน Linux ซึ่งจะโฮสต์คอนเทนเนอร์ของระบบในภายหลังและตัวควบคุม 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 ที่มีอยู่ เพียงระบุ id ของซับเน็ตของคุณ จากนั้น eksctl จะกำหนด VPC เอง

เพื่อให้แน่ใจว่าโหนดผู้ปฏิบัติงานของคุณใช้งานได้กับซับเน็ตส่วนตัวเท่านั้น คุณต้องระบุ --node-private-networking สำหรับ nodegroup

2. เราติดตั้ง vpc-controller ในคลัสเตอร์ของเรา ซึ่งจะประมวลผลโหนดผู้ปฏิบัติงานของเรา โดยนับจำนวนที่อยู่ IP ที่ว่าง รวมถึงจำนวน ENI บนอินสแตนซ์ จากนั้นจึงเพิ่มและลบออก

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

3.หลังจากที่คอนเทนเนอร์ระบบของคุณเปิดใช้งานบนโหนดผู้ปฏิบัติงาน Linux ของคุณ รวมถึง vpc-controller เรียบร้อยแล้ว สิ่งที่เหลืออยู่คือการสร้างกลุ่มโหนดอื่นด้วยผู้ปฏิบัติงาน windows

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

หากเราพยายามเรียกใช้พ็อดบนโหนดผู้ปฏิบัติงาน windows เราจะได้รับข้อผิดพลาด:

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

การค้นหาใน Google ไม่ได้นำไปสู่สิ่งใด เนื่องจากเห็นได้ชัดว่ายังไม่มีใครพบข้อบกพร่องดังกล่าวหรือไม่ได้โพสต์ปัญหา ฉันจึงต้องคิดถึงตัวเลือกต่างๆ ด้วยตัวเองก่อน สิ่งแรกที่นึกได้คือบางที vpc-controller ไม่สามารถแก้ไข ip-10-xxx.ap-xxx.compute.internal และเข้าถึงได้ ดังนั้นจึงเกิดข้อผิดพลาดขึ้น

ใช่ เราใช้เซิร์ฟเวอร์ DNS แบบกำหนดเองใน VPC และโดยหลักการแล้ว เราไม่ได้ใช้เซิร์ฟเวอร์ของ Amazon ดังนั้น แม้แต่การส่งต่อก็ไม่ได้รับการกำหนดค่าสำหรับโดเมน ap-xxx.compute.internal นี้ ฉันทดสอบตัวเลือกนี้และไม่ได้ผลลัพธ์บางทีการทดสอบอาจไม่สะอาดดังนั้นเมื่อสื่อสารกับฝ่ายสนับสนุนทางเทคนิคฉันก็ยอมจำนนต่อความคิดของพวกเขา

เนื่องจากไม่มีแนวคิดใด ๆ จริงๆ กลุ่มความปลอดภัยทั้งหมดจึงถูกสร้างขึ้นโดย eksctl เอง ดังนั้นจึงไม่ต้องสงสัยเลยเกี่ยวกับความสามารถในการให้บริการ ตารางเส้นทางก็ถูกต้องเช่นกัน nat, DNS, การเข้าถึงอินเทอร์เน็ตพร้อมโหนดผู้ปฏิบัติงานก็อยู่ที่นั่นเช่นกัน

ยิ่งไปกว่านั้น หากคุณปรับใช้โหนดผู้ปฏิบัติงานกับเครือข่ายย่อยสาธารณะโดยไม่ใช้ —node-private-networking โหนดนี้จะได้รับการอัปเดตทันทีโดยตัวควบคุม vpc และทุกอย่างทำงานเหมือนเครื่องจักร

มีสองทางเลือก:

1. ยอมแพ้และรอจนกว่าจะมีคนอธิบายจุดบกพร่องนี้ใน AWS แล้วแก้ไข จากนั้นคุณก็จะสามารถใช้ AWS EKS Windows ได้อย่างปลอดภัย เนื่องจากเพิ่งเปิดตัวใน GA (ผ่านไป 8 วันในขณะที่เขียนบทความนี้) หลายๆ คนอาจจะ ไปตามเส้นทางเดียวกับฉัน
2. เขียนถึง AWS Support และบอกพวกเขาถึงแก่นแท้ของปัญหาด้วยบันทึกจำนวนมากจากทุกที่ และพิสูจน์ให้พวกเขาเห็นว่าบริการของพวกเขาไม่ทำงานเมื่อใช้ VPC และเครือข่ายย่อยของคุณ เราได้รับการสนับสนุนทางธุรกิจแล้ว คุณควรใช้ อย่างน้อยหนึ่งครั้ง :)

การสื่อสารกับวิศวกร AWS

เมื่อสร้างตั๋วบนพอร์ทัล ฉันเลือกที่จะตอบกลับฉันผ่านทางเว็บ - อีเมลหรือศูนย์สนับสนุนโดยไม่ได้ตั้งใจ โดยตัวเลือกนี้พวกเขาสามารถตอบคุณได้หลังจากผ่านไปสองสามวัน แม้ว่าตั๋วของฉันจะมีความรุนแรง - ระบบบกพร่องก็ตาม หมายถึงการตอบกลับภายใน <12 ชั่วโมง และเนื่องจากแผนสนับสนุนธุรกิจมีการสนับสนุนตลอด 24 ชั่วโมงทุกวัน ฉันจึงหวังว่าจะได้สิ่งที่ดีที่สุด แต่ก็กลับกลายเป็นเช่นเคย

ตั๋วของฉันไม่ได้มอบหมายตั้งแต่วันศุกร์ถึงวันจันทร์ จากนั้นฉันตัดสินใจเขียนถึงพวกเขาอีกครั้งและเลือกตัวเลือกการตอบกลับทางแชท หลังจากรอได้สักพัก Harshad Madhav ก็ได้รับมอบหมายให้มาพบฉัน และจากนั้นก็เริ่ม...

เราแก้ไขจุดบกพร่องทางออนไลน์เป็นเวลา 3 ชั่วโมงติดต่อกัน ถ่ายโอนบันทึก ปรับใช้คลัสเตอร์เดียวกันในห้องปฏิบัติการ AWS เพื่อจำลองปัญหา สร้างคลัสเตอร์ขึ้นใหม่ในส่วนของฉัน และอื่นๆ สิ่งเดียวที่เราพบก็คือ บันทึกชัดเจนว่าการแก้ไขไม่ทำงานชื่อโดเมนภายใน AWS ซึ่งฉันเขียนไว้ข้างต้น และ Harshad Madhav ขอให้ฉันสร้างการส่งต่อ โดยถูกกล่าวหาว่าเราใช้ DNS ที่กำหนดเองและนี่อาจเป็นปัญหาได้

ส่งต่อ

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

นั่นคือสิ่งที่เสร็จสิ้น วันก็จบลง Harshad Madhav เขียนกลับมาเพื่อตรวจสอบและน่าจะได้ผล แต่ไม่เลย การแก้ปัญหาไม่ได้ช่วยอะไรเลย

จากนั้นก็มีการสื่อสารกับวิศวกรอีก 2 คน คนหนึ่งหลุดออกจากแชท เห็นได้ชัดว่าเขากลัวกรณีที่ซับซ้อน คนที่สองใช้เวลาวันของฉันอีกครั้งในการแก้จุดบกพร่องแบบเต็มรอบ ส่งบันทึก สร้างคลัสเตอร์ทั้งสองด้านใน ท้ายที่สุด เขาแค่บอกว่าดี มันได้ผลสำหรับฉัน ที่นี่ฉันทำทุกอย่างทีละขั้นตอนในเอกสารอย่างเป็นทางการ แล้วคุณและคุณจะประสบความสำเร็จ

ซึ่งฉันขอให้เขาออกไปอย่างสุภาพและมอบหมายให้คนอื่นดูแลตั๋วของฉันหากคุณไม่รู้ว่าจะหาปัญหาได้จากที่ไหน

ฉากสุดท้ายของละคร

ในวันที่สาม ฉันมอบหมายวิศวกรคนใหม่ชื่อ Arun B. และตั้งแต่เริ่มสื่อสารกับเขาก็ชัดเจนทันทีว่านี่ไม่ใช่วิศวกรทั้ง 3 คนก่อนหน้านี้ เขาอ่านประวัติทั้งหมดและขอให้รวบรวมบันทึกทันทีโดยใช้สคริปต์ของเขาเองบน ps1 ซึ่งอยู่บน GitHub ของเขา ตามมาอีกครั้งด้วยการสร้างคลัสเตอร์ การแสดงผลลัพธ์คำสั่ง การรวบรวมบันทึก แต่ Arun B. กำลังเดินไปในทิศทางที่ถูกต้องโดยตัดสินจากคำถามที่ถามฉัน

เมื่อใดที่เราไปถึงจุดเปิดใช้งาน -stderrthreshold=debug ใน vpc-controller และจะเกิดอะไรขึ้นต่อไป แน่นอนว่ามันใช้งานไม่ได้) พ็อดไม่ได้เริ่มต้นด้วยตัวเลือกนี้ แต่ -stderrthreshold=info เท่านั้นที่ใช้งานได้

เราทำเสร็จแล้วและอรุณบีบอกว่าจะพยายามทำซ้ำขั้นตอนของฉันเพื่อให้ได้ข้อผิดพลาดแบบเดียวกัน วันรุ่งขึ้นฉันได้รับคำตอบจาก Arun B. เขาไม่ได้ละทิ้งคดีนี้ แต่รับโค้ดตรวจสอบของ vpc-controller ของพวกเขาและพบตำแหน่งที่มันอยู่และเหตุใดจึงใช้งานไม่ได้:

ดังนั้น หากคุณใช้ตารางเส้นทางหลักใน VPC ของคุณ ตามค่าเริ่มต้นแล้ว ตารางเส้นทางจะไม่เชื่อมโยงกับเครือข่ายย่อยที่จำเป็นซึ่งจำเป็นสำหรับตัวควบคุม vpc ในกรณีของเครือข่ายย่อยสาธารณะ จะมีตารางเส้นทางที่กำหนดเอง ที่มีความสัมพันธ์

ด้วยการเพิ่มการเชื่อมโยงสำหรับตารางเส้นทางหลักด้วยตนเองด้วยซับเน็ตที่จำเป็น และสร้างกลุ่มโหนดใหม่ ทุกอย่างทำงานได้อย่างสมบูรณ์

ฉันหวังว่า Arun B. จะรายงานข้อผิดพลาดนี้แก่นักพัฒนา EKS จริงๆ และเราจะได้เห็น vpc-controller เวอร์ชันใหม่ ซึ่งทุกอย่างจะทำงานได้ทันทีที่แกะกล่อง ปัจจุบันเวอร์ชันล่าสุดคือ: 602401143452.dkr.ecr.ap-southeast-1.amazonaws.com/eks/vpc-resource-controller:0.2.1
มีปัญหานี้

ขอขอบคุณทุกคนที่อ่านจนจบ โปรดทดสอบทุกสิ่งที่คุณจะใช้ในการผลิตก่อนนำไปใช้งาน

ที่มา: will.com