🥇บทนำสู่ Helm 3 | โปรโฮสเตอร์

บันทึก. แปล: วันที่ 16 พฤษภาคมของปีนี้ถือเป็นก้าวสำคัญในการพัฒนาตัวจัดการแพ็คเกจสำหรับ Kubernetes - Helm ในวันนี้ มีการนำเสนอรุ่นอัลฟ่าแรกของโครงการเวอร์ชันหลักในอนาคต - 3.0 - การเปิดตัวครั้งนี้จะนำมาซึ่งการเปลี่ยนแปลงที่สำคัญและรอคอยมานานมาสู่ Helm ซึ่งหลายคนในชุมชน Kubernetes มีความหวังสูง พวกเราเองก็เป็นหนึ่งในนั้น เนื่องจากเราใช้ Helm เพื่อการปรับใช้แอปพลิเคชันอย่างจริงจัง: เราได้รวมมันเข้ากับเครื่องมือของเราสำหรับการนำ CI/CD ไปใช้ เวร และในบางครั้งเราก็มีส่วนสนับสนุนการพัฒนาต้นน้ำ การแปลนี้รวมบันทึก 7 ประการจากบล็อก Helm อย่างเป็นทางการ ซึ่งอุทิศให้กับ Helm 3 รุ่นอัลฟ่ารุ่นแรก และพูดคุยเกี่ยวกับประวัติของโครงการและคุณสมบัติหลักของ Helm 3 ผู้เขียนคือ Matt “bacongobbler” Fisher ซึ่งเป็นพนักงานของ Microsoft และหนึ่งในผู้ดูแลคนสำคัญของเฮล์ม

เมื่อวันที่ 15 ตุลาคม 2015 โครงการที่ปัจจุบันรู้จักกันในชื่อ Helm ได้ถือกำเนิดขึ้น เพียงหนึ่งปีหลังจากการก่อตั้ง ชุมชน Helm ได้เข้าร่วมกับ Kubernetes ในขณะที่กำลังทำงานอย่างแข็งขันกับ Helm 2 ในเดือนมิถุนายน 2018 Helm เข้าร่วม CNCF เป็นโครงการที่กำลังพัฒนา (บ่มเพาะ) กรอไปข้างหน้าสู่ปัจจุบัน และการเปิดตัวอัลฟ่าครั้งแรกของ Helm 3 ใหม่กำลังมาถึงแล้ว (การเปิดตัวครั้งนี้ ได้เกิดขึ้นแล้ว กลางเดือนพฤษภาคม – ประมาณ แปล).

ในงานชิ้นนี้ ฉันจะพูดถึงจุดเริ่มต้นทั้งหมด เรามาถึงจุดที่เราอยู่ทุกวันนี้ได้อย่างไร แนะนำคุณสมบัติพิเศษบางอย่างที่มีใน Helm 3 รุ่นอัลฟ่ารุ่นแรก และอธิบายว่าเราวางแผนจะก้าวไปข้างหน้าอย่างไร

สรุป:

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

ประวัติความเป็นมาของหมวกกันน็อค

กำเนิด

Helm 1 เริ่มต้นจากการเป็นโปรเจ็กต์โอเพ่นซอร์สที่สร้างโดย Deis เราเป็นสตาร์ทอัพเล็กๆ ดูดซึม ไมโครซอฟต์ในฤดูใบไม้ผลิ 2017 โปรเจ็กต์โอเพ่นซอร์สอื่นๆ ของเราชื่อ Deis ก็มีเครื่องมือเช่นกัน deisctlซึ่งถูกใช้ (เหนือสิ่งอื่นใด) เพื่อติดตั้งและใช้งานแพลตฟอร์ม Deis กลุ่มเรือเดินสมุทร. ในขณะนั้น Fleet เป็นหนึ่งในแพลตฟอร์มการจัดการคอนเทนเนอร์แห่งแรกๆ

