Kubernetes เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการรันคอนเทนเนอร์ Docker ในสภาพแวดล้อมการผลิตแบบคลัสเตอร์ อย่างไรก็ตาม มีปัญหาที่ Kubernetes ไม่สามารถแก้ไขได้ สำหรับการปรับใช้ที่ใช้งานจริงบ่อยครั้ง เราจำเป็นต้องมีการปรับใช้งานสีน้ำเงิน/เขียวอัตโนมัติเต็มรูปแบบเพื่อหลีกเลี่ยงการหยุดทำงานในกระบวนการ ซึ่งยังต้องจัดการคำขอ HTTP ภายนอกและดำเนินการถ่ายข้อมูล SSL ด้วย ซึ่งต้องมีการผสานรวมกับโหลดบาลานเซอร์ เช่น ha-proxy ความท้าทายอีกประการหนึ่งคือการปรับขนาดคลัสเตอร์ Kubernetes แบบกึ่งอัตโนมัติเมื่อทำงานในสภาพแวดล้อมคลาวด์ เช่น การลดขนาดคลัสเตอร์บางส่วนลงในเวลากลางคืน
แม้ว่า Kubernetes จะไม่มีฟีเจอร์เหล่านี้นอกกรอบ แต่ก็มี API ที่คุณสามารถใช้เพื่อแก้ไขปัญหาที่คล้ายกันได้ เครื่องมือสำหรับการปรับใช้สีน้ำเงิน/เขียวอัตโนมัติและการปรับขนาดคลัสเตอร์ Kubernetes ได้รับการพัฒนาโดยเป็นส่วนหนึ่งของโปรเจ็กต์ Cloud RTI ซึ่งสร้างขึ้นจากโอเพ่นซอร์ส
บทความนี้ซึ่งเป็นข้อความถอดเสียงวิดีโอ จะแสดงวิธีตั้งค่า Kubernetes พร้อมกับส่วนประกอบโอเพ่นซอร์สอื่นๆ เพื่อสร้างสภาพแวดล้อมที่พร้อมสำหรับการผลิตที่ยอมรับโค้ดจากคอมมิตคอมไพล์โดยไม่มีการหยุดทำงานในการผลิต
ดังนั้น เมื่อคุณสามารถเข้าถึงแอปพลิเคชันของคุณจากโลกภายนอกได้ คุณสามารถเริ่มตั้งค่าระบบอัตโนมัติได้อย่างสมบูรณ์ กล่าวคือ นำไปสู่ขั้นตอนที่คุณสามารถดำเนินการคอมมิตคอมไพล์ได้ และตรวจสอบให้แน่ใจว่าการคอมมิตคอมไพล์นี้จะสิ้นสุดในเวอร์ชันที่ใช้งานจริง โดยปกติแล้ว เมื่อดำเนินการตามขั้นตอนเหล่านี้ เมื่อดำเนินการปรับใช้ เราไม่ต้องการประสบปัญหาระบบหยุดทำงาน ดังนั้นการทำงานอัตโนมัติใดๆ ใน Kubernetes จะเริ่มต้นด้วย API
Kubernetes ไม่ใช่เครื่องมือที่สามารถใช้งานได้อย่างมีประสิทธิผลตั้งแต่แกะกล่อง แน่นอน คุณสามารถทำเช่นนั้นได้ ใช้ kubectl และอื่นๆ แต่ API ยังคงเป็นสิ่งที่น่าสนใจและมีประโยชน์ที่สุดเกี่ยวกับแพลตฟอร์มนี้ เมื่อใช้ API เป็นชุดฟังก์ชัน คุณจะสามารถเข้าถึงเกือบทุกอย่างที่คุณต้องการทำใน Kubernetes kubectl เองก็ใช้ REST API ด้วย
นี่คือ REST ดังนั้นคุณสามารถใช้ภาษาหรือเครื่องมือใดก็ได้เพื่อทำงานกับ API นี้ แต่ชีวิตของคุณจะง่ายขึ้นมากด้วยไลบรารีแบบกำหนดเอง ทีมของฉันเขียนไลบรารีดังกล่าว 2 ไลบรารี: หนึ่งไลบรารีสำหรับ Java/OSGi และอีกไลบรารีหนึ่งสำหรับ Go อันที่สองไม่ได้ใช้บ่อยนัก แต่ในกรณีใด ๆ คุณจะมีสิ่งที่เป็นประโยชน์เหล่านี้พร้อมใช้ เป็นโครงการโอเพ่นซอร์สที่ได้รับใบอนุญาตบางส่วน มีห้องสมุดมากมายสำหรับภาษาต่างๆ ดังนั้นคุณสามารถเลือกห้องสมุดที่เหมาะกับคุณที่สุดได้
ดังนั้น ก่อนที่คุณจะเริ่มทำให้การใช้งานของคุณเป็นแบบอัตโนมัติ คุณต้องตรวจสอบให้แน่ใจว่ากระบวนการนี้จะไม่มีการหยุดทำงานใดๆ ตัวอย่างเช่น ทีมของเราดำเนินการปรับใช้จริงในตอนกลางวันซึ่งเป็นช่วงที่ผู้คนใช้แอปพลิเคชันมากที่สุด ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องหลีกเลี่ยงความล่าช้าในกระบวนการนี้ เพื่อหลีกเลี่ยงการหยุดทำงาน มีการใช้ 2 วิธี: การปรับใช้สีน้ำเงิน/สีเขียว หรือการอัปเดตแบบต่อเนื่อง ในกรณีหลังนี้ หากคุณมีแอปพลิเคชันที่ทำงานอยู่ 5 ตัวจำลอง จะมีการอัพเดตตามลำดับตามลำดับ วิธีนี้ใช้งานได้ดี แต่ไม่เหมาะหากคุณมีแอปพลิเคชันเวอร์ชันอื่นที่ทำงานพร้อมกันในระหว่างกระบวนการปรับใช้ ในกรณีนี้ คุณสามารถอัปเดตอินเทอร์เฟซผู้ใช้ในขณะที่แบ็กเอนด์ใช้เวอร์ชันเก่าได้ และแอปพลิเคชันจะหยุดทำงาน ดังนั้นจากมุมมองของการเขียนโปรแกรม การทำงานในสภาวะดังกล่าวจึงค่อนข้างยาก
นี่คือหนึ่งในเหตุผลที่เราชอบใช้การปรับใช้สีน้ำเงิน/เขียวเพื่อทำให้แอปพลิเคชันของเราใช้งานได้โดยอัตโนมัติ ด้วยวิธีนี้ คุณต้องแน่ใจว่ามีแอปพลิเคชันที่ใช้งานอยู่ครั้งละเวอร์ชันเดียวเท่านั้น
กลไกการปรับใช้สีน้ำเงิน/เขียวมีลักษณะเช่นนี้ เราได้รับการรับส่งข้อมูลสำหรับแอปพลิเคชันของเราผ่าน ha-proxy ซึ่งจะส่งต่อไปยังแบบจำลองที่รันอยู่ของแอปพลิเคชันเวอร์ชันเดียวกัน
เมื่อมีการปรับใช้ใหม่ เราจะใช้ Deployer ซึ่งได้รับส่วนประกอบใหม่และปรับใช้เวอร์ชันใหม่ การปรับใช้แอปพลิเคชันเวอร์ชันใหม่หมายความว่าชุดการจำลองใหม่จะถูก "ยกขึ้น" หลังจากนั้นแบบจำลองของเวอร์ชันใหม่เหล่านี้จะเปิดตัวในพ็อดใหม่ที่แยกจากกัน อย่างไรก็ตาม ha-proxy ไม่รู้อะไรเลยเกี่ยวกับพวกเขาและยังไม่ได้กำหนดเส้นทางภาระงานใดๆ ไปยังพวกเขา
ดังนั้น อันดับแรก จำเป็นต้องดำเนินการตรวจสอบประสิทธิภาพของการตรวจสอบสภาพเวอร์ชันใหม่เพื่อให้แน่ใจว่าแบบจำลองพร้อมที่จะให้บริการโหลด
ส่วนประกอบการปรับใช้ทั้งหมดต้องรองรับการตรวจสอบสภาพบางรูปแบบ นี่อาจเป็นการตรวจสอบการเรียก HTTP ที่ง่ายมาก เมื่อคุณได้รับรหัสที่มีสถานะ 200 หรือการตรวจสอบเชิงลึกมากขึ้น โดยที่คุณตรวจสอบการเชื่อมต่อของเรพลิกากับฐานข้อมูลและบริการอื่น ๆ ความเสถียรของการเชื่อมต่อสภาพแวดล้อมแบบไดนามิก และทุกอย่างเริ่มต้นและทำงานอย่างถูกต้องหรือไม่ กระบวนการนี้อาจค่อนข้างซับซ้อน
หลังจากที่ระบบตรวจสอบว่าเรพลิกาที่อัปเดตทั้งหมดใช้งานได้ Deployer จะอัปเดตการกำหนดค่าและส่ง confd ที่ถูกต้อง ซึ่งจะกำหนดค่า ha-proxy ใหม่
หลังจากนั้นการรับส่งข้อมูลจะถูกส่งไปยังพ็อดที่มีการจำลองเวอร์ชันใหม่ และพ็อดเก่าจะหายไป
กลไกนี้ไม่ใช่คุณสมบัติของ Kubernetes แนวคิดของการปรับใช้สีน้ำเงิน/เขียวมีมานานแล้ว และมีการใช้โหลดบาลานเซอร์มาโดยตลอด ขั้นแรก คุณเปลี่ยนเส้นทางการรับส่งข้อมูลทั้งหมดไปยังแอปพลิเคชันเวอร์ชันเก่า และหลังการอัปเดต คุณจะถ่ายโอนไปยังเวอร์ชันใหม่โดยสมบูรณ์ หลักการนี้ใช้ไม่เพียงแต่ใน Kubernetes เท่านั้น
ตอนนี้ ผมจะแนะนำให้คุณรู้จักกับองค์ประกอบการปรับใช้ใหม่ - Deployer ซึ่งดำเนินการตรวจสอบสภาพ กำหนดค่าพร็อกซีใหม่ และอื่นๆ นี่เป็นแนวคิดที่ใช้ไม่ได้กับโลกภายนอกและมีอยู่ใน Kubernetes ฉันจะแสดงให้คุณเห็นว่าคุณสามารถสร้างแนวคิด Deployer ของคุณเองโดยใช้เครื่องมือโอเพ่นซอร์สได้อย่างไร
ดังนั้น สิ่งแรกที่ Deployer ทำคือสร้างตัวควบคุมการจำลองแบบ RC โดยใช้ Kubernetes API API นี้สร้างพ็อดและบริการสำหรับการปรับใช้เพิ่มเติม กล่าวคือ สร้างคลัสเตอร์ใหม่สำหรับแอปพลิเคชันของเรา ทันทีที่ RC มั่นใจว่าแบบจำลองได้เริ่มต้นแล้ว RC จะทำการตรวจสุขภาพฟังก์ชันการทำงาน เมื่อต้องการทำเช่นนี้ Deployer จะใช้คำสั่ง GET /health โดยจะรันส่วนประกอบการสแกนที่เหมาะสม และตรวจสอบองค์ประกอบทั้งหมดที่รองรับการทำงานของคลัสเตอร์
หลังจากที่พ็อดทั้งหมดรายงานความสมบูรณ์แล้ว Deployer จะสร้างองค์ประกอบการกำหนดค่าใหม่ - พื้นที่จัดเก็บแบบกระจาย ฯลฯ ซึ่ง Kubernetes ใช้ภายใน รวมถึงการจัดเก็บการกำหนดค่าตัวจัดสรรภาระงาน เราเขียนข้อมูลลงใน etcd และเครื่องมือขนาดเล็กที่เรียกว่า confd monitors etcd สำหรับข้อมูลใหม่
หากตรวจพบการเปลี่ยนแปลงใดๆ ในการกำหนดค่าเริ่มต้น ระบบจะสร้างไฟล์การตั้งค่าใหม่และถ่ายโอนไปยัง ha-proxy ในกรณีนี้ ha-proxy จะรีบูตโดยไม่สูญเสียการเชื่อมต่อใดๆ และจัดการกับภาระของบริการใหม่ๆ ที่ทำให้แอปพลิเคชันเวอร์ชันใหม่ของเราทำงานได้
อย่างที่คุณเห็นแม้จะมีส่วนประกอบมากมาย แต่ก็ไม่มีอะไรซับซ้อนที่นี่ คุณเพียงแค่ต้องให้ความสำคัญกับ API และอื่นๆ มากขึ้น ฉันอยากจะบอกคุณเกี่ยวกับตัวปรับใช้โอเพ่นซอร์สที่พวกเราเองใช้ - Amdatu Kubernetes Deployer
เป็นเครื่องมือสำหรับจัดการการใช้งาน Kubernetes และมีคุณสมบัติดังต่อไปนี้:
- การปรับใช้สีน้ำเงิน/เขียว
- การตั้งค่าโหลดบาลานเซอร์ภายนอก
- การจัดการตัวอธิบายการใช้งาน
- การจัดการการใช้งานจริง
- การตรวจสอบฟังก์ชันการทำงานของการตรวจสุขภาพระหว่างการใช้งาน
- การนำตัวแปรสภาพแวดล้อมไปใช้งานในพ็อด
Deployer นี้สร้างขึ้นบน Kubernetes API และจัดเตรียม REST API สำหรับการจัดการตัวจัดการและการปรับใช้ รวมถึง Websocket API สำหรับการสตรีมบันทึกระหว่างกระบวนการปรับใช้
โดยจะใส่ข้อมูลการกำหนดค่าโหลดบาลานเซอร์ลงใน etcd ดังนั้นคุณไม่จำเป็นต้องใช้ ha-proxy พร้อมการสนับสนุนที่พร้อมใช้งานทันที แต่ใช้ไฟล์การกำหนดค่าโหลดบาลานเซอร์ของคุณเองได้อย่างง่ายดาย Amdatu Deployer เขียนในภาษา Go เช่นเดียวกับ Kubernetes และได้รับอนุญาตจาก Apache
ก่อนที่ฉันจะเริ่มใช้งานเวอร์ชันนี้ของตัวปรับใช้ ฉันใช้ตัวอธิบายการปรับใช้ต่อไปนี้ ซึ่งระบุพารามิเตอร์ที่ฉันต้องการ
พารามิเตอร์ที่สำคัญประการหนึ่งของโค้ดนี้คือการเปิดใช้งานการตั้งค่าสถานะ "useHealthCheck" เราจำเป็นต้องระบุว่าต้องดำเนินการตรวจสอบสุขภาพในระหว่างกระบวนการปรับใช้ การตั้งค่านี้สามารถปิดใช้งานได้เมื่อการทำให้ใช้งานได้ใช้คอนเทนเนอร์ของบุคคลที่สามที่ไม่จำเป็นต้องได้รับการยืนยัน ตัวอธิบายนี้ยังระบุจำนวนเรพลิกาและ URL ส่วนหน้าที่ ha-proxy ต้องการ ในตอนท้ายคือแฟล็กข้อมูลจำเพาะของพ็อด "podspec" ซึ่งจะเรียก Kubernetes เพื่อขอข้อมูลเกี่ยวกับการกำหนดค่าพอร์ต รูปภาพ ฯลฯ นี่เป็นตัวอธิบาย JSON ที่ค่อนข้างง่าย
เครื่องมืออื่นที่เป็นส่วนหนึ่งของโครงการ Amdatu โอเพ่นซอร์สก็คือ Deploymentctl มี UI สำหรับการกำหนดค่าการปรับใช้ จัดเก็บประวัติการปรับใช้ และมี webhooks สำหรับการเรียกกลับจากผู้ใช้และนักพัฒนาบุคคลที่สาม คุณไม่สามารถใช้ UI ได้เนื่องจาก Amdatu Deployer นั้นเป็น REST API แต่อินเทอร์เฟซนี้สามารถทำให้การปรับใช้ง่ายขึ้นสำหรับคุณโดยไม่ต้องเกี่ยวข้องกับ API ใด ๆ Deploymentctl ถูกเขียนใน OSGi/Vertx โดยใช้ Angular 2
ตอนนี้ฉันจะสาธิตสิ่งข้างต้นบนหน้าจอโดยใช้การบันทึกที่บันทึกไว้ล่วงหน้า เพื่อให้คุณไม่ต้องรอ เราจะปรับใช้แอปพลิเคชัน Go ที่เรียบง่าย ไม่ต้องกังวลหากคุณยังไม่เคยลองใช้ Go มาก่อน มันเป็นแอปพลิเคชั่นที่ง่ายมาก ดังนั้นคุณน่าจะเข้าใจได้
ที่นี่เรากำลังสร้างเซิร์ฟเวอร์ HTTP ที่ตอบสนองต่อ /health เท่านั้น ดังนั้นแอปพลิเคชันนี้จึงทดสอบเฉพาะการตรวจสุขภาพเท่านั้นและไม่มีอะไรอื่นอีก หากผ่านการตรวจสอบ ระบบจะใช้โครงสร้าง JSON ที่แสดงด้านล่าง ประกอบด้วยเวอร์ชันของแอปพลิเคชันที่ผู้ปรับใช้จะใช้งาน ข้อความที่คุณเห็นที่ด้านบนของไฟล์ และประเภทข้อมูลบูลีน ไม่ว่าแอปพลิเคชันของเราจะใช้งานได้หรือไม่ก็ตาม
ฉันโกงเล็กน้อยในบรรทัดสุดท้าย เพราะฉันใส่ค่าบูลีนคงที่ไว้ที่ด้านบนสุดของไฟล์ ซึ่งในอนาคตจะช่วยให้ฉันปรับใช้ได้แม้กระทั่งแอปพลิเคชันที่ "ไม่แข็งแรง" เราจะจัดการกับเรื่องนี้ในภายหลัง
มาเริ่มกันเลย ขั้นแรก เราจะตรวจสอบว่ามีพ็อดที่ทำงานอยู่หรือไม่โดยใช้คำสั่ง ~ kubectl get pods และหากไม่มีการตอบกลับจาก URL ส่วนหน้า เราจะตรวจสอบให้แน่ใจว่าไม่มีการปรับใช้ใด ๆ เกิดขึ้นในขณะนี้
ถัดไปบนหน้าจอ คุณจะเห็นอินเทอร์เฟซ Deploymentctl ที่ฉันกล่าวถึง ซึ่งมีการตั้งค่าพารามิเตอร์การใช้งาน: เนมสเปซ ชื่อแอปพลิเคชัน เวอร์ชันการใช้งาน จำนวนเรพลิกา URL ส่วนหน้า ชื่อคอนเทนเนอร์ รูปภาพ ขีดจำกัดทรัพยากร หมายเลขพอร์ตสำหรับการตรวจสอบสภาพ ฯลฯ . ขีดจำกัดของทรัพยากรมีความสำคัญมาก เนื่องจากช่วยให้คุณใช้ฮาร์ดแวร์ได้สูงสุดเท่าที่จะเป็นไปได้ ที่นี่ คุณยังสามารถดูบันทึกการปรับใช้ได้อีกด้วย
หากคุณทำซ้ำคำสั่ง ~ kubectl get pods คุณจะเห็นว่าระบบ "ค้าง" เป็นเวลา 20 วินาทีในระหว่างนั้น ha-proxy ได้รับการกำหนดค่าใหม่ หลังจากนี้ พ็อดจะเริ่มทำงาน และดูแบบจำลองของเราได้ในบันทึกการปรับใช้
ฉันตัดการรอ 20 วินาทีออกจากวิดีโอ และตอนนี้คุณจะเห็นบนหน้าจอว่ามีการใช้งานแอปพลิเคชันเวอร์ชันแรกแล้ว ทั้งหมดนี้ทำได้โดยใช้เพียง UI เท่านั้น
ตอนนี้เรามาลองรุ่นที่สองกัน เมื่อต้องการทำเช่นนี้ ฉันเปลี่ยนข้อความของแอปพลิเคชันจาก "Hello, Kubernetes!" ใน "Hello, Deployer!" ระบบจะสร้างอิมเมจนี้และวางไว้ในรีจิสทรี Docker หลังจากนั้นเราก็คลิกที่ปุ่ม "Deploy" อีกครั้งในหน้าต่าง Deploymentctl ในกรณีนี้ บันทึกการปรับใช้จะถูกเปิดใช้งานโดยอัตโนมัติในลักษณะเดียวกับที่เกิดขึ้นเมื่อปรับใช้แอปพลิเคชันเวอร์ชันแรก
คำสั่ง ~ kubectl get pods แสดงว่าขณะนี้มีแอปพลิเคชันที่ทำงานอยู่ 2 เวอร์ชัน แต่ส่วนหน้าแสดงว่าเรายังคงใช้งานเวอร์ชัน 1 อยู่
ตัวจัดสรรภาระงานจะรอให้การตรวจสอบสภาพเสร็จสิ้นก่อนที่จะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังเวอร์ชันใหม่ หลังจากผ่านไป 20 วินาที เราจะเปลี่ยนเป็น curl และเห็นว่าขณะนี้เราได้ใช้งานแอปพลิเคชันเวอร์ชัน 2 แล้ว และแอปพลิเคชันแรกถูกลบไปแล้ว
นี่คือการนำแอปพลิเคชันที่ "ดีต่อสุขภาพ" มาใช้ มาดูกันว่าเกิดอะไรขึ้นหากสำหรับแอปพลิเคชันเวอร์ชันใหม่ฉันเปลี่ยนพารามิเตอร์ Healthy จากจริงเป็นเท็จนั่นคือฉันพยายามปรับใช้แอปพลิเคชันที่ไม่แข็งแรงซึ่งล้มเหลวในการตรวจสุขภาพ กรณีนี้อาจเกิดขึ้นได้หากมีข้อผิดพลาดในการกำหนดค่าในแอปพลิเคชันในขั้นตอนการพัฒนา และถูกส่งไปยังการใช้งานจริงในรูปแบบนี้
อย่างที่คุณเห็น การปรับใช้จะต้องทำตามขั้นตอนทั้งหมดข้างต้น และ ~kubectl get pods แสดงว่าทั้งสองพ็อดกำลังทำงานอยู่ แต่ต่างจากการปรับใช้ครั้งก่อนตรง บันทึกจะแสดงสถานะการหมดเวลา นั่นคือเนื่องจากการตรวจสอบสภาพล้มเหลว แอปพลิเคชันเวอร์ชันใหม่จึงไม่สามารถใช้งานได้ ด้วยเหตุนี้ คุณจึงเห็นว่าระบบได้เปลี่ยนกลับไปใช้แอปพลิเคชันเวอร์ชันเก่า และเวอร์ชันใหม่ก็ถูกถอนการติดตั้งไปแล้ว
สิ่งที่ดีเกี่ยวกับเรื่องนี้ก็คือ แม้ว่าคุณจะมีคำขอจำนวนมากที่เข้ามาในแอปพลิเคชันพร้อมกัน แต่คำขอเหล่านั้นจะไม่สังเกตเห็นการหยุดทำงานขณะดำเนินขั้นตอนการปรับใช้ด้วยซ้ำ หากคุณทดสอบแอปพลิเคชันนี้โดยใช้เฟรมเวิร์ก Gatling ซึ่งส่งคำขอให้มากที่สุดเท่าที่จะเป็นไปได้ คำขอเหล่านี้จะไม่ถูกทิ้ง ซึ่งหมายความว่าผู้ใช้ของเราจะไม่สังเกตเห็นการอัปเดตเวอร์ชันแบบเรียลไทม์ด้วยซ้ำ หากล้มเหลว การทำงานจะดำเนินต่อไปในเวอร์ชันเก่า หากสำเร็จ ผู้ใช้จะเปลี่ยนไปใช้เวอร์ชันใหม่
มีเพียงสิ่งเดียวที่สามารถล้มเหลวได้ - หากการตรวจสอบสภาพสำเร็จ แต่แอปพลิเคชันล้มเหลวทันทีที่มีการใช้ปริมาณงาน กล่าวคือ การล่มสลายจะเกิดขึ้นหลังจากการปรับใช้เสร็จสมบูรณ์เท่านั้น ในกรณีนี้ คุณจะต้องย้อนกลับเป็นเวอร์ชันเก่าด้วยตนเอง ดังนั้นเราจึงดูวิธีใช้ Kubernetes กับเครื่องมือโอเพ่นซอร์สที่ออกแบบมาสำหรับ Kubernetes กระบวนการปรับใช้จะง่ายขึ้นมากหากคุณสร้างเครื่องมือเหล่านี้ลงในไปป์ไลน์ Build/Deploy ของคุณ ในเวลาเดียวกัน เพื่อเริ่มต้นการปรับใช้ คุณสามารถใช้อินเทอร์เฟซผู้ใช้หรือทำให้กระบวนการนี้เป็นแบบอัตโนมัติโดยสมบูรณ์โดยใช้ เช่น คอมมิตเป็นต้นแบบ
Build Server ของเราจะสร้างอิมเมจ Docker พุชลงใน Docker Hub หรือรีจิสตรีใดๆ ก็ตามที่คุณใช้ Docker Hub รองรับ webhook ดังนั้นเราจึงสามารถทริกเกอร์การปรับใช้ระยะไกลผ่าน Deployer ในลักษณะที่แสดงด้านบน วิธีนี้ทำให้คุณสามารถปรับใช้แอปพลิเคชันของคุณกับการผลิตที่มีศักยภาพได้โดยอัตโนมัติ
เรามาดูหัวข้อถัดไปกันดีกว่า - การปรับขนาดคลัสเตอร์ Kubernetes โปรดทราบว่าคำสั่ง kubectl เป็นคำสั่งมาตราส่วน ด้วยความช่วยเหลือเพิ่มเติม เราจึงสามารถเพิ่มจำนวนแบบจำลองในคลัสเตอร์ที่มีอยู่ของเราได้อย่างง่ายดาย อย่างไรก็ตาม ในทางปฏิบัติ เรามักจะต้องการเพิ่มจำนวนโหนดมากกว่าพ็อด
ในเวลาเดียวกัน ในระหว่างชั่วโมงทำงาน คุณอาจต้องเพิ่มขึ้น และในเวลากลางคืนเพื่อลดต้นทุนของบริการของ Amazon คุณอาจต้องลดจำนวนอินสแตนซ์แอปพลิเคชันที่ทำงานอยู่ นี่ไม่ได้หมายความว่าการปรับขนาดเพียงจำนวนพ็อดจะเพียงพอ เพราะแม้ว่าโหนดใดโหนดหนึ่งจะไม่ได้ใช้งาน คุณก็ยังต้องจ่าย Amazon สำหรับโหนดนั้น นั่นก็คือ คุณจะต้องปรับขนาดจำนวนเครื่องจักรที่ใช้ควบคู่กับการปรับขนาดพ็อดด้วย
สิ่งนี้อาจเป็นเรื่องที่ท้าทายเพราะไม่ว่าเราจะใช้ Amazon หรือบริการคลาวด์อื่นๆ Kubernetes ก็ไม่รู้อะไรเลยเกี่ยวกับจำนวนเครื่องที่ใช้งาน ขาดเครื่องมือที่ช่วยให้คุณสามารถปรับขนาดระบบในระดับโหนดได้
ดังนั้นเราจะต้องดูแลทั้งโหนดและพ็อด เราสามารถปรับขนาดการเปิดตัวโหนดใหม่ได้อย่างง่ายดายโดยใช้ AWS API และเครื่องกลุ่ม Scaling เพื่อกำหนดค่าจำนวนโหนดของผู้ปฏิบัติงาน Kubernetes คุณยังใช้ cloud-init หรือสคริปต์ที่คล้ายกันเพื่อลงทะเบียนโหนดในคลัสเตอร์ Kubernetes ได้ด้วย
เครื่องใหม่เริ่มต้นในกลุ่ม Scaling เริ่มต้นตัวเองเป็นโหนด ลงทะเบียนในรีจิสทรีของต้นแบบ และเริ่มทำงาน หลังจากนี้ คุณสามารถเพิ่มจำนวนเรพลิกาสำหรับใช้กับโหนดผลลัพธ์ได้ การลดขนาดต้องใช้ความพยายามมากขึ้น เนื่องจากคุณต้องแน่ใจว่าขั้นตอนดังกล่าวไม่นำไปสู่การทำลายแอปพลิเคชันที่ทำงานอยู่แล้วหลังจากปิดเครื่องที่ "ไม่จำเป็น" เพื่อป้องกันสถานการณ์ดังกล่าว คุณต้องตั้งค่าโหนดให้เป็นสถานะ "ไม่สามารถจัดกำหนดการได้" ซึ่งหมายความว่าตัวกำหนดเวลาเริ่มต้นจะละเว้นโหนดเหล่านี้เมื่อกำหนดเวลาพ็อด DaemonSet ตัวกำหนดเวลาจะไม่ลบสิ่งใดออกจากเซิร์ฟเวอร์เหล่านี้ แต่จะไม่เปิดตัวคอนเทนเนอร์ใหม่ที่นั่นด้วย ขั้นตอนต่อไปคือการขับไล่โหนดเดรน กล่าวคือ ถ่ายโอนพ็อดที่ทำงานอยู่จากนั้นไปยังเครื่องอื่น หรือโหนดอื่นที่มีความจุเพียงพอสำหรับสิ่งนี้ เมื่อคุณแน่ใจว่าไม่มีคอนเทนเนอร์บนโหนดเหล่านี้แล้ว คุณสามารถลบออกจาก Kubernetes ได้ หลังจากนี้ Kubernetes จะไม่มีอีกต่อไป ถัดไป คุณต้องใช้ AWS API เพื่อปิดใช้งานโหนดหรือเครื่องที่ไม่จำเป็น
คุณสามารถใช้ Amdatu Scalerd ซึ่งเป็นเครื่องมือปรับขนาดโอเพ่นซอร์สอื่นที่คล้ายกับ AWS API มี CLI เพื่อเพิ่มหรือลบโหนดในคลัสเตอร์ คุณสมบัติที่น่าสนใจคือความสามารถในการกำหนดค่าตัวกำหนดตารางเวลาโดยใช้ไฟล์ json ต่อไปนี้
รหัสที่แสดงจะลดความจุของคลัสเตอร์ลงครึ่งหนึ่งในช่วงเวลากลางคืน โดยจะกำหนดค่าทั้งจำนวนแบบจำลองที่พร้อมใช้งานและความจุที่ต้องการของคลัสเตอร์ Amazon การใช้ตัวกำหนดเวลานี้จะลดจำนวนโหนดในเวลากลางคืนโดยอัตโนมัติและเพิ่มในตอนเช้า ซึ่งช่วยประหยัดค่าใช้จ่ายในการใช้โหนดจากบริการคลาวด์เช่น Amazon คุณลักษณะนี้ไม่ได้มีอยู่ใน Kubernetes แต่การใช้ Scalerd จะช่วยให้คุณสามารถปรับขนาดแพลตฟอร์มนี้ได้ตามที่คุณต้องการ
ฉันอยากจะชี้ให้เห็นว่าหลายๆ คนบอกฉันว่า “นั่นเป็นสิ่งที่ดีและดี แต่ฐานข้อมูลของฉันซึ่งมักจะเป็นแบบคงที่ล่ะ?” คุณจะเรียกใช้สิ่งนี้ในสภาพแวดล้อมแบบไดนามิกเช่น Kubernetes ได้อย่างไร ในความคิดของฉัน คุณไม่ควรทำสิ่งนี้ ไม่ควรพยายามเรียกใช้คลังข้อมูลใน Kubernetes สิ่งนี้เป็นไปได้ในทางเทคนิคและมีบทเรียนทางอินเทอร์เน็ตเกี่ยวกับเรื่องนี้ แต่จะทำให้ชีวิตของคุณยุ่งยากอย่างจริงจัง
ใช่ มีแนวคิดเกี่ยวกับร้านค้าถาวรใน Kubernetes และคุณสามารถลองใช้ที่เก็บข้อมูลเช่น Mongo หรือ MySQL ได้ แต่นี่เป็นงานที่ต้องใช้แรงงานมาก นี่เป็นเพราะว่าคลังข้อมูลไม่รองรับการโต้ตอบกับสภาพแวดล้อมแบบไดนามิกอย่างสมบูรณ์ ฐานข้อมูลส่วนใหญ่ต้องการการกำหนดค่าที่สำคัญ รวมถึงการกำหนดค่าคลัสเตอร์ด้วยตนเอง ซึ่งไม่ชอบการปรับขนาดอัตโนมัติและสิ่งอื่นๆ ที่คล้ายคลึงกัน
ดังนั้นคุณไม่ควรทำให้ชีวิตของคุณยุ่งยากด้วยการพยายามเรียกใช้คลังข้อมูลใน Kubernetes จัดระเบียบงานด้วยวิธีดั้งเดิมโดยใช้บริการที่คุ้นเคย และช่วยให้ Kubernetes สามารถใช้งานได้
เพื่อสรุปหัวข้อนี้ ฉันอยากจะแนะนำให้คุณรู้จักกับแพลตฟอร์ม Cloud RTI ที่ใช้ Kubernetes ซึ่งทีมของฉันกำลังดำเนินการอยู่ มีการบันทึกแบบรวมศูนย์ การตรวจสอบแอปพลิเคชันและคลัสเตอร์ และคุณสมบัติที่มีประโยชน์อื่น ๆ อีกมากมายที่จะมีประโยชน์ ใช้เครื่องมือโอเพ่นซอร์สต่างๆ เช่น Grafana เพื่อแสดงการตรวจสอบ
มีคำถามว่าทำไมจึงใช้ ha-proxy load balancer กับ Kubernetes เป็นคำถามที่ดีเพราะปัจจุบัน Load Balancing มี 2 ระดับ บริการ Kubernetes ยังคงอยู่ในที่อยู่ IP เสมือน คุณไม่สามารถใช้สิ่งเหล่านี้กับพอร์ตบนเครื่องโฮสต์ภายนอกได้ เพราะหาก Amazon โอเวอร์โหลดโฮสต์คลาวด์ ที่อยู่ก็จะเปลี่ยนไป นี่คือเหตุผลที่เราวาง ha-proxy ไว้ด้านหน้าบริการ เพื่อสร้างโครงสร้างที่คงที่มากขึ้นสำหรับการรับส่งข้อมูลเพื่อสื่อสารกับ Kubernetes ได้อย่างราบรื่น
คำถามที่ดีอีกข้อหนึ่งคือ คุณจะดูแลการเปลี่ยนแปลงสคีมาฐานข้อมูลเมื่อทำการปรับใช้สีน้ำเงิน/เขียวได้อย่างไร ความจริงก็คือไม่ว่าจะใช้ Kubernetes ก็ตาม การเปลี่ยนสคีมาฐานข้อมูลถือเป็นงานที่ยาก คุณต้องตรวจสอบให้แน่ใจว่าสคีมาเก่าและใหม่เข้ากันได้ หลังจากนั้นคุณสามารถอัปเดตฐานข้อมูลแล้วอัปเดตแอปพลิเคชันด้วยตนเองได้ คุณสามารถสลับฐานข้อมูลได้ทันทีแล้วอัปเดตแอปพลิเคชัน ฉันรู้จักผู้คนที่เคยบูทคลัสเตอร์ฐานข้อมูลใหม่ด้วยสคีมาใหม่ นี่เป็นตัวเลือกหากคุณมีฐานข้อมูลที่ไม่มีแผนเช่น Mongo แต่ก็ไม่ใช่เรื่องง่ายอยู่ดี หากคุณไม่มีคำถามเพิ่มเติม ขอขอบคุณสำหรับความสนใจของคุณ!
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com