โหนดผู้ปฏิบัติงาน Kubernetes: โหนดเล็ก ๆ จำนวนมากหรือโหนดใหญ่หลายอัน?

เมื่อสร้างคลัสเตอร์ Kubernetes อาจมีคำถามเกิดขึ้น: มีโหนดผู้ปฏิบัติงานกี่โหนดที่ต้องกำหนดค่าและประเภทใด อะไรจะดีไปกว่าสำหรับคลัสเตอร์ภายในองค์กร: ซื้อเซิร์ฟเวอร์ที่มีประสิทธิภาพหลายเครื่อง หรือใช้เครื่องเก่าหลายสิบเครื่องในศูนย์ข้อมูลของคุณ จะดีกว่าไหมถ้าใช้อินสแตนซ์แบบ single-core จำนวน 8 ตัวหรือแบบ quad-core จำนวน 2 ตัวในระบบคลาวด์

คำตอบสำหรับคำถามเหล่านี้อยู่ในบทความ Daniel Weibel วิศวกรซอฟต์แวร์และอาจารย์ของโครงการการศึกษา Learnk8s ในการแปลคำสั่ง Kubernetes aaS จาก Mail.ru.

ความจุของคลัสเตอร์

โดยทั่วไปแล้ว คลัสเตอร์ Kubernetes ถือเป็น "supernode" ขนาดใหญ่ได้ พลังการประมวลผลทั้งหมดคือผลรวมของพลังของโหนดที่เป็นส่วนประกอบทั้งหมด

มีหลายวิธีในการบรรลุเป้าหมายความจุคลัสเตอร์ที่คุณต้องการ ตัวอย่างเช่น เราต้องการคลัสเตอร์ที่มีความจุรวม 8 คอร์ของโปรเซสเซอร์และ RAM 32 GB เนื่องจากชุดแอปพลิเคชันต้องใช้ทรัพยากรจำนวนมาก จากนั้นคุณสามารถติดตั้งสองโหนดที่มีหน่วยความจำ 16 GB หรือสี่โหนดที่มีหน่วยความจำ 8 GB, โปรเซสเซอร์ Quad-Core สองตัวหรือ Dual-Core สี่ตัว

นี่เป็นเพียงสองวิธีที่เป็นไปได้ในการสร้างคลัสเตอร์:

ตัวเลือกทั้งสองจะสร้างคลัสเตอร์ที่มีความจุเท่ากัน แต่การกำหนดค่าด้านล่างมีโหนดที่เล็กกว่าสี่โหนด และการกำหนดค่าด้านบนมีโหนดที่ใหญ่กว่าสองโหนด

ตัวเลือกไหนดีกว่ากัน?

เพื่อตอบคำถามนี้ เรามาดูข้อดีของทั้งสองตัวเลือกกันดีกว่า เราได้สรุปไว้ในตารางแล้ว

โหนดขนาดใหญ่หลายแห่ง

โหนดเล็กๆ มากมาย

การจัดการคลัสเตอร์ที่ง่ายขึ้น (หากเป็นแบบภายในองค์กร)

การปรับขนาดอัตโนมัติที่ราบรื่น

ถูกกว่า (ถ้าอยู่ในสถานที่)

ราคาต่างกันนิดหน่อย (ในคลาวด์)

สามารถเรียกใช้แอปพลิเคชันที่ใช้ทรัพยากรจำนวนมากได้

การจำลองแบบเต็มรูปแบบ

