ແນະນຳ Helm 3

ຫມາຍ​ເຫດ​. ແປ.: ວັນທີ 16 ພຶດສະພາຂອງປີນີ້ເປັນຂີດໝາຍສຳຄັນໃນການພັດທະນາຕົວຈັດການຊຸດສຳລັບ Kubernetes - Helm. ໃນມື້ນີ້, ການປ່ອຍ alpha ທໍາອິດຂອງໂຄງການສະບັບທີ່ສໍາຄັນໃນອະນາຄົດ - 3.0 - ໄດ້ຖືກນໍາສະເຫນີ. ການປ່ອຍຂອງມັນຈະນໍາເອົາການປ່ຽນແປງທີ່ສໍາຄັນແລະລໍຖ້າມາດົນນານກັບ Helm, ເຊິ່ງຫຼາຍຄົນໃນຊຸມຊົນ Kubernetes ມີຄວາມຫວັງສູງ. ພວກເຮົາເອງແມ່ນຫນຶ່ງໃນບັນດາສິ່ງເຫຼົ່ານີ້, ນັບຕັ້ງແຕ່ພວກເຮົາໃຊ້ Helm ຢ່າງຈິງຈັງສໍາລັບການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກ: ພວກເຮົາໄດ້ປະສົມປະສານມັນເຂົ້າໄປໃນເຄື່ອງມືຂອງພວກເຮົາສໍາລັບການປະຕິບັດ CI / CD. werf ແລະບາງຄັ້ງພວກເຮົາປະກອບສ່ວນເຂົ້າໃນການພັດທະນາຂອງຕົ້ນນ້ໍາ. ການແປນີ້ລວມເອົາບັນທຶກ 7 ສະບັບຈາກບລັອກທີ່ເປັນທາງການຂອງ Helm, ເຊິ່ງອຸທິດຕົນໃຫ້ກັບການເປີດຕົວ alpha ທຳອິດຂອງ Helm 3 ແລະເວົ້າກ່ຽວກັບປະຫວັດຂອງໂຄງການ ແລະລັກສະນະຫຼັກຂອງ Helm 3. ຜູ້ຂຽນຂອງເຂົາເຈົ້າແມ່ນ Matt “bacongobbler” Fisher, ພະນັກງານຂອງ Microsoft. ແລະຫນຶ່ງໃນຜູ້ຮັກສາທີ່ສໍາຄັນຂອງ Helm.

ໃນວັນທີ 15 ເດືອນຕຸລາປີ 2015, ໂຄງການທີ່ເອີ້ນວ່າ Helm ໄດ້ເກີດມາ. ພຽງແຕ່ຫນຶ່ງປີຫຼັງຈາກການກໍ່ຕັ້ງຂອງຕົນ, ຊຸມຊົນ Helm ໄດ້ເຂົ້າຮ່ວມ Kubernetes, ໃນຂະນະທີ່ເຮັດວຽກຢ່າງຫ້າວຫັນໃນ Helm 2. ໃນເດືອນມິຖຸນາ 2018, Helm ເຂົ້າຮ່ວມ CNCF ເປັນໂຄງການພັດທະນາ (incubating). ໄວຕໍ່ກັບປະຈຸບັນ, ແລະການປ່ອຍ alpha ທໍາອິດຂອງ Helm 3 ໃໝ່ ແມ່ນຢູ່ໃນທາງຂອງມັນ. (ການປ່ອຍນີ້ ໄດ້ເກີດຂຶ້ນແລ້ວ ໃນກາງເດືອນພຶດສະພາ - ປະມານ. ແປ.).

ໃນສິ້ນນີ້, ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບບ່ອນທີ່ມັນທັງຫມົດໄດ້ເລີ່ມຕົ້ນ, ວິທີການທີ່ພວກເຮົາໄປບ່ອນທີ່ພວກເຮົາຢູ່ໃນມື້ນີ້, ແນະນໍາບາງລັກສະນະທີ່ເປັນເອກະລັກທີ່ມີຢູ່ໃນການປ່ອຍ alpha ທໍາອິດຂອງ Helm 3, ແລະອະທິບາຍວິທີທີ່ພວກເຮົາວາງແຜນທີ່ຈະກ້າວໄປຂ້າງຫນ້າ.

ສະຫຼຸບສັງລວມ:

• ປະຫວັດສາດຂອງການສ້າງ Helm ໄດ້;
• ການอำລາທີ່ອ່ອນໂຍນກັບ Tiller;
• ຄັງເກັບຕາຕະລາງ;
• ການຄຸ້ມຄອງການປ່ອຍຕົວ;
• ການປ່ຽນແປງໃນຕາຕະລາງຂຶ້ນກັບ;
• ຕາຕະລາງຫ້ອງສະຫມຸດ;
• ຕໍ່ໄປແມ່ນຫຍັງ?

ປະຫວັດຂອງ Helm

ການເກີດລູກ

