ການປຽບທຽບທີ່ເຫມາະສົມຂອງ Kubernetes ສະຫມັກ, ທົດແທນແລະ patch

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

ຖ້າຫາກວ່າ ຊອກຫາຢູ່ໃນ Google ຄໍາວ່າ "kubernetes ໃຊ້ vs ທົດແທນ" ແມ່ນຕັ້ງຢູ່ ຕອບກັບ StackOverflow, ເຊິ່ງບໍ່ຖືກຕ້ອງ. ເມື່ອຊອກຫາ "kubernetes ໃຊ້ vs patch" ການເຊື່ອມຕໍ່ທໍາອິດແມ່ນເອກະສານສໍາລັບ kubectl patch, ເຊິ່ງບໍ່ລວມເອົາການປຽບທຽບ apply и patch. ບົດຄວາມນີ້ຈະເບິ່ງທາງເລືອກທີ່ແຕກຕ່າງກັນ, ເຊັ່ນດຽວກັນກັບການນໍາໃຊ້ທີ່ເຫມາະສົມຂອງແຕ່ລະຄົນ.

ໃນລະຫວ່າງວົງຈອນຊີວິດຂອງຊັບພະຍາກອນ Kubernetes (ການບໍລິການ, ການນຳໃຊ້, ການປ້ອນຂໍ້ມູນ, ແລະອື່ນໆ), ບາງຄັ້ງທ່ານຕ້ອງປ່ຽນແປງ, ເພີ່ມ ຫຼືລຶບບາງຄຸນສົມບັດຂອງຊັບພະຍາກອນນີ້ອອກ. ຕົວຢ່າງ, ເພີ່ມບັນທຶກ, ເພີ່ມຫຼືຫຼຸດລົງຈໍານວນຂອງ replicas.

Kubernetes CLI

ຖ້າທ່ານເຮັດວຽກກັບກຸ່ມ Kubernetes ຜ່ານ CLI ແລ້ວ, ທ່ານຄຸ້ນເຄີຍກັບ apply и edit. ທີມງານ apply ອ່ານຂໍ້ມູນສະເພາະຂອງຊັບພະຍາກອນຈາກໄຟລ໌ ແລະສ້າງ "upsert" ໃຫ້ກັບກຸ່ມ Kubernetes, i.e. ສ້າງຊັບພະຍາກອນຖ້າມັນບໍ່ມີແລະປັບປຸງມັນຖ້າມັນມີຢູ່. ທີມງານ edit ອ່ານຊັບພະຍາກອນຜ່ານ API, ຫຼັງຈາກນັ້ນຂຽນຂໍ້ກໍານົດຂອງຊັບພະຍາກອນໄປຫາໄຟລ໌ທ້ອງຖິ່ນ, ເຊິ່ງຫຼັງຈາກນັ້ນຖືກເປີດຢູ່ໃນຕົວແກ້ໄຂຂໍ້ຄວາມ. ຫຼັງ​ຈາກ​ທີ່​ທ່ານ​ແກ້​ໄຂ​ແລະ​ບັນ​ທຶກ​ໄຟລ​໌​, kubectl ຈະສົ່ງການປ່ຽນແປງທີ່ເຮັດຄືນຜ່ານ API, ເຊິ່ງຈະນໍາໃຊ້ການປ່ຽນແປງເຫຼົ່ານີ້ກັບຊັບພະຍາກອນຢ່າງລະມັດລະວັງ.

