ຫ້າພາດເມື່ອນຳໃຊ້ແອັບພລິເຄຊັນທຳອິດໃນ Kubernetes

ລົ້ມເຫລວໂດຍ Aris-Dreamer

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

ທີມງານ Mail.ru Cloud Solutions ແປບົດຄວາມໂດຍວິສະວະກອນ DevOps Julian Gindi. ລາວແບ່ງປັນສິ່ງທີ່ປະສົບກັບບັນຫາທີ່ບໍລິສັດລາວພົບໃນລະຫວ່າງຂະບວນການການເຄື່ອນຍ້າຍເພື່ອບໍ່ໃຫ້ເຈົ້າກ້າວໄປສູ່ rake ດຽວກັນ.

ຂັ້ນຕອນທີຫນຶ່ງ: ການຕັ້ງຄ່າການຮ້ອງຂໍ Pod ແລະຂອບເຂດຈໍາກັດ

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

ຄຳຮ້ອງຂໍ Pod - ນີ້ແມ່ນຄ່າຫຼັກທີ່ໃຊ້ໂດຍຜູ້ກຳນົດເວລາເພື່ອວາງຝັກໃຫ້ດີທີ່ສຸດ.

ຈາກ ເອກະສານ Kubernetes: ຂັ້ນຕອນການກັ່ນຕອງກໍານົດຊຸດຂອງ nodes ບ່ອນທີ່ pod ສາມາດກໍານົດເວລາ. ຕົວຢ່າງ, ຕົວກອງ PodFitsResources ກວດເບິ່ງວ່າ node ມີຊັບພະຍາກອນພຽງພໍເພື່ອຕອບສະໜອງການຮ້ອງຂໍຊັບພະຍາກອນສະເພາະຂອງ pod ຫຼືບໍ່.

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

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

ຂີດຈຳກັດ Pod - ນີ້ແມ່ນຂອບເຂດຈໍາກັດທີ່ຊັດເຈນກວ່າສໍາລັບຝັກ. ມັນສະແດງເຖິງປະລິມານສູງສຸດຂອງຊັບພະຍາກອນທີ່ກຸ່ມຈະຈັດສັນໃຫ້ກັບບັນຈຸ.

ອີກເທື່ອຫນຶ່ງ, ຈາກ ເອກະສານທາງການ: ຖ້າບັນຈຸມີກໍານົດຂອບເຂດຈໍາກັດຫນ່ວຍຄວາມຈໍາ 4 GiB, kubelet (ແລະເວລາແລ່ນ container) ຈະບັງຄັບມັນ. ເວລາແລ່ນບໍ່ອະນຸຍາດໃຫ້ພາຊະນະໃຊ້ເກີນຂີດຈຳກັດຊັບພະຍາກອນທີ່ກຳນົດໄວ້. ຕົວຢ່າງເຊັ່ນ, ເມື່ອຂະບວນການໃນບັນຈຸພະຍາຍາມໃຊ້ຫຼາຍກ່ວາຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ອະນຸຍາດໃຫ້, kernel ລະບົບຈະຢຸດຂະບວນການດ້ວຍຄວາມຜິດພາດ "out of memory" (OOM).

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

ໂດຍຫລັກການແລ້ວ, ພວກເຮົາຕ້ອງການຄວາມຕ້ອງການຊັບພະຍາກອນຂອງຝັກເພື່ອປ່ຽນແປງຕະຫຼອດຊີວິດຂອງຂະບວນການໂດຍບໍ່ແຊກແຊງຂະບວນການອື່ນໆໃນລະບົບ - ນັ້ນແມ່ນເປົ້າຫມາຍຂອງການກໍານົດຂອບເຂດຈໍາກັດ.

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

1. ການນໍາໃຊ້ເຄື່ອງມືການທົດສອບການໂຫຼດ, ພວກເຮົາຈໍາລອງລະດັບພື້ນຖານຂອງການຈະລາຈອນແລະຕິດຕາມການນໍາໃຊ້ຊັບພະຍາກອນຝັກ (ຫນ່ວຍຄວາມຈໍາແລະໂປເຊດເຊີ).
2. ພວກເຮົາກໍານົດການຮ້ອງຂໍ pod ເປັນມູນຄ່າຕ່ໍາ arbitrarily (ມີຂອບເຂດຈໍາກັດຂອງຊັບພະຍາກອນປະມານ 5 ເທົ່າຂອງມູນຄ່າການຮ້ອງຂໍ) ແລະສັງເກດເຫັນ. ເມື່ອການຮ້ອງຂໍຕໍ່າເກີນໄປ, ຂະບວນການບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້, ມັກຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດຂອງ Go runtime ທີ່ລຶກລັບ.