ทรัพยากรถูกใช้อย่างมีประสิทธิภาพมากขึ้น (ค่าใช้จ่ายน้อยลงใน daemons ระบบ
ความทนทานต่อข้อบกพร่องของคลัสเตอร์ที่สูงขึ้น

โปรดทราบว่าเรากำลังพูดถึงเฉพาะโหนดผู้ปฏิบัติงานเท่านั้น การเลือกจำนวนและขนาดของโหนดหลักเป็นหัวข้อที่แตกต่างไปจากเดิมอย่างสิ้นเชิง

เรามาพูดคุยกันในแต่ละจุดจากตารางโดยละเอียดกันดีกว่า

ตัวเลือกแรก: โหนดขนาดใหญ่หลายแห่ง

ตัวเลือกที่รุนแรงที่สุดคือโหนดผู้ปฏิบัติงานหนึ่งโหนดสำหรับความจุของคลัสเตอร์ทั้งหมด ในตัวอย่างข้างต้น นี่จะเป็นโหนดผู้ปฏิบัติงานเดี่ยวที่มีคอร์ CPU 16 คอร์และ RAM ขนาด 16 GB

ข้อดี

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

โปรดทราบว่าสิ่งที่กล่าวมาทั้งหมดใช้กับฮาร์ดแวร์ เซิร์ฟเวอร์ของคุณ และไม่ใช่กับอินสแตนซ์ระบบคลาวด์

สถานการณ์แตกต่างออกไปในระบบคลาวด์ ที่นั่นการจัดการได้รับการจัดการโดยผู้ให้บริการคลาวด์ ดังนั้นการจัดการ 10 โหนดในระบบคลาวด์จึงไม่แตกต่างจากการจัดการ 1 โหนดมากนัก

การกำหนดเส้นทางการรับส่งข้อมูลและการกระจายโหลดระหว่างพ็อดในระบบคลาวด์ ดำเนินการโดยอัตโนมัติ: การรับส่งข้อมูลที่มาจากอินเทอร์เน็ตจะถูกส่งไปยังโหลดบาลานเซอร์หลัก ซึ่งจะส่งต่อการรับส่งข้อมูลไปยังพอร์ตของหนึ่งในโหนด (บริการ NodePort ตั้งค่าพอร์ตในช่วง 30000-32767 ในแต่ละโหนดคลัสเตอร์) กฎที่กำหนดโดย kube-proxy เปลี่ยนเส้นทางการรับส่งข้อมูลจากโหนดไปยังพ็อด ต่อไปนี้คือสิ่งที่ดูเหมือนสำหรับสิบพ็อดบนสองโหนด:

มือโปร #2: ต้นทุนต่อโหนดน้อยลง
รถยนต์ที่ทรงพลังมีราคาแพงกว่า แต่การเพิ่มขึ้นของราคาไม่จำเป็นต้องเป็นเส้นตรง กล่าวอีกนัยหนึ่ง เซิร์ฟเวอร์ 10-core หนึ่งตัวที่มีหน่วยความจำ XNUMX GB มักจะถูกกว่าเซิร์ฟเวอร์แบบ single-core XNUMX ตัวที่มีหน่วยความจำเท่ากัน

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

ดังนั้นในระบบคลาวด์ คุณจะไม่สามารถบันทึกบนเซิร์ฟเวอร์ที่มีประสิทธิภาพมากกว่านี้ได้

Pro #3: คุณสามารถเรียกใช้แอปพลิเคชันที่ใช้ทรัพยากรมากได้
แอปพลิเคชันบางตัวต้องการเซิร์ฟเวอร์ที่มีประสิทธิภาพในคลัสเตอร์ ตัวอย่างเช่น หากระบบแมชชีนเลิร์นนิงต้องการหน่วยความจำ 8 GB คุณจะไม่สามารถรันบนโหนดขนาด 1 GB ได้ แต่จะมีโหนดผู้ปฏิบัติงานขนาดใหญ่อย่างน้อยหนึ่งโหนดเท่านั้น

cons

ข้อเสียข้อที่ 1 มีพ็อดต่อโหนดจำนวนมาก
หากทำงานเดียวกันบนโหนดน้อยลง แต่ละโหนดก็จะมีพ็อดมากขึ้นตามธรรมชาติ

นี่อาจเป็นปัญหา

เหตุผลก็คือ แต่ละโมดูลแนะนำโอเวอร์เฮดให้กับคอนเทนเนอร์รันไทม์ (เช่น นักเทียบท่า) รวมถึง kubelet และ cAdvisor

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

CAdvisor รวบรวมสถิติการใช้ทรัพยากรสำหรับคอนเทนเนอร์ทั้งหมดบนโหนด และ kubelet จะสอบถามข้อมูลนี้เป็นประจำและจัดเตรียมผ่าน API ขอย้ำอีกครั้งว่า คอนเทนเนอร์ที่มากขึ้นหมายถึงการทำงานที่มากขึ้นสำหรับทั้ง cAdvisor และ kubelet

หากจำนวนโมดูลเพิ่มขึ้น ก็อาจทำให้ระบบช้าลงและยังบ่อนทำลายความน่าเชื่อถือของระบบอีกด้วย

ในที่เก็บ Kubernetes บางส่วน บ่นโหนดนั้นข้ามระหว่างสถานะ Ready/NotReady เนื่องจากการตรวจสอบ kubelet ตามปกติของคอนเทนเนอร์ทั้งหมดบนโหนดใช้เวลานานเกินไป
ด้วยเหตุนี้ Kubernetes แนะนำให้วางไม่เกิน 110 พ็อดต่อโหนด- คุณสามารถเรียกใช้พ็อดได้มากขึ้นต่อโหนด ทั้งนี้ขึ้นอยู่กับประสิทธิภาพของโหนด แต่เป็นการยากที่จะคาดเดาว่าจะมีปัญหาหรือทุกอย่างทำงานได้ดี มันคุ้มค่าที่จะทดสอบงานล่วงหน้า

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

แบบจำลองห้ารายการสามารถกระจายไปยังสองโหนดเท่านั้น และหากหนึ่งในนั้นล้มเหลว ระบบจะลบแบบจำลองหลายรายการพร้อมกัน

หากคุณมีห้าโหนดขึ้นไป แต่ละเรพลิกาจะทำงานบนโหนดแยกกัน และความล้มเหลวของโหนดเดียวจะลบเรพลิกาได้มากสุดหนึ่งรายการ

ดังนั้นข้อกำหนดความพร้อมใช้งานสูงอาจต้องมีจำนวนโหนดขั้นต่ำในคลัสเตอร์

ข้อเสียข้อที่ 3 ผลที่ตามมาของความล้มเหลวที่แย่ลง
เมื่อมีโหนดจำนวนไม่มากนัก ความล้มเหลวแต่ละครั้งจะมีผลกระทบร้ายแรงมากขึ้น ตัวอย่างเช่น หากคุณมีเพียงสองโหนดและหนึ่งในนั้นล้มเหลว โมดูลครึ่งหนึ่งของคุณจะหายไปทันที

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

ดังนั้นยิ่งมีโหนดมากเท่าไร ผลกระทบของความล้มเหลวของฮาร์ดแวร์ก็จะยิ่งน้อยลงเท่านั้น

ข้อเสีย #4: มีขั้นตอนการปรับขนาดอัตโนมัติเพิ่มเติม
Kubernetes มีระบบปรับขนาดคลัสเตอร์อัตโนมัติสำหรับโครงสร้างพื้นฐานคลาวด์ ซึ่งช่วยให้คุณสามารถเพิ่มหรือลบโหนดได้โดยอัตโนมัติตามความต้องการในปัจจุบันของคุณ เมื่อโหนดมีขนาดใหญ่ขึ้น การปรับขนาดอัตโนมัติจะมีความรวดเร็วและยุ่งยากมากขึ้น ตัวอย่างเช่น บนสองโหนด การเพิ่มโหนดเพิ่มเติมจะเพิ่มความจุของคลัสเตอร์ทันที 50% และคุณจะต้องจ่ายค่าทรัพยากรเหล่านั้น แม้ว่าคุณจะไม่ต้องการมันก็ตาม

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

ตอนนี้เรามาดูข้อดีและข้อเสียของโหนดขนาดเล็กจำนวนมากกัน

ตัวเลือกที่สอง: โหนดขนาดเล็กจำนวนมาก

ข้อดีของแนวทางนี้โดยพื้นฐานแล้วมีต้นกำเนิดมาจากข้อเสียของตัวเลือกตรงข้ามที่มีโหนดขนาดใหญ่หลายโหนด

ข้อดี

Pro #1: ผลกระทบจากความล้มเหลวน้อยลง
ยิ่งมีโหนดมากเท่าใด พ็อดในแต่ละโหนดก็ยิ่งน้อยลงเท่านั้น ตัวอย่างเช่น หากคุณมีหนึ่งร้อยโมดูลต่อสิบโหนด แต่ละโหนดก็จะมีโมดูลโดยเฉลี่ยสิบโมดูล

ด้วยวิธีนี้ หากโหนดใดโหนดหนึ่งล้มเหลว คุณจะสูญเสียภาระงานเพียง 10% เท่านั้น มีโอกาสที่แบบจำลองจำนวนเล็กน้อยเท่านั้นที่จะได้รับผลกระทบ และแอปพลิเคชันโดยรวมจะยังคงทำงานได้

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

Pro #2: การจำลองแบบที่ดี
หากมีโหนดเพียงพอ ตัวกำหนดเวลา Kubernetes จะสามารถกำหนดโหนดที่แตกต่างกันให้กับแบบจำลองทั้งหมดได้ ด้วยวิธีนี้ หากโหนดล้มเหลว จะมีเพียงเรพลิกาเดียวเท่านั้นที่จะได้รับผลกระทบ และแอปพลิเคชันจะยังคงพร้อมใช้งาน

cons

ข้อเสียข้อที่ 1 ควบคุมยาก
โหนดจำนวนมากจัดการได้ยากกว่า ตัวอย่างเช่น แต่ละโหนด Kubernetes จะต้องสื่อสารกับโหนดอื่นๆ ทั้งหมด กล่าวคือ จำนวนการเชื่อมต่อจะเพิ่มขึ้นเป็นกำลังสอง และการเชื่อมต่อทั้งหมดเหล่านี้จำเป็นต้องได้รับการติดตาม

ตัวควบคุมโหนดใน Kubernetes Controller Manager จะเดินผ่านโหนดทั้งหมดในคลัสเตอร์เป็นประจำเพื่อตรวจสอบสภาพ - ยิ่งมีโหนดมากเท่าใด ตัวควบคุมก็จะยิ่งมีภาระมากขึ้นเท่านั้น

โหลดบนฐานข้อมูล etcd ก็เพิ่มขึ้นเช่นกัน - การโทร kubelet และ kube-proxy แต่ละครั้ง กะลาสี สำหรับ etcd (ผ่าน API) ซึ่ง etcd ควรออกอากาศการอัปเดตออบเจ็กต์

โดยทั่วไป แต่ละโหนดของผู้ปฏิบัติงานจะกำหนดภาระเพิ่มเติมให้กับส่วนประกอบของระบบของโหนดหลัก

Kubernetes รองรับคลัสเตอร์อย่างเป็นทางการด้วย จำนวนโหนดมากถึง 5000- อย่างไรก็ตาม ในทางปฏิบัติมีอยู่แล้ว 500 โหนด อาจทำให้เกิดปัญหาที่ไม่เล็กน้อยได้.

หากต้องการจัดการโหนดผู้ปฏิบัติงานจำนวนมาก คุณควรเลือกโหนดหลักที่มีประสิทธิภาพมากกว่า ตัวอย่างเช่น kube-up ติดตั้งโดยอัตโนมัติ ขนาด VM ที่ถูกต้องสำหรับโหนดหลักขึ้นอยู่กับจำนวนโหนดของผู้ปฏิบัติงาน นั่นคือ ยิ่งโหนดของผู้ปฏิบัติงานมากเท่าใด โหนดหลักก็จะยิ่งมีประสิทธิผลมากขึ้นเท่านั้น

เพื่อแก้ไขปัญหาเฉพาะเหล่านี้จึงมีการพัฒนาพิเศษเช่น Kubelet เสมือนจริง- ระบบนี้ช่วยให้คุณข้ามข้อจำกัดและสร้างคลัสเตอร์ที่มีโหนดผู้ปฏิบัติงานจำนวนมากได้

ข้อเสีย #2: ต้นทุนค่าโสหุ้ยมากขึ้น
บนโหนดผู้ปฏิบัติงานแต่ละโหนด Kubernetes จะเรียกใช้ชุด daemons ระบบ ซึ่งรวมถึงรันไทม์ของคอนเทนเนอร์ (เช่น Docker), kube-proxy และ kubelet รวมถึง cAdvisor พวกเขาใช้ทรัพยากรร่วมกันในปริมาณที่แน่นอน

หากคุณมีโหนดเล็กๆ จำนวนมาก สัดส่วนของค่าใช้จ่ายในแต่ละโหนดก็จะมากขึ้น ตัวอย่างเช่น ลองจินตนาการว่า daemons ระบบทั้งหมดบนโหนดเดียวใช้แกน CPU 0,1 ตัวและหน่วยความจำ 0,1 GB ร่วมกัน หากคุณมีโหนดสิบคอร์หนึ่งโหนดที่มีหน่วยความจำ 10 GB ดังนั้น daemons จะใช้ 1% ของความจุของคลัสเตอร์ ในทางกลับกัน บนโหนดแบบ single-core จำนวน 1 โหนดที่มีหน่วยความจำ 10 GB daemons จะใช้ XNUMX% ของความจุของคลัสเตอร์

ดังนั้น ยิ่งมีโหนดน้อยลง โครงสร้างพื้นฐานก็จะยิ่งมีประสิทธิภาพมากขึ้นเท่านั้น

ข้อเสียข้อที่ 3 การใช้ทรัพยากรอย่างไม่มีประสิทธิภาพ
บนโหนดขนาดเล็ก อาจเป็นไปได้ว่าชิ้นทรัพยากรที่เหลือมีขนาดเล็กเกินไปที่จะมอบหมายภาระงานใดๆ ให้ ดังนั้นจึงยังไม่มีการใช้งาน

ตัวอย่างเช่น แต่ละพ็อดต้องใช้หน่วยความจำ 0,75 GB หากคุณมีสิบโหนด โดยแต่ละโหนดมีหน่วยความจำ 1GB คุณสามารถรันได้สิบพ็อด โดยปล่อยให้แต่ละโหนดมีหน่วยความจำที่ไม่ได้ใช้ 0,25GB

ซึ่งหมายความว่า 25% ของหน่วยความจำของคลัสเตอร์ทั้งหมดจะสูญเปล่า

บนโหนดขนาดใหญ่ที่มีหน่วยความจำ 10 GB คุณสามารถเรียกใช้โมดูลเหล่านี้ได้ 13 โมดูล - และจะมีเพียงแฟรกเมนต์ที่ไม่ได้ใช้เพียง 0,25 GB เท่านั้น

ในกรณีนี้จะสิ้นเปลืองหน่วยความจำเพียง 2,5% เท่านั้น

ดังนั้นทรัพยากรจึงถูกใช้อย่างเหมาะสมมากขึ้นบนโหนดขนาดใหญ่

ปมใหญ่สองสามปมหรือปมเล็ก ๆ มากมาย?

แล้วอันไหนดีกว่ากัน: มีโหนดขนาดใหญ่สองสามโหนดในคลัสเตอร์หรือโหนดเล็ก ๆ จำนวนมาก? เช่นเคยไม่มีคำตอบที่ชัดเจน ขึ้นอยู่กับประเภทของแอปพลิเคชันมาก

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

ในสถานการณ์ระดับกลาง ให้เลือกโดยพิจารณาจากข้อดีและข้อเสียของแต่ละตัวเลือก บางทีข้อโต้แย้งบางข้ออาจเกี่ยวข้องกับสถานการณ์ของคุณมากกว่าข้อโต้แย้งอื่นๆ

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

ไม่มีสูตรเดียวและแต่ละสถานการณ์มีความแตกต่างของตัวเองและมีเพียงการผลิตเท่านั้นที่จะแสดงความจริง

แปลโดยทีมงานแพลตฟอร์มคลาวด์ Mail.ru โซลูชั่นคลาวด์.

ข้อมูลเพิ่มเติมเกี่ยวกับ Kubernetes: 25 เครื่องมือที่มีประโยชน์สำหรับการจัดการและการปรับใช้คลัสเตอร์.

ที่มา: will.com