Kubernetes: โอเพ่นซอร์สเทียบกับเฉพาะผู้จำหน่าย

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

เริ่มต้นด้วยสิ่งที่เป็น Kubernetes. นี่คือระบบสำหรับจัดการคอนเทนเนอร์บนโฮสต์จำนวนมาก จากภาษากรีกแปลว่า "นักบิน" หรือ "ผู้ถือหางเสือเรือ" พัฒนาขึ้นครั้งแรกโดย Google และบริจาคเพื่อสนับสนุนเทคโนโลยีให้กับ Cloud Native Computing Foundation ซึ่งเป็นองค์กรไม่แสวงผลกำไรระดับนานาชาติที่รวบรวมนักพัฒนา ผู้ใช้ปลายทาง และผู้ให้บริการเทคโนโลยีคอนเทนเนอร์ชั้นนำของโลก

จัดการคอนเทนเนอร์จำนวนมาก

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

อิมเมจคอนเทนเนอร์แสดงถึงแอปพลิเคชันบวกกับการอ้างอิง แอปพลิเคชัน การขึ้นต่อกัน และอิมเมจระบบไฟล์ OS จะอยู่ในส่วนต่างๆ ของรูปภาพ ซึ่งเรียกว่าเลเยอร์ ชั้นต่างๆ สามารถนำมาใช้ใหม่สำหรับภาชนะต่างๆ ได้ ตัวอย่างเช่น แอปพลิเคชันทั้งหมดในบริษัทอาจใช้เลเยอร์ฐานของ Ubuntu เมื่อใช้งานคอนเทนเนอร์ ไม่จำเป็นต้องจัดเก็บสำเนาชั้นฐานเดียวหลายชุดไว้บนโฮสต์ สิ่งนี้ทำให้คุณสามารถเพิ่มประสิทธิภาพการจัดเก็บและจัดส่งรูปภาพได้

เมื่อเราต้องการเรียกใช้แอปพลิเคชันจากคอนเทนเนอร์ เลเยอร์ที่จำเป็นจะถูกซ้อนทับกัน และระบบไฟล์โอเวอร์เลย์จะถูกสร้างขึ้น เลเยอร์การบันทึกจะถูกวางไว้ด้านบน ซึ่งจะถูกเอาออกเมื่อคอนเทนเนอร์หยุด เพื่อให้แน่ใจว่าเมื่อคอนเทนเนอร์ทำงาน แอปพลิเคชันจะมีสภาพแวดล้อมเดียวกันเสมอซึ่งไม่สามารถเปลี่ยนแปลงได้ สิ่งนี้รับประกันความสามารถในการทำซ้ำของสภาพแวดล้อมบนระบบปฏิบัติการโฮสต์ที่แตกต่างกัน ไม่ว่าจะเป็น Ubuntu หรือ CentOS สภาพแวดล้อมจะเหมือนเดิมเสมอ นอกจากนี้ คอนเทนเนอร์ยังถูกแยกออกจากโฮสต์โดยใช้กลไกที่สร้างไว้ในเคอร์เนล Linux แอปพลิเคชันในคอนเทนเนอร์จะไม่เห็นไฟล์ กระบวนการของโฮสต์และคอนเทนเนอร์ใกล้เคียง การแยกแอปพลิเคชันออกจากระบบปฏิบัติการโฮสต์นี้ช่วยเพิ่มระดับการรักษาความปลอดภัยเพิ่มเติม

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

ความต้องการ Kubernetes นั้นเกิดขึ้นอย่างแม่นยำเนื่องจากความสามารถในการจัดการกลุ่มคอนเทนเนอร์บนโฮสต์หลาย ๆ ตัวในฐานะเอนทิตีเดี่ยวบางประเภท ความนิยมของระบบเปิดโอกาสให้สร้าง DevOps หรือ Development Operations ซึ่ง Kubernetes ใช้เพื่อรันกระบวนการของ DevOps นี้

รูปที่ 1 การแสดงแผนผังวิธีการทำงานของ Kubernetes

ระบบอัตโนมัติเต็มรูปแบบ

