ເຄັດລັບ ແລະເຄັດລັບ Kubernetes: ຄຸນສົມບັດຂອງການປິດລະບົບຢ່າງສະຫງ່າງາມໃນ NGINX ແລະ PHP-FPM

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

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

ທິດສະດີ. ຝັກມີຊີວິດແນວໃດ

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

ທ່ານກໍ່ຄວນຈື່ໄວ້ວ່າໄລຍະເວລາຜ່ອນຜັນເລີ່ມຕົ້ນແມ່ນ 30 ວິນາທີ: ຫຼັງຈາກນີ້, ຝັກຈະຖືກຢຸດເຊົາແລະຄໍາຮ້ອງສະຫມັກຕ້ອງມີເວລາທີ່ຈະດໍາເນີນການຮ້ອງຂໍທັງຫມົດກ່ອນໄລຍະເວລານີ້. Примечание: ເຖິງ​ແມ່ນ​ວ່າ​ການ​ຮ້ອງ​ຂໍ​ທີ່​ໃຊ້​ເວ​ລາ​ຫຼາຍ​ກ​່​ວາ 5-10 ວິ​ນາ​ທີ​ແມ່ນ​ມີ​ບັນ​ຫາ​, ແລະ​ການ​ປິດ​ຢ່າງ​ສະ​ດວກ​ສະ​ບາຍ​ຈະ​ບໍ່​ໄດ້​ຊ່ວຍ​ໃຫ້​ມັນ​ອີກ​ຕໍ່​ໄປ ...

ເພື່ອເຂົ້າໃຈດີຂຶ້ນວ່າເກີດຫຍັງຂຶ້ນເມື່ອຝັກຢຸດ, ພຽງແຕ່ເບິ່ງແຜນວາດຕໍ່ໄປນີ້:

A1, B1 - ໄດ້ຮັບການປ່ຽນແປງກ່ຽວກັບສະຖານະຂອງ hearth ໄດ້
A2 - SIGTERM ອອກເດີນທາງ
B2 - ການເອົາຝັກອອກຈາກຈຸດສິ້ນສຸດ
B3 - ໄດ້ຮັບການປ່ຽນແປງ (ບັນຊີລາຍຊື່ຂອງຈຸດສິ້ນສຸດມີການປ່ຽນແປງ)
B4 - ປັບປຸງກົດລະບຽບ iptables

ກະ​ລຸ​ນາ​ບັນ​ທຶກ​: ການ​ລຶບ​ພອດ​ຈຸດ​ສິ້ນ​ສຸດ​ແລະ​ການ​ສົ່ງ SIGTERM ບໍ່​ໄດ້​ເກີດ​ຂຶ້ນ​ຕາມ​ລໍາ​ດັບ​, ແຕ່​ໃນ​ຂະ​ຫນານ​. ແລະເນື່ອງຈາກຄວາມຈິງທີ່ວ່າ Ingress ບໍ່ໄດ້ຮັບການປັບປຸງລາຍຊື່ Endpoints ໃນທັນທີ, ການຮ້ອງຂໍໃຫມ່ຈາກລູກຄ້າຈະຖືກສົ່ງໄປຫາຝັກ, ເຊິ່ງຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດ 500 ໃນລະຫວ່າງການຢຸດຝັກ. (ສໍາລັບເອກະສານລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫານີ້, ພວກເຮົາ ແປ). ບັນຫານີ້ຕ້ອງໄດ້ຮັບການແກ້ໄຂດ້ວຍວິທີດັ່ງຕໍ່ໄປນີ້:

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

ທິດສະດີ. ວິທີການ NGINX ແລະ PHP-FPM ຢຸດເຊົາຂະບວນການຂອງພວກເຂົາ

NGINX

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍ NGINX, ເພາະວ່າທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງຫຼາຍຫຼືຫນ້ອຍກັບມັນ. ການເຂົ້າໄປໃນທິດສະດີ, ພວກເຮົາຮຽນຮູ້ວ່າ NGINX ມີຂະບວນການຕົ້ນສະບັບຫນຶ່ງແລະ "ພະນັກງານ" ຫຼາຍ - ເຫຼົ່ານີ້ແມ່ນຂະບວນການເດັກນ້ອຍທີ່ດໍາເນີນການຮ້ອງຂໍຂອງລູກຄ້າ. ທາງເລືອກທີ່ສະດວກແມ່ນສະຫນອງໃຫ້: ການນໍາໃຊ້ຄໍາສັ່ງ nginx -s <SIGNAL> ຢຸດຂະບວນການທັງໃນໂຫມດປິດໄວ ຫຼື ໂໝດປິດຢ່າງສະຫຼາດ. ແນ່ນອນ, ມັນແມ່ນທາງເລືອກສຸດທ້າຍທີ່ພວກເຮົາສົນໃຈ.