Helm 1 ໄດ້ເລີ່ມຕົ້ນເປັນໂຄງການ Open Source ທີ່ສ້າງຂຶ້ນໂດຍ Deis. ພວກເຮົາເປັນການເລີ່ມຕົ້ນຂະຫນາດນ້ອຍ ດູດຊຶມ Microsoft ໃນພາກຮຽນ spring 2017. ໂຄງການ Open Source ອື່ນໆຂອງພວກເຮົາ, ທີ່ມີຊື່ວ່າ Deis, ມີເຄື່ອງມື deisctl, ເຊິ່ງໄດ້ຖືກນໍາໃຊ້ (ໃນບັນດາສິ່ງອື່ນໆ) ໃນການຕິດຕັ້ງແລະດໍາເນີນການເວທີ Deis ໃນ ກຸ່ມເຮືອ. ໃນເວລານັ້ນ, Fleet ແມ່ນຫນຶ່ງໃນເວທີການ orchestration ຕູ້ຄອນເທນເນີທໍາອິດ.

ໃນກາງປີ 2015, ພວກເຮົາໄດ້ຕັດສິນໃຈປ່ຽນຫຼັກສູດ ແລະຍ້າຍ Deis (ໃນເວລານັ້ນປ່ຽນຊື່ Deis Workflow) ຈາກ Fleet ໄປ Kubernetes. ຫນຶ່ງໃນທໍາອິດທີ່ໄດ້ຮັບການອອກແບບໃຫມ່ແມ່ນເຄື່ອງມືການຕິດຕັ້ງ. deisctl. ພວກເຮົາໄດ້ໃຊ້ມັນເພື່ອຕິດຕັ້ງ ແລະຈັດການ Deis Workflow ໃນກຸ່ມ Fleet.

Helm 1 ຖືກສ້າງຂື້ນໃນຮູບພາບຂອງຜູ້ຈັດການຊຸດທີ່ມີຊື່ສຽງເຊັ່ນ Homebrew, apt ແລະ yum. ເປົ້າ​ຫມາຍ​ຕົ້ນ​ຕໍ​ຂອງ​ມັນ​ແມ່ນ​ເພື່ອ​ເຮັດ​ໃຫ້​ວຽກ​ງານ​ງ່າຍ​ດາຍ​ເຊັ່ນ​ການ​ຫຸ້ມ​ຫໍ່​ແລະ​ການ​ຕິດ​ຕັ້ງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ໃນ Kubernetes​. Helm ໄດ້ຖືກນໍາສະເຫນີຢ່າງເປັນທາງການໃນປີ 2015 ໃນກອງປະຊຸມ KubeCon ໃນ San Francisco.

ຄວາມພະຍາຍາມຄັ້ງທໍາອິດຂອງພວກເຮົາກັບ Helm ໄດ້ຜົນ, ແຕ່ມັນບໍ່ແມ່ນບໍ່ມີຂໍ້ຈໍາກັດທີ່ຮ້າຍແຮງບາງ. ລາວໄດ້ເອົາຊຸດຂອງ Kubernetes manifests, ປຸງລົດຊາດດ້ວຍເຄື່ອງປັ່ນໄຟເປັນທ່ອນໄມ້ YAML ແນະນໍາ. (ເລື່ອງໜ້າ)*, ແລະໂຫຼດຜົນໄດ້ຮັບໃສ່ Kubernetes.

* ຫມາຍ​ເຫດ​. ແປ.: ຈາກລຸ້ນທໍາອິດຂອງ Helm, YAML syntax ໄດ້ຖືກເລືອກເພື່ອອະທິບາຍຊັບພະຍາກອນ Kubernetes, ແລະ Jinja templates ແລະ Python ໄດ້ຖືກສະຫນັບສະຫນູນໃນເວລາທີ່ຂຽນການຕັ້ງຄ່າ. ພວກເຮົາໄດ້ຂຽນເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ແລະໂຄງສ້າງຂອງ Helm ຮຸ່ນທໍາອິດໂດຍທົ່ວໄປໃນບົດ "ປະຫວັດຫຍໍ້ຂອງ Helm" ອຸ​ປະ​ກອນ​ການ​ນີ້​.

ຕົວຢ່າງ, ເພື່ອທົດແທນຊ່ອງຂໍ້ມູນໃນໄຟລ໌ YAML, ທ່ານຕ້ອງເພີ່ມໂຄງສ້າງຕໍ່ໄປນີ້ໃສ່ manifest:

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

ມັນດີຫຼາຍທີ່ເຄື່ອງຈັກແມ່ແບບມີຢູ່ໃນມື້ນີ້, ບໍ່ແມ່ນບໍ?

ດ້ວຍເຫດຜົນຫຼາຍຢ່າງ, ໂປຣແກຣມຕິດຕັ້ງ Kubernetes ຕົ້ນນີ້ຕ້ອງການລາຍຊື່ໄຟລ໌ manifest ທີ່ມີລະຫັດຍາກ ແລະພຽງແຕ່ປະຕິບັດລໍາດັບເຫດການເລັກນ້ອຍເທົ່ານັ້ນ. ມັນເປັນການຍາກຫຼາຍທີ່ຈະນໍາໃຊ້ທີ່ທີມງານ Deis Workflow R&D ມີຄວາມຫຍຸ້ງຍາກໃນເວລາທີ່ພວກເຂົາພະຍາຍາມໂອນຜະລິດຕະພັນຂອງພວກເຂົາໄປສູ່ເວທີນີ້ - ຢ່າງໃດກໍຕາມ, ເມັດຂອງແນວຄວາມຄິດໄດ້ຖືກຫວ່ານແລ້ວ. ຄວາມພະຍາຍາມຄັ້ງທຳອິດຂອງພວກເຮົາແມ່ນໂອກາດການຮຽນຮູ້ທີ່ດີ: ພວກເຮົາຮູ້ວ່າພວກເຮົາມີຄວາມກະຕືລືລົ້ນແທ້ໆໃນການສ້າງເຄື່ອງມືທີ່ຊ່ວຍແກ້ໄຂບັນຫາປະຈຳວັນໃຫ້ກັບຜູ້ໃຊ້ຂອງພວກເຮົາ.

