ມັນງ່າຍ ແລະສະດວກໃນການກະກຽມກຸ່ມ Kubernetes ບໍ? ປະກາດ addon-operator

ຫຼັງຈາກ shell-operator ພວກເຮົາສະເຫນີອ້າຍຂອງລາວ - addon-operator. ນີ້ແມ່ນໂຄງການ Open Source ທີ່ຖືກນໍາໃຊ້ເພື່ອຕິດຕັ້ງອົງປະກອບຂອງລະບົບເຂົ້າໄປໃນກຸ່ມ Kubernetes, ເຊິ່ງສາມາດເອີ້ນວ່າ add-ons.

ເປັນຫຍັງການເພີ່ມເຕີມໃດໆ?

ມັນບໍ່ເປັນຄວາມລັບທີ່ Kubernetes ບໍ່ແມ່ນຜະລິດຕະພັນທີ່ພ້ອມແລ້ວ, ແລະເພື່ອສ້າງກຸ່ມ "ຜູ້ໃຫຍ່" ທ່ານຈະຕ້ອງການເພີ່ມເຕີມຕ່າງໆ. Addon-operator ຈະຊ່ວຍໃຫ້ທ່ານຕິດຕັ້ງ, configure ແລະຮັກສາ add-ons ເຫຼົ່ານີ້ໃຫ້ທັນສະໄຫມ.

ຄວາມຕ້ອງການສໍາລັບອົງປະກອບເພີ່ມເຕີມໃນກຸ່ມໄດ້ຖືກເປີດເຜີຍໃນ ລາຍງານ ເພື່ອນຮ່ວມງານ ດຣີຊາ. ໃນສັ້ນ, ສະຖານະການກັບ Kubernetes ໃນເວລານີ້ແມ່ນສໍາລັບການຕິດຕັ້ງ "ຫຼິ້ນຮອບ" ງ່າຍໆທີ່ທ່ານສາມາດໄດ້ຮັບດ້ວຍອົງປະກອບອອກຈາກກ່ອງ, ສໍາລັບນັກພັດທະນາແລະການທົດສອບທ່ານສາມາດເພີ່ມ Ingress, ແຕ່ສໍາລັບການຕິດຕັ້ງຢ່າງເຕັມທີ່, ກ່ຽວກັບສິ່ງທີ່. ທ່ານສາມາດເວົ້າວ່າ "ການຜະລິດຂອງທ່ານແມ່ນກຽມພ້ອມ", ທ່ານຈໍາເປັນຕ້ອງເພີ່ມຕື່ມດ້ວຍ add-ons ທີ່ແຕກຕ່າງກັນຫຼາຍສິບ: ບາງສິ່ງບາງຢ່າງສໍາລັບການຕິດຕາມກວດກາ, ບາງສິ່ງບາງຢ່າງສໍາລັບການບັນທຶກ, ຢ່າລືມ ingress ແລະ cert-manage, ເລືອກກຸ່ມຂອງ nodes, ເພີ່ມນະໂຍບາຍເຄືອຂ່າຍ, ລະດູການ. ດ້ວຍການຕັ້ງຄ່າ sysctl ແລະ pod autoscaler...

ສິ່ງທີ່ສະເພາະຂອງການເຮັດວຽກກັບພວກເຂົາ?

ໃນຖານະເປັນການປະຕິບັດສະແດງໃຫ້ເຫັນ, ເລື່ອງບໍ່ຈໍາກັດພຽງແຕ່ການຕິດຕັ້ງຫນຶ່ງ. ເພື່ອເຮັດວຽກສະດວກສະບາຍກັບ cluster, add-ons ຈະຕ້ອງໄດ້ຮັບການປັບປຸງ, ປິດການໃຊ້ງານ (ເອົາອອກຈາກ cluster), ແລະທ່ານຕ້ອງການທົດສອບບາງຢ່າງກ່ອນທີ່ຈະຕິດຕັ້ງພວກມັນຢູ່ໃນກຸ່ມການຜະລິດ.