ບໍ່ແມ່ນທຸກຄົນຮູ້ຄໍາສັ່ງ patch и replace. ທີມງານ patch ອະນຸຍາດໃຫ້ທ່ານປ່ຽນບາງສ່ວນຂອງຂໍ້ກໍານົດຂອງຊັບພະຍາກອນ, ສະຫນອງພຽງແຕ່ສ່ວນທີ່ມີການປ່ຽນແປງຢູ່ໃນເສັ້ນຄໍາສັ່ງ. ທີມງານ replace ເຮັດວຽກຄືກັນກັບ edit, ແຕ່ທຸກສິ່ງທຸກຢ່າງຕ້ອງເຮັດດ້ວຍຕົນເອງ: ທ່ານຈໍາເປັນຕ້ອງໄດ້ດາວໂຫລດສະບັບປະຈຸບັນຂອງຂໍ້ກໍານົດຊັບພະຍາກອນ, ສໍາລັບການຍົກຕົວຢ່າງ, ການນໍາໃຊ້. kubectl get -o yaml, ແກ້ໄຂມັນ, ຫຼັງຈາກນັ້ນໃຊ້ replace ເພື່ອປັບປຸງຊັບພະຍາກອນຕາມເງື່ອນໄຂທີ່ມີການປ່ຽນແປງ. ທີມງານ replace ຈະບໍ່ເຮັດວຽກຖ້າມີການປ່ຽນແປງໃດໆລະຫວ່າງການອ່ານແລະການປ່ຽນແທນຊັບພະຍາກອນ.

Kubernetes API

ທ່ານອາດຈະຄຸ້ນເຄີຍກັບວິທີການ CoreV1().Pods().Update(), replaceNamespacedService ຫຼື patch_namespaced_deployment, ຖ້າທ່ານເຮັດວຽກກັບກຸ່ມຜ່ານ ຫ້ອງສະຫມຸດລູກຄ້າສໍາລັບ Kubernetes API ໃຊ້ພາສາການຂຽນໂປລແກລມບາງ. ຫ້ອງສະຫມຸດຈັດການວິທີການເຫຼົ່ານີ້ຜ່ານການຮ້ອງຂໍ HTTP ໂດຍໃຊ້ວິທີການ PUT и PATCH... ຢູ່ໃນ update и replace ການນໍາໃຊ້ PUTແລະ patch, ບໍ່ວ່າມັນຈະເປັນເລື່ອງເລັກນ້ອຍ, ໃຊ້ PATCH.

ມັນຄວນຈະໄດ້ຮັບຍົກໃຫ້ເຫັນວ່າ kubectl ຍັງເຮັດວຽກກັບກຸ່ມຜ່ານ API. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, kubectlແມ່ນ wrapper ຢູ່ເທິງສຸດຂອງຫ້ອງສະຫມຸດລູກຄ້າສໍາລັບພາສາ Go, ເຊິ່ງສ່ວນໃຫຍ່ແມ່ນສະຫນອງຄວາມສາມາດໃນການສະຫນອງຄໍາສັ່ງຍ່ອຍໃນຮູບແບບທີ່ຫນາແຫນ້ນແລະສາມາດອ່ານໄດ້ນອກເຫນືອຈາກຄວາມສາມາດ API ມາດຕະຖານ. ຕົວຢ່າງ, ດັ່ງທີ່ທ່ານອາດຈະໄດ້ສັງເກດເຫັນແລ້ວ, ວິທີການ apply ບໍ່ໄດ້ກ່າວເຖິງຂ້າງເທິງໃນວັກທີ່ຜ່ານມາ. ໃນປັດຈຸບັນ (ເດືອນພຶດສະພາ 2020, ປະມານ ນັກແປ) ມີເຫດຜົນທັງຫມົດ kubectl apply, i.e. ການສ້າງຊັບພະຍາກອນທີ່ບໍ່ມີຢູ່ແລະການປັບປຸງທີ່ມີຢູ່ແລ້ວ, ເຮັດວຽກທັງຫມົດໃນດ້ານລະຫັດ kubectl. ຄວາມພະຍາຍາມກໍາລັງດໍາເນີນ ກ່ຽວກັບການຍົກຍ້າຍຕາມເຫດຜົນ apply ໄປຂ້າງ API, ແຕ່ມັນຍັງຢູ່ໃນເບຕ້າ. ຂ້ອຍຈະຂຽນລາຍລະອຽດເພີ່ມເຕີມຂ້າງລຸ່ມນີ້.