ຫຼັງຈາກນັ້ນ, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ: ທ່ານຈໍາເປັນຕ້ອງເພີ່ມໃສ່ preStop-hook ຄໍາສັ່ງທີ່ຈະສົ່ງສັນຍານປິດທີ່ສະຫງ່າງາມ. ນີ້ສາມາດເຮັດໄດ້ໃນ Deployment, ໃນ container block:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

ດຽວນີ້, ເມື່ອຝັກປິດລົງ, ພວກເຮົາຈະເຫັນສິ່ງຕໍ່ໄປນີ້ຢູ່ໃນບັນທຶກບັນຈຸ NGINX:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

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

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

ຂໍ້ຕົກລົງກັບ PHP-FPM ແມ່ນຫຍັງ? ມັນຈັດການກັບການປິດຢ່າງສະຫງ່າງາມແນວໃດ? ໃຫ້ຄິດອອກ.

PHP-FPM

ໃນກໍລະນີຂອງ PHP-FPM, ມີຂໍ້ມູນຫນ້ອຍລົງ. ຖ້າທ່ານສຸມໃສ່ ຄູ່​ມື​ຢ່າງ​ເປັນ​ທາງ​ການ​ ອີງຕາມ PHP-FPM, ມັນຈະເວົ້າວ່າສັນຍານ POSIX ຕໍ່ໄປນີ້ຖືກຍອມຮັບ:

1. SIGINT, SIGTERM - ປິດ​ໄວ​;
2. SIGQUIT — ການ​ປິດ​ຢ່າງ​ສະ​ຫງ່າ​ງາມ (ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​)​.

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

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

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

ປະຕິບັດ. ບັນຫາທີ່ເປັນໄປໄດ້ກັບການປິດທີ່ດີ

NGINX

ກ່ອນອື່ນ ໝົດ, ມັນເປັນປະໂຫຍດທີ່ຈະຈື່ຈໍາ: ນອກເຫນືອຈາກການປະຕິບັດຄໍາສັ່ງ nginx -s quit ມີອີກໜຶ່ງຂັ້ນຕອນທີ່ຄວນເອົາໃຈໃສ່. ພວກເຮົາພົບບັນຫາທີ່ NGINX ຍັງຈະສົ່ງ SIGTERM ແທນສັນຍານ SIGQUIT, ເຮັດໃຫ້ການຮ້ອງຂໍບໍ່ສໍາເລັດຢ່າງຖືກຕ້ອງ. ກໍລະນີທີ່ຄ້າຍຄືກັນສາມາດພົບໄດ້, ສໍາລັບການຍົກຕົວຢ່າງ, ທີ່ນີ້. ແຕ່ຫນ້າເສຍດາຍ, ພວກເຮົາບໍ່ສາມາດກໍານົດເຫດຜົນສະເພາະສໍາລັບພຶດຕິກໍານີ້: ມີຄວາມສົງໃສກ່ຽວກັບຮຸ່ນ NGINX, ແຕ່ມັນບໍ່ໄດ້ຮັບການຢືນຢັນ. ອາການແມ່ນວ່າຂໍ້ຄວາມໄດ້ຖືກສັງເກດເຫັນຢູ່ໃນບັນທຶກບັນຈຸ NGINX: "ເປີດເຕົ້າຮັບ #10 ຊ້າຍໃນການເຊື່ອມຕໍ່ 5", ຫຼັງຈາກນັ້ນຝັກໄດ້ຢຸດເຊົາ.

ພວກເຮົາສາມາດສັງເກດເຫັນບັນຫາດັ່ງກ່າວ, ສໍາລັບການຍົກຕົວຢ່າງ, ຈາກຄໍາຕອບກ່ຽວກັບ Ingress ທີ່ພວກເຮົາຕ້ອງການ:

ຕົວຊີ້ບອກຂອງລະຫັດສະຖານະໃນເວລາທີ່ການນໍາໃຊ້

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

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

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

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

PHP-FPM ... ແລະອື່ນໆອີກ