ດັ່ງນັ້ນ, ບາງທີ Ansible ຈະພຽງພໍຢູ່ທີ່ນີ້? ບາງທີ. ແຕ່ ໂດຍທົ່ວໄປ, add-ons ເຕັມຮູບແບບບໍ່ໄດ້ດໍາລົງຊີວິດໂດຍບໍ່ມີການຕັ້ງຄ່າ. ການຕັ້ງຄ່າເຫຼົ່ານີ້ອາດຈະແຕກຕ່າງກັນໂດຍຂຶ້ນກັບຕົວແປຂອງກຸ່ມ (aws, gce, azure, bare-metal, do, ...). ການຕັ້ງຄ່າບາງຢ່າງບໍ່ສາມາດລະບຸໄວ້ລ່ວງໜ້າໄດ້; ພວກມັນຈະຕ້ອງໄດ້ມາຈາກກຸ່ມ. ແລະກຸ່ມບໍ່ຄົງທີ່: ສໍາລັບການຕັ້ງຄ່າບາງຢ່າງທ່ານຈະຕ້ອງຕິດຕາມການປ່ຽນແປງ. ແລະໃນທີ່ນີ້ Ansible ຫາຍໄປແລ້ວ: ທ່ານຕ້ອງການໂຄງການທີ່ອາໄສຢູ່ໃນກຸ່ມ, i.e. ຜູ້ໃຫ້ບໍລິການ Kubernetes.

ຜູ້ທີ່ພະຍາຍາມມັນຢູ່ໃນບ່ອນເຮັດວຽກ shell-operator, ພວກເຂົາເຈົ້າຈະເວົ້າວ່າວຽກງານຂອງການຕິດຕັ້ງແລະການປັບປຸງ add-ons ແລະການຕັ້ງຄ່າການຕິດຕາມສາມາດໄດ້ຮັບການແກ້ໄຂຢ່າງສົມບູນໂດຍໃຊ້. hooks ສໍາລັບ shell-operator. ທ່ານສາມາດຂຽນສະຄິບທີ່ຈະເຮັດຕາມເງື່ອນໄຂ kubectl apply ແລະຕິດຕາມ, ສໍາລັບການຍົກຕົວຢ່າງ, ConfigMap, ບ່ອນທີ່ການຕັ້ງຄ່າຈະຖືກເກັບໄວ້. ນີ້ແມ່ນປະມານສິ່ງທີ່ຖືກປະຕິບັດໃນ addon-operator.

ນີ້ຈັດລະບຽບແນວໃດໃນ addon-operator?

ເມື່ອສ້າງການແກ້ໄຂໃຫມ່, ພວກເຮົາດໍາເນີນການຈາກຫຼັກການດັ່ງຕໍ່ໄປນີ້:

• ຕົວຕິດຕັ້ງ add-on ຕ້ອງຮອງຮັບ ການສ້າງແບບຈໍາລອງແລະການຕັ້ງຄ່າການປະກາດ. ພວກເຮົາບໍ່ໄດ້ສ້າງສະຄິບ magic ທີ່ຕິດຕັ້ງ add-ons. Addon-operator ໃຊ້ Helm ເພື່ອຕິດຕັ້ງ addons. ເພື່ອຕິດຕັ້ງ, ທ່ານຈໍາເປັນຕ້ອງສ້າງຕາຕະລາງແລະເລືອກຄ່າທີ່ຈະໃຊ້ສໍາລັບການຕັ້ງຄ່າ.
• ການຕັ້ງຄ່າສາມາດເປັນ ສ້າງໃນການຕິດຕັ້ງ, ພວກ​ເຂົາ​ສາ​ມາດ ໄດ້ຮັບຈາກກຸ່ມ, ຫຼື ໄດ້​ຮັບ​ການ​ປັບ​ປຸງ​, ການຕິດຕາມຊັບພະຍາກອນຂອງກຸ່ມ. ການດໍາເນີນງານເຫຼົ່ານີ້ສາມາດຖືກປະຕິບັດໂດຍໃຊ້ hooks.
• ການຕັ້ງຄ່າສາມາດເປັນ ເກັບຢູ່ໃນກຸ່ມ. ເພື່ອເກັບຮັກສາການຕັ້ງຄ່າໃນກຸ່ມ, ConfigMap/addon-operator ຖືກສ້າງຂຶ້ນແລະ Addon-operator ຕິດຕາມກວດກາການປ່ຽນແປງກັບ ConfigMap ນີ້. Addon-operator ໃຫ້ hooks ເຂົ້າເຖິງການຕັ້ງຄ່າໂດຍໃຊ້ສົນທິສັນຍາງ່າຍດາຍ.
• ການເພີ່ມເຕີມແມ່ນຂຶ້ນກັບການຕັ້ງຄ່າ. ຖ້າຫາກວ່າການຕັ້ງຄ່າມີການປ່ຽນແປງ, ຫຼັງຈາກນັ້ນ Addon-operator rolls ອອກຕາຕະລາງ Helm ທີ່ມີຄ່າໃຫມ່. ພວກເຮົາເອີ້ນວ່າການປະສົມປະສານຂອງຕາຕະລາງ Helm, ມູນຄ່າສໍາລັບມັນແລະ hooks ໂມດູນ (ເບິ່ງຂ້າງລຸ່ມນີ້ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ).
• ການສະແດງລະຄອນ. ບໍ່ມີສະຄຣິບປ່ອຍ magic. ກົນໄກການປັບປຸງແມ່ນຄ້າຍຄືກັນກັບຄໍາຮ້ອງສະຫມັກປົກກະຕິ - ລວບລວມ add-ons ແລະ addon-operators ເຂົ້າໄປໃນຮູບພາບ, tag ໃຫ້ເຂົາເຈົ້າແລະມ້ວນອອກ.
• ການຄວບຄຸມຜົນໄດ້ຮັບ. Addon-operator ສາມາດສະຫນອງ metrics ສໍາລັບ Prometheus.