โดยพื้นฐานแล้ว DevOps เป็นระบบอัตโนมัติของกระบวนการพัฒนา โดยคร่าวๆ แล้ว นักพัฒนาจะเขียนโค้ดที่อัปโหลดไปยังพื้นที่เก็บข้อมูล จากนั้นโค้ดนี้จะถูกรวบรวมโดยอัตโนมัติทันทีในคอนเทนเนอร์ที่มีไลบรารีทั้งหมด ทดสอบและ "เปิดตัว" ไปยังขั้นตอนถัดไป - การจัดเตรียม จากนั้นจึงไปยังเวอร์ชันที่ใช้งานจริงทันที

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

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

ข้อดี ข้อดี ข้อดี

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

• การจัดการเรพลิกาหลายรายการ สิ่งที่สำคัญที่สุดคือการจัดการคอนเทนเนอร์ข้ามโฮสต์หลายแห่ง ที่สำคัญกว่านั้นคือจัดการการจำลองแอปพลิเคชันหลายรายการในคอนเทนเนอร์เป็นเอนทิตีเดียว ด้วยเหตุนี้ วิศวกรจึงไม่ต้องกังวลเกี่ยวกับคอนเทนเนอร์แต่ละตัว หากคอนเทนเนอร์ตัวใดตัวหนึ่งขัดข้อง Kubernetes จะเห็นสิ่งนี้และรีสตาร์ทอีกครั้ง
• เครือข่ายคลัสเตอร์ Kubernetes ยังมีสิ่งที่เรียกว่าเครือข่ายคลัสเตอร์พร้อมพื้นที่ที่อยู่ของตัวเอง ด้วยเหตุนี้ แต่ละพ็อดจึงมีที่อยู่ของตัวเอง subpod เข้าใจว่าเป็นหน่วยโครงสร้างขั้นต่ำของคลัสเตอร์ซึ่งมีการเปิดตัวคอนเทนเนอร์โดยตรง นอกจากนี้ Kubernetes ยังมีฟังก์ชันที่รวมโหลดบาลานเซอร์และ Service Discovery เข้าด้วยกัน วิธีนี้ช่วยให้คุณกำจัดการจัดการที่อยู่ IP ด้วยตนเองและมอบหมายงานนี้ให้กับ Kubernetes และการตรวจสอบสภาพอัตโนมัติจะช่วยตรวจจับปัญหาและเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังพ็อดที่ใช้งานได้
• การจัดการการตั้งค่า. เมื่อจัดการแอปพลิเคชันจำนวนมาก การจัดการการกำหนดค่าแอปพลิเคชันจะทำได้ยาก เพื่อจุดประสงค์นี้ Kubernetes มีทรัพยากร ConfigMap พิเศษ ช่วยให้คุณสามารถจัดเก็บการกำหนดค่าจากส่วนกลางและเปิดเผยไปยังพ็อดเมื่อเรียกใช้แอปพลิเคชัน กลไกนี้ช่วยให้เรารับประกันความสอดคล้องของการกำหนดค่าในการจำลองแอปพลิเคชันอย่างน้อยสิบหรือร้อยรายการ
• เล่มต่อเนื่อง คอนเทนเนอร์จะไม่เปลี่ยนรูปโดยธรรมชาติ และเมื่อคอนเทนเนอร์หยุดทำงาน ข้อมูลทั้งหมดที่เขียนลงในระบบไฟล์จะถูกทำลาย แต่บางแอพพลิเคชั่นจะเก็บข้อมูลไว้บนดิสก์โดยตรง เพื่อแก้ไขปัญหานี้ Kubernetes มีฟังก์ชันการจัดการพื้นที่เก็บข้อมูลดิสก์ - Persistent Volumes กลไกนี้ใช้ที่จัดเก็บข้อมูลภายนอกสำหรับข้อมูลและสามารถถ่ายโอนที่เก็บข้อมูลถาวร บล็อกหรือไฟล์ลงในคอนเทนเนอร์ได้ โซลูชันนี้ช่วยให้คุณสามารถจัดเก็บข้อมูลแยกต่างหากจากผู้ปฏิบัติงาน ซึ่งจะช่วยบันทึกไว้หากผู้ปฏิบัติงานคนเดียวกันเหล่านี้ใช้งานไม่ได้
• โหลดบาลานเซอร์ แม้ว่าใน Kubernetes เราจะจัดการเอนทิตีเชิงนามธรรม เช่น Deployment, StatefulSet ฯลฯ แต่สุดท้ายแล้วคอนเทนเนอร์จะทำงานบนเครื่องเสมือนหรือเซิร์ฟเวอร์ฮาร์ดแวร์ทั่วไป พวกมันไม่สมบูรณ์แบบและอาจล้มลงเมื่อใดก็ได้ Kubernetes จะเห็นสิ่งนี้และเปลี่ยนเส้นทางการรับส่งข้อมูลภายในไปยังแบบจำลองอื่นๆ แต่จะทำอย่างไรกับการจราจรที่มาจากภายนอก? หากคุณเพียงกำหนดเส้นทางการรับส่งข้อมูลไปยังพนักงานคนใดคนหนึ่ง หากขัดข้อง บริการจะไม่สามารถใช้งานได้ เพื่อแก้ไขปัญหานี้ Kubernetes มีบริการต่างๆ เช่น Load Balancer ได้รับการออกแบบมาเพื่อกำหนดค่า Cloud Balancer ภายนอกสำหรับผู้ปฏิบัติงานทุกคนในคลัสเตอร์โดยอัตโนมัติ ตัวปรับสมดุลภายนอกนี้กำหนดเส้นทางการรับส่งข้อมูลภายนอกไปยังผู้ปฏิบัติงานและตรวจสอบสถานะของพวกเขาเอง หากพนักงานหนึ่งคนขึ้นไปไม่ว่าง การรับส่งข้อมูลจะถูกเปลี่ยนเส้นทางไปยังผู้อื่น สิ่งนี้ช่วยให้คุณสร้างบริการที่มีความพร้อมใช้งานสูงโดยใช้ Kubernetes

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

