គន្លឹះ និងល្បិច Kubernetes៖ លក្ខណៈពិសេសនៃការបិទយ៉ាងប្រណិតនៅក្នុង NGINX និង PHP-FPM

លក្ខខណ្ឌធម្មតានៅពេលអនុវត្ត CI/CD នៅក្នុង Kubernetes៖ កម្មវិធីត្រូវតែមិនអាចទទួលយកសំណើរបស់អតិថិជនថ្មី មុនពេលបញ្ឈប់ទាំងស្រុង ហើយសំខាន់បំផុតគឺ បញ្ចប់ដោយជោគជ័យនូវអ្វីដែលមានស្រាប់។

ការអនុលោមតាមលក្ខខណ្ឌនេះអនុញ្ញាតឱ្យអ្នកសម្រេចបាននូវពេលវេលារងចាំសូន្យក្នុងអំឡុងពេលដាក់ពង្រាយ។ ទោះយ៉ាងណាក៏ដោយ សូម្បីតែនៅពេលប្រើកញ្ចប់ដែលពេញនិយមខ្លាំង (ដូចជា NGINX និង PHP-FPM) អ្នកអាចជួបប្រទះការលំបាកដែលនឹងនាំឱ្យមានការកើនឡើងនៃកំហុសជាមួយនឹងការដាក់ពង្រាយនីមួយៗ ...

ទ្រឹស្ដី។ របៀបដែល pod រស់នៅ

យើង​បាន​ចុះ​ផ្សាយ​យ៉ាង​លម្អិត​អំពី​វដ្ដ​ជីវិត​របស់​ផត អត្ថបទនេះ. នៅក្នុងបរិបទនៃប្រធានបទដែលកំពុងពិចារណា យើងចាប់អារម្មណ៍លើចំណុចខាងក្រោម៖ នៅពេល pod ចូលរដ្ឋ បញ្ចប់សំណើថ្មីឈប់ផ្ញើទៅវា (pod បានយកចេញ ពីបញ្ជីនៃចំណុចបញ្ចប់សម្រាប់សេវាកម្ម) ។ ដូច្នេះ ដើម្បីជៀសវាងការផ្អាកអំឡុងពេលដាក់ពង្រាយ វាគ្រប់គ្រាន់សម្រាប់យើងក្នុងការដោះស្រាយបញ្ហានៃការបញ្ឈប់កម្មវិធីឱ្យបានត្រឹមត្រូវ។

អ្នកគួរចងចាំផងដែរថារយៈពេលអនុគ្រោះលំនាំដើមគឺ 30 វិនាទី៖ បន្ទាប់ពីនេះ ផតនឹងត្រូវបានបញ្ចប់ ហើយកម្មវិធីត្រូវតែមានពេលវេលាដើម្បីដំណើរការសំណើទាំងអស់មុនរយៈពេលនេះ។ ការកត់សម្គាល់: ទោះបីជាការស្នើសុំណាមួយដែលចំណាយពេលលើសពី 5-10 វិនាទីមានបញ្ហារួចហើយក៏ដោយ ហើយការបិទយ៉ាងប្រណិតនឹងមិនអាចជួយវាទៀតទេ...

ដើម្បីយល់កាន់តែច្បាស់ថា តើមានអ្វីកើតឡើងនៅពេលដែលផតត្រូវបានបញ្ចប់ សូមក្រឡេកមើលដ្យាក្រាមខាងក្រោម៖

A1, B1 - ទទួលការផ្លាស់ប្តូរអំពីស្ថានភាពនៃ hearth នេះ។
A2 - SIGTERM ចេញដំណើរ
B2 - ការដក pod ចេញពីចំណុចបញ្ចប់
B3 - ការ​ទទួល​បាន​ការ​ផ្លាស់​ប្តូ​រ (បញ្ជី​នៃ​ចំណុច​បញ្ចប់​បាន​ផ្លាស់​ប្តូ​រ​)
B4 - ធ្វើបច្ចុប្បន្នភាពច្បាប់ iptables