padding ໃນ addon-operator ແມ່ນຫຍັງ?

ການເພີ່ມເຕີມສາມາດພິຈາລະນາສິ່ງໃດແດ່ທີ່ເພີ່ມຫນ້າທີ່ໃຫມ່ໃຫ້ກັບກຸ່ມ. ຕົວຢ່າງ, ການຕິດຕັ້ງ Ingress ເປັນຕົວຢ່າງທີ່ດີຂອງ add-on. ນີ້ສາມາດເປັນຕົວປະຕິບັດການຫຼືຕົວຄວບຄຸມທີ່ມີ CRD ຂອງຕົນເອງ: prometheus-operator, cert-manager, kube-controller-manager, ແລະອື່ນໆ. ຫຼືບາງສິ່ງບາງຢ່າງຂະຫນາດນ້ອຍ, ແຕ່ງ່າຍຕໍ່ການໃຊ້ - ຕົວຢ່າງ, ເຄື່ອງສໍາເນົາລັບ, ເຊິ່ງຄັດລອກຄວາມລັບຂອງທະບຽນໄປຫາ namespaces ໃຫມ່, ຫຼື sysctl tuner, ເຊິ່ງກໍາຫນົດຄ່າພາລາມິເຕີ sysctl ໃນ nodes ໃຫມ່.

ເພື່ອປະຕິບັດ add-ons, Addon-operator ໃຫ້ແນວຄວາມຄິດຫຼາຍຢ່າງ:

• ຕາຕະລາງຫມວກກັນກະທົບ ໃຊ້ໃນການຕິດຕັ້ງຊອບແວຕ່າງໆເຂົ້າໄປໃນກຸ່ມ - ຕົວຢ່າງເຊັ່ນ Prometheus, Grafana, nginx-ingress. ຖ້າອົງປະກອບທີ່ຕ້ອງການມີຕາຕະລາງ Helm, ຫຼັງຈາກນັ້ນການຕິດຕັ້ງມັນໂດຍໃຊ້ Addon-operator ຈະງ່າຍດາຍຫຼາຍ.
• ການເກັບຮັກສາຄຸນຄ່າ. ຕາຕະລາງ Helm ປົກກະຕິແລ້ວມີຫຼາຍການຕັ້ງຄ່າທີ່ແຕກຕ່າງກັນທີ່ສາມາດປ່ຽນແປງໄດ້ຕະຫຼອດເວລາ. Addon-operator ສະຫນັບສະຫນູນການເກັບຮັກສາການຕັ້ງຄ່າເຫຼົ່ານີ້ແລະສາມາດຕິດຕາມການປ່ຽນແປງຂອງພວກເຂົາເພື່ອຕິດຕັ້ງຕາຕະລາງ Helm ທີ່ມີຄ່າໃຫມ່.
• Hooks ແມ່ນໄຟລ໌ທີ່ສາມາດປະຕິບັດໄດ້ທີ່ Addon-operator ດໍາເນີນການກ່ຽວກັບເຫດການແລະທີ່ເຂົ້າເຖິງຄ່າເກັບຮັກສາ. hook ສາມາດຕິດຕາມການປ່ຽນແປງໃນ cluster ແລະປັບປຸງຄ່າໃນຮ້ານ values. ເຫຼົ່ານັ້ນ. ການນໍາໃຊ້ hooks, ທ່ານສາມາດເຮັດໃຫ້ການຄົ້ນພົບເພື່ອເກັບກໍາມູນຄ່າຈາກ cluster ໃນຕອນເລີ່ມຕົ້ນຫຼືຕາມຕາຕະລາງ, ຫຼືທ່ານສາມາດເຮັດການຄົ້ນພົບຢ່າງຕໍ່ເນື່ອງ, ເກັບກໍາມູນຄ່າຈາກ cluster ໂດຍອີງໃສ່ການປ່ຽນແປງໃນ cluster.
• ໂມດູນ ແມ່ນການປະສົມປະສານຂອງຕາຕະລາງ Helm, ຄັງເກັບຄ່າແລະ hooks. ໂມດູນສາມາດຖືກເປີດໃຊ້ງານຫຼືປິດການໃຊ້ງານ. ການປິດການນຳໃຊ້ໂມດູນໝາຍເຖິງການລຶບການອອກແຜນວາດ Helm ທັງໝົດ. ໂມດູນສາມາດເປີດໃຊ້ຕົວມັນເອງແບບໄດນາມິກ, ຕົວຢ່າງ, ຖ້າທຸກໂມດູນທີ່ມັນຕ້ອງການຖືກເປີດໃຊ້ງານຫຼືຖ້າການຄົ້ນພົບໄດ້ພົບເຫັນຕົວກໍານົດການທີ່ຈໍາເປັນໃນ hooks - ນີ້ແມ່ນເຮັດໂດຍໃຊ້ສະຄິບທີ່ເປີດໃຊ້ຕົວຊ່ວຍ.
• hooks ໂລກ. ເຫຼົ່ານີ້ແມ່ນ hooks "ດ້ວຍຕົນເອງ", ພວກເຂົາບໍ່ໄດ້ລວມຢູ່ໃນໂມດູນແລະມີການເຂົ້າເຖິງຮ້ານມູນຄ່າທົ່ວໂລກ, ມູນຄ່າທີ່ມີຢູ່ໃນທຸກ hooks ໃນໂມດູນ.

ພາກສ່ວນເຫຼົ່ານີ້ເຮັດວຽກຮ່ວມກັນແນວໃດ? ຂໍໃຫ້ເບິ່ງຮູບພາບຈາກເອກະສານ:

ມີສອງສະຖານະການເຮັດວຽກ:

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

ການເພີ່ມເຕີມສາມາດຖືກປະຕິບັດເປັນ hook ດຽວ, ຫຼືເປັນຕາຕະລາງ Helm ຫນຶ່ງ, ຫຼື ເຖິງແມ່ນວ່າເປັນໂມດູນທີ່ຂຶ້ນກັບຫຼາຍ - ນີ້ແມ່ນຂຶ້ນກັບຄວາມສັບສົນຂອງອົງປະກອບທີ່ຖືກຕິດຕັ້ງຢູ່ໃນກຸ່ມແລະໃນລະດັບທີ່ຕ້ອງການຂອງຄວາມຍືດຫຍຸ່ນໃນການຕັ້ງຄ່າ. ສໍາລັບຕົວຢ່າງ, ໃນ repository (/ຕົວຢ່າງ) ມີ sysctl-tuner add-on, ເຊິ່ງຖືກປະຕິບັດທັງເປັນໂມດູນແບບງ່າຍດາຍທີ່ມີ hook ແລະ Helm chart, ແລະການນໍາໃຊ້ຄ່າເກັບຮັກສາ, ເຊິ່ງເຮັດໃຫ້ມັນສາມາດເພີ່ມການຕັ້ງຄ່າໂດຍການດັດແກ້ ConfigMap.

ການຈັດສົ່ງການປັບປຸງ

ສອງສາມຄໍາກ່ຽວກັບການຈັດຕັ້ງການປັບປຸງອົງປະກອບທີ່ Addon-operator ຕິດຕັ້ງ.