ໃຫ້ສັງເກດວ່າການຈໍາກັດຊັບພະຍາກອນທີ່ສູງຂຶ້ນເຮັດໃຫ້ການກໍານົດເວລາມີຄວາມຫຍຸ້ງຍາກຫຼາຍເພາະວ່າ pod ຕ້ອງການ node ເປົ້າຫມາຍທີ່ມີຊັບພະຍາກອນພຽງພໍ.

ຈິນຕະນາການສະຖານະການທີ່ທ່ານມີເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ທີ່ມີນ້ໍາຫນັກເບົາທີ່ມີຂອບເຂດຈໍາກັດຂອງຊັບພະຍາກອນສູງ, ເວົ້າວ່າ 4 GB ຂອງຫນ່ວຍຄວາມຈໍາ. ຂະບວນການນີ້ອາດຈະຕ້ອງປັບຂະຫນາດຕາມແນວນອນ, ແລະແຕ່ລະໂມດູນໃຫມ່ຈະຕ້ອງຖືກກໍານົດໄວ້ໃນ node ທີ່ມີຫນ່ວຍຄວາມຈໍາຢ່າງຫນ້ອຍ 4 GB. ຖ້າບໍ່ມີ node ດັ່ງກ່າວ, cluster ຕ້ອງແນະນຳ node ໃໝ່ເພື່ອປະມວນຜົນ pod ນັ້ນ, ເຊິ່ງອາດຈະໃຊ້ເວລາໄລຍະໜຶ່ງ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮັກສາຄວາມແຕກຕ່າງລະຫວ່າງການຮ້ອງຂໍຊັບພະຍາກອນແລະຂອບເຂດຈໍາກັດຫນ້ອຍທີ່ສຸດເພື່ອຮັບປະກັນການປັບຂະຫນາດໄວແລະລຽບງ່າຍ.

ຂັ້ນ​ຕອນ​ທີ​ສອງ​: ການ​ຕັ້ງ​ຄ່າ​ການ​ທົດ​ສອບ​ການ​ມີ​ຊີ​ວິດ​ແລະ​ຄວາມ​ພ້ອມ​

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

ຊີວິດການເປັນຢູ່ ສະແດງໃຫ້ເຫັນວ່າຖັງກໍາລັງແລ່ນຫຼືບໍ່. ຖ້າມັນລົ້ມເຫລວ, kubelet ຈະຂ້າຕູ້ຄອນເທນເນີແລະນະໂຍບາຍການປິດເປີດໃຫມ່ສໍາລັບມັນ. ຖ້າຕູ້ຄອນເທນເນີບໍ່ມີອຸປະກອນການສືບສວນ Liveness, ຫຼັງຈາກນັ້ນສະຖານະເລີ່ມຕົ້ນຈະປະສົບຜົນສໍາເລັດ - ນີ້ແມ່ນສິ່ງທີ່ມັນເວົ້າໃນ ເອກະສານ Kubernetes.

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

ຖ້າທ່ານກໍານົດທາງເລືອກທີ່ຈະດໍາເນີນການທຸກໆວິນາທີ, ນີ້ຈະເພີ່ມ 1 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ດັ່ງນັ້ນຈົ່ງຮູ້ວ່າຊັບພະຍາກອນເພີ່ມເຕີມຈະມີຄວາມຈໍາເປັນເພື່ອຈັດການກັບການຈະລາຈອນນີ້.

ຢູ່ບໍລິສັດຂອງພວກເຮົາ, ການທົດສອບ Liveness ກວດເບິ່ງອົງປະກອບຫຼັກຂອງແອັບພລິເຄຊັນ, ເຖິງແມ່ນວ່າຂໍ້ມູນ (ຕົວຢ່າງ, ຈາກຖານຂໍ້ມູນຫ່າງໄກສອກຫຼີກຫຼື cache) ແມ່ນບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຢ່າງເຕັມສ່ວນ.

ພວກເຮົາໄດ້ກໍາຫນົດຄ່າແອັບຯທີ່ມີຈຸດສິ້ນສຸດ "ສຸຂະພາບ" ທີ່ພຽງແຕ່ສົ່ງຄືນລະຫັດຕອບສະຫນອງຂອງ 200. ນີ້ແມ່ນຕົວຊີ້ບອກວ່າຂະບວນການກໍາລັງເຮັດວຽກແລະສາມາດດໍາເນີນການຮ້ອງຂໍ (ແຕ່ຍັງບໍ່ທັນມີການຈະລາຈອນ).