Patch ຕາມຄ່າເລີ່ມຕົ້ນ

ໃຊ້ດີທີ່ສຸດ patch, ຖ້າທ່ານຕ້ອງການປັບປຸງຊັບພະຍາກອນ. ນີ້ແມ່ນວິທີທີ່ຫ້ອງສະຫມຸດລູກຄ້າທັງສອງເຮັດວຽກຢູ່ເທິງ Kubernetes API ແລະ kubectl (ບໍ່ແປກໃຈ, ເນື່ອງຈາກວ່າມັນເປັນ wrapper ສໍາລັບຫ້ອງສະຫມຸດລູກຄ້າ, ປະມານ ນັກແປ).

ເຮັດວຽກຍຸດທະສາດ

ທີມງານທັງຫມົດ kubectl apply, edit и patch ໃຊ້ວິທີການ PATCH ໃນ HTTP ຮ້ອງຂໍໃຫ້ປັບປຸງຊັບພະຍາກອນທີ່ມີຢູ່ແລ້ວ. ຖ້າທ່ານເຈາະເຂົ້າໄປໃນການປະຕິບັດຄໍາສັ່ງໃນລາຍລະອຽດເພີ່ມເຕີມ, ຫຼັງຈາກນັ້ນທັງຫມົດຂອງພວກເຂົາໃຊ້ວິທີການ ການ​ເຊື່ອມ​ໂຍງ​ຍຸດ​ທະ​ສາດ ເພື່ອປັບປຸງຊັບພະຍາກອນ, ເຖິງແມ່ນວ່າຄໍາສັ່ງ patch ອາດຈະໃຊ້ວິທີການອື່ນໆ (ເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ຂ້າງລຸ່ມນີ້). ວິທີການ patching-merge ຍຸດທະສາດພະຍາຍາມ "ເຮັດໃຫ້ມັນຖືກຕ້ອງ" ໂດຍການລວມເອົາຂໍ້ກໍານົດທີ່ສະຫນອງໃຫ້ກັບຂໍ້ກໍານົດທີ່ມີຢູ່ແລ້ວ. ໂດຍສະເພາະ, ມັນພະຍາຍາມສົມທົບທັງວັດຖຸແລະ arrays, ຊຶ່ງຫມາຍຄວາມວ່າການປ່ຽນແປງມີແນວໂນ້ມທີ່ຈະເພີ່ມ. ສໍາລັບຕົວຢ່າງ, ແລ່ນຄໍາສັ່ງ patch ດ້ວຍຕົວແປສະພາບແວດລ້ອມໃໝ່ໃນສະເພາະຕົວບັນຈຸຝັກ, ເຮັດໃຫ້ຕົວແປສະພາບແວດລ້ອມນັ້ນຖືກເພີ່ມໃສ່ຕົວແປສະພາບແວດລ້ອມທີ່ມີຢູ່ແລ້ວແທນທີ່ຈະຂຽນທັບພວກມັນ. ເພື່ອເອົາອອກໂດຍໃຊ້ວິທີການນີ້, ທ່ານຕ້ອງບັງຄັບຄ່າພາລາມິເຕີໃຫ້ເປັນ null ໃນຂໍ້ກໍານົດທີ່ສະຫນອງໃຫ້. ທີມໃດ kubectl ມັນດີທີ່ສຸດທີ່ຈະໃຊ້ສໍາລັບການອັບເດດບໍ?