ອີງໃສ່ປະສົບການຂອງຄວາມຜິດພາດທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ເລີ່ມພັດທະນາ Helm 2.

ການເຮັດ Helm 2

ໃນຕອນທ້າຍຂອງ 2015, ທີມງານ Google ໄດ້ຕິດຕໍ່ພວກເຮົາ. ພວກເຂົາເຈົ້າກໍາລັງເຮັດວຽກກ່ຽວກັບເຄື່ອງມືທີ່ຄ້າຍຄືກັນສໍາລັບ Kubernetes. Deployment Manager ສໍາລັບ Kubernetes ເປັນພອດຂອງເຄື່ອງມືທີ່ມີຢູ່ແລ້ວທີ່ໃຊ້ສໍາລັບ Google Cloud Platform. "ພວກເຮົາຕ້ອງການ," ເຂົາເຈົ້າຖາມວ່າ, "ໃຊ້ເວລາສອງສາມມື້ປຶກສາຫາລືຄວາມຄ້າຍຄືກັນແລະຄວາມແຕກຕ່າງ?"

ໃນເດືອນມັງກອນ 2016, ທີມງານ Helm ແລະ Deployment Manager ໄດ້ປະຊຸມກັນຢູ່ Seattle ເພື່ອແລກປ່ຽນຄວາມຄິດເຫັນ. ການເຈລະຈາໄດ້ສິ້ນສຸດລົງດ້ວຍແຜນການທີ່ມີຄວາມທະເຍີທະຍານ: ເພື່ອສົມທົບທັງສອງໂຄງການເພື່ອສ້າງ Helm 2. ຄຽງຄູ່ກັບ Deis ແລະ Google, guys ຈາກ. SkippBox (ປະຈຸບັນເປັນສ່ວນຫນຶ່ງຂອງ Bitnami - ປະມານການແປ.), ແລະພວກເຮົາໄດ້ເລີ່ມເຮັດວຽກຢູ່ໃນ Helm 2.

ພວກເຮົາຕ້ອງການຮັກສາຄວາມສະດວກໃນການນໍາໃຊ້ຂອງ Helm, ແຕ່ເພີ່ມສິ່ງຕໍ່ໄປນີ້:

• ແມ່ແບບຕາຕະລາງສໍາລັບການປັບແຕ່ງ;
• ການຄຸ້ມຄອງພາຍໃນກຸ່ມສໍາລັບທີມງານ;
• repository ຕາຕະລາງລະດັບໂລກ;
• ຮູບແບບຊຸດທີ່ຫມັ້ນຄົງທີ່ມີທາງເລືອກລາຍເຊັນ;
• ຄໍາຫມັ້ນສັນຍາທີ່ເຂັ້ມແຂງກັບສະບັບພາສາ semantic ແລະຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບຄືນໄປບ່ອນລະຫວ່າງສະບັບ.

ເພື່ອບັນລຸເປົ້າຫມາຍເຫຼົ່ານີ້, ອົງປະກອບທີສອງໄດ້ຖືກເພີ່ມເຂົ້າໃນລະບົບນິເວດ Helm. ອົງປະກອບພາຍໃນກຸ່ມນີ້ເອີ້ນວ່າ Tiller ແລະຮັບຜິດຊອບໃນການຕິດຕັ້ງ ແລະຈັດການ Helm charts.

ນັບຕັ້ງແຕ່ການປ່ອຍ Helm 2 ໃນປີ 2016, Kubernetes ໄດ້ເພີ່ມນະວັດຕະກໍາທີ່ສໍາຄັນຈໍານວນຫນຶ່ງ. ເພີ່ມການຄວບຄຸມການເຂົ້າເຖິງໂດຍອີງໃສ່ບົດບາດ (RBAC), ເຊິ່ງໃນທີ່ສຸດກໍໄດ້ປ່ຽນແທນ Attribute-Based Access Control (ABAC). ປະເພດຊັບພະຍາກອນໃຫມ່ໄດ້ຖືກນໍາສະເຫນີ (ການໃຊ້ງານຍັງຢູ່ໃນເບຕ້າໃນເວລານັ້ນ). ຄໍານິຍາມຊັບພະຍາກອນທີ່ກໍາຫນົດເອງ (ເດີມເອີ້ນວ່າຊັບພະຍາກອນພາກສ່ວນທີສາມຫຼື TPRs) ຖືກປະດິດ. ແລະສໍາຄັນທີ່ສຸດ, ຊຸດການປະຕິບັດທີ່ດີທີ່ສຸດໄດ້ເກີດຂື້ນ.

