ການສືບສວນການມີຊີວິດຢູ່ໃນ Kubernetes ສາມາດເປັນອັນຕະລາຍ

ຫມາຍ​ເຫດ​. ແປ.: ວິສະວະກອນຊັ້ນນໍາຈາກ Zalando, Henning Jacobs, ໄດ້ສັງເກດເຫັນຫຼາຍຄັ້ງບັນຫາໃນບັນດາຜູ້ໃຊ້ Kubernetes ໃນການເຂົ້າໃຈຈຸດປະສົງຂອງການມີຊີວິດ (ແລະຄວາມພ້ອມ) probes ແລະການນໍາໃຊ້ທີ່ຖືກຕ້ອງຂອງພວກເຂົາ. ດັ່ງນັ້ນ, ລາວໄດ້ລວບລວມຄວາມຄິດຂອງລາວໃນບັນທຶກທີ່ມີຄວາມສາມາດນີ້, ເຊິ່ງໃນທີ່ສຸດຈະກາຍເປັນສ່ວນຫນຶ່ງຂອງເອກະສານ K8s.

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

ເພື່ອນຮ່ວມງານຂອງຂ້ອຍ Sandor ບໍ່ດົນມານີ້ໄດ້ແບ່ງປັນໃນ Twitter ກ່ຽວກັບຄວາມຜິດພາດທົ່ວໄປທີ່ສຸດທີ່ລາວພົບ, ລວມທັງສິ່ງທີ່ກ່ຽວຂ້ອງກັບການນໍາໃຊ້ການກຽມພ້ອມ / ການກວດສອບຊີວິດ:

ຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ livenessProbe ສາມາດເຮັດໃຫ້ສະຖານະການການໂຫຼດສູງ (ການປິດ snowball + ໄລຍະເວລາການເລີ່ມຕົ້ນຂອງຕູ້ຄອນເທນເນີທີ່ມີທ່າແຮງຍາວ) ແລະນໍາໄປສູ່ຜົນສະທ້ອນທາງລົບອື່ນໆເຊັ່ນ: ການຫຼຸດລົງຂອງການເພິ່ງພາອາໄສ. (ເບິ່ງຍັງ ບົດຄວາມທີ່ຜ່ານມາຂອງຂ້ອຍ ກ່ຽວກັບການຈໍາກັດຈໍານວນການຮ້ອງຂໍໃນການປະສົມປະສານ K3s + ACME). ມັນຮ້າຍແຮງກວ່າເກົ່າເມື່ອການສືບສວນການມີຊີວິດໄດ້ຖືກລວມເຂົ້າກັບການກວດສຸຂະພາບ, ເຊິ່ງເປັນຖານຂໍ້ມູນພາຍນອກ: ຄວາມລົ້ມເຫຼວຂອງ DB ດຽວຈະ restart ກ່ອງບັນຈຸທັງຫມົດຂອງທ່ານ!

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

ຫມາຍເຫດ: ການທົດສອບສ່ວນໃຫຍ່ຂ້າງລຸ່ມນີ້ແມ່ນລວມຢູ່ໃນເອກະສານນັກພັດທະນາພາຍໃນຂອງ Zalando.

ການກວດສອບຄວາມພ້ອມ ແລະຊີວິດການເປັນຢູ່

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

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

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

ຖ້າທ່ານພະຍາຍາມຕິດຕັ້ງການອັບເດດແອັບພລິເຄຊັນທີ່ລົ້ມເຫລວໃນການກວດສອບຄວາມພ້ອມ / ຄວາມພ້ອມ, ການເປີດຕົວຂອງມັນຈະຖືກຢຸດໃນຂະນະທີ່ Kubernetes ລໍຖ້າສະຖານະ Ready ຈາກຝັກທັງໝົດ.

ຕົວຢ່າງ:

ນີ້ແມ່ນຕົວຢ່າງຂອງການສຳຫຼວດຄວາມພ້ອມໃນການກວດສອບເສັ້ນທາງ /health ຜ່ານ HTTP ດ້ວຍການຕັ້ງຄ່າເລີ່ມຕົ້ນ (ໄລຍະຫ່າງ: 10 ວິນາທີ, ຫມົດ​ເວ​ລາ: 1 ວິນາທີ, ເກນຄວາມສຳເລັດ: 1, ເກນຄວາມລົ້ມເຫຼວ: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

ຂໍ້ສະເຫນີແນະ

1. ສໍາລັບການບໍລິການຈຸລະພາກທີ່ມີຈຸດສິ້ນສຸດ HTTP (REST, ແລະອື່ນໆ) ກຳນົດການສຳຫຼວດຄວາມພ້ອມສະເໝີ, ເຊິ່ງກວດເບິ່ງວ່າແອັບພລິເຄຊັນ (pod) ແມ່ນພ້ອມທີ່ຈະຍອມຮັບການຈະລາຈອນ.
2. ໃຫ້ແນ່ໃຈວ່າການສືບສວນການກຽມພ້ອມ ກວມເອົາຄວາມພ້ອມຂອງພອດເຊີບເວີເວັບຕົວຈິງ:
   • ການນໍາໃຊ້ພອດສໍາລັບຈຸດປະສົງການບໍລິຫານ, ເອີ້ນວ່າ "admin" ຫຼື "ການຄຸ້ມຄອງ" (ຕົວຢ່າງ, 9090), ສໍາລັບ readinessProbe, ໃຫ້ແນ່ໃຈວ່າຈຸດສິ້ນສຸດພຽງແຕ່ກັບຄືນ OK ຖ້າພອດ HTTP ຕົ້ນຕໍ (ເຊັ່ນ 8080) ພ້ອມທີ່ຈະຮັບການຈະລາຈອນ*;

     *ຂ້ອຍຮູ້ຢ່າງນ້ອຍໜຶ່ງກໍລະນີຢູ່ Zalando ບ່ອນທີ່ມັນບໍ່ໄດ້ເກີດຂຶ້ນ, i.e. readinessProbe ຂ້ອຍໄດ້ກວດເບິ່ງພອດ "ການຈັດການ", ແຕ່ເຄື່ອງແມ່ຂ່າຍຂອງມັນເອງບໍ່ໄດ້ເລີ່ມເຮັດວຽກຍ້ອນບັນຫາໃນການໂຫລດ cache.

   • ການຕິດອຸປະກອນການກຽມພ້ອມກັບພອດແຍກຕ່າງຫາກສາມາດນໍາໄປສູ່ຄວາມຈິງທີ່ວ່າການໂຫຼດເກີນຢູ່ໃນພອດຕົ້ນຕໍຈະບໍ່ຖືກສະທ້ອນໃຫ້ເຫັນໃນການກວດສຸຂະພາບ (ຫມາຍຄວາມວ່າ, ສະນຸກເກີ thread ໃນເຄື່ອງແມ່ຂ່າຍແມ່ນເຕັມ, ແຕ່ການກວດສອບສຸຂະພາບຍັງສະແດງໃຫ້ເຫັນວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນ OK. ).
3. ໃຫ້ແນ່ໃຈວ່າວ່າ ການສືບສວນຄວາມພ້ອມເຮັດໃຫ້ການເລີ່ມຕົ້ນ/ການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ;
   • ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະບັນລຸນີ້ແມ່ນການຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ HTTP ພຽງແຕ່ຫຼັງຈາກການເລີ່ມຕົ້ນສໍາເລັດ (ຕົວຢ່າງ, ການເຄື່ອນຍ້າຍຖານຂໍ້ມູນຈາກ. ເສັ້ນທາງບິນ ແລະ ອື່ນໆ.); ນັ້ນແມ່ນ, ແທນທີ່ຈະປ່ຽນສະຖານະການກວດສຸຂະພາບ, ພຽງແຕ່ບໍ່ເລີ່ມຕົ້ນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ຈົນກ່ວາການເຄື່ອນຍ້າຍຖານຂໍ້ມູນຈະສໍາເລັດ *.

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

4. ໃຊ້ httpGet ສໍາລັບການກວດສອບຄວາມພ້ອມຜ່ານຈຸດສິ້ນສຸດການກວດສຸຂະພາບປົກກະຕິ (ຕົວຢ່າງ, /health).
5. ເຂົ້າໃຈຕົວກໍານົດການກວດສອບຄ່າເລີ່ມຕົ້ນ (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ຕົວເລືອກເລີ່ມຕົ້ນຫມາຍຄວາມວ່າຝັກຈະກາຍເປັນ ບໍ່​ພ້ອມ ຫຼັງ​ຈາກ​ປະ​ມານ 30 ວິ​ນາ​ທີ (3 ການ​ກວດ​ສອບ​ສຸ​ຂະ​ພາບ​ບໍ່​ສໍາ​ເລັດ​)​.
6. ໃຊ້ພອດແຍກຕ່າງຫາກສໍາລັບ "admin" ຫຼື "ການຄຸ້ມຄອງ" ຖ້າຫາກວ່າ stack ເຕັກໂນໂລຊີ (ເຊັ່ນ: Java / Spring) ອະນຸຍາດໃຫ້ມັນ, ເພື່ອແຍກການຄຸ້ມຄອງສຸຂະພາບແລະ metrics ຈາກການຈະລາຈອນປົກກະຕິ:
   • ແຕ່ຢ່າລືມກ່ຽວກັບຈຸດ 2.
7. ຖ້າຈໍາເປັນ, ການສືບສວນຄວາມພ້ອມສາມາດຖືກນໍາໃຊ້ເພື່ອອົບອຸ່ນຂຶ້ນ / ໂຫຼດ cache ແລະສົ່ງຄືນລະຫັດສະຖານະ 503 ຈົນກ່ວາຖັງອຸ່ນຂຶ້ນ:
   • ຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ທ່ານອ່ານການກວດສອບໃຫມ່ startupProbe, ປາກົດຢູ່ໃນສະບັບ 1.16 (ພວກເຮົາຂຽນກ່ຽວກັບມັນໃນພາສາລັດເຊຍ ທີ່ນີ້ — ປະ​ມານ​. ແປ.).

Caveats

1. ຢ່າອີງໃສ່ການເພິ່ງພາອາໄສພາຍນອກ (ເຊັ່ນ: ຄັງເກັບຂໍ້ມູນ) ເມື່ອດໍາເນີນການທົດສອບຄວາມພ້ອມ/ການດໍາລົງຊີວິດ - ນີ້ສາມາດນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງ cascading:
   • ເປັນຕົວຢ່າງ, ໃຫ້ເອົາການບໍລິການ REST ທີ່ມີລັດທີ່ມີ 10 pods ຂຶ້ນກັບຖານຂໍ້ມູນ Postgres: ເມື່ອການກວດສອບແມ່ນຂຶ້ນກັບການເຊື່ອມຕໍ່ທີ່ເຮັດວຽກກັບ DB, ທັງຫມົດ 10 pods ອາດຈະລົ້ມເຫລວຖ້າຫາກວ່າມີຄວາມຊັກຊ້າໃນເຄືອຂ່າຍ / DB - ປົກກະຕິແລ້ວມັນ. ສິ້ນ ສຸດ ລົງ ທັງ ຫມົດ ຮ້າຍ ແຮງ ກວ່າ ທີ່ ມັນ ສາ ມາດ ເຮັດ ໄດ້;
   • ກະລຸນາສັງເກດວ່າ Spring Data ກວດສອບການເຊື່ອມຕໍ່ຖານຂໍ້ມູນໂດຍຄ່າເລີ່ມຕົ້ນ*;

     * ນີ້ແມ່ນພຶດຕິກໍາເລີ່ມຕົ້ນຂອງ Spring Data Redis (ຢ່າງຫນ້ອຍມັນແມ່ນຄັ້ງສຸດທ້າຍທີ່ຂ້ອຍກວດເບິ່ງ), ເຊິ່ງນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງ "ໄພພິບັດ": ເມື່ອ Redis ບໍ່ສາມາດໃຊ້ໄດ້ໃນເວລາສັ້ນໆ, ຝັກທັງຫມົດ " crashed ".

   • "ພາຍນອກ" ໃນຄວາມຫມາຍນີ້ຍັງສາມາດຫມາຍຄວາມວ່າຝັກອື່ນໆຂອງຄໍາຮ້ອງສະຫມັກດຽວກັນ, ນັ້ນແມ່ນ, ໂດຍທົ່ວໄປແລ້ວການກວດສອບບໍ່ຄວນຂຶ້ນກັບສະຖານະຂອງຝັກອື່ນໆຂອງກຸ່ມດຽວກັນເພື່ອປ້ອງກັນບໍ່ໃຫ້ເກີດຄວາມເສຍຫາຍ:
     • ຜົນໄດ້ຮັບອາດຈະແຕກຕ່າງກັນສໍາລັບແອັບພລິເຄຊັນທີ່ມີສະຖານະແຈກຢາຍ (ຕົວຢ່າງເຊັ່ນ, ການເກັບຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາໃນຝັກ).
2. ຢ່າໃຊ້ເຄື່ອງກວດຫາຊີວິດ ສໍາລັບຝັກ (ຂໍ້ຍົກເວັ້ນແມ່ນກໍລະນີທີ່ພວກມັນມີຄວາມຈໍາເປັນແທ້ໆແລະທ່ານຮູ້ຢ່າງເຕັມສ່ວນກ່ຽວກັບສະເພາະແລະຜົນສະທ້ອນຂອງການນໍາໃຊ້ຂອງມັນ):
   • ການສືບສວນການມີຊີວິດສາມາດຊ່ວຍຟື້ນຟູພາຊະນະທີ່ຖືກຫ້ອຍໄດ້, ແຕ່ຍ້ອນວ່າທ່ານມີການຄວບຄຸມຢ່າງເຕັມທີ່ກ່ຽວກັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ສິ່ງຕ່າງໆເຊັ່ນຂະບວນການ hung ແລະ deadlocks ບໍ່ຄວນເກີດຂື້ນ: ທາງເລືອກທີ່ດີທີ່ສຸດແມ່ນການປິດແອັບພລິເຄຊັນໂດຍເຈດຕະນາແລະເຮັດໃຫ້ມັນກັບຄືນສູ່ສະພາບເດີມ;
   • ການສືບສວນການມີຊີວິດທີ່ລົ້ມເຫລວຈະເຮັດໃຫ້ຕູ້ຄອນເທນເນີຣີສະຕາດ, ເຊິ່ງອາດຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດທີ່ກ່ຽວຂ້ອງກັບການໂຫຼດ: ການປິດເປີດກ່ອງບັນຈຸໃໝ່ຈະເຮັດໃຫ້ມີການຢຸດເຮັດວຽກ (ຢ່າງນ້ອຍໃນໄລຍະເວລາຂອງການເລີ່ມຕົ້ນແອັບພລິເຄຊັນ, ເວົ້າວ່າ 30 ວິນາທີ), ເຊິ່ງກໍ່ໃຫ້ເກີດຄວາມຜິດພາດໃໝ່. , ການເພີ່ມການໂຫຼດຂອງບັນຈຸອື່ນໆແລະເພີ່ມຄວາມເປັນໄປໄດ້ຂອງຄວາມລົ້ມເຫຼວຂອງເຂົາເຈົ້າ, ແລະອື່ນໆ;
   • ການກວດສອບຊີວິດລວມກັບການເພິ່ງພາອາໄສພາຍນອກແມ່ນການປະສົມປະສານທີ່ຮ້າຍແຮງທີ່ສຸດ, ໄພຂົ່ມຂູ່ຕໍ່ຄວາມລົ້ມເຫຼວຂອງ cascading: ການຊັກຊ້າເລັກນ້ອຍໃນດ້ານຖານຂໍ້ມູນຈະນໍາໄປສູ່ການ restart ຂອງບັນຈຸທັງຫມົດຂອງທ່ານ!
3. ຕົວກໍານົດການຂອງການກວດສອບຊີວິດແລະຄວາມພ້ອມ ຈະຕ້ອງແຕກຕ່າງກັນ:
   • ທ່ານ​ສາ​ມາດ​ໃຊ້​ການ​ສືບ​ສວນ​ການ​ມີ​ຊີ​ວິດ​ທີ່​ມີ​ການ​ກວດ​ສອບ​ສຸ​ຂະ​ພາບ​ດຽວ​ກັນ​, ແຕ່​ລະ​ດັບ​ການ​ຕອບ​ສະ​ຫນອງ​ສູງ​ກວ່າ (failureThreshold), ສໍາລັບການຍົກຕົວຢ່າງ, ກໍານົດສະຖານະພາບ ບໍ່​ພ້ອມ ຫຼັງຈາກ 3 ຄວາມພະຍາຍາມແລະພິຈາລະນາວ່າການສືບສວນການດໍາລົງຊີວິດໄດ້ລົ້ມເຫລວຫຼັງຈາກ 10 ຄວາມພະຍາຍາມ;
4. ຢ່າໃຊ້ການກວດສອບ exec, ນັບຕັ້ງແຕ່ພວກມັນກ່ຽວຂ້ອງກັບບັນຫາທີ່ຮູ້ຈັກທີ່ນໍາໄປສູ່ການປະກົດຕົວຂອງຂະບວນການ zombie:
   • ລາຍລະອຽດ: ເບິ່ງ ການນໍາສະເຫນີໂດຍຜູ້ຊ່ຽວຊານ Datadog.

Summary

• ໃຊ້ການສຳຫຼວດຄວາມພ້ອມເພື່ອກຳນົດເວລາທີ່ຝັກພ້ອມຮັບການຈະລາຈອນ.
• ໃຊ້ເຄື່ອງກວດການມີຊີວິດພຽງແຕ່ເມື່ອພວກມັນຕ້ອງການແທ້ໆ.
• ການນຳໃຊ້ເຄື່ອງກວດຄວາມພ້ອມ/ຊີວິດການເປັນຢູ່ທີ່ບໍ່ເໝາະສົມສາມາດນຳໄປສູ່ການຫຼຸດຄວາມພ້ອມ ແລະ ຄວາມລົ້ມເຫຼວຂອງຕົວລະຄອນ.

ເອກະສານເພີ່ມເຕີມໃນຫົວຂໍ້

• Kubernetes docs: ກຳນົດຄ່າການສຳຫຼວດຄວາມພ້ອມ ແລະ ຄວາມພ້ອມ;
• Kubernetes Liveness ແລະຄວາມພ້ອມ Probes ທົບທວນຄືນ: ວິທີການຫຼີກເວັ້ນການຍິງຕົວເອງໃສ່ຕີນອື່ນ;
• NRE Labs Outage Post-mortem (ລາວຍັງເວົ້າກ່ຽວກັບຊີວິດProbe).

ອັບເດດເບີ 1 2019-09-29

ກ່ຽວກັບບັນຈຸ init ສໍາລັບການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ: ເພີ່ມຂໍ້ຄວາມທ້າຍ.

EJ ເຕືອນຂ້ອຍ ກ່ຽວກັບ PDB: ຫນຶ່ງໃນບັນຫາທີ່ມີການກວດສອບຊີວິດແມ່ນການຂາດການປະສານງານລະຫວ່າງຝັກ. Kubernetes ມີ Pod Disruption Budgets (PDB) ເພື່ອຈໍາກັດຈໍານວນຂອງຄວາມລົ້ມເຫລວພ້ອມກັນທີ່ຄໍາຮ້ອງສະຫມັກສາມາດປະສົບ, ຢ່າງໃດກໍຕາມການກວດສອບບໍ່ໄດ້ຄໍານຶງເຖິງ PDB. ໂດຍຫລັກການແລ້ວ, ພວກເຮົາສາມາດບອກ K8s ໃຫ້ "ຣີສະຕາດຫນຶ່ງຝັກຖ້າການທົດສອບລົ້ມເຫລວ, ແຕ່ຢ່າ restart ພວກມັນທັງຫມົດເພື່ອຫຼີກເວັ້ນການເຮັດໃຫ້ສິ່ງທີ່ຮ້າຍແຮງຂຶ້ນ."

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

ອັບເດດເບີ 2 2019-09-29

ກ່ຽວກັບການອ່ານເອກະສານກ່ອນການນໍາໃຊ້: ຂ້ອຍສ້າງຄໍາຮ້ອງຂໍທີ່ສອດຄ້ອງກັນ (ການຮ້ອງຂໍຄຸນນະສົມບັດ) ເພື່ອ​ເພີ່ມ​ເອ​ກະ​ສານ​ກ່ຽວ​ກັບ​ການ probes ຊີ​ວິດ​.

PS ຈາກນັກແປ

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

• «Kubernetes: Pod Life"
• «7 ການປະຕິບັດທີ່ດີທີ່ສຸດສໍາລັບການນໍາໃຊ້ containers ອີງຕາມ Google"
• «7 ຫຼັກການໃນການອອກແບບຄໍາຮ້ອງສະຫມັກທີ່ໃຊ້ໃນຕູ້ຄອນເທນເນີ".

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