ຖ້າທ່ານສ້າງແລະຈັດການຊັບພະຍາກອນຂອງທ່ານໂດຍໃຊ້ kubectl apply, ເມື່ອປັບປຸງມັນດີກວ່າທີ່ຈະໃຊ້ສະເຫມີ kubectl applyເຖິງ kubectl ສາມາດຈັດການການຕັ້ງຄ່າ ແລະຕິດຕາມການປ່ຽນແປງທີ່ຮ້ອງຂໍຈາກແອັບພລິເຄຊັນໄປຫາແອັບພລິເຄຊັນໄດ້ຢ່າງຖືກຕ້ອງ. ຂໍ້ໄດ້ປຽບສະເຫມີໃຊ້ apply ແມ່ນວ່າມັນຕິດຕາມຂໍ້ມູນສະເພາະທີ່ໃຊ້ໃນເມື່ອກ່ອນ, ໃຫ້ມັນຮູ້ວ່າເມື່ອຄຸນສົມບັດສະເພາະ ແລະອົງປະກອບອາເຣຖືກຖອດອອກຢ່າງຈະແຈ້ງ. ນີ້ອະນຸຍາດໃຫ້ທ່ານໃຊ້ apply ເພື່ອເອົາຄຸນສົມບັດແລະອົງປະກອບ array, ໃນຂະນະທີ່ການລວມຍຸດທະສາດປົກກະຕິຈະບໍ່ເຮັດວຽກ. ທີມງານ edit и patch ບໍ່ປັບປຸງບັນທຶກທີ່ kubectl apply ໃຊ້ເພື່ອຕິດຕາມການປ່ຽນແປງຂອງມັນ, ດັ່ງນັ້ນການປ່ຽນແປງໃດໆທີ່ຖືກຕິດຕາມແລະເຮັດຜ່ານ Kubernetes API, ແຕ່ເຮັດຜ່ານຄໍາສັ່ງ edit и patch, ເບິ່ງບໍ່ເຫັນກັບຄໍາສັ່ງຕໍ່ໄປ apply, ວ່າແມ່ນ apply ບໍ່ເອົາພວກມັນອອກເຖິງແມ່ນວ່າພວກມັນບໍ່ປາກົດຢູ່ໃນຂໍ້ກໍານົດການປ້ອນຂໍ້ມູນສໍາລັບ apply (ເອກະສານບອກວ່າ edit и patch ປັບປຸງບັນທຶກທີ່ໃຊ້ apply, ແຕ່ໃນການປະຕິບັດ - ບໍ່ມີ).

ຖ້າທ່ານບໍ່ໃຊ້ຄໍາສັ່ງ apply, ສາມາດນໍາໃຊ້ເປັນ edit, ແລະ patch, ເລືອກຄໍາສັ່ງທີ່ເຫມາະສົມທີ່ສຸດກັບການປ່ຽນແປງທີ່ກໍາລັງເຮັດ. ເມື່ອເພີ່ມແລະປ່ຽນຄຸນສົມບັດ BOM, ທັງສອງວິທີການແມ່ນປະມານຄືກັນ. ເມື່ອລຶບຄຸນສົມບັດສະເພາະ ຫຼືອົງປະກອບອາເຣ edit ປະຕິບັດຕົວຄືກັບການເປີດຕົວຄັ້ງດຽວ apply, ລວມທັງການຕິດຕາມສິ່ງທີ່ສະເພາະກ່ອນແລະຫຼັງຈາກມັນຖືກດັດແກ້, ດັ່ງນັ້ນທ່ານສາມາດເອົາຄຸນສົມບັດແລະອົງປະກອບ array ອອກຈາກຊັບພະຍາກອນຢ່າງຊັດເຈນ. ທ່ານຈໍາເປັນຕ້ອງໄດ້ກໍານົດຢ່າງຈະແຈ້ງມູນຄ່າຊັບສິນເປັນ null ໃນຂໍ້ກໍານົດສໍາລັບ patchເພື່ອເອົາມັນອອກຈາກຊັບພະຍາກອນ. ການຖອນອົງປະກອບ array ໂດຍໃຊ້ strategic-merge patching ແມ່ນສັບສົນຫຼາຍເພາະວ່າມັນຮຽກຮ້ອງໃຫ້ມີການນໍາໃຊ້ຄໍາສັ່ງລວມ. ເບິ່ງວິທີການຍົກລະດັບອື່ນໆຂ້າງລຸ່ມນີ້ສໍາລັບທາງເລືອກທີ່ເປັນໄປໄດ້ຫຼາຍ.

