ອຸປະກອນ Helm ແລະ pitfalls ຂອງມັນ

ແນວຄວາມຄິດຂອງລົດຂົນສົ່ງສິນຄ້າ Typhon, Anton Swanepoel

ຂ້ອຍຊື່ Dmitry Sugrobov, ຂ້ອຍເປັນຜູ້ພັດທະນາຢູ່ Leroy Merlin. ໃນບົດຄວາມນີ້ຂ້າພະເຈົ້າຈະບອກທ່ານວ່າເປັນຫຍັງ Helm ຕ້ອງການ, ມັນເຮັດໃຫ້ການເຮັດວຽກກັບ Kubernetes ງ່າຍຂຶ້ນ, ສິ່ງທີ່ມີການປ່ຽນແປງໃນສະບັບທີສາມ, ແລະວິທີການນໍາໃຊ້ມັນເພື່ອປັບປຸງຄໍາຮ້ອງສະຫມັກໃນການຜະລິດໂດຍບໍ່ມີການ downtime.

ນີ້​ແມ່ນ​ບົດ​ສະຫຼຸບ​ໂດຍ​ອີງ​ຕາມ​ຄຳ​ປາ​ໄສ​ໃນ​ກອງ​ປະຊຸມ @Kubernetes ກອງປະຊຸມ by Mail.ru Cloud Solutions — ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ບໍ່​ຕ້ອງ​ການ​ທີ່​ຈະ​ອ່ານ​, ເບິ່ງ​ວິ​ດີ​ໂອ​ໄດ້​.

ເປັນຫຍັງພວກເຮົາຈຶ່ງໃຊ້ Kubernetes ໃນການຜະລິດ

Leroy Merlin ເປັນຜູ້ນໍາໃນຕະຫຼາດຂາຍຍ່ອຍ DIY ໃນລັດເຊຍແລະເອີຣົບ. ບໍລິສັດຂອງພວກເຮົາມີຫຼາຍກວ່າຫນຶ່ງຮ້ອຍນັກພັດທະນາ, 33 ພະນັກງານພາຍໃນແລະຈໍານວນ huge ຂອງຜູ້ທີ່ໄປຢ້ຽມຢາມ hypermarkets ແລະເວັບໄຊທ໌. ເພື່ອເຮັດໃຫ້ພວກເຂົາທັງຫມົດມີຄວາມສຸກ, ພວກເຮົາໄດ້ຕັດສິນໃຈປະຕິບັດຕາມວິທີການມາດຕະຖານອຸດສາຫະກໍາ. ພັດທະນາຄໍາຮ້ອງສະຫມັກໃຫມ່ໂດຍໃຊ້ສະຖາປັດຕະຍະກໍາຈຸລະພາກ; ໃຊ້ຕູ້ຄອນເທນເນີເພື່ອແຍກສະພາບແວດລ້ອມແລະຮັບປະກັນການຈັດສົ່ງທີ່ເຫມາະສົມ; ແລະໃຊ້ Kubernetes ສໍາລັບ orchestration. ລາຄາຂອງການໃຊ້ orchestrators ແມ່ນລາຄາຖືກລົງຢ່າງໄວວາ: ຈໍານວນຂອງວິສະວະກອນທີ່ມີຄວາມຊໍານິຊໍານານໃນເຕັກໂນໂລຢີກໍາລັງເຕີບໂຕໃນຕະຫຼາດ, ແລະຜູ້ໃຫ້ບໍລິການກໍາລັງປະກົດຕົວສະເຫນີ Kubernetes ເປັນບໍລິການ.

ທຸກສິ່ງທຸກຢ່າງທີ່ Kubernetes ເຮັດ, ແນ່ນອນ, ສາມາດເຮັດໄດ້ດ້ວຍວິທີອື່ນ, ຕົວຢ່າງ, ໂດຍກວມເອົາບາງ Jenkins ແລະ docker-compose ກັບ scripts, ແຕ່ເປັນຫຍັງຊີວິດສັບສົນຖ້າມີການແກ້ໄຂທີ່ກຽມພ້ອມແລະເຊື່ອຖືໄດ້? ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາມາຮອດ Kubernetes ແລະໄດ້ໃຊ້ມັນໃນການຜະລິດເປັນເວລາຫນຶ່ງປີແລ້ວ. ໃນປັດຈຸບັນພວກເຮົາມີກຸ່ມ Kubernetes ຊາວສີ່ກຸ່ມ, ເຊິ່ງເກົ່າແກ່ທີ່ສຸດແມ່ນຫຼາຍກວ່າຫນຶ່ງປີ, ມີປະມານສອງຮ້ອຍຝັກ.