សូមចំណាំ៖ ការលុបចំណុចបញ្ចប់ និងការផ្ញើ SIGTERM មិនកើតឡើងជាបន្តបន្ទាប់នោះទេ ប៉ុន្តែស្របគ្នា។ ហើយដោយសារតែការពិតដែលថា Ingress មិនទទួលបានបញ្ជីចុងក្រោយដែលបានធ្វើបច្ចុប្បន្នភាពភ្លាមៗ សំណើថ្មីពីអតិថិជននឹងត្រូវបានផ្ញើទៅកាន់ផត ដែលនឹងបណ្តាលឱ្យមានកំហុសចំនួន 500 កំឡុងពេលបញ្ចប់ផត (សម្រាប់សម្ភារៈលម្អិតបន្ថែមលើបញ្ហានេះ យើង បកប្រែ). បញ្ហានេះចាំបាច់ត្រូវដោះស្រាយតាមវិធីដូចខាងក្រោមៈ

• ផ្ញើ​ការ​តភ្ជាប់៖ បិទ​នៅ​ក្នុង​ក្បាល​ការ​ឆ្លើយតប (ប្រសិន​បើ​វា​ទាក់ទង​នឹង​កម្មវិធី HTTP)។
• ប្រសិនបើមិនអាចធ្វើការផ្លាស់ប្តូរកូដបានទេនោះ អត្ថបទខាងក្រោមពិពណ៌នាអំពីដំណោះស្រាយដែលនឹងអនុញ្ញាតឱ្យអ្នកដំណើរការសំណើរហូតដល់ចុងបញ្ចប់នៃរយៈពេលដ៏រីករាយ។

ទ្រឹស្ដី។ របៀបដែល NGINX និង PHP-FPM បញ្ចប់ដំណើរការរបស់ពួកគេ។

NGINX

ចូរចាប់ផ្តើមជាមួយ NGINX ចាប់តាំងពីអ្វីគ្រប់យ៉ាងគឺច្បាស់ជាងឬតិចជាងជាមួយវា។ ការចូលទៅក្នុងទ្រឹស្តី យើងរៀនថា NGINX មានដំណើរការមេតែមួយ និង "កម្មករ" ជាច្រើន - ទាំងនេះគឺជាដំណើរការកុមារដែលដំណើរការសំណើរបស់អតិថិជន។ ជម្រើសងាយស្រួលមួយត្រូវបានផ្តល់ជូន៖ ដោយប្រើពាក្យបញ្ជា nginx -s <SIGNAL> បញ្ចប់ដំណើរការទាំងក្នុងរបៀបបិទលឿន ឬរបៀបបិទដំណើរការល្អ។ ជាក់ស្តែងវាគឺជាជម្រើសចុងក្រោយដែលចាប់អារម្មណ៍យើង។

បន្ទាប់មកអ្វីគ្រប់យ៉ាងគឺសាមញ្ញ: អ្នកត្រូវបន្ថែមទៅ preStop-hook ពាក្យ​បញ្ជា​ដែល​នឹង​ផ្ញើ​សញ្ញា​បិទ​ដ៏​ល្អ​មួយ​។ នេះអាចត្រូវបានធ្វើនៅក្នុង Deployment នៅក្នុងប្លុកកុងតឺន័រ៖

       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 - ការបិទយ៉ាងទន់ភ្លន់ (អ្វីដែលយើងត្រូវការ) ។

សញ្ញាដែលនៅសល់មិនត្រូវបានទាមទារនៅក្នុងកិច្ចការនេះទេ ដូច្នេះយើងនឹងលុបចោលការវិភាគរបស់ពួកគេ។ ដើម្បីបញ្ចប់ដំណើរការបានត្រឹមត្រូវ អ្នកនឹងត្រូវសរសេរទំពក់ preStop ខាងក្រោម៖

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

នៅ glance ដំបូង នេះ​គឺ​ជា​អ្វី​ទាំងអស់​ដែល​ត្រូវ​បាន​ទាមទារ​ដើម្បី​អនុវត្ត​ការ​បិទ​យ៉ាង​ល្អ​ក្នុង​ធុង​ទាំង​ពីរ។ ទោះយ៉ាងណាក៏ដោយភារកិច្ចគឺពិបាកជាងវាហាក់ដូចជា។ ខាងក្រោមនេះគឺជាករណីចំនួនពីរដែលការបិទដោយប្រយោលមិនដំណើរការ និងបណ្តាលឱ្យមិនមានគម្រោងរយៈពេលខ្លីក្នុងអំឡុងពេលដាក់ពង្រាយ។