ในช่วงกลางปี 2015 เราตัดสินใจเปลี่ยนหลักสูตรและย้าย Deis (ในขณะนั้นเปลี่ยนชื่อเป็น Deis Workflow) จาก Fleet เป็น Kubernetes สิ่งแรกๆ ที่ได้รับการออกแบบใหม่คือเครื่องมือการติดตั้ง deisctl. เราใช้มันเพื่อติดตั้งและจัดการ Deis Workflow ในคลัสเตอร์ Fleet

Helm 1 ถูกสร้างขึ้นโดยอาศัยอิมเมจของผู้จัดการแพ็คเกจที่มีชื่อเสียง เช่น Homebrew, apt และ yum เป้าหมายหลักคือทำให้งานต่างๆ เช่น การบรรจุและการติดตั้งแอปพลิเคชันบน Kubernetes ง่ายขึ้น Helm เปิดตัวอย่างเป็นทางการในปี 2015 ที่การประชุม KubeCon ในซานฟรานซิสโก

ความพยายามครั้งแรกของเรากับ Helm ได้ผล แต่ก็ไม่ได้ไร้ข้อจำกัดร้ายแรงบางประการ เขาหยิบชุด Kubernetes manifests ซึ่งปรุงแต่งด้วยเครื่องกำเนิดไฟฟ้าเป็นบล็อก YAML เบื้องต้น (เบื้องหน้า)* และโหลดผลลัพธ์ลงใน Kubernetes

* บันทึก. แปล: จากเวอร์ชันแรกของ Helm ไวยากรณ์ YAML ได้รับเลือกเพื่ออธิบายทรัพยากร Kubernetes และเทมเพลต Jinja และสคริปต์ Python ได้รับการสนับสนุนเมื่อเขียนการกำหนดค่า เราได้เขียนเพิ่มเติมเกี่ยวกับเรื่องนี้และโครงสร้างของ Helm เวอร์ชันแรกโดยทั่วไปในบท "ประวัติโดยย่อของ Helm" วัสดุนี้.

ตัวอย่างเช่น หากต้องการแทนที่ช่องในไฟล์ YAML คุณต้องเพิ่มโครงสร้างต่อไปนี้ลงในรายการ:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

เป็นเรื่องดีที่เครื่องมือเทมเพลตมีอยู่ในปัจจุบันใช่ไหม

ด้วยเหตุผลหลายประการ โปรแกรมติดตั้ง Kubernetes รุ่นแรกๆ นี้จำเป็นต้องมีรายการไฟล์ Manifest แบบฮาร์ดโค้ด และดำเนินการตามลำดับเหตุการณ์เล็กๆ ที่คงที่เท่านั้น การใช้งานเป็นเรื่องยากมากจนทีม R&D ของ Deis Workflow มีช่วงเวลาที่ยากลำบากเมื่อพวกเขาพยายามถ่ายโอนผลิตภัณฑ์ไปยังแพลตฟอร์มนี้ อย่างไรก็ตาม เมล็ดพืชของแนวคิดนี้ได้ถูกหว่านไปแล้ว ความพยายามครั้งแรกของเราคือโอกาสในการเรียนรู้ที่ยอดเยี่ยม: เราตระหนักว่าเรามีความหลงใหลอย่างแท้จริงในการสร้างเครื่องมือเชิงปฏิบัติที่แก้ปัญหาในชีวิตประจำวันให้กับผู้ใช้ของเรา

จากประสบการณ์ความผิดพลาดในอดีต เราเริ่มพัฒนา Helm 2

การทำหมวกกันน็อค 2

เมื่อปลายปี 2015 ทีมงาน Google ติดต่อเรา พวกเขากำลังทำงานกับเครื่องมือที่คล้ายกันสำหรับ Kubernetes Deployment Manager สำหรับ Kubernetes เป็นพอร์ตของเครื่องมือที่มีอยู่ซึ่งใช้สำหรับ Google Cloud Platform “เราต้องการไหม” พวกเขาถาม “ใช้เวลาสองสามวันเพื่อหารือเกี่ยวกับความเหมือนและความแตกต่าง”