ຄຳສາບແຊ່ງຂອງໄຟລ໌ YAML ຂະໜາດໃຫຍ່ໃນ Kubernetes

ເພື່ອເປີດຕົວບໍລິການຈຸລະພາກໃນ Kubernetes, ພວກເຮົາຈະສ້າງໄຟລ໌ YAML ຢ່າງຫນ້ອຍຫ້າໄຟລ໌: ສໍາລັບການຕິດຕັ້ງ, ການບໍລິການ, Ingress, ConfigMap, ຄວາມລັບ - ແລະສົ່ງພວກມັນໄປຫາກຸ່ມ. ສໍາລັບຄໍາຮ້ອງສະຫມັກຕໍ່ໄປພວກເຮົາຈະຂຽນຊຸດດຽວກັນຂອງ jambs, ກັບອັນທີສາມພວກເຮົາຈະຂຽນອີກອັນຫນຶ່ງ, ແລະອື່ນໆ. ຖ້າພວກເຮົາຄູນຈໍານວນເອກະສານດ້ວຍຈໍານວນສະພາບແວດລ້ອມ, ພວກເຮົາຈະໄດ້ຮັບໄຟລ໌ຫຼາຍຮ້ອຍໄຟລ໌, ແລະນີ້ຍັງບໍ່ທັນຄໍານຶງເຖິງສະພາບແວດລ້ອມແບບເຄື່ອນໄຫວ.

Adam Reese, ຜູ້ຮັກສາຫຼັກຂອງ Helm, ໄດ້ແນະນໍາແນວຄວາມຄິດຂອງ "ວົງຈອນການພັດທະນາໃນ Kubernetes", ເຊິ່ງເບິ່ງຄືວ່ານີ້:

1. ສຳເນົາ YAML - ສຳເນົາໄຟລ໌ YAML.
2. ວາງ YAML - ວາງມັນ.
3. ແກ້ໄຂຫຍໍ້ໜ້າ - fix indents.
4. Repeat - ເຮັດຊ້ໍາອີກຄັ້ງ.

ທາງເລືອກເຮັດວຽກ, ແຕ່ວ່າທ່ານຕ້ອງຄັດລອກໄຟລ໌ YAML ຫຼາຍຄັ້ງ. ເພື່ອປ່ຽນວົງຈອນນີ້, Helm ໄດ້ຖືກປະດິດ.

Helm ແມ່ນຫຍັງ

ປະການທໍາອິດ, Helm - ຜູ້ຈັດການຊຸດ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານຊອກຫາແລະຕິດຕັ້ງໂຄງການທີ່ທ່ານຕ້ອງການ. ການຕິດຕັ້ງ, ສໍາລັບການຍົກຕົວຢ່າງ, MongoDB, ທ່ານບໍ່ຈໍາເປັນຕ້ອງໄປຫາເວັບໄຊທ໌ທາງການແລະດາວນ໌ໂຫລດ binaries, ພຽງແຕ່ດໍາເນີນການຄໍາສັ່ງ. helm install stable/mongodb.

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

ອັນທີສາມ, Helm - ແມ່​ບົດ​ການ​ນໍາ​ໃຊ້​. ກັບມັນທ່ານສາມາດຕິດຕັ້ງ, rollback ແລະປັບປຸງຄໍາຮ້ອງສະຫມັກ. ລອງຄິດເບິ່ງວິທີເຮັດອັນນີ້.

ວິທີການໃຊ້ Helm ເພື່ອນຳໃຊ້ແອັບພລິເຄຊັນຂອງທ່ານເອງ

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

• ຊີ້ບອກໂຟນເດີທີ່ມີແມ່ແບບ;
• pack ຮວບຮວມເຂົ້າໄປໃນ .tar ແລະຊີ້ໄປຫາມັນ;
• ເອົາແມ່ແບບຢູ່ໃນບ່ອນເກັບມ້ຽນຫ່າງໄກສອກຫຼີກແລະເພີ່ມການເຊື່ອມຕໍ່ກັບບ່ອນເກັບມ້ຽນໃນ Helm client.