ເພື່ອປະຕິບັດວິທີການປັບປຸງໃນຫ້ອງສະຫມຸດລູກຄ້າທີ່ມີລັກສະນະຄ້າຍຄືກັນກັບຄໍາສັ່ງຂ້າງເທິງ kubectl, ຄວນຖືກກໍານົດໄວ້ໃນຄໍາຮ້ອງຂໍ content-type в application/strategic-merge-patch+json. ຖ້າທ່ານຕ້ອງການເອົາຄຸນສົມບັດໃນສະເພາະ, ທ່ານຈໍາເປັນຕ້ອງກໍານົດຄ່າຂອງພວກມັນຢ່າງຊັດເຈນເປັນ null ໃນທາງທີ່ຄ້າຍຄືກັນ. kubectl patch. ຖ້າທ່ານຕ້ອງການເອົາອົງປະກອບ array, ທ່ານຄວນລວມເອົາຄໍາສັ່ງລວມຢູ່ໃນຂໍ້ກໍານົດຂອງການປັບປຸງຫຼືໃຊ້ວິທີການທີ່ແຕກຕ່າງກັນໃນການປັບປຸງ.

ວິທີການອື່ນເພື່ອການປັບປຸງ

Kubernetes ສະຫນັບສະຫນູນສອງວິທີການປັບປຸງອື່ນໆ: JSON ລວມ patch и JSON patch. ວິທີການແກ້ໄຂ JSON merge ໃຊ້ເວລາບາງສ່ວນສະເພາະ Kubernetes ເປັນການປ້ອນຂໍ້ມູນ ແລະສະຫນັບສະຫນູນການລວມວັດຖຸທີ່ຄ້າຍຄືກັນກັບວິທີການປັບປຸງແກ້ໄຂຍຸດທະສາດ. ຄວາມແຕກຕ່າງລະຫວ່າງສອງແມ່ນວ່າມັນພຽງແຕ່ສະຫນັບສະຫນູນການທົດແທນ array, ລວມທັງ array container ໃນຂໍ້ກໍານົດຂອງຝັກ. ນີ້ຫມາຍຄວາມວ່າເມື່ອໃຊ້ JSON merge patch, ທ່ານຈໍາເປັນຕ້ອງໄດ້ສະຫນອງຂໍ້ມູນຈໍາເພາະທີ່ສົມບູນສໍາລັບພາຊະນະທັງຫມົດໃນກໍລະນີທີ່ຊັບສິນຂອງບັນຈຸໃດມີການປ່ຽນແປງ. ດັ່ງນັ້ນວິທີການນີ້ແມ່ນເປັນປະໂຫຍດສໍາລັບການຖອນອົງປະກອບຈາກ array ໃນ BOM. ໃນເສັ້ນຄໍາສັ່ງທ່ານສາມາດເລືອກ JSON merge patch ໂດຍໃຊ້ kubectl patch --type=merge. ເມື່ອເຮັດວຽກກັບ Kubernetes API, ທ່ານຄວນໃຊ້ວິທີການຮ້ອງຂໍ PATCH ແລະການຕິດຕັ້ງ content-type в application/merge-patch+json.

