ການແນະນຳສັ້ນໆເພື່ອປັບແຕ່ງ

ຫມາຍ​ເຫດ​. ແປ.: ບົດຄວາມດັ່ງກ່າວຖືກຂຽນໂດຍ Scott Lowe, ວິສະວະກອນທີ່ມີປະສົບການຢ່າງກວ້າງຂວາງໃນດ້ານໄອທີ, ຜູ້ທີ່ເປັນຜູ້ຂຽນ / ຜູ້ຂຽນຮ່ວມຂອງເຈັດປື້ມທີ່ພິມອອກ (ສ່ວນໃຫຍ່ແມ່ນຢູ່ໃນ VMware vSphere). ຕອນນີ້ລາວເຮັດວຽກໃຫ້ບໍລິສັດສາຂາ VMware Heptio (ໄດ້ມາໃນປີ 2016), ຊ່ຽວຊານດ້ານຄອມພິວເຕີຄລາວ ແລະ Kubernetes. ຂໍ້ຄວາມຕົວມັນເອງເຮັດຫນ້າທີ່ເປັນການແນະນໍາທີ່ຊັດເຈນແລະເຂົ້າໃຈງ່າຍໃນການຈັດການການຕັ້ງຄ່າສໍາລັບ Kubernetes ໂດຍໃຊ້ເຕັກໂນໂລຢີ ປັບແຕ່ງ, ເຊິ່ງບໍ່ດົນມານີ້ໄດ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງ K8s.

Kustomize ເປັນເຄື່ອງມືທີ່ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດ "ປັບແຕ່ງໄຟລ໌ YAML ແບບງ່າຍດາຍ, ບໍ່ມີແມ່ແບບສໍາລັບຈຸດປະສົງທີ່ແຕກຕ່າງກັນ, ເຮັດໃຫ້ YAML ຕົ້ນສະບັບບໍ່ສະອາດແລະໃຊ້ໄດ້" (ຄໍາອະທິບາຍໄດ້ຢືມໂດຍກົງຈາກ ປັບແຕ່ງບ່ອນເກັບມ້ຽນໃນ GitHub). Kustomize ສາມາດດໍາເນີນການໂດຍກົງຫຼື, ເປັນຂອງ Kubernetes 1.14, ຖືກນໍາໃຊ້ kubectl -k ເພື່ອເຂົ້າເຖິງການເຮັດວຽກຂອງມັນ (ເຖິງແມ່ນວ່າໃນ Kubernetes 1.15, binary ແຍກຕ່າງຫາກແມ່ນໃຫມ່ກວ່າຄວາມສາມາດທີ່ສ້າງຂຶ້ນໃນ kubectl). (ຫມາຍ​ເຫດ​. ແປ.: ແລະມີການເປີດຕົວທີ່ຜ່ານມາ ຄູໂບຕ້າ 1.16 ປັບແຕ່ງ ສະ ໜັບ ສະ ໜູນ ໂດຍ ຍັງຢູ່ໃນຜົນປະໂຫຍດ kubeadm.) ໃນບົດຂຽນນີ້, ຂ້າພະເຈົ້າຕ້ອງການແນະນໍາຜູ້ອ່ານກ່ຽວກັບພື້ນຖານຂອງ kustomize.

ໃນຮູບແບບ / ຄໍາຮ້ອງສະຫມັກທີ່ງ່າຍດາຍທີ່ສຸດ, kustomize ແມ່ນພຽງແຕ່ການລວບລວມຊັບພະຍາກອນ (ໄຟລ໌ YAML ທີ່ກໍານົດວັດຖຸ Kubernetes: ການຕິດຕັ້ງ, ການບໍລິການ, ແລະອື່ນໆ) ບວກກັບບັນຊີລາຍຊື່ຄໍາແນະນໍາສໍາລັບການປ່ຽນແປງທີ່ຕ້ອງເຮັດກັບຊັບພະຍາກອນເຫຼົ່ານັ້ນ. ເຊັ່ນດຽວກັບເຮັດໃຫ້ການນໍາໃຊ້ຊຸດຄໍາແນະນໍາທີ່ມີຢູ່ໃນ Makefile, ແລະ Docker ກໍ່ສ້າງ container ໂດຍອີງໃສ່ຄໍາແນະນໍາຈາກ Dockerfile, ປັບ​ການ​ນໍາ​ໃຊ້​ kustomization.yaml ເພື່ອເກັບຮັກສາຄໍາແນະນໍາກ່ຽວກັບການປ່ຽນແປງທີ່ຜູ້ໃຊ້ຕ້ອງການເຮັດກັບຊຸດຂອງຊັບພະຍາກອນ.