ນອກນັ້ນທ່ານຍັງຕ້ອງການໄຟລ໌ທີ່ມີຄ່າ - values.yaml . ຂໍ້ມູນຈາກບ່ອນນັ້ນຈະຖືກໃສ່ເຂົ້າໄປໃນແມ່ແບບ. ໃຫ້ສ້າງມັນຄືກັນ.

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

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

ມັນເຮັດວຽກແນວໃດ

ດໍາເນີນການຄໍາສັ່ງ helm install. ໃຫ້ຊີ້ບອກຊື່ຂອງການປ່ອຍແອັບພລິເຄຊັນແລະໃຫ້ເສັ້ນທາງໄປຫາ values.yaml. ໃນຕອນທ້າຍພວກເຮົາຈະຊີ້ບອກບ່ອນເກັບມ້ຽນທີ່ຕາຕະລາງຕັ້ງຢູ່ແລະຊື່ຂອງຕາຕະລາງ. ໃນຕົວຢ່າງ, ເຫຼົ່ານີ້ແມ່ນ "lmru" ແລະ "ຕາຕະລາງທີ່ດີທີ່ສຸດ", ຕາມລໍາດັບ.

helm install --name bestapp --values values.yaml lmru/bestchart

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

helm upgrade --install bestapp --values values.yaml lmru/bestchart

ຄວາມຜິດພາດຂອງການນຳໃຊ້ແອັບພລິເຄຊັນເວີຊັນໃໝ່ກັບ Helm

ໃນຈຸດນີ້ໃນເລື່ອງນີ້, ຂ້ອຍກໍາລັງຫຼີ້ນ Who Wants to Be a Millionaire ກັບຜູ້ຊົມ, ແລະພວກເຮົາກໍາລັງຊອກຫາວິທີທີ່ຈະໄດ້ຮັບ Helm ເພື່ອປັບປຸງເວີຊັນຂອງແອັບຯ. ເບິ່ງວິດີໂອ.

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

ວິທີການ 1. ຢ່າປ່ຽນແປງຂໍ້ມູນນັບຕັ້ງແຕ່ການເປີດຕົວຄັ້ງສຸດທ້າຍ

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

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

ວິທີ 2. ອັບເດດ LABEL ໃນຮູບ

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

ວິທີທີ 3: ໃຊ້ກະແຈ --force

ໃຫ້ຫັນໄປຫາຄູ່ມືແລະຊອກຫາກະແຈທີ່ຕ້ອງການ. ທີ່ສໍາຄັນເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ສຸດ --force. ເຖິງວ່າຈະມີຊື່ທີ່ຊັດເຈນ, ພຶດຕິກໍາແມ່ນແຕກຕ່າງຈາກທີ່ຄາດໄວ້. ແທນທີ່ຈະບັງຄັບໃຫ້ອັບເດດແອັບພລິເຄຊັນ, ຈຸດປະສົງທີ່ແທ້ຈິງຂອງມັນແມ່ນເພື່ອຟື້ນຟູການປ່ອຍທີ່ຢູ່ໃນສະຖານະ FAILED. ຖ້າທ່ານບໍ່ໃຊ້ລະຫັດນີ້, ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດຄໍາສັ່ງຕາມລໍາດັບ helm delete && helm install --replace. ຂໍແນະນຳໃຫ້ໃຊ້ກະແຈແທນ --force, ເຊິ່ງເຮັດໃຫ້ການປະຕິບັດຕາມລໍາດັບຂອງຄໍາສັ່ງເຫຼົ່ານີ້ອັດຕະໂນມັດ. ຂໍ້ມູນເພີ່ມເຕີມຢູ່ໃນນີ້ ດຶງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​. ເພື່ອບອກໃຫ້ Helm ອັບເດດເວີຊັນແອັບພລິເຄຊັນ, ແຕ່ຫນ້າເສຍດາຍ, ລະຫັດນີ້ຈະບໍ່ເຮັດວຽກ.

ວິທີການ 4. ປ່ຽນປ້າຍຊື່ໂດຍກົງໃນ Kubernetes