អនុវត្ត។ បញ្ហាដែលអាចកើតមានជាមួយនឹងការបិទយ៉ាងប្រណិត

NGINX

ជាដំបូងវាមានប្រយោជន៍ក្នុងការចងចាំ: បន្ថែមពីលើការប្រតិបត្តិពាក្យបញ្ជា nginx -s quit មានដំណាក់កាលមួយទៀតដែលគួរយកចិត្តទុកដាក់។ យើងជួបប្រទះបញ្ហាដែល NGINX នឹងនៅតែផ្ញើ SIGTERM ជំនួសឱ្យសញ្ញា SIGQUIT ដែលបណ្តាលឱ្យសំណើមិនបំពេញត្រឹមត្រូវ។ ករណីស្រដៀងគ្នាអាចត្រូវបានរកឃើញឧទាហរណ៍។ នៅទីនេះ. ជាអកុសល យើងមិនអាចកំណត់ហេតុផលជាក់លាក់សម្រាប់ឥរិយាបថនេះបានទេ៖ មានការសង្ស័យអំពីកំណែ NGINX ប៉ុន្តែវាមិនត្រូវបានបញ្ជាក់ទេ។ រោគសញ្ញាគឺថាសារត្រូវបានគេសង្កេតឃើញនៅក្នុងកំណត់ហេតុកុងតឺន័រ NGINX៖ "បើករន្ធ #10 ខាងឆ្វេងក្នុងការតភ្ជាប់ 5"បន្ទាប់ពីនោះ pod បានឈប់។

យើងអាចសង្កេតមើលបញ្ហាបែបនេះ ជាឧទាហរណ៍ ពីការឆ្លើយតបនៅលើ 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 មិនត្រូវបានអង្កេតទៀតទេ។

ប្រសិនបើអ្នកជួបប្រទះបញ្ហាស្រដៀងគ្នានេះ វាសមហេតុផលក្នុងការស្វែងយល់ថាតើសញ្ញាឈប់ប្រើអ្វីនៅក្នុងកុងតឺន័រ ហើយតើទំពក់ preStop មើលទៅដូចអ្វី។ វាអាចទៅរួចដែលថាហេតុផលគឺច្បាស់នៅក្នុងរឿងនេះ។

PHP-FPM ... និងច្រើនទៀត

បញ្ហាជាមួយ PHP-FPM ត្រូវបានពិពណ៌នាតាមវិធីតូចតាច៖ វាមិនរង់ចាំការបញ្ចប់ដំណើរការកុមារទេ វាបញ្ចប់ពួកវា ដែលជាមូលហេតុដែលកំហុស 502 កើតឡើងកំឡុងពេលដាក់ពង្រាយ និងប្រតិបត្តិការផ្សេងទៀត។ មានរបាយការណ៍កំហុសជាច្រើននៅលើ bugs.php.net តាំងពីឆ្នាំ 2005 (ឧ នៅទីនេះ и នៅទីនេះ) ដែលពិពណ៌នាអំពីបញ្ហានេះ។ ប៉ុន្តែអ្នកទំនងជានឹងមិនឃើញអ្វីនៅក្នុងកំណត់ហេតុនោះទេ៖ PHP-FPM នឹងប្រកាសពីការបញ្ចប់ដំណើរការរបស់វាដោយគ្មានកំហុស ឬការជូនដំណឹងពីភាគីទីបី។

វាមានតម្លៃក្នុងការបញ្ជាក់ឱ្យច្បាស់ថាបញ្ហាខ្លួនឯងអាចអាស្រ័យលើវិសាលភាពតិចជាង ឬធំជាងនៅលើកម្មវិធីខ្លួនវា ហើយប្រហែលជាមិនបង្ហាញឱ្យឃើញដោយខ្លួនឯង ឧទាហរណ៍ក្នុងការត្រួតពិនិត្យ។ ប្រសិនបើអ្នកជួបប្រទះវា ដំណោះស្រាយសាមញ្ញមួយមកក្នុងគំនិតជាមុនសិន៖ បន្ថែមទំពក់មុនឈប់ជាមួយ sleep(30). វា​នឹង​អនុញ្ញាត​ឱ្យ​អ្នក​បំពេញ​សំណើ​ទាំង​អស់​ដែល​មាន​ពីមុន​មក (ហើយ​យើង​មិន​ទទួល​យក​សំណើ​ថ្មី​ទេ ចាប់តាំងពី pod រួចទៅហើយ មាន​សមត្ថភាព​ក្នុង​ការ បញ្ចប់) ហើយបន្ទាប់ពី 30 វិនាទី pod ខ្លួនវានឹងបញ្ចប់ដោយសញ្ញាមួយ។ SIGTERM.