ທ່າມກາງການປ່ຽນແປງທັງໝົດນີ້, Helm ສືບຕໍ່ຮັບໃຊ້ຜູ້ໃຊ້ Kubernetes ຢ່າງຊື່ສັດ. ຫຼັງຈາກສາມປີແລະການເພີ່ມເຕີມໃຫມ່ຈໍານວນຫຼາຍ, ມັນເປັນທີ່ຊັດເຈນວ່າມັນເຖິງເວລາທີ່ຈະເຮັດການປ່ຽນແປງທີ່ສໍາຄັນໃນ codebase ເພື່ອຮັບປະກັນວ່າ Helm ສາມາດສືບຕໍ່ຕອບສະຫນອງຄວາມຕ້ອງການທີ່ເພີ່ມຂຶ້ນຂອງລະບົບນິເວດທີ່ພັດທະນາ.

ຄຳອຳລາທີ່ອ່ອນໂຍນກັບ Tiller

ໃນລະຫວ່າງການພັດທະນາ Helm 2, ພວກເຮົາໄດ້ແນະນໍາ Tiller ເປັນສ່ວນຫນຶ່ງຂອງການເຊື່ອມໂຍງກັບ Google's Deployment Manager. Tiller ມີບົດບາດສໍາຄັນສໍາລັບທີມງານທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມທົ່ວໄປ: ມັນອະນຸຍາດໃຫ້ຜູ້ຊ່ຽວຊານທີ່ແຕກຕ່າງກັນທີ່ປະຕິບັດໂຄງສ້າງພື້ນຖານເພື່ອພົວພັນກັບຊຸດດຽວກັນ.

ນັບຕັ້ງແຕ່ການຄວບຄຸມການເຂົ້າເຖິງໂດຍອີງໃສ່ບົດບາດ (RBAC) ຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນໃນ Kubernetes 1.6, ການເຮັດວຽກກັບ Tiller ໃນການຜະລິດໄດ້ກາຍເປັນຄວາມຫຍຸ້ງຍາກຫຼາຍ. ເນື່ອງຈາກນະໂຍບາຍຄວາມປອດໄພທີ່ເປັນໄປໄດ້ຫຼາຍ, ຕຳແໜ່ງຂອງພວກເຮົາແມ່ນສະເໜີໃຫ້ມີການກຳນົດຄ່າທີ່ອະນຸຍາດໂດຍຄ່າເລີ່ມຕົ້ນ. ອັນນີ້ເຮັດໃຫ້ຄົນໃໝ່ສາມາດທົດລອງໃຊ້ Helm ແລະ Kubernetes ໂດຍບໍ່ຕ້ອງເຂົ້າໄປໃນການຕັ້ງຄ່າຄວາມປອດໄພກ່ອນ. ແຕ່ຫນ້າເສຍດາຍ, ການຕັ້ງຄ່າການອະນຸຍາດນີ້ສາມາດໃຫ້ຜູ້ໃຊ້ມີຂອບເຂດການອະນຸຍາດທີ່ກວ້າງເກີນໄປທີ່ພວກເຂົາບໍ່ຕ້ອງການ. ວິສະວະກອນ DevOps ແລະ SRE ຕ້ອງຮຽນຮູ້ຂັ້ນຕອນການດໍາເນີນງານເພີ່ມເຕີມເມື່ອຕິດຕັ້ງ Tiller ໃນກຸ່ມຜູ້ເຊົ່າຫຼາຍ.

ຫຼັງຈາກການຮຽນຮູ້ວິທີການທີ່ຊຸມຊົນໃຊ້ Helm ໃນສະຖານະການສະເພາະ, ພວກເຮົາຮູ້ວ່າລະບົບການຄຸ້ມຄອງການປ່ອຍຕົວຂອງ Tiller ບໍ່ຈໍາເປັນຕ້ອງອີງໃສ່ອົງປະກອບພາຍໃນກຸ່ມເພື່ອຮັກສາລັດຫຼືຫນ້າທີ່ເປັນສູນກາງສໍາລັບການປ່ອຍຂໍ້ມູນ. ແທນທີ່ຈະ, ພວກເຮົາພຽງແຕ່ສາມາດໄດ້ຮັບຂໍ້ມູນຈາກເຄື່ອງແມ່ຂ່າຍ Kubernetes API, ສ້າງຕາຕະລາງໃນດ້ານລູກຄ້າ, ແລະເກັບຮັກສາບັນທຶກການຕິດຕັ້ງໃນ Kubernetes.

ເປົ້າຫມາຍຕົ້ນຕໍຂອງ Tiller ສາມາດບັນລຸໄດ້ໂດຍບໍ່ມີການ Tiller, ດັ່ງນັ້ນຫນຶ່ງໃນການຕັດສິນໃຈທໍາອິດຂອງພວກເຮົາກ່ຽວກັບ Helm 3 ແມ່ນການປະຖິ້ມ Tiller ຢ່າງສົມບູນ.