ການປັບປຸງປ້າຍຊື່ໂດຍກົງໃນກຸ່ມໂດຍໃຊ້ຄໍາສັ່ງ kubectl edit - ຄວາມຄິດທີ່ບໍ່ດີ. ການກະທຳນີ້ຈະນຳໄປສູ່ຄວາມບໍ່ສອດຄ່ອງຂອງຂໍ້ມູນລະຫວ່າງແອັບພລິເຄຊັນທີ່ກຳລັງແລ່ນ ແລະອັນທີ່ສົ່ງມາເພື່ອນຳໃຊ້ໃນເບື້ອງຕົ້ນ. ພຶດຕິກໍາຂອງ Helm ໃນລະຫວ່າງການຕິດຕັ້ງໃນກໍລະນີນີ້ແຕກຕ່າງຈາກສະບັບຂອງມັນ: Helm 2 ຈະບໍ່ເຮັດຫຍັງ, ແລະ Helm 3 ຈະນໍາໃຊ້ເວີຊັນໃຫມ່ຂອງແອັບພລິເຄຊັນ. ເພື່ອເຂົ້າໃຈວ່າເປັນຫຍັງ, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າ Helm ເຮັດວຽກແນວໃດ.

Helm ເຮັດວຽກແນວໃດ?

ເພື່ອກໍານົດວ່າແອັບພລິເຄຊັນໃດນຶ່ງມີການປ່ຽນແປງນັບຕັ້ງແຕ່ການເປີດຕົວຄັ້ງສຸດທ້າຍຂອງມັນ, Helm ສາມາດໃຊ້:

• ແລ່ນແອັບພລິເຄຊັນໃນ Kubernetes;
• values.yaml ໃໝ່ ແລະຕາຕະລາງປະຈຸບັນ;
• ຂໍ້ມູນການປ່ອຍຕົວພາຍໃນຂອງ Helm.

ສໍາລັບສິ່ງທີ່ຢາກຮູ້ຢາກເຫັນຫຼາຍ: Helm ເກັບຮັກສາຂໍ້ມູນພາຍໃນກ່ຽວກັບການປ່ອຍອອກມາຢູ່ໃສ?ໂດຍ​ການ​ປະ​ຕິ​ບັດ​ຄໍາ​ສັ່ງ​ helm history, ພວກເຮົາຈະໄດ້ຮັບຂໍ້ມູນທັງໝົດກ່ຽວກັບລຸ້ນທີ່ຕິດຕັ້ງໂດຍໃຊ້ Helm.

ຍັງມີຂໍ້ມູນລະອຽດກ່ຽວກັບແມ່ແບບ ແລະຄ່າທີ່ສົ່ງມາ. ພວກ​ເຮົາ​ສາ​ມາດ​ຮ້ອງ​ຂໍ​ມັນ​:

ໃນ Helm ຮຸ່ນທີສອງ, ຂໍ້ມູນນີ້ແມ່ນຢູ່ໃນ namespace ດຽວກັນທີ່ Tiller ກໍາລັງເຮັດວຽກ (ລະບົບ kube ໂດຍຄ່າເລີ່ມຕົ້ນ), ໃນ ConfigMap, ຫມາຍດ້ວຍປ້າຍຊື່ "OWNER = TILLER":

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

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

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

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

ວິທີ 5. ໃຊ້ປຸ່ມສະວິດ --recreate-pods

ດ້ວຍກະແຈ --recreate-pods ທ່ານ​ສາ​ມາດ​ບັນ​ລຸ​ສິ່ງ​ທີ່​ທ່ານ​ໄດ້​ວາງ​ແຜນ​ໄວ້​ໃນ​ເບື້ອງ​ຕົ້ນ​ເພື່ອ​ບັນ​ລຸ​ໄດ້​ທີ່​ສໍາ​ຄັນ​ --force. ກ່ອງບັນຈຸຈະປິດເປີດໃໝ່ ແລະອີງຕາມນະໂຍບາຍຂອງ imagePullPolicy: ນະໂຍບາຍສະເໝີສຳລັບແທັກຫຼ້າສຸດ (ເພີ່ມເຕີມກ່ຽວກັບສິ່ງນີ້ໃນສ່ວນທ້າຍຂ້າງເທິງ), Kubernetes ຈະດາວໂຫລດ ແລະເປີດຕົວເວີຊັນໃໝ່ຂອງຮູບ. ອັນນີ້ຈະບໍ່ຖືກເຮັດໃນວິທີທີ່ດີທີ່ສຸດ: ໂດຍບໍ່ຄໍານຶງເຖິງປະເພດຂອງການນໍາໄປໃຊ້ຍຸດທະສາດ, ມັນຈະປິດການໃຊ້ຄໍາຮ້ອງສະຫມັກເກົ່າທັງຫມົດຢ່າງກະທັນຫັນແລະເລີ່ມຕົ້ນການເປີດຕົວໃຫມ່. ໃນລະຫວ່າງການເລີ່ມຕົ້ນໃຫມ່, ລະບົບຈະບໍ່ເຮັດວຽກ, ຜູ້ໃຊ້ຈະທົນທຸກ.