វាប្រែថា lifecycle សម្រាប់ធុងនឹងមើលទៅដូចនេះ:

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

ទោះយ៉ាងណាក៏ដោយដោយសារតែ 30 វិនាទី sleep мы យ៉ាងខ្លាំង យើង​នឹង​បង្កើន​ពេល​វេលា​សម្រាប់​ការ​ដាក់​ពង្រាយ ដោយ​សារ​ផត​នីមួយៗ​នឹង​ត្រូវ​បាន​បញ្ចប់ អប្បបរមា 30 វិនាទីដែលអាក្រក់។ តើអាចធ្វើអ្វីបានអំពីរឿងនេះ?

ចូរយើងងាកទៅរកភាគីដែលទទួលខុសត្រូវចំពោះការប្រតិបត្តិដោយផ្ទាល់នៃកម្មវិធី។ ក្នុងករណីរបស់យើងវាគឺ PHP-FPM, ដែល តាមលំនាំដើមមិនត្រួតពិនិត្យការប្រតិបត្តិនៃដំណើរការកូនរបស់វាទេ។៖ ដំណើរការមេត្រូវបានបញ្ចប់ភ្លាមៗ។ អ្នកអាចផ្លាស់ប្តូរឥរិយាបថនេះដោយប្រើការណែនាំ process_control_timeoutដែលបញ្ជាក់ពីពេលវេលាកំណត់សម្រាប់ដំណើរការកុមារដើម្បីរង់ចាំសញ្ញាពីមេ។ ប្រសិនបើអ្នកកំណត់តម្លៃត្រឹម 20 វិនាទី វានឹងគ្របដណ្តប់សំណួរភាគច្រើនដែលកំពុងដំណើរការនៅក្នុងកុងតឺន័រ ហើយនឹងបញ្ឈប់ដំណើរការមេនៅពេលពួកគេបានបញ្ចប់។

ជាមួយនឹងចំណេះដឹងនេះសូមត្រលប់ទៅបញ្ហាចុងក្រោយរបស់យើង។ ដូចដែលបានរៀបរាប់រួចហើយ Kubernetes មិនមែនជាវេទិកាតែមួយទេ៖ ការទំនាក់ទំនងរវាងសមាសធាតុផ្សេងៗរបស់វាត្រូវចំណាយពេលខ្លះ។ នេះជាការពិតជាពិសេសនៅពេលដែលយើងពិចារណាប្រតិបត្តិការរបស់ 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 ខ្លួនវាផ្ទាល់។

អ្វីដែលសំខាន់បំផុតនៅទីនេះគឺ ពិនិត្យមើលការផ្លាស់ប្តូរជាជំហាន ៗ. បន្ទាប់ពីបន្ថែមការជួសជុលថ្មី សូមដំណើរការការធ្វើតេស្ត ហើយមើលថាតើលទ្ធផលបានផ្លាស់ប្តូរបើធៀបនឹងការរត់ចុងក្រោយ។ បើមិនដូច្នោះទេ វានឹងពិបាកក្នុងការកំណត់អត្តសញ្ញាណដំណោះស្រាយដែលមិនមានប្រសិទ្ធភាព ហើយក្នុងរយៈពេលវែង វាអាចបង្កគ្រោះថ្នាក់តែប៉ុណ្ណោះ (ឧទាហរណ៍ បង្កើនពេលវេលាដាក់ពង្រាយ)។