โอเพ่นซอร์ส Kubernetes

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

• ประการแรกคือความต้องการความรู้และประสบการณ์ของผู้ดูแลระบบและวิศวกรที่จะปรับใช้และสนับสนุนทั้งหมดนี้ เนื่องจากลูกค้าได้รับอิสระในการดำเนินการอย่างสมบูรณ์ในคลัสเตอร์ เขาจึงต้องรับผิดชอบต่อประสิทธิภาพของคลัสเตอร์เอง และมันง่ายมากที่จะทำลายทุกสิ่งที่นี่
• ประการที่สองคือการขาดการบูรณาการ หากคุณใช้งาน Kubernetes โดยไม่มีแพลตฟอร์มการจำลองเสมือนยอดนิยม คุณจะไม่ได้รับประโยชน์ทั้งหมดจากโปรแกรม เช่น การใช้บริการ Persistent Volumes และ Load Balancer

รูปที่ 2. สถาปัตยกรรม k8s

Kubernetes จากผู้จำหน่าย

การบูรณาการกับผู้ให้บริการระบบคลาวด์มีสองทางเลือก:

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

มันเกิดขึ้นที่นี่ได้อย่างไร. วิศวกรที่เริ่มคลัสเตอร์จะระบุจำนวนผู้ปฏิบัติงานที่เขาต้องการและพารามิเตอร์ใด (เช่น ผู้ปฏิบัติงาน 5 คน โดยแต่ละรายมี CPU 10 ตัว, RAM ขนาด 16 GB และดิสก์ขนาด 100 GB) หลังจากนั้นจะสามารถเข้าถึงคลัสเตอร์ที่สร้างไว้แล้วได้ ในกรณีนี้ ผู้ปฏิบัติงานที่มีการเปิดใช้โหลดจะถูกโอนไปยังไคลเอนต์โดยสมบูรณ์ แต่ระนาบการจัดการทั้งหมดยังคงอยู่ภายใต้ความรับผิดชอบของผู้จัดจำหน่าย (หากมีการให้บริการตามรูปแบบบริการที่มีการจัดการ)

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

รูปที่ 3 ตัวอย่างคลัสเตอร์ Kubernetes จากผู้ให้บริการระบบคลาวด์

สิ่งที่ควรเลือก: โอเพ่นซอร์สหรือผู้จำหน่าย

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

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

บทความนี้จัดทำโดย Dmitry Krasnov สถาปนิกชั้นนำของบริการ Containerum ของผู้ให้บริการ #CloudMTS

ที่มา: will.com