บันทึก. แปล: เนื้อหานี้มาจากโครงการด้านการศึกษา คือคำตอบสำหรับคำถามยอดนิยมเมื่อออกแบบโครงสร้างพื้นฐานที่ใช้ Kubernetes เราหวังว่าคำอธิบายโดยละเอียดเกี่ยวกับข้อดีข้อเสียของแต่ละตัวเลือกจะช่วยให้คุณตัดสินใจเลือกโครงการได้ดีที่สุด
TL; DR: ชุดปริมาณงานเดียวกันสามารถรันบนคลัสเตอร์ขนาดใหญ่หลายคลัสเตอร์ (แต่ละคลัสเตอร์จะมีปริมาณงานจำนวนมาก) หรือบนคลัสเตอร์ขนาดเล็กจำนวนมาก (โดยมีจำนวนโหลดน้อยในแต่ละคลัสเตอร์)
ด้านล่างนี้เป็นตารางที่ประเมินข้อดีข้อเสียของแต่ละวิธี:
เมื่อใช้ Kubernetes เป็นแพลตฟอร์มสำหรับการรันแอปพลิเคชัน มักมีคำถามพื้นฐานหลายประการเกี่ยวกับความซับซ้อนของการตั้งค่าคลัสเตอร์:
- ฉันควรใช้คลัสเตอร์จำนวนเท่าใด
- ฉันควรทำให้มันใหญ่แค่ไหน?
- แต่ละคลัสเตอร์ควรมีอะไรบ้าง?
ในบทความนี้ ฉันจะพยายามตอบคำถามเหล่านี้ทั้งหมดโดยการวิเคราะห์ข้อดีข้อเสียของแต่ละวิธี
คำชี้แจงของคำถาม
ในฐานะนักพัฒนาซอฟต์แวร์ คุณน่าจะพัฒนาและใช้งานแอพพลิเคชั่นหลายตัวในเวลาเดียวกัน
นอกจากนี้ อินสแตนซ์จำนวนมากของแอปพลิเคชันเหล่านี้มีแนวโน้มที่จะทำงานในสภาพแวดล้อมที่แตกต่างกัน - ตัวอย่างเช่น สิ่งเหล่านี้อาจเป็น dev, ทดสอบ и แยง.
ผลลัพธ์ที่ได้คือเมทริกซ์ทั้งหมดของแอปพลิเคชันและสภาพแวดล้อม:
การใช้งานและสภาพแวดล้อม
ตัวอย่างข้างต้นแสดงถึง 3 แอปพลิเคชันและ 3 สภาพแวดล้อม ส่งผลให้มีทั้งหมด 9 ตัวเลือกที่เป็นไปได้
อินสแตนซ์แอปพลิเคชันแต่ละรายการเป็นหน่วยการปรับใช้งานในตัวเองที่สามารถทำงานร่วมกับผู้อื่นได้โดยอิสระ
โปรดทราบว่า อินสแตนซ์ของแอปพลิเคชัน อาจประกอบด้วยหลายอย่าง ส่วนประกอบเช่นส่วนหน้า แบ็คเอนด์ ฐานข้อมูล เป็นต้น ในกรณีของแอปพลิเคชันไมโครเซอร์วิส อินสแตนซ์จะรวมไมโครเซอร์วิสทั้งหมดไว้ด้วย
ด้วยเหตุนี้ ผู้ใช้ Kubernetes จึงมีคำถามหลายประการ:
- อินสแตนซ์ของแอปพลิเคชันทั้งหมดควรอยู่ในคลัสเตอร์เดียวหรือไม่
- คุ้มไหมที่จะมีคลัสเตอร์แยกต่างหากสำหรับแต่ละอินสแตนซ์ของแอปพลิเคชัน
- หรือบางทีควรใช้วิธีการข้างต้นรวมกัน?
ตัวเลือกทั้งหมดเหล่านี้ค่อนข้างใช้งานได้ เนื่องจาก Kubernetes เป็นระบบที่ยืดหยุ่นซึ่งไม่จำกัดความสามารถของผู้ใช้
ต่อไปนี้เป็นวิธีที่เป็นไปได้บางส่วน:
- คลัสเตอร์ทั่วไปขนาดใหญ่หนึ่งคลัสเตอร์
- กลุ่มที่มีความเชี่ยวชาญสูงขนาดเล็กจำนวนมาก
- หนึ่งคลัสเตอร์ต่อแอปพลิเคชัน
- หนึ่งคลัสเตอร์ต่อสภาพแวดล้อม
ดังที่แสดงด้านล่าง สองแนวทางแรกอยู่ที่ปลายตรงข้ามกันของขนาดของตัวเลือก:
จากกลุ่มใหญ่ (ซ้าย) สู่กลุ่มเล็ก (ขวา)
โดยทั่วไปแล้ว คลัสเตอร์หนึ่งจะถือว่า "ใหญ่กว่า" มากกว่าอีกคลัสเตอร์หนึ่งหากมีโหนดและพ็อดรวมกันมากกว่า ตัวอย่างเช่น คลัสเตอร์ที่มี 10 โหนดและ 100 พ็อดจะใหญ่กว่าคลัสเตอร์ที่มี 1 โหนดและ 10 พ็อด
เอาล่ะ มาเริ่มกันเลย!
1. คลัสเตอร์ทั่วไปขนาดใหญ่หนึ่งคลัสเตอร์
ตัวเลือกแรกคือการวางปริมาณงานทั้งหมดไว้ในคลัสเตอร์เดียว:
กลุ่มใหญ่กลุ่มหนึ่ง
ภายในแนวทางนี้ คลัสเตอร์จะถูกใช้เป็นสากล แพลตฟอร์มโครงสร้างพื้นฐาน — คุณเพียงแค่ปรับใช้ทุกสิ่งที่คุณต้องการในคลัสเตอร์ Kubernetes ที่มีอยู่
Kubernetes อนุญาตให้ส่วนต่างๆ ของคลัสเตอร์แยกออกจากกันในเชิงตรรกะ เพื่อให้แต่ละอินสแตนซ์ของแอปพลิเคชันสามารถมีเนมสเปซของตัวเองได้
ลองดูข้อดีข้อเสียของแนวทางนี้
+ การใช้ทรัพยากรอย่างมีประสิทธิภาพ
ด้วยคลัสเตอร์เดียว คุณจะต้องมีสำเนาทรัพยากรทั้งหมดที่จำเป็นในการเรียกใช้และจัดการคลัสเตอร์ Kubernetes เพียงสำเนาเดียว
ตัวอย่างเช่น สิ่งนี้เป็นจริงสำหรับโหนดหลัก โดยทั่วไปแล้ว คลัสเตอร์ Kubernetes แต่ละคลัสเตอร์จะมีโหนดหลัก 3 โหนด ดังนั้นสำหรับคลัสเตอร์เดียว จำนวนของโหนดจะยังคงเป็นแบบนั้น (สำหรับการเปรียบเทียบ 10 คลัสเตอร์จะต้องมีโหนดหลัก 30 โหนด)
รายละเอียดข้างต้นยังใช้กับบริการอื่นๆ ที่ดำเนินการทั่วทั้งคลัสเตอร์ เช่น โหลดบาลานเซอร์ ตัวควบคุม Ingress การตรวจสอบสิทธิ์ การบันทึก และระบบการตรวจสอบ
ในคลัสเตอร์เดียว บริการทั้งหมดเหล่านี้สามารถใช้ได้พร้อมกันสำหรับปริมาณงานทั้งหมด (ไม่จำเป็นต้องสร้างสำเนาของบริการเหล่านี้ เช่นเดียวกับกรณีที่มีหลายคลัสเตอร์)
+ ราคาถูก
จากผลที่ตามมาข้างต้น คลัสเตอร์จำนวนน้อยลงมักจะถูกกว่าเนื่องจากไม่มีค่าใช้จ่ายค่าโสหุ้ย
นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งสำหรับโหนดหลัก ซึ่งอาจมีค่าใช้จ่ายจำนวนมากไม่ว่าโหนดเหล่านั้นจะโฮสต์อย่างไร (ภายในองค์กรหรือในระบบคลาวด์)
บริการ Kubernetes ที่มีการจัดการบางอย่าง เช่น หรือ จัดเตรียมเลเยอร์ควบคุมให้ฟรี ในกรณีนี้ ปัญหาด้านต้นทุนจะรุนแรงน้อยลง
นอกจากนี้ยังมีบริการที่มีการจัดการซึ่งเรียกเก็บค่าธรรมเนียมคงที่สำหรับการดำเนินงานของแต่ละคลัสเตอร์ Kubernetes (เช่น ).
+ การบริหารงานที่มีประสิทธิภาพ
การจัดการหนึ่งคลัสเตอร์นั้นง่ายกว่าการจัดการหลายคลัสเตอร์
การบริหารอาจรวมถึงงานต่อไปนี้:
- อัปเดตเวอร์ชัน Kubernetes;
- การตั้งค่าไปป์ไลน์ CI/CD
- การติดตั้งปลั๊กอิน CNI
- การตั้งค่าระบบยืนยันตัวตนผู้ใช้
- การติดตั้งตัวควบคุมการเข้าถึง
และอื่น ๆ อีกมากมาย…
ในกรณีของคลัสเตอร์เดียว คุณจะต้องดำเนินการทั้งหมดนี้เพียงครั้งเดียวเท่านั้น
สำหรับคลัสเตอร์จำนวนมาก การดำเนินการจะต้องทำซ้ำหลายครั้ง ซึ่งอาจต้องใช้กระบวนการและเครื่องมืออัตโนมัติบางอย่างเพื่อให้มั่นใจถึงความสอดคล้องและความสม่ำเสมอในกระบวนการ
และตอนนี้บางคำเกี่ยวกับข้อเสีย
− จุดเดียวของความล้มเหลว
ในกรณีที่ถูกปฏิเสธ เท่านั้น คลัสเตอร์จะหยุดทำงานทันที ทั้งหมด ภาระงาน!
มีหลายสิ่งที่อาจผิดพลาดได้:
- การอัปเดต Kubernetes ทำให้เกิดผลข้างเคียงที่ไม่คาดคิด
- ส่วนประกอบทั่วทั้งคลัสเตอร์ (เช่น ปลั๊กอิน CNI) เริ่มทำงานไม่ทำงานตามที่คาดไว้
- คอมโพเนนต์คลัสเตอร์ตัวใดตัวหนึ่งไม่ได้รับการกำหนดค่าอย่างถูกต้อง
- ความล้มเหลวในโครงสร้างพื้นฐานพื้นฐาน
เหตุการณ์ดังกล่าวอย่างหนึ่งอาจทำให้เกิดความเสียหายอย่างร้ายแรงต่อปริมาณงานทั้งหมดที่โฮสต์อยู่ในคลัสเตอร์ที่ใช้ร่วมกัน
− ไม่มีฉนวนแข็ง
การทำงานในคลัสเตอร์ที่ใช้ร่วมกันหมายความว่าแอปพลิเคชันจะแชร์ฮาร์ดแวร์ ความสามารถด้านเครือข่าย และระบบปฏิบัติการบนโหนดคลัสเตอร์
ในแง่หนึ่ง คอนเทนเนอร์สองตัวที่มีแอปพลิเคชันสองตัวที่ทำงานบนโหนดเดียวกันก็เหมือนกับสองกระบวนการที่ทำงานบนเครื่องเดียวกันที่ใช้เคอร์เนลระบบปฏิบัติการเดียวกัน
คอนเทนเนอร์ Linux มีรูปแบบการแยกบางส่วน แต่ก็ไม่ได้แข็งแกร่งเท่ากับที่มอบให้โดยเครื่องเสมือน โดยพื้นฐานแล้ว กระบวนการในคอนเทนเนอร์นั้นเป็นกระบวนการเดียวกับที่ทำงานบนระบบปฏิบัติการโฮสต์
นี่อาจเป็นปัญหาด้านความปลอดภัย: ในทางทฤษฎีแล้ว การจัดการนี้อนุญาตให้แอปพลิเคชันที่ไม่เกี่ยวข้องสามารถสื่อสารระหว่างกันได้ (ทั้งโดยตั้งใจหรือโดยบังเอิญ)
นอกจากนี้ ปริมาณงานทั้งหมดในคลัสเตอร์ Kubernetes ยังแชร์บริการบางอย่างทั่วทั้งคลัสเตอร์ เช่น - ช่วยให้แอปพลิเคชันสามารถค้นหาบริการของแอปพลิเคชันอื่นในคลัสเตอร์ได้
ประเด็นข้างต้นทั้งหมดอาจมีความหมายที่แตกต่างกันขึ้นอยู่กับข้อกำหนดด้านความปลอดภัยของแอปพลิเคชัน
Kubernetes มีเครื่องมือต่างๆ เพื่อป้องกันปัญหาด้านความปลอดภัย เช่น и . อย่างไรก็ตาม การตั้งค่าอย่างถูกต้องต้องอาศัยประสบการณ์ นอกจากนี้ ยังไม่สามารถปิดช่องโหว่ด้านความปลอดภัยทั้งหมดได้อย่างสมบูรณ์
สิ่งสำคัญคือต้องจำไว้เสมอว่า Kubernetes ได้รับการออกแบบมาเพื่อ การแบ่งปัน, ไม่ใช่สำหรับ การแยกตัวและความปลอดภัย.
- ขาดการเช่าหลายรายการที่เข้มงวด
เนื่องจากมีทรัพยากรที่ใช้ร่วมกันมากมายในคลัสเตอร์ Kubernetes มีหลายวิธีที่แอปพลิเคชันต่างๆ สามารถก้าวข้ามกันและกันได้
ตัวอย่างเช่น แอปพลิเคชันอาจผูกขาดทรัพยากรที่ใช้ร่วมกัน (เช่น CPU หรือหน่วยความจำ) และปฏิเสธการเข้าถึงแอปพลิเคชันอื่นที่ทำงานบนโหนดเดียวกัน
Kubernetes มีกลไกต่างๆ เพื่อควบคุมพฤติกรรมนี้ เช่น (ดูบทความ "ด้วย" - ประมาณ แปล), и . อย่างไรก็ตาม ในกรณีด้านความปลอดภัย การกำหนดค่านั้นค่อนข้างไม่สำคัญและไม่สามารถป้องกันผลข้างเคียงที่คาดไม่ถึงได้ทั้งหมด
- ผู้ใช้จำนวนมาก
ในกรณีที่เป็นคลัสเตอร์เดียว คุณต้องเปิดให้คนจำนวนมากเข้าถึงได้ และยิ่งมีจำนวนมากเท่าใด ความเสี่ยงที่พวกเขาจะ "ทำลาย" บางสิ่งบางอย่างก็จะยิ่งมากขึ้นเท่านั้น
ภายในคลัสเตอร์ คุณสามารถควบคุมได้ว่าใครสามารถทำอะไรได้บ้าง (ดูบทความ “" - ประมาณ แปล). อย่างไรก็ตาม จะไม่ป้องกันผู้ใช้จากการ "ทำลาย" บางสิ่งที่อยู่ในขอบเขตความรับผิดชอบของตน
− กลุ่มไม่สามารถเติบโตได้อย่างไม่มีกำหนด
คลัสเตอร์ที่ใช้สำหรับปริมาณงานทั้งหมดอาจมีขนาดค่อนข้างใหญ่ (ในแง่ของจำนวนโหนดและพ็อด)
แต่ปัญหาอื่นก็เกิดขึ้น: คลัสเตอร์ใน Kubernetes ไม่สามารถเติบโตได้อย่างไม่มีกำหนด
มีขีดจำกัดทางทฤษฎีเกี่ยวกับขนาดคลัสเตอร์ ใน Kubernetes จะอยู่ที่ประมาณ .
อย่างไรก็ตาม ในชีวิตจริง ปัญหาอาจเริ่มเร็วกว่านั้นมาก เช่น แค่กับ .
ความจริงก็คือคลัสเตอร์ขนาดใหญ่มีภาระงานสูงบนเลเยอร์ควบคุม Kubernetes กล่าวอีกนัยหนึ่ง การรักษาคลัสเตอร์ให้ทำงานอย่างมีประสิทธิภาพจำเป็นต้องมีการปรับแต่งอย่างระมัดระวัง
มีการสำรวจปัญหานี้ในบทความที่เกี่ยวข้องในบล็อกต้นฉบับชื่อ "'
แต่ลองพิจารณาแนวทางตรงกันข้าม: กระจุกขนาดเล็กจำนวนมาก
2. คลัสเตอร์เฉพาะทางขนาดเล็กจำนวนมาก
ด้วยแนวทางนี้ คุณจะใช้คลัสเตอร์แยกต่างหากสำหรับแต่ละองค์ประกอบที่คุณปรับใช้:
เป็นกลุ่มเล็กๆจำนวนมาก
เพื่อวัตถุประสงค์ของบทความนี้ภายใต้ องค์ประกอบที่ปรับใช้ได้ อ้างถึงอินสแตนซ์ของแอปพลิเคชัน - ตัวอย่างเช่น เวอร์ชัน dev ของแอปพลิเคชันแยกต่างหาก
กลยุทธ์นี้ใช้ Kubernetes เป็นผู้เชี่ยวชาญ รันไทม์ สำหรับอินสแตนซ์แอปพลิเคชันแต่ละรายการ
ลองดูข้อดีข้อเสียของแนวทางนี้
+ “รัศมีการระเบิด” ที่จำกัด
เมื่อคลัสเตอร์ล้มเหลว ผลที่ตามมาด้านลบจะถูกจำกัดเฉพาะกับปริมาณงานที่ถูกปรับใช้ในคลัสเตอร์นั้นเท่านั้น ปริมาณงานอื่นๆ ทั้งหมดยังคงไม่ถูกแตะต้อง
+ ฉนวนกันความร้อน
ปริมาณงานที่โฮสต์ในแต่ละคลัสเตอร์จะไม่แชร์ทรัพยากร เช่น โปรเซสเซอร์ หน่วยความจำ ระบบปฏิบัติการ เครือข่าย หรือบริการอื่นๆ
ผลลัพธ์ที่ได้คือการแยกแอปพลิเคชันที่ไม่เกี่ยวข้องออกจากกันอย่างแน่นหนา ซึ่งอาจเป็นประโยชน์ต่อความปลอดภัย
+ ผู้ใช้จำนวนน้อย
เนื่องจากแต่ละคลัสเตอร์มีชุดปริมาณงานที่จำกัด จำนวนผู้ใช้ที่มีสิทธิ์เข้าถึงคลัสเตอร์จึงลดลง
ยิ่งมีคนเข้าถึงคลัสเตอร์ได้น้อยลงเท่าใด ความเสี่ยงที่บางสิ่งจะ "พัง" ก็จะยิ่งน้อยลงเท่านั้น
มาดูข้อเสียกัน
− การใช้ทรัพยากรอย่างไม่มีประสิทธิภาพ
ตามที่กล่าวไว้ข้างต้น แต่ละคลัสเตอร์ Kubernetes ต้องการชุดทรัพยากรการจัดการเฉพาะ ได้แก่ โหนดหลัก ส่วนประกอบของเลเยอร์ควบคุม โซลูชันการตรวจสอบและการบันทึก
ในกรณีที่มีคลัสเตอร์ขนาดเล็กจำนวนมาก จะต้องจัดสรรทรัพยากรให้กับฝ่ายจัดการมากขึ้น
- ราคาแพง
การใช้ทรัพยากรอย่างไม่มีประสิทธิภาพทำให้เกิดต้นทุนสูงโดยอัตโนมัติ
ตัวอย่างเช่น การรักษาโหนดหลัก 30 โหนดแทนที่จะเป็น XNUMX โหนดที่มีพลังการประมวลผลเท่ากันย่อมส่งผลต่อต้นทุน
− ความยากลำบากในการบริหาร
การจัดการคลัสเตอร์ Kubernetes หลายคลัสเตอร์นั้นยากกว่าการจัดการคลัสเตอร์เดียวมาก
ตัวอย่างเช่น คุณจะต้องกำหนดค่าการตรวจสอบสิทธิ์และการอนุญาตสำหรับแต่ละคลัสเตอร์ เวอร์ชัน Kubernetes จะต้องได้รับการอัปเดตหลายครั้งด้วย
คุณอาจจำเป็นต้องใช้ระบบอัตโนมัติเพื่อทำให้งานทั้งหมดเหล่านี้มีประสิทธิภาพมากขึ้น
ตอนนี้เรามาดูสถานการณ์ที่รุนแรงน้อยลงกัน
3. หนึ่งคลัสเตอร์ต่อแอปพลิเคชัน
ในแนวทางนี้ คุณจะสร้างคลัสเตอร์แยกต่างหากสำหรับอินสแตนซ์ทั้งหมดของแอปพลิเคชันเฉพาะ:
คลัสเตอร์ต่อแอปพลิเคชัน
เส้นทางนี้ถือได้ว่าเป็นภาพรวมของหลักการ”แยกคลัสเตอร์ต่อทีม” เนื่องจากโดยปกติแล้วทีมวิศวกรกำลังพัฒนาแอปพลิเคชันหนึ่งรายการขึ้นไป
ลองดูข้อดีข้อเสียของแนวทางนี้
+ คลัสเตอร์สามารถปรับให้เข้ากับแอปพลิเคชันได้
หากแอปพลิเคชันมีความต้องการพิเศษ แอปพลิเคชันเหล่านั้นสามารถนำไปใช้ในคลัสเตอร์ได้โดยไม่ส่งผลกระทบต่อคลัสเตอร์อื่นๆ
ความต้องการดังกล่าวอาจรวมถึงผู้ปฏิบัติงาน GPU, ปลั๊กอิน CNI บางตัว, โครงข่ายบริการ หรือบริการอื่น ๆ
แต่ละคลัสเตอร์สามารถปรับแต่งให้เหมาะกับแอปพลิเคชันที่ทำงานอยู่ในนั้น เพื่อให้มีเฉพาะสิ่งที่จำเป็นเท่านั้น
− สภาพแวดล้อมที่แตกต่างกันในคลัสเตอร์เดียว
ข้อเสียของแนวทางนี้คืออินสแตนซ์ของแอปพลิเคชันจากสภาพแวดล้อมที่แตกต่างกันอยู่ร่วมกันในคลัสเตอร์เดียวกัน
ตัวอย่างเช่น เวอร์ชัน prod ของแอปพลิเคชันจะทำงานในคลัสเตอร์เดียวกันกับเวอร์ชัน dev นอกจากนี้ยังหมายความว่านักพัฒนาดำเนินการในคลัสเตอร์เดียวกันกับที่แอปพลิเคชันเวอร์ชันที่ใช้งานจริงดำเนินการอยู่
เนื่องจากการกระทำของนักพัฒนาหรือข้อบกพร่องในเวอร์ชัน dev หากเกิดความล้มเหลวในคลัสเตอร์ เวอร์ชัน prod ก็อาจได้รับผลกระทบเช่นกัน ซึ่งเป็นข้อเสียเปรียบอย่างมากของแนวทางนี้
และสุดท้าย สถานการณ์สุดท้ายในรายการของเรา
4. หนึ่งคลัสเตอร์ต่อสภาพแวดล้อม
สถานการณ์นี้เกี่ยวข้องกับการจัดสรรคลัสเตอร์แยกต่างหากสำหรับแต่ละสภาพแวดล้อม:
หนึ่งคลัสเตอร์ต่อสภาพแวดล้อม
ตัวอย่างเช่น คุณอาจมีคลัสเตอร์ dev, ทดสอบ и แยงซึ่งคุณจะเรียกใช้อินสแตนซ์ทั้งหมดของแอปพลิเคชันสำหรับสภาพแวดล้อมเฉพาะโดยเฉพาะ
ต่อไปนี้เป็นข้อดีและข้อเสียของแนวทางนี้
+ การแยกสภาพแวดล้อมการผลิต
ภายในแนวทางนี้ สภาพแวดล้อมทั้งหมดจะถูกแยกออกจากกัน อย่างไรก็ตาม ในทางปฏิบัติ สิ่งนี้มีความสำคัญอย่างยิ่งในสภาพแวดล้อมการผลิต
ขณะนี้แอปพลิเคชันเวอร์ชันที่ใช้งานจริงไม่ขึ้นอยู่กับสิ่งที่เกิดขึ้นในคลัสเตอร์และสภาพแวดล้อมอื่นๆ
ด้วยวิธีนี้ หากเกิดปัญหาขึ้นอย่างกะทันหันในคลัสเตอร์ dev แอปพลิเคชันเวอร์ชัน prod จะยังคงทำงานต่อไปราวกับว่าไม่มีอะไรเกิดขึ้น
+ คลัสเตอร์สามารถปรับให้เข้ากับสภาพแวดล้อมได้
แต่ละคลัสเตอร์สามารถปรับให้เข้ากับสภาพแวดล้อมได้ ตัวอย่างเช่น คุณสามารถ:
- ติดตั้งเครื่องมือสำหรับการพัฒนาและการดีบักในคลัสเตอร์ dev
- ติดตั้งกรอบการทดสอบและเครื่องมือในคลัสเตอร์ ทดสอบ;
- ใช้ฮาร์ดแวร์และช่องทางเครือข่ายที่มีประสิทธิภาพมากขึ้นในคลัสเตอร์ แยง.
สิ่งนี้ช่วยให้คุณเพิ่มประสิทธิภาพทั้งการพัฒนาแอพพลิเคชั่นและการดำเนินงาน
+ การจำกัดการเข้าถึงคลัสเตอร์การผลิต
ความจำเป็นในการทำงานโดยตรงกับคลัสเตอร์ผลิตภัณฑ์แทบจะไม่เกิดขึ้น ดังนั้นคุณจึงสามารถจำกัดกลุ่มคนที่สามารถเข้าถึงคลัสเตอร์ได้อย่างมาก
คุณสามารถก้าวไปอีกขั้นและปฏิเสธไม่ให้ผู้คนเข้าถึงคลัสเตอร์นี้ได้เลย และดำเนินการปรับใช้ทั้งหมดโดยใช้เครื่องมือ CI/CD อัตโนมัติ วิธีการดังกล่าวจะช่วยลดความเสี่ยงของข้อผิดพลาดของมนุษย์ให้เหลือน้อยที่สุดในจุดที่เกี่ยวข้องมากที่สุด
และตอนนี้บางคำเกี่ยวกับข้อเสีย
− ไม่มีการแยกระหว่างแอปพลิเคชัน
ข้อเสียเปรียบหลักของแนวทางนี้คือการขาดการแยกฮาร์ดแวร์และทรัพยากรระหว่างแอปพลิเคชัน
แอปพลิเคชันที่ไม่เกี่ยวข้องจะแชร์ทรัพยากรคลัสเตอร์: แกนระบบ ตัวประมวลผล หน่วยความจำ และบริการอื่นๆ บางอย่าง
ดังที่ได้กล่าวไปแล้ว สิ่งนี้อาจเป็นอันตรายได้
- ไม่สามารถแปลการพึ่งพาแอปพลิเคชันได้
หากแอปพลิเคชันมีข้อกำหนดพิเศษ จะต้องเป็นไปตามข้อกำหนดดังกล่าวในทุกคลัสเตอร์
ตัวอย่างเช่น หากแอปพลิเคชันต้องใช้ GPU แต่ละคลัสเตอร์จะต้องมีผู้ปฏิบัติงานอย่างน้อยหนึ่งคนที่มี GPU (แม้ว่าแอปพลิเคชันนั้นจะใช้เพียงแอปพลิเคชันนั้นก็ตาม)
เป็นผลให้เราเสี่ยงต่อต้นทุนที่สูงขึ้นและการใช้ทรัพยากรอย่างไม่มีประสิทธิภาพ
ข้อสรุป
หากคุณมีชุดแอปพลิเคชันเฉพาะ คุณสามารถจัดวางแอปพลิเคชันเหล่านั้นไว้ในคลัสเตอร์ขนาดใหญ่หลายคลัสเตอร์หรือคลัสเตอร์ขนาดเล็กจำนวนมากได้
บทความนี้กล่าวถึงข้อดีข้อเสียของแนวทางต่างๆ ตั้งแต่คลัสเตอร์ระดับโลกกลุ่มเดียวไปจนถึงคลัสเตอร์ขนาดเล็กและมีความเชี่ยวชาญสูงหลายกลุ่ม:
- คลัสเตอร์ทั่วไปขนาดใหญ่หนึ่งคลัสเตอร์
- กลุ่มที่มีความเชี่ยวชาญสูงขนาดเล็กจำนวนมาก
- หนึ่งคลัสเตอร์ต่อแอปพลิเคชัน
- หนึ่งคลัสเตอร์ต่อสภาพแวดล้อม
คุณควรใช้แนวทางใด?
เช่นเคย คำตอบขึ้นอยู่กับกรณีการใช้งาน: คุณต้องชั่งน้ำหนักข้อดีข้อเสียของแนวทางต่างๆ และเลือกตัวเลือกที่เหมาะสมที่สุด
อย่างไรก็ตาม ตัวเลือกไม่ได้จำกัดอยู่เพียงตัวอย่างข้างต้น คุณสามารถใช้ทั้งสองอย่างผสมกันก็ได้!
ตัวอย่างเช่น คุณสามารถจัดระเบียบคลัสเตอร์สองสามคลัสเตอร์สำหรับแต่ละทีม: คลัสเตอร์การพัฒนา (ซึ่งจะมีสภาพแวดล้อม dev и ทดสอบ) และคลัสเตอร์สำหรับ การผลิต (ซึ่งสภาพแวดล้อมการผลิตจะตั้งอยู่)
ตามข้อมูลในบทความนี้ คุณสามารถปรับข้อดีและข้อเสียให้เหมาะสมสำหรับสถานการณ์เฉพาะได้ ขอให้โชคดี!
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «";
- «";
- «'
ที่มา: will.com