ในเดือนมกราคม 2016 ทีม Helm และ Deployment Manager ได้พบกันที่ซีแอตเทิลเพื่อแลกเปลี่ยนความคิดเห็น การเจรจาจบลงด้วยแผนที่ทะเยอทะยาน: เพื่อรวมทั้งสองโครงการเพื่อสร้าง Helm 2 พร้อมด้วย Deis และ Google พวกเขาจาก ข้ามกล่อง (ปัจจุบันเป็นส่วนหนึ่งของ Bitnami - แปลโดยประมาณ)และเราเริ่มทำงานกับ Helm 2

เราต้องการทำให้ Helm ใช้งานได้ง่าย แต่เพิ่มสิ่งต่อไปนี้:

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

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

นับตั้งแต่เปิดตัว Helm 2 ในปี 2016 Kubernetes ได้เพิ่มนวัตกรรมที่สำคัญหลายประการ เพิ่มการควบคุมการเข้าถึงตามบทบาท (อาร์แบค) ซึ่งในที่สุดก็เข้ามาแทนที่ Attribute-Based Access Control (ABAC) มีการแนะนำประเภททรัพยากรใหม่ (การปรับใช้ยังอยู่ในช่วงเบต้าในขณะนั้น) คำจำกัดความทรัพยากรที่กำหนดเอง (แต่เดิมเรียกว่าทรัพยากรของบุคคลที่สามหรือ TPR) ได้รับการประดิษฐ์ขึ้น และที่สำคัญที่สุด ชุดแนวทางปฏิบัติที่ดีที่สุดได้เกิดขึ้นแล้ว

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

คำอำลาอย่างอ่อนโยนต่อทิลเลอร์

ในระหว่างการพัฒนา Helm 2 เราได้แนะนำ Tiller ซึ่งเป็นส่วนหนึ่งของการผสานรวมกับ Deployment Manager ของ Google Tiller มีบทบาทสำคัญในทีมที่ทำงานภายในคลัสเตอร์ทั่วไป โดยอนุญาตให้ผู้เชี่ยวชาญหลายรายที่ทำงานโครงสร้างพื้นฐานสามารถโต้ตอบกับชุดรุ่นเดียวกันได้

เนื่องจากการควบคุมการเข้าถึงตามบทบาท (RBAC) ถูกเปิดใช้งานโดยค่าเริ่มต้นใน Kubernetes 1.6 การทำงานร่วมกับ Tiller ในการผลิตจึงยากขึ้น เนื่องจากมีนโยบายความปลอดภัยที่เป็นไปได้มากมาย จุดยืนของเราคือการเสนอการกำหนดค่าที่อนุญาตตามค่าเริ่มต้น ซึ่งช่วยให้มือใหม่สามารถทดลองกับ Helm และ Kubernetes ได้โดยไม่ต้องเจาะลึกการตั้งค่าความปลอดภัยก่อน น่าเสียดายที่การกำหนดค่าสิทธิ์นี้อาจทำให้ผู้ใช้มีสิทธิ์อนุญาตที่หลากหลายเกินไปซึ่งพวกเขาไม่ต้องการ วิศวกร DevOps และ SRE ต้องเรียนรู้ขั้นตอนการปฏิบัติงานเพิ่มเติมเมื่อติดตั้ง Tiller ในคลัสเตอร์ที่มีผู้เช่าหลายราย

หลังจากเรียนรู้วิธีที่ชุมชนใช้ Helm ในสถานการณ์เฉพาะ เราก็ตระหนักว่าระบบการจัดการการเผยแพร่ของ Tiller ไม่จำเป็นต้องพึ่งพาส่วนประกอบภายในคลัสเตอร์เพื่อรักษาสถานะหรือหน้าที่เป็นศูนย์กลางสำหรับข้อมูลการเผยแพร่ แต่เราสามารถรับข้อมูลจากเซิร์ฟเวอร์ Kubernetes API สร้างแผนภูมิในฝั่งไคลเอ็นต์ และจัดเก็บบันทึกการติดตั้งใน Kubernetes แทน

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

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