ບັນຫາກັບ PHP-FPM ໄດ້ຖືກອະທິບາຍໃນແບບຫຍໍ້ໆ: ມັນບໍ່ໄດ້ລໍຖ້າການສໍາເລັດຂອງຂະບວນການເດັກ, ມັນຢຸດພວກມັນ, ຊຶ່ງເປັນເຫດຜົນ 502 ຂໍ້ຜິດພາດເກີດຂື້ນໃນລະຫວ່າງການປະຕິບັດແລະການດໍາເນີນງານອື່ນໆ. ມີຫຼາຍບົດລາຍງານກ່ຽວກັບ bug.php.net ຕັ້ງແຕ່ປີ 2005 (ຕົວຢ່າງ ທີ່ນີ້ и ທີ່ນີ້), ເຊິ່ງອະທິບາຍບັນຫານີ້. ແຕ່ທ່ານອາດຈະບໍ່ເຫັນຫຍັງຢູ່ໃນບັນທຶກ: PHP-FPM ຈະປະກາດການສໍາເລັດຂະບວນການຂອງມັນໂດຍບໍ່ມີຂໍ້ຜິດພາດຫຼືການແຈ້ງເຕືອນຈາກພາກສ່ວນທີສາມ.

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

ມັນສະແດງໃຫ້ເຫັນວ່າ lifecycle ສໍາລັບຕູ້ຄອນເທນເນີຈະມີລັກສະນະນີ້:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກ 30 ວິນາທີ sleep мы ຫຼາຍ ພວກ​ເຮົາ​ຈະ​ເພີ່ມ​ເວ​ລາ​ການ​ປະ​ຕິ​ບັດ, ນັບ​ຕັ້ງ​ແຕ່​ແຕ່​ລະ​ຝັກ​ຈະ​ຖືກ​ລະ​ງັບ​ ຕໍາ່ສຸດທີ່ 30 ວິນາທີ, ເຊິ່ງບໍ່ດີ. ສິ່ງທີ່ສາມາດເຮັດໄດ້ກ່ຽວກັບເລື່ອງນີ້?

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

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

ສະນັ້ນ, ໃນຈໍານວນທັງຫມົດ ກັບຄໍາສັ່ງທີ່ໄດ້ກ່າວມາແລ້ວ process_control_timeout ທ່ານສາມາດນໍາໃຊ້ການກໍ່ສ້າງດັ່ງຕໍ່ໄປນີ້ສໍາລັບ lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

ໃນກໍລະນີນີ້, ພວກເຮົາຈະຊົດເຊີຍການຊັກຊ້າກັບຄໍາສັ່ງ sleep ແລະບໍ່ເພີ່ມເວລາໃນການນໍາໃຊ້ຢ່າງຫຼວງຫຼາຍ: ມີຄວາມແຕກຕ່າງກັນລະຫວ່າງ 30 ວິນາທີແລະຫນຶ່ງທີ່ສັງເກດເຫັນບໍ? ... ໃນຄວາມເປັນຈິງ, ມັນແມ່ນ process_control_timeoutແລະ lifecycle ຖືກນໍາໃຊ້ພຽງແຕ່ເປັນ "ຕາຫນ່າງຄວາມປອດໄພ" ໃນກໍລະນີຂອງຄວາມຊັກຊ້າ.

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

ປະຕິບັດ. ໂຫຼດການທົດສອບເພື່ອກວດກາເບິ່ງການດໍາເນີນງານຂອງຝັກ

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

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

nuance ອື່ນແມ່ນການເບິ່ງບັນທຶກພາຊະນະໃນລະຫວ່າງການຢຸດຂອງມັນ. ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ການ​ປິດ​ຢ່າງ​ສະ​ດວກ​ສະ​ບາຍ​ໄດ້​ຖືກ​ບັນ​ທຶກ​ໄວ້​ທີ່​ນັ້ນ​? ມີຂໍ້ຜິດພາດໃດໆໃນບັນທຶກໃນເວລາທີ່ເຂົ້າເຖິງຊັບພະຍາກອນອື່ນໆ (ຕົວຢ່າງເຊັ່ນຕູ້ຄອນເທນເນີ PHP-FPM ທີ່ໃກ້ຄຽງ)? ຂໍ້ຜິດພາດໃນແອັບພລິເຄຊັນຕົວມັນເອງ (ຄືກັບ NGINX ທີ່ອະທິບາຍຂ້າງເທິງ)? ຂ້າພະເຈົ້າຫວັງວ່າຂໍ້ມູນແນະນໍາຈາກບົດຄວາມນີ້ຈະຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈດີຂຶ້ນກ່ຽວກັບສິ່ງທີ່ເກີດຂື້ນກັບຖັງໃນລະຫວ່າງການປິດຂອງມັນ.