ພະຍາຍາມ ຄວາມພ້ອມ ລະບຸວ່າຕູ້ຄອນເທນເນີພ້ອມໃຫ້ບໍລິການຄຳຮ້ອງຂໍຫຼືບໍ່. ຖ້າການສຳຫຼວດຄວາມພ້ອມລົ້ມເຫລວ, ຕົວຄວບຄຸມຈຸດສິ້ນສຸດຈະລຶບທີ່ຢູ່ IP ຂອງຝັກອອກຈາກຈຸດສິ້ນສຸດຂອງບໍລິການທັງໝົດທີ່ສອດຄ້ອງກັບພອດ. ອັນນີ້ຍັງຖືກລະບຸໄວ້ໃນເອກະສານ Kubernetes.

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

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

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

SELECT small_item FROM table LIMIT 1

ນີ້ແມ່ນຕົວຢ່າງຂອງວິທີທີ່ພວກເຮົາຕັ້ງຄ່າສອງຄ່ານີ້ໃນ Kubernetes:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

ທ່ານສາມາດເພີ່ມບາງທາງເລືອກໃນການຕັ້ງຄ່າເພີ່ມເຕີມ:

• initialDelaySeconds — ເວລາເທົ່າໃດວິນາທີຈະຜ່ານລະຫວ່າງການເປີດຕົວຂອງບັນຈຸແລະການເລີ່ມຕົ້ນຂອງຕົວຢ່າງ.
• periodSeconds — ໄລຍະລໍຖ້າລະຫວ່າງການແລ່ນຕົວຢ່າງ.
• timeoutSeconds — ຈໍາ​ນວນ​ວິ​ນາ​ທີ​ຫຼັງ​ຈາກ​ນັ້ນ​ຫນ່ວຍ​ບໍ​ລິ​ການ​ໄດ້​ຮັບ​ການ​ພິ​ຈາ​ລະ​ນາ​ສຸກ​ເສີນ​. ໝົດເວລາປົກກະຕິ.
• failureThreshold — ຈໍາ​ນວນ​ຂອງ​ຄວາມ​ລົ້ມ​ເຫຼວ​ຂອງ​ການ​ທົດ​ສອບ​ກ່ອນ​ທີ່​ຈະ​ມີ​ສັນ​ຍານ​ເລີ່ມ​ຕົ້ນ​ໃຫມ່​ຈະ​ຖືກ​ສົ່ງ​ໄປ​ຫາ​ຝັກ​.
• successThreshold — ຈໍາ​ນວນ​ຂອງ probes ສົບ​ຜົນ​ສໍາ​ເລັດ​ກ່ອນ​ທີ່​ຝັກ​ຈະ​ເຂົ້າ​ໄປ​ໃນ​ສະ​ພາບ​ກຽມ​ພ້ອມ (ຫຼັງ​ຈາກ​ຄວາມ​ລົ້ມ​ເຫຼວ​, ເມື່ອ​ຝັກ​ເລີ່ມ​ຕົ້ນ​ຫຼື​ຟື້ນ​ຕົວ​)​.

ຂັ້ນ​ຕອນ​ທີ​ສາມ​: ການ​ຕັ້ງ​ຄ່າ​ນະ​ໂຍ​ບາຍ​ເຄືອ​ຂ່າຍ​ເລີ່ມ​ຕົ້ນ​ສໍາ​ລັບ pod ໄດ້​

Kubernetes ມີພູມສັນຖານເຄືອຂ່າຍ “ຮາບພຽງ”; ໂດຍຄ່າເລີ່ມຕົ້ນ, ຝັກທັງໝົດຕິດຕໍ່ສື່ສານໂດຍກົງກັບກັນແລະກັນ. ໃນບາງກໍລະນີ, ນີ້ບໍ່ແມ່ນຄວາມປາຖະຫນາ.

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

ຕົວຢ່າງ, ຂ້າງລຸ່ມນີ້ແມ່ນນະໂຍບາຍທີ່ງ່າຍດາຍທີ່ປະຕິເສດການຈະລາຈອນຂາເຂົ້າທັງຫມົດສໍາລັບ namespace ສະເພາະ:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

ການສະແດງພາບຂອງການຕັ້ງຄ່ານີ້:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
ລາຍລະອຽດເພີ່ມເຕີມ ທີ່ນີ້.

