ການອັບເກຣດກຸ່ມ Kubernetes ໂດຍບໍ່ມີການຢຸດເຮັດວຽກ

ຂະບວນການອັບເກຣດສຳລັບກຸ່ມ Kubernetes ຂອງທ່ານ

ໃນບາງຈຸດ, ເມື່ອໃຊ້ກຸ່ມ Kubernetes, ມີຄວາມຕ້ອງການທີ່ຈະປັບປຸງ nodes ແລ່ນ. ອັນນີ້ອາດຈະລວມເຖິງການອັບເດດຊຸດ, ການປັບປຸງແກ່ນ, ຫຼືການນຳໃຊ້ຮູບພາບເຄື່ອງສະເໝືອນໃໝ່. ໃນຄຳສັບ Kubernetes ອັນນີ້ເອີ້ນວ່າ "ການຂັດຂວາງການສະຫມັກໃຈ".

ໂພສນີ້ເປັນສ່ວນຫນຶ່ງຂອງຊຸດ 4 ໂພສ:

1. ຕອບນີ້.
2. ການປິດພອດທີ່ຖືກຕ້ອງໃນກຸ່ມ Kubernetes
3. ຊັກຊ້າການສໍາເລັດຂອງຝັກເມື່ອມັນຖືກລຶບ
4. ວິທີການຫຼີກເວັ້ນ Kubernetes Cluster Downtime ໂດຍໃຊ້ PodDisruptionBudgets

(ປະມານ. ຄາດວ່າຈະມີການແປບົດຄວາມທີ່ຍັງເຫຼືອຢູ່ໃນຊຸດໃນອະນາຄົດອັນໃກ້ນີ້)

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

ການ ກຳ ນົດບັນຫາ

ພວກເຮົາຈະໃຊ້ວິທີການ naive ໃນຕອນທໍາອິດ, ກໍານົດບັນຫາແລະປະເມີນຄວາມສ່ຽງທີ່ອາດຈະເກີດຂຶ້ນຂອງວິທີການນີ້, ແລະສ້າງຄວາມຮູ້ເພື່ອແກ້ໄຂແຕ່ລະບັນຫາທີ່ພວກເຮົາພົບຕະຫຼອດວົງຈອນ. ຜົນໄດ້ຮັບແມ່ນເປັນການຕັ້ງຄ່າທີ່ໃຊ້ hooks lifecycle, probes ກຽມພ້ອມ, ແລະ Pod disruption budgets ເພື່ອບັນລຸເປົ້າຫມາຍການຢຸດເຮັດວຽກຂອງພວກເຮົາສູນ.

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

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍສອງພອດທີ່ມີ Nginx ແລະການບໍລິການທີ່ເຮັດວຽກຢູ່ໃນສອງ nodes cluster Kubernetes ຂອງພວກເຮົາ.

ພວກເຮົາຕ້ອງການອັບເດດ kernel version ຂອງສອງ worker nodes ໃນ cluster ຂອງພວກເຮົາ. ພວກເຮົາເຮັດແນວໃດນີ້? ການແກ້ໄຂງ່າຍໆຄືການ boot nodes ໃໝ່ດ້ວຍການຕັ້ງຄ່າທີ່ອັບເດດແລ້ວປິດ nodes ເກົ່າ ໃນຂະນະທີ່ເລີ່ມອັນໃໝ່. ໃນຂະນະທີ່ນີ້ຈະເຮັດວຽກ, ມັນຈະມີບັນຫາເລັກນ້ອຍກັບວິທີການນີ້:

• ເມື່ອທ່ານປິດໂຫມດເກົ່າ, ຝັກທີ່ແລ່ນຢູ່ເທິງພວກມັນຈະຖືກປິດເຊັ່ນກັນ. ຈະເປັນແນວໃດຖ້າຝັກຕ້ອງຖືກລ້າງສໍາລັບການປິດຢ່າງສະຫງ່າງາມ? ລະບົບ virtualization ທີ່ທ່ານກໍາລັງໃຊ້ອາດຈະບໍ່ລໍຖ້າໃຫ້ຂະບວນການທໍາຄວາມສະອາດສໍາເລັດ.
• ຈະເປັນແນວໃດຖ້າຫາກວ່າທ່ານປິດ nodes ທັງຫມົດໃນເວລາດຽວກັນ? ທ່ານຈະໄດ້ຮັບເວລາຢຸດເຮັດວຽກທີ່ເໝາະສົມ ໃນຂະນະທີ່ຝັກຍ້າຍໄປຫາຂໍ້ໃໝ່.

ພວກເຮົາຕ້ອງການວິທີການເຄື່ອນຍ້າຍພອດຈາກໂຫນດເກົ່າຢ່າງສະຫງ່າງາມໃນຂະນະທີ່ຮັບປະກັນວ່າບໍ່ມີຂະບວນການຂອງພະນັກງານຂອງພວກເຮົາເຮັດວຽກໃນຂະນະທີ່ພວກເຮົາເຮັດການປ່ຽນແປງໃນ node. ຫຼືເມື່ອພວກເຮົາເຮັດການທົດແທນທີ່ສົມບູນຂອງກຸ່ມ, ເຊັ່ນດຽວກັບຕົວຢ່າງ (ນັ້ນແມ່ນ, ພວກເຮົາປ່ຽນແທນຮູບພາບ VM), ພວກເຮົາຕ້ອງການໂອນແອັບພລິເຄຊັນທີ່ເຮັດວຽກຈາກໂຫນດເກົ່າໄປຫາອັນໃຫມ່. ໃນທັງສອງກໍລະນີ, ພວກເຮົາຕ້ອງການປ້ອງກັນບໍ່ໃຫ້ຝັກໃຫມ່ຖືກກໍານົດໄວ້ໃນຂໍ້ເກົ່າ, ແລະຫຼັງຈາກນັ້ນຂັບໄລ່ຝັກທີ່ແລ່ນທັງຫມົດອອກຈາກພວກມັນ. ເພື່ອບັນລຸເປົ້າຫມາຍເຫຼົ່ານີ້ພວກເຮົາສາມາດນໍາໃຊ້ຄໍາສັ່ງ kubectl drain.

ການແຈກຢາຍຝັກທັງໝົດຈາກ node

ການປະຕິບັດການລະບາຍນ້ໍາອະນຸຍາດໃຫ້ທ່ານສາມາດແຈກຢາຍຝັກທັງຫມົດຈາກໂຫນດຫນຶ່ງ. ໃນ​ລະ​ຫວ່າງ​ການ​ປະ​ຕິ​ບັດ​ການ​ລະບາຍ​, node ໄດ້​ຖືກ​ຫມາຍ​ວ່າ​ບໍ່​ໄດ້​ກໍາ​ນົດ​ເວ​ລາ (ທຸງ​ NoSchedule). ນີ້ປ້ອງກັນບໍ່ໃຫ້ຝັກໃຫມ່ປາກົດຢູ່ໃນມັນ. ຫຼັງຈາກນັ້ນ, ການລະບາຍນ້ໍາເລີ່ມຕົ້ນທີ່ຈະຂັບໄລ່ຝັກອອກຈາກ node, ປິດພາຊະນະບັນຈຸທີ່ປະຈຸບັນເຮັດວຽກຢູ່ໃນ node ໂດຍການສົ່ງສັນຍານ. TERM ບັນຈຸຢູ່ໃນຝັກ.

ເຖິງແມ່ນວ່າ kubectl drain ຈະເຮັດວຽກທີ່ດີໃນການຂັບໄລ່ຝັກ, ມີສອງປັດໃຈອື່ນໆທີ່ສາມາດເຮັດໃຫ້ການດໍາເນີນງານຂອງທໍ່ລະບາຍນ້ໍາລົ້ມເຫລວ:

• ຄໍາຮ້ອງສະຫມັກຂອງທ່ານຕ້ອງສາມາດຢຸດເຊົາຢ່າງສະຫງ່າງາມເມື່ອຍື່ນສະເຫນີ TERM ສັນຍານ. ເມື່ອຝັກຖືກຂັບໄລ່, Kubernetes ຈະສົ່ງສັນຍານ TERM ຕູ້ຄອນເທນເນີແລະລໍຖ້າໃຫ້ພວກເຂົາຢຸດໃນຈໍານວນເວລາທີ່ກໍານົດໄວ້, ຫຼັງຈາກນັ້ນ, ຖ້າພວກເຂົາບໍ່ໄດ້ຢຸດ, ມັນຈະຢຸດພວກມັນຢ່າງບັງຄັບ. ໃນກໍລະນີໃດກໍ່ຕາມ, ຖ້າຕູ້ຄອນເທນເນີຂອງທ່ານບໍ່ຮັບຮູ້ສັນຍານຢ່າງຖືກຕ້ອງ, ທ່ານຍັງສາມາດດັບໄຟຝັກໄດ້ບໍ່ຖືກຕ້ອງຖ້າພວກມັນກໍາລັງເຮັດວຽກຢູ່ (ຕົວຢ່າງເຊັ່ນ, ການເຮັດທຸລະກໍາຖານຂໍ້ມູນກໍາລັງດໍາເນີນຢູ່).
• ທ່ານສູນເສຍຝັກທັງຫມົດທີ່ບັນຈຸຄໍາຮ້ອງສະຫມັກຂອງທ່ານ. ມັນອາດຈະບໍ່ສາມາດໃຊ້ໄດ້ເມື່ອກ່ອງບັນຈຸໃຫມ່ຖືກເປີດຕົວໃນໂຫນດໃຫມ່, ຫຼືຖ້າ pods ຂອງທ່ານຖືກນໍາໄປໃຊ້ໂດຍບໍ່ມີຕົວຄວບຄຸມ, ພວກມັນອາດຈະບໍ່ restart ເລີຍ.

ຫຼີກ​ລ້ຽງ​ການ​ຢຸດ​ເຊົາ​ການ​

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

• ການຢຸດເຊົາທີ່ສະຫງ່າງາມ
• hooks ວົງຈອນຊີວິດ
• PodDisruptionBudgets

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

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

ການຕັ້ງຄ່ານີ້ແມ່ນຕົວຢ່າງຫນ້ອຍທີ່ສຸດ Deployment, ເຊິ່ງຈັດການຝັກ nginx ໃນກຸ່ມ. ນອກຈາກນັ້ນ, ການຕັ້ງຄ່າອະທິບາຍຊັບພະຍາກອນ Service, ເຊິ່ງສາມາດໃຊ້ເພື່ອເຂົ້າເຖິງ pods nginx ໃນກຸ່ມ.

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

ສໍາລັບສະບັບທີ່ປະຕິບັດແລະທົດສອບຢ່າງເຕັມທີ່ຂອງການປັບປຸງ cluster Kubernetes ສໍາລັບການບໍ່ມີເວລາຢຸດຢູ່ໃນ AWS ແລະຫຼາຍກວ່ານັ້ນ, ເຂົ້າໄປເບິ່ງ Gruntwork.io.

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• ການນຳໃຊ້ສູນການຢຸດເຮັດວຽກ ແລະຖານຂໍ້ມູນ
• Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?
• ທໍ່ Tekton - Kubernetes-native pipelines
• ການກໍ່ສ້າງໂມດູນແບບເຄື່ອນໄຫວສໍາລັບ Nginx
• ການແນະນໍາການອະນຸຍາດ Kubernetes ຂອງກົງສຸນ Hashicorp
• ການເຄື່ອນຍ້າຍຈາກ ClickHouse ໂດຍບໍ່ມີການອະນຸຍາດໄປຫາ ClickHouse ດ້ວຍການອະນຸຍາດນໍາໄປສູ່ຫຍັງ?

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