ວິທີການ patch JSON, ແທນທີ່ຈະສະຫນອງບາງສ່ວນຂອງຊັບພະຍາກອນ, ໃຊ້ການສະຫນອງການປ່ຽນແປງທີ່ທ່ານຕ້ອງການເຮັດກັບຊັບພະຍາກອນເປັນ array, ເຊິ່ງແຕ່ລະອົງປະກອບຂອງ array ເປັນຕົວແທນຂອງລາຍລະອຽດຂອງການປ່ຽນແປງທີ່ເກີດຂື້ນກັບຊັບພະຍາກອນ. ວິທີການນີ້ແມ່ນວິທີການທີ່ມີຄວາມຍືດຫຍຸ່ນແລະມີອໍານາດຫຼາຍເພື່ອສະແດງການປ່ຽນແປງທີ່ກໍາລັງເຮັດ, ແຕ່ໃນຄ່າໃຊ້ຈ່າຍຂອງລາຍຊື່ການປ່ຽນແປງທີ່ເຮັດຢູ່ໃນຮູບແບບແຍກຕ່າງຫາກທີ່ບໍ່ແມ່ນ Kubernetes, ແທນທີ່ຈະສົ່ງຂໍ້ມູນສະເພາະຂອງຊັບພະຍາກອນບາງສ່ວນ. IN kubectl ທ່ານສາມາດເລືອກ JSON patch ໂດຍໃຊ້ kubectl patch --type=json. ເມື່ອໃຊ້ Kubernetes API, ວິທີການນີ້ເຮັດວຽກໂດຍໃຊ້ວິທີການຮ້ອງຂໍ PATCH ແລະການຕິດຕັ້ງ content-type в application/json-patch+json.

ພວກເຮົາຕ້ອງການຄວາມຫມັ້ນໃຈ - ໃຊ້ແທນ

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

• A ແລະ B ໄດ້ຮັບສະຖານະປັດຈຸບັນຂອງຊັບພະຍາກອນຈາກ API
• ແຕ່ລະທ້ອງຖິ່ນປັບປຸງຂໍ້ມູນສະເພາະໂດຍການເພີ່ມຕົວນັບແລະເພີ່ມ "A" ຫຼື "B" ຕາມລໍາດັບໃສ່ບັນທຶກ "ປັບປຸງໂດຍ"
• ແລະມັນປັບປຸງຊັບພະຍາກອນໄວຂຶ້ນເລັກນ້ອຍ
• B ປັບປຸງຊັບພະຍາກອນ

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

• A ແລະ B ໄດ້ຮັບສະຖານະປັດຈຸບັນຂອງຊັບພະຍາກອນຈາກ API
• ແຕ່ລະທ້ອງຖິ່ນປັບປຸງຂໍ້ມູນສະເພາະໂດຍການເພີ່ມຕົວນັບແລະເພີ່ມ "A" ຫຼື "B" ຕາມລໍາດັບໃສ່ບັນທຶກ "ປັບປຸງໂດຍ"
• ແລະມັນປັບປຸງຊັບພະຍາກອນໄວຂຶ້ນເລັກນ້ອຍ
• B ພະຍາຍາມປັບປຸງຊັບພະຍາກອນ, ແຕ່ການປັບປຸງໄດ້ຖືກປະຕິເສດໂດຍ API ເພາະວ່າສະບັບຂອງຊັບພະຍາກອນແມ່ນຢູ່ໃນຂໍ້ກໍານົດ. replace ບໍ່ກົງກັບເວີຊັ່ນປັດຈຸບັນຂອງຊັບພະຍາກອນໃນ Kubernetes ເພາະວ່າເວີຊັນຂອງຊັບພະຍາກອນເພີ່ມຂຶ້ນໂດຍການດຳເນີນການແທນທີ່ຂອງ A.

ໃນກໍລະນີຂ້າງເທິງ, B ຈະຕ້ອງເອົາຊັບພະຍາກອນຄືນໃຫມ່, ປ່ຽນແປງລັດໃຫມ່ແລະພະຍາຍາມອີກເທື່ອຫນຶ່ງ replace. ນີ້ຈະເຮັດໃຫ້ຕົວຕ້ານການເພີ່ມຂຶ້ນໂດຍສອງແລະບັນທຶກ "ປັບປຸງໂດຍ" ປະກອບມີ "AB" ໃນຕອນທ້າຍ.