ที่เก็บแผนภูมิ

ในระดับสูง พื้นที่เก็บข้อมูลแผนภูมิเป็นสถานที่ที่สามารถจัดเก็บและแบ่งปันแผนภูมิได้ ไคลเอนต์ Helm จัดทำแพ็กเกจและส่งแผนภูมิไปยังพื้นที่เก็บข้อมูล พูดง่ายๆ ก็คือ พื้นที่เก็บข้อมูลแผนภูมิคือเซิร์ฟเวอร์ HTTP ดั้งเดิมที่มีไฟล์ index.yaml และแผนภูมิแพ็กเกจบางส่วน

แม้ว่า Charts Repository API จะมีข้อดีบางประการที่ตรงตามข้อกำหนดพื้นที่จัดเก็บข้อมูลพื้นฐานส่วนใหญ่ แต่ก็มีข้อเสียอยู่บ้างเช่นกัน:

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

โครงการ การกระจายนักเทียบท่า (หรือที่รู้จักในชื่อ Docker Registry v2) เป็นผู้สืบทอดต่อจาก Docker Registry และทำหน้าที่เป็นชุดเครื่องมือสำหรับการบรรจุ จัดส่ง จัดเก็บ และจัดส่งอิมเมจ Docker บริการคลาวด์ขนาดใหญ่จำนวนมากนำเสนอผลิตภัณฑ์ตามการจัดจำหน่าย ด้วยความสนใจที่เพิ่มขึ้นนี้ โครงการ Distribution จึงได้รับประโยชน์จากการปรับปรุง แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย และการทดสอบภาคสนามเป็นเวลาหลายปี ซึ่งทำให้โครงการนี้เป็นหนึ่งในฮีโร่ที่ไม่มีใครเอ่ยถึงที่ประสบความสำเร็จมากที่สุดในโลกของ Open Source

แต่คุณรู้หรือไม่ว่าโครงการจัดจำหน่ายได้รับการออกแบบมาเพื่อเผยแพร่เนื้อหาทุกรูปแบบ ไม่ใช่แค่คอนเทนเนอร์อิมเมจเท่านั้น

ขอบคุณความพยายาม เปิด Container Initiative (หรือ OCI) สามารถวางแผนภูมิ Helm บนอินสแตนซ์การแจกจ่ายใดก็ได้ ในตอนนี้ กระบวนการนี้อยู่ระหว่างการทดลอง การสนับสนุนการเข้าสู่ระบบและคุณสมบัติอื่นๆ ที่จำเป็นสำหรับ Helm 3 ตัวเต็มนั้นยังอยู่ในระหว่างดำเนินการ แต่เรารู้สึกตื่นเต้นที่จะเรียนรู้จากการค้นพบที่ทีม OCI และ Distribution ได้ทำมาตลอดหลายปีที่ผ่านมา และด้วยการให้คำปรึกษาและคำแนะนำของพวกเขา เราได้เรียนรู้ว่าการดำเนินการบริการที่มีความพร้อมใช้งานสูงในวงกว้างนั้นเป็นอย่างไร

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

การจัดการการปล่อย

ใน Helm 3 สถานะของแอปพลิเคชันจะถูกติดตามภายในคลัสเตอร์โดยอ็อบเจ็กต์คู่หนึ่ง:

release object - แสดงถึงอินสแตนซ์ของแอปพลิเคชัน
release version Secret - แสดงถึงสถานะที่ต้องการของแอปพลิเคชัน ณ เวลาที่กำหนด (เช่น การเปิดตัวเวอร์ชันใหม่)

โทรศัพท์ helm install สร้างวัตถุ release และ release version Secret เรียก helm upgrade ต้องใช้อ็อบเจ็กต์ release (ซึ่งสามารถเปลี่ยนแปลงได้) และสร้างความลับเวอร์ชันรีลีสใหม่ที่มีค่าใหม่และไฟล์ Manifest ที่เตรียมไว้