ໃນ Kubernetes ຕົວຂອງມັນເອງ, ບັນຫາທີ່ຄ້າຍຄືກັນຍັງມີຢູ່ເປັນເວລາດົນນານ. ແລະໃນປັດຈຸບັນ, 4 ປີຫຼັງຈາກການເປີດ ບັນຫາ, ບັນຫາໄດ້ຖືກແກ້ໄຂແລ້ວ, ແລະເລີ່ມຕົ້ນດ້ວຍ Kubernetes ຮຸ່ນ 1.15, ຄວາມສາມາດໃນການມ້ວນ-restart pods ປະກົດຂຶ້ນ.

Helm ພຽງແຕ່ປິດທຸກແອັບພລິເຄຊັນ ແລະເປີດກ່ອງບັນຈຸໃໝ່ທີ່ຢູ່ໃກ້ຄຽງ. ທ່ານ​ບໍ່​ສາ​ມາດ​ເຮັດ​ສິ່ງ​ນີ້​ໃນ​ການ​ຜະ​ລິດ​, ດັ່ງ​ນັ້ນ​ເປັນ​ການ​ບໍ່​ເຮັດ​ໃຫ້​ເກີດ​ການ​ຢຸດ​ເຊົາ​ການ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​. ນີ້ແມ່ນຈໍາເປັນພຽງແຕ່ສໍາລັບຄວາມຕ້ອງການພັດທະນາແລະສາມາດປະຕິບັດໄດ້ພຽງແຕ່ໃນສະພາບແວດລ້ອມເວທີ.

ວິທີການອັບເດດເວີຊັນແອັບພລິເຄຊັນໂດຍໃຊ້ Helm?

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

1. ຄ່າສຸ່ມ ການ​ນໍາ​ໃຊ້​ຫນ້າ​ທີ່​ມາດ​ຕະ​ຖານ - {{ randAlphaNum 6 }}.
   ມີການເຕືອນໄພ: ຫຼັງຈາກການປະຕິບັດແຕ່ລະອັນໂດຍໃຊ້ຕາຕະລາງທີ່ມີຕົວແປດັ່ງກ່າວ, ຄ່າຂອງຄໍາບັນຍາຍຈະເປັນເອກະລັກ, ແລະ Helm ຈະສົມມຸດວ່າມີການປ່ຽນແປງ. ມັນ turns ໃຫ້ ເຫັນ ວ່າ ພວກ ເຮົາ ສະ ເຫມີ restart ຄໍາ ຮ້ອງ ສະ ຫມັກ, ເຖິງ ແມ່ນ ວ່າ ພວກ ເຮົາ ບໍ່ ໄດ້ ປ່ຽນ ແປງ ສະ ບັບ ຂອງ ຕົນ. ນີ້ບໍ່ສໍາຄັນ, ເພາະວ່າຈະບໍ່ມີເວລາຢຸດ, ແຕ່ມັນຍັງບໍ່ພໍໃຈ.
2. ວາງປັດຈຸບັນ ວັນທີແລະເວລາ - {{ .Release.Date }}.
   ຕົວແປແມ່ນຄ້າຍຄືກັນກັບຄ່າສຸ່ມທີ່ມີຕົວແປທີ່ເປັນເອກະລັກຖາວອນ.