ເມື່ອ Tiller ຫາຍໄປ, ຮູບແບບຄວາມປອດໄພຂອງ Helm ໄດ້ຖືກປັບປຸງໃຫ້ງ່າຍດາຍຫຼາຍ. ດຽວນີ້ Helm 3 ຮອງຮັບຄວາມປອດໄພ, ຕົວຕົນ, ແລະວິທີການອະນຸຍາດຂອງ Kubernetes ໃນປະຈຸບັນ. ການອະນຸຍາດ Helm ຖືກກໍານົດໂດຍໃຊ້ ໄຟລ໌ kubeconfig. ຜູ້ບໍລິຫານກຸ່ມສາມາດຈໍາກັດສິດຂອງຜູ້ໃຊ້ຕໍ່ກັບລະດັບຂອງ granularity ໃດ. ການປ່ອຍຍັງຖືກບັນທຶກໄວ້ພາຍໃນກຸ່ມ, ແລະສ່ວນທີ່ເຫລືອຂອງການເຮັດວຽກຂອງ Helm ຍັງຄົງຢູ່.

ຄັງເກັບຕາຕະລາງ

ໃນລະດັບສູງ, ຄັງເກັບຕາຕະລາງແມ່ນບ່ອນທີ່ຕາຕະລາງສາມາດເກັບຮັກສາແລະແບ່ງປັນໄດ້. Helm client packages ແລະສົ່ງຕາຕະລາງກັບ repository. ເວົ້າງ່າຍໆ, ຄັງເກັບຕາຕະລາງແມ່ນເຄື່ອງແມ່ຂ່າຍ HTTP ເບື້ອງຕົ້ນທີ່ມີໄຟລ໌ index.yaml ແລະບາງຕາຕະລາງຫຸ້ມຫໍ່.

ໃນຂະນະທີ່ມີບາງຂໍ້ໄດ້ປຽບຂອງ Charts Repository API ທີ່ຕອບສະຫນອງຄວາມຕ້ອງການການເກັບຮັກສາພື້ນຖານສ່ວນໃຫຍ່, ຍັງມີຂໍ້ເສຍເລັກນ້ອຍ:

• ຄັງເກັບຕາຕະລາງບໍ່ເຫມາະສົມກັບການປະຕິບັດຄວາມປອດໄພສ່ວນໃຫຍ່ທີ່ຕ້ອງການໃນສະພາບແວດລ້ອມການຜະລິດ. ການມີ API ມາດຕະຖານສໍາລັບການຢັ້ງຢືນແລະການອະນຸຍາດແມ່ນມີຄວາມສໍາຄັນຫຼາຍໃນສະຖານະການການຜະລິດ.
• ເຄື່ອງມືພິສູດແຜນວາດຂອງ Helm, ໃຊ້ເພື່ອເຊັນ, ຢັ້ງຢືນຄວາມຊື່ສັດ ແລະຫຼັກຖານສະແດງຂອງຕາຕະລາງ, ແມ່ນສ່ວນໜຶ່ງທີ່ເປັນທາງເລືອກຂອງຂະບວນການເຜີຍແຜ່ຕາຕະລາງ.
• ໃນສະຖານະການທີ່ມີຜູ້ໃຊ້ຫຼາຍ, ຕາຕະລາງດຽວກັນສາມາດຖືກອັບໂຫລດໂດຍຜູ້ໃຊ້ອື່ນ, ເພີ່ມສອງເທົ່າຂອງຈໍານວນພື້ນທີ່ທີ່ຕ້ອງການເພື່ອເກັບຮັກສາເນື້ອຫາດຽວກັນ. ຄັງເກັບມ້ຽນທີ່ສະຫລາດກວ່າໄດ້ຖືກພັດທະນາເພື່ອແກ້ໄຂບັນຫານີ້, ແຕ່ພວກມັນບໍ່ແມ່ນສ່ວນຫນຶ່ງຂອງການກໍານົດຢ່າງເປັນທາງການ.
• ການນໍາໃຊ້ໄຟລ໌ດັດສະນີດຽວສໍາລັບການຄົ້ນຫາ, ເກັບຮັກສາ metadata, ແລະການດຶງເອົາຕາຕະລາງໄດ້ເຮັດໃຫ້ມັນຍາກທີ່ຈະພັດທະນາການປະຕິບັດທີ່ມີຄວາມປອດໄພຫຼາຍຜູ້ໃຊ້.

ໂຄງການ ການແຈກຢາຍ Docker (ຍັງເອີ້ນວ່າ Docker Registry v2) ເປັນຜູ້ສືບທອດ Docker Registry ແລະເຮັດຫນ້າທີ່ເປັນຊຸດເຄື່ອງມືສໍາລັບການຫຸ້ມຫໍ່, ການຂົນສົ່ງ, ການເກັບຮັກສາແລະສົ່ງຮູບພາບ Docker. ການບໍລິການຄລາວຂະຫນາດໃຫຍ່ຈໍານວນຫຼາຍສະເຫນີຜະລິດຕະພັນທີ່ອີງໃສ່ການແຈກຢາຍ. ຂໍຂອບໃຈກັບຄວາມສົນໃຈທີ່ເພີ່ມຂຶ້ນນີ້, ໂຄງການການແຈກຢາຍໄດ້ຮັບຜົນປະໂຫຍດຈາກການປັບປຸງຫຼາຍປີ, ການປະຕິບັດທີ່ດີທີ່ສຸດດ້ານຄວາມປອດໄພ, ແລະການທົດສອບພາກສະຫນາມທີ່ເຮັດໃຫ້ມັນເປັນຫນຶ່ງໃນ heroes unsung ສົບຜົນສໍາເລັດທີ່ສຸດຂອງໂລກ Open Source.