อ็อบเจ็กต์ Release มีข้อมูลเกี่ยวกับการเปิดตัว โดยที่ release คือการติดตั้งเฉพาะของแผนภูมิและค่าที่มีชื่อ ออบเจ็กต์นี้อธิบายข้อมูลเมตาระดับบนสุดเกี่ยวกับการเผยแพร่ ออบเจ็กต์ Release จะคงอยู่ตลอดวงจรการใช้งานของแอปพลิเคชัน และเป็นเจ้าของความลับของเวอร์ชันรีลีสทั้งหมด รวมถึงออบเจ็กต์ทั้งหมดที่สร้างขึ้นโดยตรงจากแผนภูมิ Helm

ข้อมูลลับของเวอร์ชันรีลีสจะเชื่อมโยงรีลีสกับชุดการแก้ไข (การติดตั้ง การอัพเดต การย้อนกลับ การลบ)

ใน Helm 2 การแก้ไขมีความสอดคล้องกันอย่างมาก เรียก helm install สร้าง v1, การอัพเดตครั้งต่อไป (อัปเกรด) - v2 และอื่น ๆ ข้อมูลลับของเวอร์ชันรีลีสและรีลีสถูกยุบเป็นออบเจ็กต์เดียวที่เรียกว่าการแก้ไข การแก้ไขถูกจัดเก็บไว้ในเนมสเปซเดียวกันกับ Tiller ซึ่งหมายความว่าแต่ละรุ่นจะเป็น "สากล" ในแง่ของเนมสเปซ เป็นผลให้สามารถใช้ชื่อได้เพียงอินสแตนซ์เดียวเท่านั้น

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

หลังจากที่ Tiller ถูกทอดทิ้ง Helm 3 จะจัดเก็บข้อมูลการเผยแพร่ในเนมสเปซเดียวกันกับการเผยแพร่ การเปลี่ยนแปลงนี้ช่วยให้คุณติดตั้งแผนภูมิที่มีชื่อรีลีสเดียวกันในเนมสเปซอื่นได้ และข้อมูลจะถูกบันทึกไว้ระหว่างการอัปเดต/การรีบูตคลัสเตอร์ใน ฯลฯ ตัวอย่างเช่น คุณสามารถติดตั้ง WordPress ในเนมสเปซ "foo" จากนั้นในเนมสเปซ "bar" และสามารถตั้งชื่อทั้งสองรุ่นว่า "wordpress" ได้

การเปลี่ยนแปลงการพึ่งพาแผนภูมิ

แผนภูมิที่บรรจุ (โดยใช้ helm package) สำหรับใช้กับ Helm 2 สามารถติดตั้งกับ Helm 3 ได้ อย่างไรก็ตาม ขั้นตอนการพัฒนาแผนภูมิได้รับการปรับปรุงใหม่ทั้งหมด ดังนั้นจึงต้องมีการเปลี่ยนแปลงบางอย่างเพื่อพัฒนาแผนภูมิต่อไปด้วย Helm 3 โดยเฉพาะอย่างยิ่ง ระบบการจัดการการพึ่งพาแผนภูมิมีการเปลี่ยนแปลง

ระบบการจัดการการพึ่งพาของแผนภูมิได้ย้ายจาก requirements.yaml и requirements.lock บน Chart.yaml и Chart.lock. ซึ่งหมายความว่าแผนภูมิที่ใช้คำสั่ง helm dependencyต้องมีการตั้งค่าบางอย่างจึงจะทำงานใน Helm 3 ได้

ลองดูตัวอย่าง มาเพิ่มการขึ้นต่อกันให้กับแผนภูมิใน Helm 2 และดูว่ามีอะไรเปลี่ยนแปลงเมื่อย้ายไปที่ Helm 3

ในหางเสือ 2 requirements.yaml ดูเหมือนว่านี้:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