ភាពខុសប្លែកមួយទៀតគឺត្រូវមើលកំណត់ហេតុកុងតឺន័រកំឡុងពេលបញ្ចប់របស់វា។ តើព័ត៌មានអំពីការបិទយ៉ាងប្រណិតត្រូវបានកត់ត្រានៅទីនោះទេ? តើមានកំហុសណាមួយនៅក្នុងកំណត់ហេតុនៅពេលចូលប្រើធនធានផ្សេងទៀត (ឧទាហរណ៍ កុងតឺន័រ PHP-FPM ដែលនៅជិតគ្នា)? កំហុសនៅក្នុងកម្មវិធីខ្លួនវា (ដូចនៅក្នុងករណីជាមួយ NGINX ដែលបានពិពណ៌នាខាងលើ)? ខ្ញុំសង្ឃឹមថាព័ត៌មានណែនាំពីអត្ថបទនេះនឹងជួយអ្នកឱ្យយល់កាន់តែច្បាស់អំពីអ្វីដែលកើតឡើងចំពោះកុងតឺន័រអំឡុងពេលបិទដំណើរការរបស់វា។

ដូច្នេះ ការរត់ការសាកល្បងដំបូងបានធ្វើឡើងដោយគ្មាន lifecycle និងដោយគ្មានការណែនាំបន្ថែមសម្រាប់ម៉ាស៊ីនមេកម្មវិធី (process_control_timeout នៅក្នុង PHP-FPM) ។ គោលបំណងនៃការធ្វើតេស្តនេះគឺដើម្បីកំណត់អត្តសញ្ញាណចំនួនប្រហាក់ប្រហែលនៃកំហុស (និងថាតើមានទេ)។ ផងដែរ ពីព័ត៌មានបន្ថែម អ្នកគួរតែដឹងថាពេលវេលាដាក់ពង្រាយជាមធ្យមសម្រាប់ផតនីមួយៗគឺប្រហែល 5-10 វិនាទីរហូតដល់វារួចរាល់ទាំងស្រុង។ លទ្ធផលគឺ៖

បន្ទះព័ត៌មាន Yandex.Tank បង្ហាញពីការកើនឡើងនៃកំហុសចំនួន 502 ដែលបានកើតឡើងនៅពេលដាក់ពង្រាយ និងមានរយៈពេលជាមធ្យមរហូតដល់ 5 វិនាទី។ សន្មតថានេះគឺដោយសារតែសំណើដែលមានស្រាប់ទៅកាន់ផតចាស់កំពុងត្រូវបានបញ្ចប់នៅពេលដែលវាត្រូវបានបញ្ចប់។ បន្ទាប់ពីនេះ កំហុសចំនួន 503 បានលេចចេញមក ដែលជាលទ្ធផលនៃកុងតឺន័រ NGINX ដែលបានបញ្ឈប់ ដែលត្រូវបានបញ្ឈប់ផងដែរដោយសារតែផ្នែកខាងក្រោយ (ដែលរារាំង Ingress ពីការភ្ជាប់ទៅវា) ។

តោះមើលពីរបៀប process_control_timeout នៅក្នុង PHP-FPM នឹងជួយយើងឱ្យរង់ចាំការបញ្ចប់ដំណើរការកុមារ ពោលគឺឧ។ កែកំហុសបែបនេះ។ ដាក់ពង្រាយឡើងវិញដោយប្រើការណែនាំនេះ៖

មិនមានកំហុសទៀតទេក្នុងអំឡុងពេលដាក់ពង្រាយលើកទី 500! ការ​ដាក់​ពង្រាយ​គឺ​ទទួល​បាន​ជោគជ័យ និង​ដំណើរការ​បិទ​យ៉ាង​រលូន។

ទោះជាយ៉ាងណាក៏ដោយ វាគឺមានតំលៃចងចាំបញ្ហាជាមួយ Ingress containers ដែលជាភាគរយតូចមួយនៃកំហុសដែលយើងអាចទទួលបានដោយសារតែពេលវេលាយឺត។ ដើម្បីជៀសវាងពួកគេ អ្វីទាំងអស់ដែលនៅសល់គឺត្រូវបន្ថែមរចនាសម្ព័ន្ធជាមួយ sleep និងការដាក់ពង្រាយម្តងទៀត។ ទោះយ៉ាងណាក៏ដោយ ក្នុងករណីពិសេសរបស់យើង គ្មានការផ្លាស់ប្តូរណាមួយអាចមើលឃើញទេ (ម្តងទៀត គ្មានកំហុស)។

សេចក្តីសន្និដ្ឋាន

ដើម្បីបញ្ចប់ដំណើរការដោយរលូន យើងរំពឹងថានឹងមានអាកប្បកិរិយាដូចខាងក្រោមពីកម្មវិធី៖