ແຕ່ທ່ານຮູ້ບໍວ່າໂຄງການແຈກຢາຍໄດ້ຖືກອອກແບບເພື່ອແຈກຢາຍເນື້ອຫາໃດກໍ່ຕາມ, ບໍ່ພຽງແຕ່ຮູບພາບບັນຈຸ?

ຂໍຂອບໃຈກັບຄວາມພະຍາຍາມ ການລິເລີ່ມການບັນຈຸຕູ້ຄອນເທນເນີ (ຫຼື OCI), ຕາຕະລາງ Helm ສາມາດຖືກວາງໄວ້ໃນຕົວຢ່າງການແຈກຢາຍໃດໆ. ສໍາລັບໃນປັດຈຸບັນ, ຂະບວນການນີ້ແມ່ນທົດລອງ. ການສະຫນັບສະຫນູນການເຂົ້າສູ່ລະບົບແລະລັກສະນະອື່ນໆທີ່ຈໍາເປັນສໍາລັບ Helm 3 ເຕັມແມ່ນວຽກງານທີ່ກໍາລັງດໍາເນີນຢູ່, ແຕ່ພວກເຮົາຕື່ນເຕັ້ນທີ່ຈະຮຽນຮູ້ຈາກການຄົ້ນພົບທີ່ທີມງານ OCI ແລະ Distribution ໄດ້ເຮັດໃນໄລຍະປີທີ່ຜ່ານມາ. ແລະໂດຍຜ່ານການໃຫ້ຄໍາປຶກສາແລະການຊີ້ນໍາຂອງພວກເຂົາ, ພວກເຮົາຮຽນຮູ້ວ່າມັນເປັນແນວໃດທີ່ຈະດໍາເນີນການບໍລິການທີ່ມີຫຼາຍໃນລະດັບ.

ລາຍລະອຽດເພີ່ມເຕີມຂອງບາງການປ່ຽນແປງທີ່ຈະມາເຖິງຕໍ່ກັບບ່ອນເກັບຂໍ້ມູນຕາຕະລາງ Helm ແມ່ນມີໃຫ້ ການເຊື່ອມຕໍ່.

ການຄຸ້ມຄອງການປ່ອຍ

ໃນ Helm 3, ສະຖານະແອັບພລິເຄຊັນຖືກຕິດຕາມພາຍໃນກຸ່ມໂດຍຄູ່ຂອງວັດຖຸ:

• ປ່ອຍວັດຖຸ - ເປັນຕົວແທນຂອງຄໍາຮ້ອງສະຫມັກ;
• ການປ່ອຍເວີຊັນລັບ - ສະແດງໃຫ້ເຫັນເຖິງສະຖານະທີ່ຕ້ອງການຂອງແອັບພລິເຄຊັນໃນເວລາສະເພາະ (ຕົວຢ່າງ, ການປ່ອຍເວີຊັນໃຫມ່).

ທ້າທາຍ helm install ສ້າງວັດຖຸປ່ອຍແລະປ່ອຍສະບັບລັບ. ໂທ helm upgrade ຮຽກ​ຮ້ອງ​ໃຫ້​ມີ​ການ​ປ່ອຍ​ວັດ​ຖຸ (ທີ່​ມັນ​ສາ​ມາດ​ປ່ຽນ​ແປງ​ໄດ້​) ແລະ​ສ້າງ​ຄວາມ​ລັບ​ສະ​ບັບ​ປ່ອຍ​ໃຫມ່​ທີ່​ມີ​ຄ່າ​ໃຫມ່​ແລະ manifest ການ​ກະ​ກຽມ​.

ການປ່ອຍວັດຖຸປະກອບດ້ວຍຂໍ້ມູນກ່ຽວກັບການປ່ອຍ, ບ່ອນທີ່ການປ່ອຍແມ່ນການຕິດຕັ້ງສະເພາະຂອງຕາຕະລາງທີ່ມີຊື່ແລະຄ່າ. ວັດຖຸນີ້ອະທິບາຍ metadata ລະດັບສູງສຸດກ່ຽວກັບການປ່ອຍ. ວັດຖຸການປ່ອຍຕົວຍັງຄົງຢູ່ຕະຫຼອດວົງຈອນຊີວິດຂອງແອັບພລິເຄຊັນ ແລະເປັນເຈົ້າຂອງຄວາມລັບຂອງລຸ້ນລຸ້ນທັງໝົດ, ເຊັ່ນດຽວກັນກັບວັດຖຸທັງໝົດທີ່ສ້າງຂຶ້ນໂດຍກົງໂດຍຕາຕະລາງ Helm.

ລຸ້ນລຸ້ນລັບຮ່ວມກັບລຸ້ນທີ່ມີການປັບປຸງຊຸດ (ການຕິດຕັ້ງ, ອັບເດດ, rollbacks, ລົບ).

