หลังจาก เรานำเสนอพี่ชายของเขา - . นี่คือโปรเจ็กต์โอเพนซอร์สที่ใช้ในการติดตั้งส่วนประกอบของระบบลงในคลัสเตอร์ Kubernetes ซึ่งสามารถเรียกว่าส่วนเสริมได้
เหตุใดจึงมีการเพิ่มเติมใดๆ เลย?
ไม่ใช่ความลับที่ Kubernetes ไม่ใช่ผลิตภัณฑ์ออลอินวันสำเร็จรูป และในการสร้างคลัสเตอร์ "สำหรับผู้ใหญ่" คุณจะต้องมีส่วนเพิ่มเติมต่างๆ ตัวดำเนินการ Addon จะช่วยคุณติดตั้ง กำหนดค่า และอัปเดตส่วนเสริมเหล่านี้ให้ทันสมัยอยู่เสมอ
มีการเปิดเผยความต้องการส่วนประกอบเพิ่มเติมในคลัสเตอร์ เพื่อนร่วมงาน . กล่าวโดยสรุป สถานการณ์ของ Kubernetes ในขณะนี้เป็นเช่นนั้นสำหรับการติดตั้งแบบ "เล่นๆ" แบบง่ายๆ คุณสามารถใช้งานส่วนประกอบต่างๆ ที่แกะกล่องได้ สำหรับนักพัฒนาและการทดสอบ คุณสามารถเพิ่ม Ingress ได้ แต่สำหรับการติดตั้งแบบเต็ม ซึ่งเกี่ยวกับ คุณสามารถพูดว่า "การผลิตของคุณพร้อมแล้ว" คุณต้องเพิ่มโปรแกรมเสริมต่างๆ มากมาย: บางอย่างสำหรับการตรวจสอบ บางอย่างสำหรับการบันทึก อย่าลืมทางเข้าและผู้จัดการใบรับรอง เลือกกลุ่มของโหนด เพิ่มนโยบายเครือข่าย ฤดูกาล ด้วยการตั้งค่าตัวปรับขนาดอัตโนมัติ sysctl และ pod ...
อะไรคือลักษณะเฉพาะของการทำงานร่วมกับพวกเขา?
ตามที่แสดงในทางปฏิบัติ เรื่องนี้ไม่ได้จำกัดอยู่เพียงการติดตั้งเพียงครั้งเดียว เพื่อให้ทำงานกับคลัสเตอร์ได้อย่างสะดวกสบาย ส่วนเสริมจะต้องได้รับการอัปเดต ปิดใช้งาน (ลบออกจากคลัสเตอร์) และคุณจะต้องการทดสอบบางอย่างก่อนที่จะติดตั้งในคลัสเตอร์ที่ใช้งานจริง
ดังนั้นบางที Ansible อาจจะเพียงพอที่นี่? อาจจะ. แต่ โดยทั่วไปแล้ว ส่วนเสริมที่มีคุณสมบัติครบถ้วนจะไม่สามารถใช้งานได้หากไม่มีการตั้งค่า. การตั้งค่าเหล่านี้อาจแตกต่างกันไปขึ้นอยู่กับตัวแปรคลัสเตอร์ (aws, gce, azure, bare-metal, do, ...) การตั้งค่าบางอย่างไม่สามารถระบุล่วงหน้าได้ ต้องได้รับจากคลัสเตอร์ และคลัสเตอร์ไม่คงที่: คุณจะต้องตรวจสอบการเปลี่ยนแปลงสำหรับการตั้งค่าบางอย่าง และที่นี่ Ansible หายไปแล้ว: คุณต้องมีโปรแกรมที่อยู่ในคลัสเตอร์เช่น ตัวดำเนินการ Kubernetes
ผู้ที่ได้ลองใช้งานแล้ว พวกเขาจะบอกว่างานการติดตั้งและอัปเดตส่วนเสริมและการตั้งค่าการตรวจสอบสามารถแก้ไขได้อย่างสมบูรณ์โดยใช้ สำหรับผู้ประกอบการเชลล์ คุณสามารถเขียนสคริปต์ที่จะทำตามเงื่อนไขได้ kubectl apply และตรวจสอบ เช่น ConfigMap ซึ่งการตั้งค่าจะถูกจัดเก็บ นี่คือสิ่งที่นำไปใช้โดยประมาณใน addon-operator
สิ่งนี้ถูกจัดระเบียบใน addon-operator อย่างไร
เมื่อสร้างโซลูชันใหม่ เราดำเนินการตามหลักการต่อไปนี้:
- โปรแกรมติดตั้งส่วนเสริมต้องรองรับ การกำหนดค่าเทมเพลตและการประกาศ. เราไม่ได้สร้างสคริปต์วิเศษที่ติดตั้งส่วนเสริม ตัวดำเนินการ Addon ใช้ Helm เพื่อติดตั้งส่วนเสริม ในการติดตั้ง คุณจะต้องสร้างแผนภูมิและเลือกค่าที่จะใช้สำหรับการกำหนดค่า
- การตั้งค่าได้ สร้างขึ้นในการติดตั้ง, พวกเขาสามารถ ได้รับจากคลัสเตอร์หรือ รับการอัปเดต, การตรวจสอบทรัพยากรคลัสเตอร์ การดำเนินการเหล่านี้สามารถนำไปใช้ได้โดยใช้ hooks
- การตั้งค่าได้ เก็บไว้ในคลัสเตอร์. หากต้องการจัดเก็บการตั้งค่าในคลัสเตอร์ ตัวดำเนินการ ConfigMap/addon จะถูกสร้างขึ้น และตัวดำเนินการ Addon จะตรวจสอบการเปลี่ยนแปลงใน ConfigMap นี้ ตัวดำเนินการ Addon ช่วยให้ hooks เข้าถึงการตั้งค่าโดยใช้แบบแผนง่ายๆ
- นอกจากนี้ขึ้นอยู่กับการตั้งค่า. หากการตั้งค่ามีการเปลี่ยนแปลง ตัวดำเนินการ Addon จะเปิดตัวแผนภูมิ Helm ด้วยค่าใหม่ เราเรียกการรวมกันของแผนภูมิ Helm ค่าสำหรับมันและเชื่อมโยงโมดูล (ดูรายละเอียดเพิ่มเติมด้านล่าง)
- จัดฉาก. ไม่มีสคริปต์เผยแพร่เวทย์มนตร์ กลไกการอัปเดตจะคล้ายกับแอปพลิเคชันทั่วไป โดยรวบรวมส่วนเสริมและตัวดำเนินการส่วนเสริมลงในรูปภาพ แท็กและเผยแพร่
- การควบคุมผลลัพธ์. ตัวดำเนินการ Addon สามารถจัดเตรียมตัววัดสำหรับ Prometheus
ช่องว่างภายในในตัวดำเนินการ addon คืออะไร?
การเพิ่มสามารถถือเป็นสิ่งใดก็ตามที่เพิ่มฟังก์ชันใหม่ให้กับคลัสเตอร์ ตัวอย่างเช่น การติดตั้ง Ingress เป็นตัวอย่างที่ดีของส่วนเสริม ซึ่งอาจเป็นโอเปอเรเตอร์หรือตัวควบคุมใดก็ได้ที่มี CRD ของตัวเอง: prometheus-operator, cert-manager, kube-controller-manager เป็นต้น หรือสิ่งเล็กๆ แต่ใช้งานง่ายกว่า เช่น เครื่องถ่ายเอกสารลับซึ่งคัดลอกความลับของรีจิสทรีไปยังเนมสเปซใหม่ หรือเครื่องรับ sysctl ซึ่งกำหนดค่าพารามิเตอร์ sysctl บนโหนดใหม่
ในการใช้งานส่วนเสริม Addon-operator มีแนวคิดหลายประการ:
- แผนภูมิหางเสือ ใช้เพื่อติดตั้งซอฟต์แวร์ต่าง ๆ ลงในคลัสเตอร์ - เช่น Prometheus, Grafana, nginx-ingress หากส่วนประกอบที่ต้องการมีแผนภูมิ Helm การติดตั้งโดยใช้ตัวดำเนินการ Addon จะง่ายมาก
- การจัดเก็บค่า. แผนภูมิ Helm มักจะมีการตั้งค่าต่างๆ มากมายที่สามารถเปลี่ยนแปลงได้ตลอดเวลา ตัวดำเนินการ Addon รองรับการจัดเก็บการตั้งค่าเหล่านี้และสามารถตรวจสอบการเปลี่ยนแปลงเพื่อติดตั้งแผนภูมิ Helm ใหม่ด้วยค่าใหม่
- ตะขอ เป็นไฟล์ปฏิบัติการที่ตัวดำเนินการ Addon รันในเหตุการณ์และเข้าถึงที่เก็บค่า hook สามารถตรวจสอบการเปลี่ยนแปลงในคลัสเตอร์และอัปเดตค่าในที่เก็บค่า เหล่านั้น. การใช้ hooks ช่วยให้คุณสามารถค้นพบเพื่อรวบรวมค่าจากคลัสเตอร์เมื่อเริ่มต้นหรือตามกำหนดเวลา หรือคุณสามารถทำการค้นหาอย่างต่อเนื่องโดยรวบรวมค่าจากคลัสเตอร์ตามการเปลี่ยนแปลงในคลัสเตอร์
- โมดึล เป็นการผสมผสานระหว่างแผนภูมิ Helm การจัดเก็บค่าและ hooks โมดูลสามารถเปิดหรือปิดใช้งานได้ การปิดใช้งานโมดูลหมายถึงการลบการเผยแพร่แผนภูมิ Helm ทั้งหมด โมดูลสามารถเปิดใช้งานตัวเองแบบไดนามิกได้ ตัวอย่างเช่น หากโมดูลทั้งหมดที่ต้องการถูกเปิดใช้งาน หรือหากการค้นพบพบพารามิเตอร์ที่จำเป็นใน hooks - ทำได้โดยใช้สคริปต์ที่เปิดใช้งานเสริม
- ตะขอระดับโลก. สิ่งเหล่านี้คือ hooks "ด้วยตัวเอง" ซึ่งไม่รวมอยู่ในโมดูลและมีสิทธิ์เข้าถึงที่เก็บค่าส่วนกลางซึ่งค่าดังกล่าวจะพร้อมใช้งานสำหรับ hook ทั้งหมดในโมดูล
ชิ้นส่วนเหล่านี้ทำงานร่วมกันอย่างไร? ลองดูภาพจากเอกสารประกอบ:
มีสองสถานการณ์การทำงาน:
- Global hook ถูกทริกเกอร์โดยเหตุการณ์ เช่น เมื่อทรัพยากรในคลัสเตอร์เปลี่ยนแปลง เบ็ดนี้ประมวลผลการเปลี่ยนแปลงและเขียนค่าใหม่ไปยังที่เก็บค่าโกลบอล ตัวดำเนินการ Addon สังเกตว่าที่เก็บข้อมูลส่วนกลางมีการเปลี่ยนแปลงและเริ่มโมดูลทั้งหมด แต่ละโมดูลที่ใช้ hooks จะกำหนดว่าจำเป็นต้องเปิดใช้งานและอัปเดตที่เก็บค่าหรือไม่ หากเปิดใช้งานโมดูล ตัวดำเนินการ Addon จะเริ่มการติดตั้งแผนภูมิ Helm ในกรณีนี้ แผนภูมิ Helm สามารถเข้าถึงค่าจากที่เก็บข้อมูลโมดูลและจากที่เก็บข้อมูลส่วนกลาง
- สถานการณ์ที่สองนั้นง่ายกว่า: hook ของโมดูลถูกทริกเกอร์โดยเหตุการณ์และการเปลี่ยนแปลงค่าในที่เก็บค่าของโมดูล ตัวดำเนินการ Addon สังเกตเห็นสิ่งนี้และเปิดตัวแผนภูมิ Helm พร้อมค่าที่อัปเดต
การเพิ่มสามารถนำไปใช้เป็นตะขอเดี่ยวหรือเป็นแผนภูมิ Helm หรือ แม้ว่าจะเป็นโมดูลที่ต้องพึ่งพาหลายโมดูลก็ตาม - ขึ้นอยู่กับความซับซ้อนของส่วนประกอบที่ติดตั้งในคลัสเตอร์และระดับความยืดหยุ่นในการกำหนดค่าที่ต้องการ ตัวอย่างเช่น ในพื้นที่เก็บข้อมูล () มีส่วนเสริม sysctl-tuner ซึ่งใช้งานทั้งในรูปแบบโมดูลธรรมดาที่มี hook และแผนภูมิ Helm และใช้ที่เก็บค่าซึ่งทำให้สามารถเพิ่มการตั้งค่าได้โดยการแก้ไข ConfigMap
การส่งมอบการอัปเดต
คำไม่กี่คำเกี่ยวกับการจัดระเบียบการอัปเดตส่วนประกอบที่ตัวดำเนินการ Addon ติดตั้ง
หากต้องการรัน Addon-operator ในคลัสเตอร์ คุณต้องมี สร้างภาพด้วยการเพิ่มเติม ในรูปแบบของไฟล์แผนภูมิ hook และ Helm ให้เพิ่มไฟล์ไบนารี addon-operator และทุกสิ่งที่คุณต้องการสำหรับตะขอ: bash, kubectl, jq, python ฯลฯ จากนั้น อิมเมจนี้สามารถเผยแพร่ไปยังคลัสเตอร์ได้เป็นแอปพลิเคชันทั่วไป และเป็นไปได้มากว่าคุณจะต้องการจัดระเบียบรูปแบบการแท็กอย่างใดอย่างหนึ่ง หากมีคลัสเตอร์ไม่กี่คลัสเตอร์ วิธีการเดียวกันกับแอปพลิเคชันอาจเหมาะสม: รีลีสใหม่ เวอร์ชันใหม่ ไปที่คลัสเตอร์ทั้งหมดและแก้ไขอิมเมจของ Pod อย่างไรก็ตาม ในกรณีที่มีการเปิดตัวไปยังคลัสเตอร์จำนวนมาก แนวคิดในการอัปเดตด้วยตนเองจากช่องทางจะเหมาะกับเรามากกว่า
นี่คือวิธีที่เราทำ:
- โดยพื้นฐานแล้ว Channel เป็นตัวระบุที่สามารถตั้งค่าเป็นอะไรก็ได้ (เช่น dev/stage/ea/stable)
- ชื่อช่องคือแท็กรูปภาพ เมื่อคุณต้องการเปิดตัวการอัปเดตให้กับช่อง รูปภาพใหม่จะถูกประกอบและติดแท็กด้วยชื่อช่อง
- เมื่ออิมเมจใหม่ปรากฏในรีจิสทรี ตัวดำเนินการ Addon จะรีสตาร์ทและเปิดใช้งานพร้อมกับอิมเมจใหม่
นี่ไม่ใช่แนวปฏิบัติที่ดีที่สุดตามที่เขียนไว้ . ไม่แนะนำให้ทำเช่นนี้ แต่เรากำลังพูดถึง แอปพลิเคชันปกติที่อยู่ในคลัสเตอร์เดียวกัน. ในกรณีของตัวดำเนินการ Addon แอปพลิเคชันจะมีการปรับใช้จำนวนมากที่กระจัดกระจายไปทั่วคลัสเตอร์ และการอัปเดตด้วยตนเองช่วยได้มากและทำให้ชีวิตง่ายขึ้น
ช่องช่วยเหลือและ ในการทดสอบ: หากมีคลัสเตอร์เสริม คุณสามารถกำหนดค่าให้กับช่องสัญญาณได้ stage และเผยแพร่การอัปเดตก่อนที่จะเผยแพร่ไปยังช่องต่างๆ ea и stable. หากมีคลัสเตอร์บนช่อง ea เกิดข้อผิดพลาด คุณสามารถเปลี่ยนไปใช้ stableในขณะที่ปัญหาเกี่ยวกับคลัสเตอร์นี้กำลังถูกตรวจสอบ หากคลัสเตอร์ถูกนำออกจากการสนับสนุนที่ใช้งานอยู่ คลัสเตอร์จะสลับไปที่ช่องทาง "หยุดนิ่ง" - ตัวอย่างเช่น freeze-2019-03-20.
นอกจากการอัปเดต hooks และแผนภูมิ Helm แล้ว คุณอาจต้องการด้วย อัปเดตและส่วนประกอบของบุคคลที่สาม. ตัวอย่างเช่น คุณสังเกตเห็นข้อบกพร่องในตัวส่งออกโหนดแบบมีเงื่อนไข และยังคิดหาวิธีแก้ไขอีกด้วย ถัดไป คุณเปิด PR และกำลังรอให้รีลีสใหม่ผ่านคลัสเตอร์ทั้งหมดและเพิ่มเวอร์ชันของอิมเมจ เพื่อไม่ให้รออย่างไม่มีกำหนด คุณสามารถสร้างผู้ส่งออกโหนดของคุณและเปลี่ยนไปใช้ก่อนที่จะยอมรับ PR
โดยทั่วไปสามารถทำได้โดยไม่ต้องใช้ตัวดำเนินการ Addon แต่ด้วยตัวดำเนินการ Addon โมดูลสำหรับการติดตั้ง node-exporter จะปรากฏในพื้นที่เก็บข้อมูลเดียว Dockerfile สำหรับการสร้างอิมเมจของคุณสามารถเก็บไว้ที่นั่นได้ มันจะง่ายขึ้นสำหรับผู้เข้าร่วมทุกคนใน กระบวนการทำความเข้าใจว่าเกิดอะไรขึ้น... และหากมีหลายคลัสเตอร์ ทั้งการทดสอบ PR และการเปิดตัวเวอร์ชันใหม่ก็จะง่ายขึ้น!
การจัดระเบียบการอัปเดตส่วนประกอบนี้ใช้งานได้ดีสำหรับเรา แต่สามารถนำแผนงานที่เหมาะสมอื่น ๆ ไปใช้ได้เช่นกัน ในกรณีนี้ Addon-operator เป็นไฟล์ไบนารี่ธรรมดา.
ข้อสรุป
หลักการที่นำมาใช้ในโอเปอเรเตอร์ Addon ช่วยให้คุณสร้างกระบวนการที่โปร่งใสสำหรับการสร้าง ทดสอบ ติดตั้ง และอัปเดตส่วนเสริมในคลัสเตอร์ คล้ายกับกระบวนการพัฒนาของแอปพลิเคชันทั่วไป
ส่วนเสริมสำหรับตัวดำเนินการ Addon ในรูปแบบโมดูล (แผนภูมิหางเสือ + ตะขอ) สามารถเผยแพร่สู่สาธารณะได้ เราซึ่งเป็นบริษัท Flant วางแผนที่จะเผยแพร่การพัฒนาของเราในรูปแบบของการเพิ่มเติมดังกล่าวในช่วงฤดูร้อน เข้าร่วมการพัฒนาบน GitHub (, ) พยายามทำการบวกของคุณเองตาม и รอข่าวจากฮาเบรและของเรา !
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- «";
- «'
ที่มา: will.com