ນີ້ແມ່ນໄຟລ໌ຕົວຢ່າງ kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ຂ້ອຍຈະບໍ່ພະຍາຍາມເວົ້າກ່ຽວກັບຊ່ອງຂໍ້ມູນທີ່ເປັນໄປໄດ້ທັງໝົດໃນໄຟລ໌. kustomization.yaml (ນີ້​ແມ່ນ​ໄດ້​ຖືກ​ລາຍ​ລັກ​ອັກ​ສອນ​ດີ​ກ່ຽວ​ກັບ​ ທີ່ນີ້), ແຕ່ຂ້າພະເຈົ້າຈະໃຫ້ຄໍາອະທິບາຍສັ້ນໆກ່ຽວກັບຕົວຢ່າງສະເພາະ:

• ພາກສະຫນາມ resources ຊີ້ບອກສິ່ງທີ່ (ຊັບພະຍາກອນອັນໃດ) ປັບແຕ່ງຈະປ່ຽນແປງ. ໃນກໍລະນີນີ້, ມັນຈະຊອກຫາຊັບພະຍາກອນໃນໄຟລ໌ deployment.yaml и service.yaml ໃນໄດເລກະທໍລີຂອງທ່ານ (ທ່ານສາມາດລະບຸເສັ້ນທາງເຕັມຫຼືພີ່ນ້ອງຖ້າຈໍາເປັນ).
• ພາກສະຫນາມ namePrefix ແນະນໍາ kustomize ເພື່ອເພີ່ມຄໍານໍາຫນ້າທີ່ແນ່ນອນ (ໃນກໍລະນີນີ້ - dev-) ເພື່ອ​ຄຸນ​ລັກ​ສະ​ນະ​ name ຊັບພະຍາກອນທັງຫມົດທີ່ກໍານົດຢູ່ໃນພາກສະຫນາມ resources. ດັ່ງນັ້ນ, ຖ້າ Deployment ມີ name ທີ່​ມີ​ຄວາມ​ຫມາຍ​ nginx-deployment, ປັບແຕ່ງຈະເຮັດໃຫ້ມັນ dev-nginx-deployment.
• ພາກສະຫນາມ namespace ແນະນຳໃຫ້ປັບແຕ່ງເພື່ອເພີ່ມ namespace ໃຫ້ກັບຊັບພະຍາກອນທັງໝົດ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ການ​ນໍາ​ໃຊ້​ແລະ​ການ​ບໍ​ລິ​ການ​ຈະ​ຕົກ​ຢູ່​ໃນ namespace ໄດ້​ development.
• ສຸດທ້າຍ, ພາກສະຫນາມ commonLabels ມີຊຸດປ້າຍກຳກັບທີ່ຈະຖືກເພີ່ມໃສ່ຊັບພະຍາກອນທັງໝົດ. ໃນຕົວຢ່າງຂອງພວກເຮົາ, kustomize ຈະກໍານົດປ້າຍຊື່ໃຫ້ກັບຊັບພະຍາກອນທີ່ມີຊື່ environment ແລະຄວາມຫມາຍ development.

ຖ້າຜູ້ໃຊ້ເຮັດ kustomize build . ໃນໄດເລກະທໍລີທີ່ມີໄຟລ໌ kustomization.yaml ແລະຊັບພະຍາກອນທີ່ຈໍາເປັນ (i.e. ໄຟລ໌ deployment.yaml и service.yaml), ຫຼັງຈາກນັ້ນຢູ່ທີ່ຜົນຜະລິດມັນຈະໄດ້ຮັບຂໍ້ຄວາມທີ່ມີການປ່ຽນແປງທີ່ລະບຸໄວ້ໃນ kustomization.yaml.

ຫມາຍ​ເຫດ​. ແປ.: ຮູບປະກອບຈາກເອກະສານໂຄງການກ່ຽວກັບການນໍາໃຊ້ "ງ່າຍດາຍ" ຂອງ kustomize

ຜົນຜະລິດສາມາດຖືກປ່ຽນເສັ້ນທາງໄດ້ຖ້າການປ່ຽນແປງຕ້ອງມີຄວາມມຸ່ງຫມັ້ນ:

kustomize build . > custom-config.yaml

ຂໍ້​ມູນ​ການ​ຜະ​ລິດ​ແມ່ນ​ການ​ກໍາ​ນົດ (ຂໍ້​ມູນ​ການ​ປ້ອນ​ຂໍ້​ມູນ​ດຽວ​ກັນ​ຈະ​ໃຫ້​ຜົນ​ໄດ້​ຮັບ​ຜົນ​ຜະ​ລິດ​ດຽວ​ກັນ​)​, ດັ່ງ​ນັ້ນ​ທ່ານ​ບໍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ບັນ​ທຶກ​ຜົນ​ໄດ້​ຮັບ​ໃນ​ໄຟລ​໌​. ແທນທີ່ຈະ, ມັນສາມາດຖືກສົ່ງໂດຍກົງໄປຫາຄໍາສັ່ງອື່ນ:

kustomize build . | kubectl apply -f -

ຄຸນສົມບັດ customize ຍັງສາມາດເຂົ້າເຖິງໄດ້ໂດຍຜ່ານ kubectl -k (ນັບຕັ້ງແຕ່ Kubernetes ຮຸ່ນ 1.14). ຢ່າງໃດກໍຕາມ, ຈົ່ງຈື່ໄວ້ວ່າຊຸດ kustomize ແບບ standalone ໄດ້ຖືກປັບປຸງໄວກວ່າຊຸດ kubectl ປະສົມປະສານ (ຢ່າງຫນ້ອຍນີ້ແມ່ນກໍລະນີທີ່ມີການປ່ອຍ Kubernetes 1.15).

ຜູ້ອ່ານອາດຈະຖາມວ່າ: "ເປັນຫຍັງຄວາມສັບສົນທັງຫມົດນີ້ຖ້າທ່ານສາມາດແກ້ໄຂໄຟລ໌ໂດຍກົງ?" ຄໍາຖາມທີ່ຍິ່ງໃຫຍ່. ໃນຕົວຢ່າງຂອງພວກເຮົາ, ແທ້ຈິງແລ້ວ ສາມາດເຮັດໄດ້ ແກ້ໄຂໄຟລ໌ deployment.yaml и service.yaml ໂດຍກົງ, ແຕ່ຈະເປັນແນວໃດຖ້າພວກເຂົາເປັນທາງແຍກຂອງໂຄງການຂອງຜູ້ອື່ນ? ການປ່ຽນໄຟລ໌ໂດຍກົງເຮັດໃຫ້ມັນຍາກ (ຖ້າເປັນໄປບໍ່ໄດ້) ທີ່ຈະໃຊ້ສ້ອມຄືນໃໝ່ເມື່ອມີການປ່ຽນແປງກັບຕົ້ນທາງ/ແຫຼ່ງທີ່ມາ. ການນໍາໃຊ້ kustomize ຊ່ວຍໃຫ້ທ່ານສາມາດສູນກາງການປ່ຽນແປງເຫຼົ່ານີ້ຢູ່ໃນໄຟລ໌ kustomization.yaml, ເຮັດໃຫ້ໄຟລ໌ຕົ້ນສະບັບ intact ແລະດັ່ງນັ້ນເຮັດໃຫ້ມັນງ່າຍຕໍ່ການ rebase ໄຟລ໌ຕົ້ນສະບັບຖ້າຫາກວ່າມີຄວາມຈໍາເປັນ.

ຜົນປະໂຫຍດຂອງ kustomize ກາຍເປັນປາກົດຂື້ນໃນກໍລະນີການນໍາໃຊ້ທີ່ສັບສົນຫຼາຍ. ໃນຕົວຢ່າງຂ້າງເທິງ kustomization.yaml ແລະຊັບພະຍາກອນຢູ່ໃນໄດເລກະທໍລີດຽວກັນ. ຢ່າງໃດກໍຕາມ, kustomize ສະຫນັບສະຫນູນກໍລະນີການນໍາໃຊ້ທີ່ມີການຕັ້ງຄ່າພື້ນຖານແລະຫຼາຍ variants ຂອງມັນ, ຊຶ່ງເອີ້ນກັນວ່າ. ການຊ້ອນກັນ. ຕົວຢ່າງ, ຜູ້ໃຊ້ຕ້ອງການໃຊ້ Deployment and Service ສໍາລັບ nginx, ເຊິ່ງຂ້ອຍໃຊ້ເປັນຕົວຢ່າງ, ແລະສ້າງການພັດທະນາ, ຂັ້ນຕອນແລະການຜະລິດ (ຫຼືຕົວແປ) ຂອງໄຟລ໌ເຫຼົ່ານັ້ນ. ເພື່ອເຮັດສິ່ງນີ້, ລາວຈະຕ້ອງການການຊ້ອນກັນຂ້າງເທິງແລະ, ໃນຄວາມເປັນຈິງ, ຊັບພະຍາກອນພື້ນຖານຂອງມັນເອງ.

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

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

ໃນໄຟລ໌ base/kustomization.yaml ຜູ້ໃຊ້ທີ່ໃຊ້ພາກສະຫນາມ resources ພຽງແຕ່ປະກາດຊັບພະຍາກອນທີ່ customize ຄວນປະກອບມີ.