ໃນ Helm 2, ການດັດແກ້ແມ່ນສອດຄ່ອງທີ່ສຸດ. ໂທ helm install ສ້າງ v1, ການປັບປຸງຕໍ່ໄປ (ການຍົກລະດັບ) - v2, ແລະອື່ນໆ. ການປ່ອຍແລະການປ່ອຍຄວາມລັບສະບັບໄດ້ຖືກຍຸບເຂົ້າໄປໃນວັດຖຸອັນດຽວທີ່ເອີ້ນວ່າການປັບປຸງ. ການແກ້ໄຂໄດ້ຖືກເກັບໄວ້ໃນ namespace ດຽວກັນກັບ Tiller, ຊຶ່ງຫມາຍຄວາມວ່າແຕ່ລະການປ່ອຍແມ່ນ "ທົ່ວໂລກ" ໃນຂໍ້ກໍານົດຂອງ namespace; ດັ່ງນັ້ນ, ພຽງແຕ່ຫນຶ່ງຕົວຢ່າງຂອງຊື່ສາມາດຖືກນໍາໃຊ້.

ໃນ Helm 3, ແຕ່ລະການປ່ອຍແມ່ນກ່ຽວຂ້ອງກັບຄວາມລັບສະບັບປ່ອຍຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນ. ອອບເຈັກການປ່ອຍຕົວອະທິບາຍເຖິງການປ່ອຍປະຈຸບັນທີ່ນຳໃຊ້ກັບ Kubernetes ສະເໝີ. ແຕ່ລະລຸ້ນທີ່ເປັນຄວາມລັບອະທິບາຍເຖິງລຸ້ນດຽວເທົ່ານັ້ນ. ຕົວຢ່າງ, ການອັບເກຣດຈະສ້າງເວີຊັນທີ່ປ່ອຍອອກມາໃໝ່ເປັນຄວາມລັບ ແລະຫຼັງຈາກນັ້ນປ່ຽນວັດຖຸການປ່ອຍເພື່ອຊີ້ໄປຫາເວີຊັນໃໝ່ນັ້ນ. ໃນ​ກໍ​ລະ​ນີ​ຂອງ rollback ເປັນ​, ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້​ຄວາມ​ລັບ​ຂອງ​ສະ​ບັບ​ປ່ອຍ​ກ່ອນ​ຫນ້າ​ນີ້​ເພື່ອ​ມ້ວນ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ການ​ປ່ອຍ​ທີ່​ຜ່ານ​ມາ​.

ຫຼັງຈາກ Tiller ຖືກປະຖິ້ມ, Helm 3 ເກັບຮັກສາຂໍ້ມູນອອກໃນ namespace ດຽວກັນກັບການປ່ອຍ. ການປ່ຽນແປງນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕັ້ງຕາຕະລາງທີ່ມີຊື່ການປ່ອຍດຽວກັນໃນ namespace ທີ່ແຕກຕ່າງກັນ, ແລະຂໍ້ມູນຈະຖືກບັນທຶກໄວ້ລະຫວ່າງການປັບປຸງ cluster / reboots ໃນ etcd. ຕົວຢ່າງ, ທ່ານສາມາດຕິດຕັ້ງ WordPress ໃນ namespace "foo" ແລະຫຼັງຈາກນັ້ນໃນ "bar" namespace, ແລະທັງສອງລຸ້ນສາມາດມີຊື່ວ່າ "wordpress".

ການປ່ຽນແປງການຂຶ້ນກັບຕາຕະລາງ

ຕາຕະລາງບັນຈຸ (ການນໍາໃຊ້ helm package) ສໍາລັບການນໍາໃຊ້ກັບ Helm 2 ສາມາດຕິດຕັ້ງໄດ້ກັບ Helm 3, ຢ່າງໃດກໍຕາມ, ຂະບວນການພັດທະນາຕາຕະລາງໄດ້ຖືກ overhauled ຢ່າງສົມບູນ, ດັ່ງນັ້ນການປ່ຽນແປງບາງຢ່າງຕ້ອງເຮັດເພື່ອສືບຕໍ່ການພັດທະນາຕາຕະລາງກັບ Helm 3. ໂດຍສະເພາະ, ລະບົບການຄຸ້ມຄອງການຂຶ້ນກັບຕາຕະລາງໄດ້ມີການປ່ຽນແປງ.

ລະບົບການຈັດການຄວາມເພິ່ງພາອາໄສຂອງຕາຕະລາງໄດ້ຍ້າຍຈາກ requirements.yaml и requirements.lock ສຸດ Chart.yaml и Chart.lock. ນີ້ຫມາຍຄວາມວ່າຕາຕະລາງທີ່ໃຊ້ຄໍາສັ່ງ helm dependency, ຕ້ອງການການຕິດຕັ້ງບາງຢ່າງເພື່ອເຮັດວຽກໃນ Helm 3.

ໃຫ້ເບິ່ງຕົວຢ່າງ. ຂໍໃຫ້ເພີ່ມຄວາມເພິ່ງພາອາໄສໃສ່ຕາຕະລາງໃນ Helm 2 ແລະເບິ່ງວ່າມີຫຍັງປ່ຽນແປງເມື່ອຍ້າຍໄປ Helm 3.