3. ວິທີທີ່ຖືກຕ້ອງກວ່າແມ່ນການໃຊ້ ເຊັກsums. ນີ້ແມ່ນ SHA ຂອງຮູບພາບຫຼື SHA ຂອງຄໍາຫມັ້ນສັນຍາສຸດທ້າຍໃນ git - {{ .Values.sha }}.
   ພວກເຂົາຈະຕ້ອງໄດ້ຮັບການນັບແລະຖືກສົ່ງໄປຫາລູກຄ້າ Helm ໃນດ້ານການໂທ, ຕົວຢ່າງໃນ Jenkins. ຖ້າຄໍາຮ້ອງສະຫມັກມີການປ່ຽນແປງ, ຫຼັງຈາກນັ້ນ checksum ຈະມີການປ່ຽນແປງ. ດັ່ງນັ້ນ, Helm ຈະອັບເດດແອັບພລິເຄຊັນເມື່ອຕ້ອງການເທົ່ານັ້ນ.

ໃຫ້ສະຫຼຸບຄວາມພະຍາຍາມຂອງພວກເຮົາ

• Helm ເຮັດການປ່ຽນແປງໃນທາງທີ່ຮຸກຮານຫນ້ອຍທີ່ສຸດ, ດັ່ງນັ້ນການປ່ຽນແປງໃດໆໃນລະດັບຮູບພາບຂອງແອັບພລິເຄຊັນໃນ Docker Registry ຈະບໍ່ສົ່ງຜົນໃຫ້ການປັບປຸງ: ບໍ່ມີຫຍັງຈະເກີດຂຶ້ນຫຼັງຈາກຄໍາສັ່ງຖືກປະຕິບັດ.
• Key --force ໃຊ້ເພື່ອຟື້ນຟູການປ່ອຍທີ່ມີບັນຫາ ແລະບໍ່ກ່ຽວຂ້ອງກັບການອັບເດດທີ່ຖືກບັງຄັບ.
• Key --recreate-pods ຈະປັບປຸງແອັບພລິເຄຊັນຢ່າງບັງຄັບ, ແຕ່ຈະເຮັດມັນໃນທາງທີ່ໂຫດຮ້າຍ: ມັນຈະປິດການບັນຈຸທັງໝົດຢ່າງກະທັນຫັນ. ຜູ້ໃຊ້ຈະທົນທຸກຈາກນີ້; ທ່ານບໍ່ຄວນເຮັດໃນການຜະລິດ.
• ເຮັດການປ່ຽນແປງໂດຍກົງກັບກຸ່ມ Kubernetes ໂດຍໃຊ້ຄໍາສັ່ງ kubectl edit ຢ່າ: ພວກເຮົາຈະທໍາລາຍຄວາມສອດຄ່ອງ, ແລະພຶດຕິກໍາຈະແຕກຕ່າງກັນໄປຕາມສະບັບຂອງ Helm.
• ດ້ວຍການເປີດຕົວຂອງ Helm ຮຸ່ນໃຫມ່, ມີຫຼາຍ nuances ໄດ້ປາກົດ. ບັນຫາຢູ່ໃນບ່ອນເກັບມ້ຽນ Helm ຖືກອະທິບາຍເປັນພາສາທີ່ຊັດເຈນ, ພວກມັນຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈລາຍລະອຽດ.
• ການເພີ່ມຄໍາບັນຍາຍທີ່ສາມາດແກ້ໄຂໄດ້ໃສ່ຕາຕະລາງຈະເຮັດໃຫ້ມີຄວາມຍືດຫຍຸ່ນຫຼາຍຂຶ້ນ. ນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດມ້ວນຄໍາຮ້ອງສະຫມັກໄດ້ຢ່າງຖືກຕ້ອງ, ໂດຍບໍ່ມີການ downtime.

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

ລິ້ງທີ່ກ່ຽວຂ້ອງອື່ນໆ:

1. ຄົນຮູ້ຈັກກັບ Helm 3
2. ເວັບໄຊທ໌ທາງການຂອງ Helm
3. ຄັງເກັບ Helm ໃນ GitHub
4. 25 ເຄື່ອງມື Kubernetes ທີ່ເປັນປະໂຫຍດ: ການນຳໃຊ້ ແລະການຈັດການ

ບົດລາຍງານນີ້ໄດ້ຖືກນໍາສະເຫນີຄັ້ງທໍາອິດຢູ່ທີ່ @Kubernetes ກອງປະຊຸມ ໂດຍ Mail.ru Cloud Solutions. ເບິ່ງ видео ການສະແດງອື່ນໆ ແລະສະໝັກຮັບການປະກາດເຫດການໃນ Telegram ປະມານ Kubernetes ຢູ່ Mail.ru Group.

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