ຕົວຢ່າງຂ້າງເທິງນີ້ຫມາຍຄວາມວ່າໃນເວລາທີ່ປະຕິບັດ replace ຊັບພະຍາກອນທັງຫມົດໄດ້ຖືກທົດແທນຢ່າງສົມບູນ. ຂໍ້ມູນຈໍາເພາະທີ່ໃຊ້ສໍາລັບ replace, ຈະຕ້ອງບໍ່ເປັນບາງສ່ວນ, ຫຼືບາງສ່ວນຄືກັບໃນ apply, ແຕ່ຄົບຖ້ວນສົມບູນ, ລວມທັງການເພີ່ມເຕີມ resourceVersion ເຂົ້າໄປໃນ metadata ສະເພາະ. ຖ້າທ່ານບໍ່ໄດ້ເປີດໃຊ້ງານ resourceVersion ຫຼືສະບັບທີ່ທ່ານໃຫ້ບໍ່ແມ່ນປະຈຸບັນ, ການທົດແທນຈະຖືກປະຕິເສດ. ດັ່ງນັ້ນວິທີການທີ່ດີທີ່ສຸດທີ່ຈະນໍາໃຊ້ແມ່ນ replace - ອ່ານ​ຊັບ​ພະ​ຍາ​ກອນ​, ປັບ​ປຸງ​ມັນ​ແລະ​ປ່ຽນ​ແທນ​ມັນ​ທັນ​ທີ​ທັນ​ໃດ​. ການນໍາໃຊ້ kubectl, ມັນອາດຈະເບິ່ງຄືວ່ານີ້:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າສອງຄໍາສັ່ງຕໍ່ໄປນີ້, ດໍາເນີນການຕາມລໍາດັບ, ຈະປະຕິບັດຢ່າງສໍາເລັດຜົນ, ນັບຕັ້ງແຕ່ deployment.yaml ບໍ່ມີຊັບສິນ .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

ນີ້ຈະເບິ່ງຄືວ່າກົງກັນຂ້າມກັບສິ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, i.e. "ເພີ່ມ resourceVersion ເຂົ້າໄປໃນ metadata ສະເພາະ. "ເວົ້າຜິດບໍ? ບໍ່, ມັນບໍ່ແມ່ນ, ເພາະວ່າຖ້າ kubectl ແຈ້ງການທີ່ທ່ານບໍ່ໄດ້ລະບຸ resourceVersion, ມັນຈະອ່ານມັນຈາກຊັບພະຍາກອນແລະເພີ່ມມັນໃສ່ສະເພາະທີ່ທ່ານລະບຸ, ແລະຫຼັງຈາກນັ້ນປະຕິບັດມັນເທົ່ານັ້ນ replace. ເນື່ອງຈາກວ່ານີ້ອາດຈະເປັນອັນຕະລາຍຖ້າຫາກວ່າທ່ານອີງໃສ່ປະລໍາມະນູ, magic ເຮັດວຽກທັງຫມົດຂ້າງ kubectl, ທ່ານບໍ່ຄວນອີງໃສ່ມັນໃນເວລາທີ່ໃຊ້ຫ້ອງສະຫມຸດລູກຄ້າທີ່ເຮັດວຽກກັບ API. ໃນກໍລະນີນີ້, ທ່ານຈະຕ້ອງອ່ານຂໍ້ກໍານົດຂອງຊັບພະຍາກອນໃນປະຈຸບັນ, ປັບປຸງມັນແລະຫຼັງຈາກນັ້ນດໍາເນີນການ PUT ຮ້ອງຂໍ.

ທ່ານບໍ່ສາມາດເຮັດ patch ໄດ້ - ພວກເຮົາປ່ຽນແທນ