ໃນແຕ່ລະໄຟລ໌ overlays/{dev,staging,prod}/kustomization.yaml ຜູ້ໃຊ້ອ້າງອີງເຖິງການຕັ້ງຄ່າພື້ນຖານໃນພາກສະຫນາມ resources, ແລະຫຼັງຈາກນັ້ນຊີ້ໃຫ້ເຫັນການປ່ຽນແປງສະເພາະສໍາລັບ ສະພາບແວດລ້ອມໃຫ້. ຕົວຢ່າງ, ໄຟລ໌ overlays/dev/kustomization.yaml ອາດຈະຄ້າຍຄືຕົວຢ່າງທີ່ໄດ້ໃຫ້ກ່ອນຫນ້ານີ້:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ໃນກໍລະນີດັ່ງກ່າວນີ້, ໄຟລ໌ overlays/prod/kustomization.yaml ອາດຈະແຕກຕ່າງກັນຫມົດ:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

ເມື່ອຜູ້ໃຊ້ແລ່ນ kustomize build . ໃນລາຍການ overlays/dev, customize ຈະສ້າງທາງເລືອກໃນການພັດທະນາ. ຖ້າເຈົ້າແລ່ນ kustomize build . ໃນລາຍການ overlays/prod - ທ່ານໄດ້ຮັບທາງເລືອກການຜະລິດ. ແລະທັງຫມົດນີ້ - ໂດຍບໍ່ມີການປ່ຽນແປງໃດໆກັບຕົ້ນສະບັບ (ຖານ) ໄຟລ໌, ທັງຫມົດໃນວິທີການປະກາດແລະກໍານົດ. ທ່ານສາມາດເຮັດການກໍານົດຄ່າພື້ນຖານແລະ overlay ໄດເລກະທໍລີໂດຍກົງກັບການຄວບຄຸມສະບັບ, ໂດຍຮູ້ວ່າໂດຍອີງໃສ່ໄຟລ໌ເຫຼົ່ານີ້ທ່ານສາມາດຜະລິດໃຫມ່ການຕັ້ງຄ່າທີ່ຕ້ອງການໄດ້ທຸກເວລາ.

ຫມາຍ​ເຫດ​. ແປ.: ພາບປະກອບຈາກເອກະສານໂຄງການກ່ຽວກັບການໃຊ້ການວາງຊ້ອນກັນໃນ customize

ສາມາດປັບແຕ່ງໄດ້ ຫຼາຍ ຫຼາຍກ່ວາສິ່ງທີ່ກວມເອົາໃນບົດຄວາມນີ້. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າຫວັງວ່າມັນເປັນການແນະນໍາທີ່ດີ.

ຊັບພະຍາກອນເພີ່ມເຕີມ

ມີຫຼາຍບົດຄວາມ ແລະສິ່ງພິມທີ່ດີກ່ຽວກັບການປັບແຕ່ງ. ນີ້ແມ່ນບາງອັນທີ່ຂ້ອຍພົບວ່າເປັນປະໂຫຍດໂດຍສະເພາະ:

• ປ່ຽນພື້ນຖານການຕັ້ງຄ່າ YAML ສໍາລັບສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ prod/test ໂດຍໃຊ້ Kustomize;
• ປັບແຕ່ງ - ວິທີທີ່ຖືກຕ້ອງເພື່ອເຮັດແມ່ແບບໃນ Kubernetes;
• ການຈັດການປະກາດຂອງວັດຖຸ Kubernetes ໂດຍໃຊ້ Customize;
• ການປັບແຕ່ງ Upstream Helm Charts ດ້ວຍການປັບແຕ່ງ.

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

ຖ້າ​ຫາກ​ທ່ານ​ມີ​ຄໍາ​ຖາມ​ຫຼື​ຄໍາ​ແນະ​ນໍາ​ສໍາ​ລັບ​ການ​ປັບ​ປຸງ​ອຸ​ປະ​ກອນ​ການ​ນີ້​, ຂ້າ​ພະ​ເຈົ້າ​ສະ​ເຫມີ​ເປີດ​ໃຫ້​ຄໍາ​ຄຶດ​ຄໍາ​ເຫັນ​. ເຈົ້າສາມາດຕິດຕໍ່ຂ້ອຍໄດ້ທີ່ Twitter ຫຼື ຊ່ອງ Kubernetes Slack. ມ່ວນກັບການດັດແປງ manifests ຂອງທ່ານດ້ວຍການປັບແຕ່ງ!

PS ຈາກນັກແປ

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

• «ເຄື່ອງມືສໍາລັບນັກພັດທະນາແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່ໃນ Kubernetes"
• «Kubernetes 1.14: ຈຸດເດັ່ນຂອງສິ່ງໃໝ່"
• «ຫ້າຜົນການຄົ້ນຫາຫຼັກຂອງ Helm Summit 2019 ໃນ Amsterdam"
• «ການແນະນໍາພາກປະຕິບັດຕໍ່ກັບຜູ້ຈັດການຊຸດສໍາລັບ Kubernetes - Helm".

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