ຂັ້ນຕອນທີສີ່: ພຶດຕິກໍາທີ່ກໍາຫນົດເອງໂດຍໃຊ້ hooks ແລະ init containers

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

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

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

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

ແຕ່ວ່າ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

ອີກປະການຫນຶ່ງທີ່ເປັນປະໂຫຍດທີ່ສຸດແມ່ນການນໍາໃຊ້ບັນຈຸ init ເພື່ອຈັດການກັບການເລີ່ມຕົ້ນຂອງຄໍາຮ້ອງສະຫມັກສະເພາະ. ນີ້ແມ່ນເປັນປະໂຫຍດໂດຍສະເພາະຖ້າທ່ານມີຂະບວນການການເຄື່ອນຍ້າຍຖານຂໍ້ມູນທີ່ອີງໃສ່ຊັບພະຍາກອນທີ່ຕ້ອງການດໍາເນີນການກ່ອນທີ່ຈະເລີ່ມຕົ້ນຄໍາຮ້ອງສະຫມັກ. ນອກນັ້ນທ່ານຍັງສາມາດກໍານົດຂອບເຂດຈໍາກັດຂອງຊັບພະຍາກອນທີ່ສູງຂຶ້ນສໍາລັບຂະບວນການນີ້ໂດຍບໍ່ມີການກໍານົດຂອບເຂດຈໍາກັດດັ່ງກ່າວສໍາລັບຄໍາຮ້ອງສະຫມັກຕົ້ນຕໍ.

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

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

ຂັ້ນຕອນທີຫ້າ: ການຕັ້ງຄ່າ Kernel

ສຸດທ້າຍ, ໃຫ້ເວົ້າກ່ຽວກັບເຕັກນິກທີ່ກ້າວຫນ້າກວ່າ.

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

ໃນການສະຫລຸບ

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

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

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

ຖາມຕົວເອງທຸກຄຳຖາມເຫຼົ່ານີ້:

1. ແອັບພລິເຄຊັນໃຊ້ຊັບພະຍາກອນຫຼາຍປານໃດ ແລະປະລິມານນີ້ຈະປ່ຽນແປງແນວໃດ?
2. ຄວາມຕ້ອງການຂະຫນາດທີ່ແທ້ຈິງແມ່ນຫຍັງ? ແອັບຯຈະຈັດການກັບການຈະລາຈອນໂດຍສະເລ່ຍເທົ່າໃດ? ຈະເປັນແນວໃດກ່ຽວກັບການຈະລາຈອນສູງສຸດ?
3. ການບໍລິການຈະຕ້ອງປັບຂະໜາດແນວນອນຫຼາຍປານໃດ? ຝັກໃຫມ່ຈໍາເປັນຕ້ອງຖືກນໍາມາທາງອິນເຕີເນັດໄວເທົ່າໃດເພື່ອຮັບການຈະລາຈອນ?
4. ຝັກປິດຢ່າງຖືກຕ້ອງແນວໃດ? ນີ້ເປັນສິ່ງຈໍາເປັນທັງຫມົດບໍ? ມັນເປັນໄປໄດ້ທີ່ຈະບັນລຸການປະຕິບັດໂດຍບໍ່ມີການ downtime?
5. ທ່ານສາມາດຫຼຸດຜ່ອນຄວາມສ່ຽງດ້ານຄວາມປອດໄພແລະຈໍາກັດຄວາມເສຍຫາຍຈາກຝັກທີ່ຖືກທໍາລາຍແນວໃດ? ບໍລິການໃດມີການອະນຸຍາດ ຫຼືການເຂົ້າເຖິງທີ່ເຂົາເຈົ້າບໍ່ຕ້ອງການບໍ?

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

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

ມີຫຍັງອີກແດ່ທີ່ຈະອ່ານ:

1. ການປະຕິບັດທີ່ດີທີ່ສຸດແລະການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການແລ່ນຕູ້ຄອນເທນເນີແລະ Kubernetes ໃນສະພາບແວດລ້ອມການຜະລິດ.
2. 90+ ເຄື່ອງມືທີ່ເປັນປະໂຫຍດສໍາລັບ Kubernetes: ການນຳໃຊ້, ການຈັດການ, ການຕິດຕາມ, ຄວາມປອດໄພ ແລະອື່ນໆອີກ.
3. ຊ່ອງຂອງພວກເຮົາປະມານ Kubernetes ໃນ Telegram.

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