ใน Helm 3 การพึ่งพาแบบเดียวกันนี้จะสะท้อนให้เห็นในตัวคุณ Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

แผนภูมิยังคงถูกดาวน์โหลดและวางไว้ในไดเร็กทอรี charts/ดังนั้นแผนภูมิย่อย (แผนภูมิย่อย)นอนอยู่ในแค็ตตาล็อก charts/จะยังคงทำงานต่อไปโดยไม่มีการเปลี่ยนแปลง

ขอแนะนำแผนภูมิห้องสมุด

Helm 3 รองรับคลาสของแผนภูมิที่เรียกว่าแผนภูมิไลบรารี (แผนภูมิห้องสมุด). แผนภูมินี้ถูกใช้โดยแผนภูมิอื่น แต่ไม่ได้สร้างอาร์ติแฟกต์การเผยแพร่ใดๆ ในตัวมันเอง เทมเพลตแผนภูมิไลบรารีสามารถประกาศองค์ประกอบได้เท่านั้น define. เนื้อหาอื่น ๆ จะถูกละเว้น วิธีนี้ช่วยให้ผู้ใช้สามารถใช้ซ้ำและแบ่งปันโค้ดย่อยที่สามารถใช้กับแผนภูมิหลาย ๆ อันได้ จึงหลีกเลี่ยงการทำซ้ำและยึดมั่นในหลักการ แห้ง.

แผนภูมิห้องสมุดมีการประกาศไว้ในส่วนนี้ dependencies ในไฟล์ Chart.yaml. การติดตั้งและการจัดการก็ไม่ต่างจากแผนภูมิอื่นๆ

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

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

ทำอะไรต่อไป

Helm 3.0.0-alpha.1 เป็นรากฐานที่เราเริ่มสร้าง Helm เวอร์ชันใหม่ ในบทความ ฉันได้อธิบายคุณสมบัติที่น่าสนใจบางอย่างของ Helm 3 แล้ว หลายคุณสมบัติยังอยู่ในช่วงเริ่มต้นของการพัฒนา และนี่เป็นเรื่องปกติ จุดประสงค์ของการเปิดตัวรุ่นอัลฟ่าคือเพื่อทดสอบแนวคิด รวบรวมคำติชมจากผู้ใช้ในช่วงแรก และยืนยันสมมติฐานของเรา

ทันทีที่มีการเปิดตัวเวอร์ชันอัลฟ่า (จำไว้ว่านี่คือ. เกิดขึ้นแล้ว - ประมาณ แปล.)เราจะเริ่มรับแพทช์สำหรับ Helm 3 จากชุมชน คุณต้องสร้างรากฐานที่แข็งแกร่งที่ช่วยให้สามารถพัฒนาและปรับใช้ฟังก์ชันใหม่ได้ และเพื่อให้ผู้ใช้รู้สึกมีส่วนร่วมในกระบวนการนี้โดยการเปิดตั๋วและทำการแก้ไข

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

หากคุณรู้สึกว่าเราพลาดอะไรไป เรายินดีรับฟังความคิดเห็นของคุณ!

เข้าร่วมการสนทนาเกี่ยวกับเรา ช่องหย่อน:

#helm-users สำหรับคำถามและการสื่อสารที่เรียบง่ายกับชุมชน
#helm-dev เพื่อหารือเกี่ยวกับคำขอดึง โค้ด และข้อบกพร่อง

คุณยังสามารถสนทนาใน Public Developer Calls รายสัปดาห์ของเราในวันพฤหัสบดี เวลา 19:30 น. MSK การประชุมมีไว้เพื่อหารือเกี่ยวกับประเด็นต่างๆ ที่ผู้พัฒนาหลักและชุมชนกำลังดำเนินการอยู่ รวมถึงหัวข้อการอภิปรายประจำสัปดาห์ ทุกคนสามารถเข้าร่วมและมีส่วนร่วมในการประชุมได้ ลิงค์อยู่ในช่อง Slack #helm-dev.

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

ขอแนะนำหมวกกันน็อค 3