ໃນ Helm 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. ຈໍານວນຫຼາຍຂອງພວກເຂົາຍັງຢູ່ໃນຂັ້ນຕອນຕົ້ນຂອງການພັດທະນາແລະນີ້ແມ່ນເລື່ອງປົກກະຕິ; ຈຸດຂອງການປ່ອຍ alpha ແມ່ນການທົດສອບຄວາມຄິດ, ລວບລວມຄໍາຄຶດຄໍາເຫັນຈາກຜູ້ໃຊ້ຕົ້ນ, ແລະຢືນຢັນການສົມມຸດຕິຖານຂອງພວກເຮົາ.

ທັນທີທີ່ສະບັບ alpha ຖືກປ່ອຍອອກມາ (ຈື່ໄວ້ວ່ານີ້ແມ່ນ ໄດ້ເກີດຂຶ້ນແລ້ວ — ປະ​ມານ​. ແປ.), ພວກເຮົາຈະເລີ່ມຮັບເອົາ patches ສໍາລັບ Helm 3 ຈາກຊຸມຊົນ. ທ່ານຈໍາເປັນຕ້ອງສ້າງພື້ນຖານທີ່ເຂັ້ມແຂງທີ່ອະນຸຍາດໃຫ້ການທໍາງານໃຫມ່ໄດ້ຮັບການພັດທະນາແລະຮັບຮອງເອົາ, ແລະເພື່ອໃຫ້ຜູ້ໃຊ້ມີຄວາມຮູ້ສຶກມີສ່ວນຮ່ວມໃນຂະບວນການໂດຍການເປີດຕົ໋ວແລະແກ້ໄຂ.

ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມຍົກໃຫ້ເຫັນບາງການປັບປຸງທີ່ສໍາຄັນທີ່ຈະມາເຖິງ Helm 3, ແຕ່ບັນຊີລາຍຊື່ນີ້ແມ່ນບໍ່ຄົບຖ້ວນ. ແຜນຜັງເສັ້ນທາງອັນເຕັມທີ່ສໍາລັບ Helm 3 ປະກອບມີຄຸນສົມບັດເຊັ່ນ: ຍຸດທະສາດການປັບປຸງການປັບປຸງ, ການເຊື່ອມໂຍງກັບການລົງທະບຽນ OCI ທີ່ເລິກເຊິ່ງ, ແລະການນໍາໃຊ້ JSON schemas ເພື່ອກວດສອບມູນຄ່າຕາຕະລາງ. ພວກເຮົາຍັງວາງແຜນທີ່ຈະທໍາຄວາມສະອາດ codebase ແລະປັບປຸງພາກສ່ວນຂອງມັນທີ່ຖືກລະເລີຍສໍາລັບສາມປີທີ່ຜ່ານມາ.

ຖ້າທ່ານຮູ້ສຶກວ່າພວກເຮົາພາດບາງສິ່ງບາງຢ່າງ, ພວກເຮົາຢາກໄດ້ຍິນຄວາມຄິດຂອງເຈົ້າ!

ເຂົ້າຮ່ວມການສົນທະນາຂອງພວກເຮົາ ຊ່ອງຫວ່າງ:

• #helm-users ສໍາລັບຄໍາຖາມແລະການສື່ສານງ່າຍດາຍກັບຊຸມຊົນ;
• #helm-dev ເພື່ອປຶກສາຫາລືການຮ້ອງຂໍດຶງ, ລະຫັດແລະແມງໄມ້.

ທ່ານຍັງສາມາດສົນທະນາໃນການໂທນັກພັດທະນາສາທາລະນະປະຈໍາອາທິດຂອງພວກເຮົາໃນວັນພະຫັດເວລາ 19:30 MSK. ກອງປະຊຸມແມ່ນອຸທິດຕົນເພື່ອປຶກສາຫາລືບັນຫາທີ່ນັກພັດທະນາທີ່ສໍາຄັນແລະຊຸມຊົນກໍາລັງເຮັດວຽກ, ເຊັ່ນດຽວກັນກັບຫົວຂໍ້ຂອງການສົນທະນາສໍາລັບອາທິດ. ທຸກຄົນສາມາດເຂົ້າຮ່ວມ ແລະເຂົ້າຮ່ວມການປະຊຸມໄດ້. ລິ້ງມີຢູ່ໃນຊ່ອງ Slack #helm-dev.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ຜູ້ຈັດການຊຸດສໍາລັບ Kubernetes - Helm: ອະດີດ, ປັດຈຸບັນ, ອະນາຄົດ"
• «ເບິ່ງຢ່າງມີສະຕິຢູ່ Helm 2: “ອັນນີ້ຄືອັນນີ້…”"
• «ການແນະນໍາພາກປະຕິບັດຕໍ່ກັບຜູ້ຈັດການຊຸດສໍາລັບ Kubernetes - Helm"
• «ເຄັດລັບ ແລະເຄັດລັບ Kubernetes: ການໂອນຊັບພະຍາກອນທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມໄປຫາການຈັດການ Helm 2"
• «ຝຶກຊ້ອມກັບ dapp. ສ່ວນທີ 2. ການນຳໃຊ້ຮູບ Docker ກັບ Kubernetes ໂດຍໃຊ້ Helm".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com