ບາງຄັ້ງທ່ານຈໍາເປັນຕ້ອງເຮັດການປ່ຽນແປງບາງຢ່າງທີ່ບໍ່ສາມາດຈັດການກັບ API ໄດ້. ໃນກໍລະນີເຫຼົ່ານີ້, ທ່ານສາມາດບັງຄັບການທົດແທນຊັບພະຍາກອນໂດຍການລຶບແລະສ້າງມັນໃຫມ່. ນີ້ແມ່ນເຮັດໄດ້ໂດຍໃຊ້ kubectl replace --force. ການດໍາເນີນການຄໍາສັ່ງທັນທີເອົາຊັບພະຍາກອນແລະຫຼັງຈາກນັ້ນ recreates ໃຫ້ເຂົາເຈົ້າຈາກຂໍ້ກໍານົດທີ່ສະຫນອງໃຫ້. ບໍ່ມີຕົວຈັດການ "force replace" ໃນ API, ແລະເພື່ອເຮັດແນວນັ້ນຜ່ານ API, ທ່ານຈໍາເປັນຕ້ອງປະຕິບັດສອງຢ່າງ. ກ່ອນອື່ນ ໝົດ ທ່ານຕ້ອງລຶບຊັບພະຍາກອນໂດຍການຕັ້ງຄ່າມັນ gracePeriodSeconds ຫາສູນ (0) ແລະ propagationPolicy ໃນ "ພື້ນຫລັງ" ແລະຫຼັງຈາກນັ້ນສ້າງຊັບພະຍາກອນນີ້ຄືນໃຫມ່ດ້ວຍຂໍ້ກໍານົດທີ່ຕ້ອງການ.

ຄໍາເຕືອນ: ວິທີການນີ້ອາດຈະເປັນອັນຕະລາຍແລະອາດຈະນໍາໄປສູ່ສະຖານະທີ່ບໍ່ໄດ້ກໍານົດ.

ນຳໃຊ້ຢູ່ຂ້າງເຊີບເວີ

ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ນັກພັດທະນາ Kubernetes ກໍາລັງເຮັດວຽກກ່ຽວກັບການປະຕິບັດເຫດຜົນ apply ຈາກນັ້ນ kubectl ໃນ Kubernetes API. ເຫດຜົນ apply ມີຢູ່ໃນ Kubernetes 1.18 ຜ່ານ kubectl apply --server-side ຫຼືຜ່ານ API ໂດຍໃຊ້ວິທີການ PATCH с content-type application/apply-patch+YAML.

ຫມາຍເຫດ: JSON ຍັງເປັນ YAML ທີ່ຖືກຕ້ອງ, ດັ່ງນັ້ນທ່ານສາມາດສົ່ງສະເພາະເປັນ JSON ເຖິງແມ່ນວ່າ content-type ຈະ application/apply-patch+yaml.

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

ຜົນໄດ້ຮັບ

ຂ້າ​ພະ​ເຈົ້າ​ຫວັງ​ວ່າ​ພາບ​ລວມ​ສັ້ນ​ຂອງ​ວິ​ທີ​ການ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ໃນ​ການ​ປັບ​ປຸງ​ຊັບ​ພະ​ຍາ​ກອນ​ໃນ​ກຸ່ມ​ແມ່ນ​ເປັນ​ປະ​ໂຫຍດ​ສໍາ​ລັບ​ທ່ານ. ມັນເປັນການດີທີ່ຈະຮູ້ວ່າມັນບໍ່ພຽງແຕ່ນໍາໃຊ້ກັບທົດແທນ; ຫຼັງຈາກທີ່ທັງຫມົດ, ໃນຫຼັກການ, ແຕ່ລະວິທີການມີພື້ນທີ່ຂອງຕົນເອງຂອງຄໍາຮ້ອງສະຫມັກ. ສໍາລັບການປ່ຽນແປງປະລໍາມະນູ, ການທົດແທນແມ່ນດີກວ່າ; ຢ່າງຫນ້ອຍ, ຂ້າພະເຈົ້າຄາດຫວັງວ່າທ່ານຈະເຂົ້າໃຈວ່າທ່ານບໍ່ສາມາດໄວ້ວາງໃຈ Google ຫຼື StackOerflow ໃນເວລາທີ່ຊອກຫາ "kubernetes apply vs replace". ຢ່າງຫນ້ອຍຈົນກ່ວາບົດຄວາມນີ້ຈະທົດແທນຄໍາຕອບໃນປະຈຸບັນ.

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