ເພື່ອດໍາເນີນການ Addon-operator ໃນກຸ່ມ, ທ່ານຕ້ອງການ ສ້າງຮູບພາບທີ່ມີການເພີ່ມເຕີມ ໃນຮູບແບບຂອງ hook ແລະ Helm ໄຟລ໌ຕາຕະລາງ, ເພີ່ມໄຟລ໌ຄູ່ addon-operator ແລະ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​ສໍາ​ລັບ​ການ hooks​: bash, kubectl, jq, python ແລະອື່ນໆ ຫຼັງຈາກນັ້ນ, ຮູບພາບນີ້ສາມາດຖືກ rolled ອອກໄປຫາກຸ່ມເປັນຄໍາຮ້ອງສະຫມັກປົກກະຕິ, ແລະສ່ວນຫຼາຍອາດຈະທ່ານຕ້ອງການທີ່ຈະຈັດຫນຶ່ງຫຼືໂຄງການ tagging ອື່ນ. ຖ້າມີກຸ່ມຈໍານວນຫນ້ອຍ, ວິທີການດຽວກັນກັບຄໍາຮ້ອງສະຫມັກອາດຈະເຫມາະສົມ: ການປ່ອຍໃຫມ່, ຮຸ່ນໃຫມ່, ໄປຫາທຸກກຸ່ມແລະແກ້ໄຂຮູບພາບຂອງ Pods. ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີຂອງການເປີດຕົວເປັນຈໍານວນທີ່ສໍາຄັນຂອງກຸ່ມ, ແນວຄວາມຄິດຂອງການປັບປຸງຕົນເອງຈາກຊ່ອງທາງແມ່ນເຫມາະສົມສໍາລັບພວກເຮົາ.

ນີ້ແມ່ນວິທີທີ່ພວກເຮົາເຮັດມັນ:

• ຊ່ອງແມ່ນສໍາຄັນຕົວລະບຸທີ່ສາມາດຕັ້ງເປັນອັນໃດກໍໄດ້ (ຕົວຢ່າງ: dev/stage/ea/stable).
• ຊື່ຊ່ອງແມ່ນແທັກຮູບພາບ. ເມື່ອທ່ານຕ້ອງການອັບເດດຊ່ອງໃດໜຶ່ງ, ຮູບພາບໃໝ່ຈະຖືກປະກອບ ແລະຕິດແທັກດ້ວຍຊື່ຊ່ອງ.
• ເມື່ອຮູບພາບໃຫມ່ປາກົດຢູ່ໃນທະບຽນ, Addon-operator ແມ່ນ restarted ແລະເປີດຕົວດ້ວຍຮູບພາບໃຫມ່.

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

ຊ່ອງທາງຊ່ວຍເຫຼືອແລະ ໃນ​ການ​ທົດ​ສອບ​: ຖ້າມີກຸ່ມຊ່ວຍ, ທ່ານສາມາດຕັ້ງຄ່າມັນໃສ່ຊ່ອງໄດ້ stage ແລະມ້ວນການປັບປຸງໃສ່ມັນກ່ອນທີ່ຈະມ້ວນມັນອອກໄປຫາຊ່ອງທາງ ea и stable. ຖ້າມີກຸ່ມຢູ່ໃນຊ່ອງທາງ ea ມີ​ຄວາມ​ຜິດ​ພາດ​ເກີດ​ຂຶ້ນ​, ທ່ານ​ສາ​ມາດ​ສະ​ຫຼັບ​ມັນ​ stable, ໃນຂະນະທີ່ບັນຫາກັບກຸ່ມນີ້ກໍາລັງຖືກສືບສວນ. ຖ້າກຸ່ມຖືກເອົາອອກຈາກການສະຫນັບສະຫນູນຢ່າງຫ້າວຫັນ, ມັນຈະປ່ຽນໄປຫາຊ່ອງທາງ "frozen" ຂອງມັນ - ຕົວຢ່າງ, freeze-2019-03-20.