1. រង់ចាំពីរបីវិនាទី ហើយបន្ទាប់មកឈប់ទទួលយកការតភ្ជាប់ថ្មី។
2. រង់ចាំ​សំណើ​ទាំងអស់​ដើម្បី​បញ្ចប់ និង​បិទ​ការ​តភ្ជាប់​រក្សា​ទុក​ទាំងអស់​ដែល​មិន​ដំណើរការ​សំណើ។
3. បញ្ចប់ដំណើរការរបស់អ្នក។

ទោះយ៉ាងណាក៏ដោយ មិនមែនគ្រប់កម្មវិធីទាំងអស់អាចដំណើរការតាមរបៀបនេះទេ។ ដំណោះស្រាយមួយចំពោះបញ្ហានៅក្នុងការពិត Kubernetes គឺ៖

• បន្ថែមទំពក់មុនឈប់ដែលនឹងរង់ចាំពីរបីវិនាទី;
• សិក្សាឯកសារកំណត់រចនាសម្ព័ន្ធនៃផ្នែកខាងក្រោយរបស់យើងសម្រាប់ប៉ារ៉ាម៉ែត្រសមស្រប។

ឧទាហរណ៍ជាមួយ NGINX ធ្វើឱ្យវាច្បាស់ថា សូម្បីតែកម្មវិធីដែលគួរដំណើរការសញ្ញាបញ្ចប់ដំបូងឱ្យបានត្រឹមត្រូវ ក៏មិនអាចធ្វើដូច្នេះបាន ដូច្នេះវាមានសារៈសំខាន់ណាស់ក្នុងការត្រួតពិនិត្យមើលកំហុសចំនួន 500 កំឡុងពេលដាក់ឱ្យប្រើប្រាស់កម្មវិធី។ នេះក៏អនុញ្ញាតឱ្យអ្នកមើលបញ្ហាកាន់តែទូលំទូលាយ និងមិនផ្តោតលើផតឃែរ ឬកុងតឺន័រតែមួយទេ ប៉ុន្តែមើលទៅលើហេដ្ឋារចនាសម្ព័ន្ធទាំងមូលទាំងមូល។

ជាឧបករណ៍សាកល្បង អ្នកអាចប្រើ Yandex.Tank ភ្ជាប់ជាមួយប្រព័ន្ធត្រួតពិនិត្យណាមួយ (ក្នុងករណីរបស់យើង ទិន្នន័យត្រូវបានយកចេញពី Grafana ជាមួយនឹងកម្មវិធីខាងក្រោយ Prometheus សម្រាប់ការធ្វើតេស្ត)។ បញ្ហាជាមួយនឹងការបិទដោយប្រយោលគឺអាចមើលឃើញយ៉ាងច្បាស់នៅក្រោមបន្ទុកធ្ងន់ដែលសូចនាករអាចបង្កើតបាន ហើយការត្រួតពិនិត្យជួយវិភាគស្ថានភាពឱ្យកាន់តែលម្អិតក្នុងអំឡុងពេល ឬបន្ទាប់ពីការសាកល្បង។

ជាការឆ្លើយតបទៅនឹងមតិកែលម្អលើអត្ថបទ៖ វាមានតម្លៃក្នុងការនិយាយថាបញ្ហា និងដំណោះស្រាយត្រូវបានពិពណ៌នានៅទីនេះទាក់ទងនឹង NGINX Ingress។ សម្រាប់ករណីផ្សេងទៀត មានដំណោះស្រាយផ្សេងទៀត ដែលយើងអាចពិចារណាក្នុងឯកសារខាងក្រោមនៃស៊េរី។

PS

ផ្សេងទៀតពីស៊េរីគន្លឹះ និងល្បិច K8s៖

• «ទំព័រកំហុសផ្ទាល់ខ្លួននៅក្នុង NGINX Ingress»
• «អំពីការបែងចែកថ្នាំង និងការផ្ទុកនៅលើកម្មវិធីបណ្តាញ»
• «ការចូលប្រើគេហទំព័រអភិវឌ្ឍន៍»
• «បង្កើនល្បឿន Bootstrap សម្រាប់មូលដ្ឋានទិន្នន័យធំ"។

ប្រភព: www.habr.com