ດັ່ງນັ້ນ, ການທົດສອບຄັ້ງທໍາອິດໄດ້ຈັດຂຶ້ນໂດຍບໍ່ມີການ lifecycle ແລະໂດຍບໍ່ມີຄໍາແນະນໍາເພີ່ມເຕີມສໍາລັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນ (process_control_timeout ໃນ PHP-FPM). ຈຸດປະສົງຂອງການທົດສອບນີ້ແມ່ນເພື່ອກໍານົດຈໍານວນໂດຍປະມານຂອງຄວາມຜິດພາດ (ແລະບໍ່ວ່າຈະມີ). ນອກຈາກນັ້ນ, ຈາກຂໍ້ມູນເພີ່ມເຕີມ, ທ່ານຄວນຮູ້ວ່າເວລາປະຕິບັດໂດຍສະເລ່ຍສໍາລັບແຕ່ລະຝັກແມ່ນປະມານ 5-10 ວິນາທີຈົນກ່ວາມັນກຽມພ້ອມຢ່າງເຕັມທີ່. ຜົນໄດ້ຮັບແມ່ນ:

ແຜງຂໍ້ມູນ Yandex.Tank ສະແດງໃຫ້ເຫັນເຖິງຄວາມຜິດພາດ 502 ເພີ່ມຂຶ້ນ, ເຊິ່ງເກີດຂຶ້ນໃນເວລາຂອງການຕິດຕັ້ງແລະໃຊ້ເວລາໂດຍສະເລ່ຍເຖິງ 5 ວິນາທີ. ຄາດວ່ານີ້ແມ່ນຍ້ອນວ່າການຮ້ອງຂໍທີ່ມີຢູ່ກັບຝັກເກົ່າຖືກຢຸດເຊົາໃນເວລາທີ່ມັນຖືກຍົກເລີກ. ຫຼັງຈາກນີ້, 503 ຂໍ້ຜິດພາດປາກົດ, ເຊິ່ງເປັນຜົນມາຈາກການຢຸດເຊົາການບັນຈຸ NGINX, ເຊິ່ງຍັງຫຼຸດລົງການເຊື່ອມຕໍ່ເນື່ອງຈາກ backend (ເຊິ່ງປ້ອງກັນບໍ່ໃຫ້ Ingress ເຊື່ອມຕໍ່ກັບມັນ).

ໃຫ້ເບິ່ງວິທີການ process_control_timeout ໃນ PHP-FPM ຈະຊ່ວຍໃຫ້ພວກເຮົາລໍຖ້າການສໍາເລັດຂອງຂະບວນການເດັກ, i.e. ແກ້​ໄຂ​ຄວາມ​ຜິດ​ພາດ​ດັ່ງ​ກ່າວ​. ນຳໃຊ້ຄືນໃໝ່ໂດຍໃຊ້ຄຳສັ່ງນີ້:

ບໍ່ມີຂໍ້ຜິດພາດອີກຕໍ່ໄປໃນລະຫວ່າງການນຳໃຊ້ 500th! ການ​ປະ​ຕິ​ບັດ​ແມ່ນ​ສົບ​ຜົນ​ສໍາ​ເລັດ​, ການ​ປິດ​ທີ່​ສະ​ດວກ​ສະ​ບາຍ​ເຮັດ​ວຽກ​.

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

ສະຫລຸບ

ເພື່ອຢຸດຂະບວນການຢ່າງສະຫງ່າງາມ, ພວກເຮົາຄາດຫວັງວ່າການປະພຶດຕໍ່ໄປນີ້ຈາກແອັບພລິເຄຊັນ:

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

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

• ເພີ່ມ hook ທາງສ່ວນຫນ້າຂອງຢຸດທີ່ຈະລໍຖ້າສອງສາມວິນາທີ;
• ການສຶກສາໄຟລ໌ການຕັ້ງຄ່າຂອງ backend ຂອງພວກເຮົາສໍາລັບພາລາມິເຕີທີ່ເຫມາະສົມ.

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

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

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

PS

ອື່ນໆຈາກຊຸດເຄັດລັບ ແລະເຄັດລັບຂອງ K8s:

• «ໜ້າຂໍ້ຜິດພາດແບບກຳນົດເອງໃນ NGINX Ingress"
• «ກ່ຽວກັບການຈັດສັນ node ແລະການໂຫຼດໃນແອັບພລິເຄຊັນເວັບ"
• «ການເຂົ້າເຖິງເວັບໄຊທ໌ dev"
• «ເລັ່ງ bootstrap ສໍາລັບຖານຂໍ້ມູນຂະຫນາດໃຫຍ່".

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