ນອກເຫນືອຈາກການອັບເດດ hooks ແລະ Helm charts, ທ່ານອາດຈະຕ້ອງການ ການປັບປຸງແລະອົງປະກອບພາກສ່ວນທີສາມ. ສໍາລັບຕົວຢ່າງ, ທ່ານໄດ້ສັງເກດເຫັນ bug ໃນ node-exporter ທີ່ມີເງື່ອນໄຂແລະແມ້ກະທັ້ງຊອກຫາວິທີການແກ້ໄຂມັນ. ຕໍ່ໄປ, ທ່ານໄດ້ເປີດ PR ແລະລໍຖ້າການປ່ອຍໃຫມ່ເພື່ອຜ່ານກຸ່ມທັງຫມົດແລະເພີ່ມສະບັບຂອງຮູບພາບ. ເພື່ອບໍ່ໃຫ້ລໍຖ້າຢ່າງບໍ່ມີກໍານົດ, ທ່ານສາມາດສ້າງ node-exporter ຂອງທ່ານແລະປ່ຽນໄປຫາມັນກ່ອນທີ່ຈະຍອມຮັບ PR.

ໂດຍທົ່ວໄປ, ນີ້ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີ Addon-operator, ແຕ່ດ້ວຍ Addon-operator ໂມດູນສໍາລັບການຕິດຕັ້ງ node-exporter ຈະເຫັນໄດ້ໃນບ່ອນເກັບມ້ຽນຫນຶ່ງ, Dockerfile ສໍາລັບການສ້າງຮູບພາບຂອງທ່ານສາມາດເກັບຮັກສາໄວ້ຢູ່ທີ່ນັ້ນ, ມັນຈະງ່າຍຂຶ້ນສໍາລັບຜູ້ເຂົ້າຮ່ວມທັງຫມົດໃນ. ຂະບວນການທີ່ຈະເຂົ້າໃຈສິ່ງທີ່ເກີດຂຶ້ນ ... ແລະຖ້າຫາກວ່າມີຫຼາຍກຸ່ມ, ຫຼັງຈາກນັ້ນມັນຈະກາຍເປັນງ່າຍຂຶ້ນທີ່ຈະທັງສອງທົດສອບ PR ຂອງທ່ານແລະເປີດຕົວສະບັບໃຫມ່!

ການຈັດຕັ້ງການປັບປຸງອົງປະກອບນີ້ເຮັດວຽກຢ່າງສໍາເລັດຜົນສໍາລັບພວກເຮົາ, ແຕ່ໂຄງການທີ່ເຫມາະສົມອື່ນໆສາມາດປະຕິບັດໄດ້ - ຫຼັງຈາກທີ່ທັງຫມົດ ໃນກໍລະນີນີ້ Addon-operator ແມ່ນໄຟລ໌ສອງງ່າຍດາຍ.

ສະຫລຸບ

ຫຼັກການທີ່ປະຕິບັດໃນ Addon-operator ອະນຸຍາດໃຫ້ທ່ານສ້າງຂະບວນການທີ່ມີຄວາມໂປ່ງໃສໃນການສ້າງ, ການທົດສອບ, ການຕິດຕັ້ງແລະການປັບປຸງ add-ons ໃນກຸ່ມ, ຄ້າຍຄືກັບຂະບວນການພັດທະນາຂອງຄໍາຮ້ອງສະຫມັກປົກກະຕິ.

Add-ons ສໍາລັບ Addon-operator ໃນຮູບແບບໂມດູນ (Helm chart + hooks) ສາມາດເປີດເຜີຍໃຫ້ສາທາລະນະໄດ້. ພວກເຮົາ, ບໍລິສັດ Flant, ວາງແຜນທີ່ຈະເຜີຍແຜ່ການພັດທະນາຂອງພວກເຮົາໃນຮູບແບບຂອງການເພີ່ມເຕີມດັ່ງກ່າວໃນຊ່ວງລຶະເບິ່ງຮ້ອນ. ເຂົ້າຮ່ວມການພັດທະນາໃນ GitHub (shell-operator, addon-operator), ພະຍາຍາມເຮັດໃຫ້ການເພີ່ມເຕີມຂອງທ່ານເອງໂດຍອີງໃສ່ ຕົວຢ່າງ и ເອກະສານ, ລໍຖ້າຂ່າວກ່ຽວກັບ Habre ແລະຂອງພວກເຮົາ ຊ່ອງ YouTube!

PS

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

• «ການ​ຂະ​ຫຍາຍ​ແລະ​ເສີມ Kubernetes (ການ​ທົບ​ທວນ​ຄືນ​ແລະ​ລາຍ​ງານ​ວິ​ດີ​ໂອ​)"
• «ແນະນຳ Shell-operator: ການສ້າງຕົວປະຕິບັດການສຳລັບ Kubernetes ງ່າຍຂຶ້ນ".

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