കുബെർനെറ്റസ് നുറുങ്ങുകളും തന്ത്രങ്ങളും: NGINX, PHP-FPM എന്നിവയിലെ മനോഹരമായ ഷട്ട്ഡൗൺ സവിശേഷതകൾ

Kubernetes-ൽ CI/CD നടപ്പിലാക്കുമ്പോൾ ഒരു സാധാരണ വ്യവസ്ഥ: പൂർണ്ണമായും നിർത്തുന്നതിന് മുമ്പ് പുതിയ ക്ലയന്റ് അഭ്യർത്ഥനകൾ സ്വീകരിക്കാതിരിക്കാൻ അപ്ലിക്കേഷന് കഴിയണം, ഏറ്റവും പ്രധാനമായി, നിലവിലുള്ളവ വിജയകരമായി പൂർത്തിയാക്കുക.

ഈ വ്യവസ്ഥ പാലിക്കുന്നത് വിന്യാസ സമയത്ത് പൂജ്യം പ്രവർത്തനരഹിതമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, വളരെ ജനപ്രിയമായ ബണ്ടിലുകൾ ഉപയോഗിക്കുമ്പോൾ പോലും (NGINX, PHP-FPM പോലുള്ളവ), ഓരോ വിന്യാസത്തിലും പിശകുകളുടെ കുതിച്ചുചാട്ടത്തിന് കാരണമാകുന്ന ബുദ്ധിമുട്ടുകൾ നിങ്ങൾക്ക് നേരിടാം...

സിദ്ധാന്തം. പോഡ് എങ്ങനെ ജീവിക്കുന്നു

ഒരു പോഡിന്റെ ജീവിത ചക്രത്തെക്കുറിച്ച് ഞങ്ങൾ ഇതിനകം വിശദമായി പ്രസിദ്ധീകരിച്ചിട്ടുണ്ട് ഈ ലേഖനം. പരിഗണനയിലുള്ള വിഷയത്തിന്റെ പശ്ചാത്തലത്തിൽ, ഇനിപ്പറയുന്നവയിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്: പോഡ് സംസ്ഥാനത്ത് പ്രവേശിക്കുന്ന നിമിഷത്തിൽ അവസാനിപ്പിക്കുന്നു, പുതിയ അഭ്യർത്ഥനകൾ ഇതിലേക്ക് അയക്കുന്നത് നിർത്തുന്നു (pod നീക്കം ചെയ്തു സേവനത്തിനുള്ള അവസാന പോയിന്റുകളുടെ പട്ടികയിൽ നിന്ന്). അതിനാൽ, വിന്യാസ സമയത്ത് പ്രവർത്തനരഹിതമായ സമയം ഒഴിവാക്കാൻ, ആപ്ലിക്കേഷൻ ശരിയായി നിർത്തുന്നതിനുള്ള പ്രശ്നം പരിഹരിക്കാൻ ഞങ്ങൾക്ക് ഇത് മതിയാകും.

ഡിഫോൾട്ട് ഗ്രേസ് പിരീഡ് ആണെന്നും നിങ്ങൾ ഓർക്കണം 30 സെക്കൻഡ്: ഇതിനുശേഷം, പോഡ് അവസാനിപ്പിക്കും, ഈ കാലയളവിന് മുമ്പുള്ള എല്ലാ അഭ്യർത്ഥനകളും പ്രോസസ്സ് ചെയ്യുന്നതിന് അപ്ലിക്കേഷന് സമയമുണ്ടായിരിക്കണം. അഭിപായപ്പെടുക: 5-10 സെക്കൻഡിൽ കൂടുതൽ സമയമെടുക്കുന്ന ഏതൊരു അഭ്യർത്ഥനയും ഇതിനകം തന്നെ പ്രശ്‌നമുള്ളതാണെങ്കിലും, ഭംഗിയുള്ള ഷട്ട്ഡൗൺ ഇനി അതിനെ സഹായിക്കില്ല...

ഒരു പോഡ് അവസാനിക്കുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് നന്നായി മനസ്സിലാക്കാൻ, ഇനിപ്പറയുന്ന ഡയഗ്രം നോക്കുക:

A1, B1 - അടുപ്പിന്റെ അവസ്ഥയെക്കുറിച്ചുള്ള മാറ്റങ്ങൾ സ്വീകരിക്കുന്നു
A2 - പുറപ്പെടൽ SIGTERM
B2 - അവസാന പോയിന്റുകളിൽ നിന്ന് ഒരു പോഡ് നീക്കം ചെയ്യുന്നു
B3 - മാറ്റങ്ങൾ സ്വീകരിക്കുന്നു (അവസാന പോയിന്റുകളുടെ പട്ടിക മാറിയിരിക്കുന്നു)
B4 - iptables നിയമങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുക

ദയവായി ശ്രദ്ധിക്കുക: എൻഡ്‌പോയിന്റ് പോഡ് ഇല്ലാതാക്കുന്നതും SIGTERM അയയ്‌ക്കുന്നതും തുടർച്ചയായി സംഭവിക്കുന്നതല്ല, സമാന്തരമായാണ്. എൻഡ്‌പോയിന്റുകളുടെ പുതുക്കിയ ലിസ്റ്റ് ഇൻഗ്രസിന് ഉടനടി ലഭിക്കാത്തതിനാൽ, ക്ലയന്റുകളിൽ നിന്നുള്ള പുതിയ അഭ്യർത്ഥനകൾ പോഡിലേക്ക് അയയ്‌ക്കും, ഇത് പോഡ് അവസാനിപ്പിക്കുമ്പോൾ 500 പിശകിന് കാരണമാകും. (ഈ പ്രശ്നത്തെക്കുറിച്ചുള്ള കൂടുതൽ വിശദമായ വിവരങ്ങൾക്കായി, ഞങ്ങൾ പരിഭാഷപ്പെടുത്തി). ഈ പ്രശ്നം ഇനിപ്പറയുന്ന രീതികളിൽ പരിഹരിക്കേണ്ടതുണ്ട്:

• അയയ്‌ക്കുന്ന കണക്ഷൻ: പ്രതികരണ തലക്കെട്ടുകളിൽ അടയ്ക്കുക (ഇത് ഒരു HTTP ആപ്ലിക്കേഷനാണെങ്കിൽ).
• കോഡിൽ മാറ്റങ്ങൾ വരുത്തുന്നത് സാധ്യമല്ലെങ്കിൽ, കൃത്യസമയത്തിന്റെ അവസാനം വരെ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു പരിഹാരം ഇനിപ്പറയുന്ന ലേഖനം വിവരിക്കുന്നു.

സിദ്ധാന്തം. NGINX, PHP-FPM എന്നിവ അവരുടെ പ്രക്രിയകൾ എങ്ങനെ അവസാനിപ്പിക്കുന്നു

NGINX

NGINX-ൽ നിന്ന് ആരംഭിക്കാം, കാരണം എല്ലാം കൂടുതലോ കുറവോ വ്യക്തമാണ്. സിദ്ധാന്തത്തിലേക്ക് കടക്കുമ്പോൾ, NGINX-ന് ഒരു പ്രധാന പ്രക്രിയയും നിരവധി "തൊഴിലാളികളും" ഉണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു - ഇവ ക്ലയന്റ് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്ന ചൈൽഡ് പ്രോസസ്സുകളാണ്. സൗകര്യപ്രദമായ ഒരു ഓപ്ഷൻ നൽകിയിരിക്കുന്നു: കമാൻഡ് ഉപയോഗിച്ച് nginx -s <SIGNAL> വേഗത്തിലുള്ള ഷട്ട്ഡൗൺ അല്ലെങ്കിൽ മനോഹരമായ ഷട്ട്ഡൗൺ മോഡിൽ പ്രക്രിയകൾ അവസാനിപ്പിക്കുക. വ്യക്തമായും, ഞങ്ങൾക്ക് താൽപ്പര്യമുള്ള രണ്ടാമത്തെ ഓപ്ഷനാണ് ഇത്.

അപ്പോൾ എല്ലാം ലളിതമാണ്: നിങ്ങൾ ഇതിലേക്ക് ചേർക്കേണ്ടതുണ്ട് പ്രീസ്റ്റോപ്പ്-ഹുക്ക് മനോഹരമായ ഒരു ഷട്ട്ഡൗൺ സിഗ്നൽ അയയ്ക്കുന്ന ഒരു കമാൻഡ്. ഇത് വിന്യാസത്തിൽ, കണ്ടെയ്നർ ബ്ലോക്കിൽ ചെയ്യാം:

       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 - ഭംഗിയുള്ള ഷട്ട്ഡൗൺ (നമുക്ക് ആവശ്യമുള്ളത്).

ഈ ടാസ്ക്കിൽ ശേഷിക്കുന്ന സിഗ്നലുകൾ ആവശ്യമില്ല, അതിനാൽ ഞങ്ങൾ അവരുടെ വിശകലനം ഒഴിവാക്കും. പ്രക്രിയ ശരിയായി അവസാനിപ്പിക്കുന്നതിന്, നിങ്ങൾ ഇനിപ്പറയുന്ന പ്രീസ്റ്റോപ്പ് ഹുക്ക് എഴുതേണ്ടതുണ്ട്:

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

ഒറ്റനോട്ടത്തിൽ, രണ്ട് കണ്ടെയ്‌നറുകളിലും മനോഹരമായ ഷട്ട്ഡൗൺ നടത്താൻ ഇത് ആവശ്യമാണ്. എന്നിരുന്നാലും, ചുമതല തോന്നുന്നതിനേക്കാൾ ബുദ്ധിമുട്ടാണ്. മനോഹരമായ ഷട്ട്ഡൗൺ പ്രവർത്തിക്കാത്തതും വിന്യാസ സമയത്ത് പ്രോജക്‌റ്റിന്റെ ഹ്രസ്വകാല ലഭ്യതക്കുറവിന് കാരണമായതുമായ രണ്ട് കേസുകൾ ചുവടെയുണ്ട്.

പരിശീലിക്കുക. ഗംഭീരമായ ഷട്ട്ഡൗൺ കൊണ്ട് സാധ്യമായ പ്രശ്നങ്ങൾ

NGINX

ഒന്നാമതായി, ഓർമ്മിക്കുന്നത് ഉപയോഗപ്രദമാണ്: കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുന്നതിന് പുറമേ nginx -s quit ശ്രദ്ധിക്കേണ്ട ഒരു ഘട്ടം കൂടിയുണ്ട്. SIGQUIT സിഗ്നലിന് പകരം NGINX ഇപ്പോഴും SIGTERM അയയ്‌ക്കുന്ന ഒരു പ്രശ്‌നം ഞങ്ങൾ നേരിട്ടു, ഇത് അഭ്യർത്ഥനകൾ ശരിയായി പൂർത്തിയാകാത്തതിന് കാരണമാകുന്നു. സമാനമായ കേസുകൾ കണ്ടെത്താൻ കഴിയും, ഉദാഹരണത്തിന്, ഇവിടെ. നിർഭാഗ്യവശാൽ, ഈ സ്വഭാവത്തിന്റെ പ്രത്യേക കാരണം നിർണ്ണയിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല: NGINX പതിപ്പിനെക്കുറിച്ച് ഒരു സംശയം ഉണ്ടായിരുന്നു, പക്ഷേ അത് സ്ഥിരീകരിച്ചിട്ടില്ല. NGINX കണ്ടെയ്‌നർ ലോഗുകളിൽ സന്ദേശങ്ങൾ നിരീക്ഷിച്ചതാണ് ലക്ഷണം: "കണക്ഷൻ 10-ൽ ഓപ്പൺ സോക്കറ്റ് #5 അവശേഷിക്കുന്നു", അതിനുശേഷം പോഡ് നിർത്തി.

അത്തരമൊരു പ്രശ്നം നമുക്ക് നിരീക്ഷിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് ആവശ്യമായ ഇൻഗ്രെസ് സംബന്ധിച്ച പ്രതികരണങ്ങളിൽ നിന്ന്:

വിന്യാസ സമയത്ത് സ്റ്റാറ്റസ് കോഡുകളുടെ സൂചകങ്ങൾ

ഈ സാഹചര്യത്തിൽ, Ingress-ൽ നിന്ന് തന്നെ ഞങ്ങൾക്ക് 503 പിശക് കോഡ് മാത്രമേ ലഭിക്കുന്നുള്ളൂ: അതിന് 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 പിശക് ഇനി നിരീക്ഷിക്കപ്പെടുന്നില്ല എന്ന വസ്തുത ഇത് സ്ഥിരീകരിക്കുന്നു.

നിങ്ങൾക്ക് സമാനമായ ഒരു പ്രശ്നം നേരിടുകയാണെങ്കിൽ, കണ്ടെയ്നറിൽ എന്ത് സ്റ്റോപ്പ് സിഗ്നൽ ഉപയോഗിച്ചുവെന്നും പ്രീസ്റ്റോപ്പ് ഹുക്ക് എങ്ങനെയാണെന്നും മനസ്സിലാക്കുന്നത് അർത്ഥമാക്കുന്നു. കാരണം ഇതിൽ കൃത്യമായി അടങ്ങിയിരിക്കാൻ സാധ്യതയുണ്ട്.

PHP-FPM... കൂടാതെ മറ്റു പലതും

പി‌എച്ച്‌പി-എഫ്‌പി‌എമ്മുമായുള്ള പ്രശ്നം നിസ്സാരമായ രീതിയിൽ വിവരിച്ചിരിക്കുന്നു: ഇത് ചൈൽഡ് പ്രോസസുകളുടെ പൂർത്തീകരണത്തിനായി കാത്തിരിക്കുന്നില്ല, അത് അവരെ അവസാനിപ്പിക്കുന്നു, അതിനാലാണ് വിന്യാസത്തിലും മറ്റ് പ്രവർത്തനങ്ങളിലും 502 പിശകുകൾ സംഭവിക്കുന്നത്. 2005 മുതൽ bugs.php.net-ൽ നിരവധി ബഗ് റിപ്പോർട്ടുകൾ ഉണ്ട് (ഉദാ ഇവിടെ и ഇവിടെ), ഈ പ്രശ്നം വിവരിക്കുന്നു. എന്നാൽ ലോഗുകളിൽ നിങ്ങൾ മിക്കവാറും ഒന്നും കാണാനിടയില്ല: PHP-FPM അതിന്റെ പ്രക്രിയയുടെ പൂർത്തീകരണം പിഴവുകളോ മൂന്നാം കക്ഷി അറിയിപ്പുകളോ ഇല്ലാതെ പ്രഖ്യാപിക്കും.

പ്രശ്നം തന്നെ ആപ്ലിക്കേഷനെത്തന്നെ ചെറുതോ വലുതോ ആയ പരിധിവരെ ആശ്രയിച്ചിരിക്കുന്നുവെന്നും അത് സ്വയം പ്രകടമാകില്ലെന്നും വ്യക്തമാക്കേണ്ടതാണ്, ഉദാഹരണത്തിന്, നിരീക്ഷണത്തിൽ. നിങ്ങൾ അത് നേരിടുകയാണെങ്കിൽ, ഒരു ലളിതമായ പരിഹാരമാണ് ആദ്യം മനസ്സിൽ വരുന്നത്: ഒരു പ്രീസ്റ്റോപ്പ് ഹുക്ക് ചേർക്കുക sleep(30). മുമ്പുണ്ടായിരുന്ന എല്ലാ അഭ്യർത്ഥനകളും പൂർത്തിയാക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കും (പോഡ് മുതൽ ഞങ്ങൾ പുതിയവ സ്വീകരിക്കില്ല ഇതിനകം കഴിവുള്ള അവസാനിപ്പിക്കുന്നു), കൂടാതെ 30 സെക്കൻഡിനുശേഷം പോഡ് തന്നെ ഒരു സിഗ്നലിൽ അവസാനിക്കും SIGTERM.

അത് മാറുകയാണ് lifecycle കാരണം കണ്ടെയ്നർ ഇതുപോലെ കാണപ്പെടും:

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

എന്നിരുന്നാലും, 30 സെക്കൻഡ് കാരണം sleep ഞങ്ങൾ ശക്തമായി ഓരോ പോഡും അവസാനിപ്പിക്കുന്നതിനാൽ ഞങ്ങൾ വിന്യാസ സമയം വർദ്ധിപ്പിക്കും കുറഞ്ഞത് 30 സെക്കൻഡ്, അത് മോശമാണ്. ഇതിന് എന്ത് ചെയ്യാൻ കഴിയും?

അപേക്ഷയുടെ നേരിട്ടുള്ള നിർവ്വഹണത്തിന് ഉത്തരവാദിയായ കക്ഷിയിലേക്ക് തിരിയാം. നമ്മുടെ കാര്യത്തിൽ അങ്ങനെയാണ് PHP-FPM, ഏത് സ്ഥിരസ്ഥിതിയായി അതിന്റെ ചൈൽഡ് പ്രക്രിയകളുടെ നിർവ്വഹണം നിരീക്ഷിക്കുന്നില്ല: മാസ്റ്റർ പ്രക്രിയ ഉടനടി അവസാനിച്ചു. നിർദ്ദേശം ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ സ്വഭാവം മാറ്റാം process_control_timeout, ഇത് മാസ്റ്ററിൽ നിന്നുള്ള സിഗ്നലുകൾക്കായി കാത്തിരിക്കുന്നതിനുള്ള കുട്ടികളുടെ പ്രക്രിയകൾക്കുള്ള സമയ പരിധി വ്യക്തമാക്കുന്നു. നിങ്ങൾ മൂല്യം 20 സെക്കൻഡായി സജ്ജമാക്കുകയാണെങ്കിൽ, ഇത് കണ്ടെയ്‌നറിൽ പ്രവർത്തിക്കുന്ന മിക്ക ചോദ്യങ്ങളും ഉൾക്കൊള്ളുകയും അവ പൂർത്തിയാകുമ്പോൾ മാസ്റ്റർ പ്രോസസ്സ് നിർത്തുകയും ചെയ്യും.

ഈ അറിവോടെ, നമുക്ക് നമ്മുടെ അവസാന പ്രശ്നത്തിലേക്ക് മടങ്ങാം. സൂചിപ്പിച്ചതുപോലെ, കുബർനെറ്റസ് ഒരു മോണോലിത്തിക്ക് പ്ലാറ്റ്ഫോം അല്ല: അതിന്റെ വ്യത്യസ്ത ഘടകങ്ങൾ തമ്മിലുള്ള ആശയവിനിമയം കുറച്ച് സമയമെടുക്കും. ഇൻഗ്രെസുകളുടെയും മറ്റ് അനുബന്ധ ഘടകങ്ങളുടെയും പ്രവർത്തനം ഞങ്ങൾ പരിഗണിക്കുമ്പോൾ ഇത് പ്രത്യേകിച്ചും സത്യമാണ്, കാരണം വിന്യാസ സമയത്ത് ഇത്രയും കാലതാമസം കാരണം 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: ഇത് നമ്മുടെ എല്ലാ ആവശ്യങ്ങളും തികച്ചും ഉൾക്കൊള്ളുന്നു. ഗ്രാഫാനയുടെയും Yandex.Tank-ന്റെയും ഗ്രാഫുകൾക്ക് നന്ദി, ഞങ്ങളുടെ അനുഭവത്തിൽ നിന്നുള്ള വ്യക്തമായ ഉദാഹരണം ഉപയോഗിച്ച് പരിശോധന നടത്തുന്നതിനുള്ള നുറുങ്ങുകളും ശുപാർശകളും ഇനിപ്പറയുന്നവയാണ്.

ഇവിടെ ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം മാറ്റങ്ങൾ ഘട്ടം ഘട്ടമായി പരിശോധിക്കുക. ഒരു പുതിയ പരിഹാരം ചേർത്തതിന് ശേഷം, ടെസ്റ്റ് റൺ ചെയ്ത് അവസാന റണ്ണുമായി താരതമ്യം ചെയ്യുമ്പോൾ ഫലങ്ങൾ മാറിയിട്ടുണ്ടോ എന്ന് നോക്കുക. അല്ലാത്തപക്ഷം, ഫലപ്രദമല്ലാത്ത പരിഹാരങ്ങൾ തിരിച്ചറിയാൻ പ്രയാസമായിരിക്കും, ദീർഘകാലാടിസ്ഥാനത്തിൽ അത് ദോഷം ചെയ്യാൻ മാത്രമേ കഴിയൂ (ഉദാഹരണത്തിന്, വിന്യാസ സമയം വർദ്ധിപ്പിക്കുക).

കണ്ടെയ്നർ ലോഗുകൾ അവസാനിപ്പിക്കുന്ന സമയത്ത് നോക്കുക എന്നതാണ് മറ്റൊരു സൂക്ഷ്മത. ഗംഭീരമായ ഷട്ട്ഡൗൺ സംബന്ധിച്ച വിവരങ്ങൾ അവിടെ രേഖപ്പെടുത്തിയിട്ടുണ്ടോ? മറ്റ് ഉറവിടങ്ങൾ ആക്സസ് ചെയ്യുമ്പോൾ ലോഗുകളിൽ എന്തെങ്കിലും പിശകുകൾ ഉണ്ടോ (ഉദാഹരണത്തിന്, അയൽപക്കത്തുള്ള PHP-FPM കണ്ടെയ്നറിലേക്ക്)? ആപ്ലിക്കേഷനിലെ തന്നെ പിശകുകൾ (മുകളിൽ വിവരിച്ച NGINX-ന്റെ കാര്യത്തിലെന്നപോലെ)? ഈ ലേഖനത്തിൽ നിന്നുള്ള ആമുഖ വിവരങ്ങൾ കണ്ടെയ്നർ അവസാനിപ്പിക്കുമ്പോൾ അതിന് എന്ത് സംഭവിക്കുമെന്ന് നന്നായി മനസ്സിലാക്കാൻ നിങ്ങളെ സഹായിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

അതിനാൽ, ആദ്യ പരീക്ഷണ ഓട്ടം ഇല്ലാതെ നടന്നു lifecycle കൂടാതെ ആപ്ലിക്കേഷൻ സെർവറിനുള്ള അധിക നിർദ്ദേശങ്ങൾ ഇല്ലാതെ (process_control_timeout PHP-FPM-ൽ). പിശകുകളുടെ ഏകദേശ എണ്ണം (ഏതെങ്കിലും ഉണ്ടോ എന്ന്) തിരിച്ചറിയുക എന്നതായിരുന്നു ഈ പരിശോധനയുടെ ലക്ഷ്യം. കൂടാതെ, അധിക വിവരങ്ങളിൽ നിന്ന്, ഓരോ പോഡിന്റെയും വിന്യാസ സമയം പൂർണ്ണമായും തയ്യാറാകുന്നത് വരെ ഏകദേശം 5-10 സെക്കൻഡ് ആയിരുന്നുവെന്ന് നിങ്ങൾ അറിഞ്ഞിരിക്കണം. ഫലങ്ങൾ ഇവയാണ്:

Yandex.Tank വിവര പാനൽ 502 പിശകുകളുടെ ഒരു സ്‌പൈക്ക് കാണിക്കുന്നു, ഇത് വിന്യാസ സമയത്ത് സംഭവിച്ചതും ശരാശരി 5 സെക്കൻഡ് വരെ നീണ്ടുനിൽക്കുന്നതുമാണ്. പഴയ പോഡിലേക്കുള്ള നിലവിലുള്ള അഭ്യർത്ഥനകൾ അത് അവസാനിപ്പിക്കുമ്പോൾ അത് അവസാനിപ്പിക്കുന്നതിനാലാകാം ഇത്. ഇതിനുശേഷം, 503 പിശകുകൾ പ്രത്യക്ഷപ്പെട്ടു, ഇത് നിർത്തിയ NGINX കണ്ടെയ്‌നറിന്റെ ഫലമായിരുന്നു, ഇത് ബാക്കെൻഡ് കാരണം കണക്ഷനുകൾ ഉപേക്ഷിച്ചു (ഇത് ഇതിലേക്ക് കണക്റ്റുചെയ്യുന്നതിൽ നിന്ന് തടയുന്നു).

എങ്ങനെയെന്ന് നോക്കാം process_control_timeout PHP-FPM-ൽ ചൈൽഡ് പ്രോസസുകളുടെ പൂർത്തീകരണത്തിനായി കാത്തിരിക്കാൻ ഞങ്ങളെ സഹായിക്കും, അതായത്. അത്തരം തെറ്റുകൾ തിരുത്തുക. ഈ നിർദ്ദേശം ഉപയോഗിച്ച് വീണ്ടും വിന്യസിക്കുക:

500-ാമത്തെ വിന്യാസ സമയത്ത് കൂടുതൽ പിശകുകളൊന്നുമില്ല! വിന്യാസം വിജയകരമാണ്, മനോഹരമായ ഷട്ട്ഡൗൺ വർക്കുകൾ.

എന്നിരുന്നാലും, ഇൻഗ്രെസ് കണ്ടെയ്‌നറുകളിലെ പ്രശ്‌നം ഓർമ്മിക്കുന്നത് മൂല്യവത്താണ്, സമയക്കുറവ് കാരണം ഞങ്ങൾക്ക് ലഭിച്ചേക്കാവുന്ന ഒരു ചെറിയ ശതമാനം പിശകുകൾ. അവ ഒഴിവാക്കാൻ, ഒരു ഘടന ചേർക്കുന്നത് മാത്രമാണ് അവശേഷിക്കുന്നത് sleep വിന്യാസം ആവർത്തിക്കുക. എന്നിരുന്നാലും, ഞങ്ങളുടെ പ്രത്യേക സാഹചര്യത്തിൽ, മാറ്റങ്ങളൊന്നും ദൃശ്യമായില്ല (വീണ്ടും, പിശകുകളൊന്നുമില്ല).

തീരുമാനം

പ്രക്രിയ ഭംഗിയായി അവസാനിപ്പിക്കുന്നതിന്, ആപ്ലിക്കേഷനിൽ നിന്ന് ഇനിപ്പറയുന്ന പെരുമാറ്റം ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു:

1. കുറച്ച് നിമിഷങ്ങൾ കാത്തിരിക്കുക, തുടർന്ന് പുതിയ കണക്ഷനുകൾ സ്വീകരിക്കുന്നത് നിർത്തുക.
2. എല്ലാ അഭ്യർത്ഥനകളും പൂർത്തിയാകുന്നതിനും അഭ്യർത്ഥനകൾ നടപ്പിലാക്കാത്ത എല്ലാ കീപലൈവ് കണക്ഷനുകളും അടയ്ക്കുന്നതിനും കാത്തിരിക്കുക.
3. നിങ്ങളുടെ പ്രക്രിയ അവസാനിപ്പിക്കുക.

എന്നിരുന്നാലും, എല്ലാ ആപ്ലിക്കേഷനുകളും ഈ രീതിയിൽ പ്രവർത്തിക്കാൻ കഴിയില്ല. കുബർനെറ്റസ് യാഥാർത്ഥ്യങ്ങളിലെ പ്രശ്നത്തിനുള്ള ഒരു പരിഹാരം ഇതാണ്:

• കുറച്ച് നിമിഷങ്ങൾ കാത്തിരിക്കുന്ന ഒരു പ്രീ-സ്റ്റോപ്പ് ഹുക്ക് ചേർക്കുന്നു;
• ഉചിതമായ പരാമീറ്ററുകൾക്കായി ഞങ്ങളുടെ ബാക്കെൻഡിന്റെ കോൺഫിഗറേഷൻ ഫയൽ പഠിക്കുന്നു.

തുടക്കത്തിൽ ടെർമിനേഷൻ സിഗ്നലുകൾ ശരിയായി പ്രോസസ്സ് ചെയ്യേണ്ട ഒരു ആപ്ലിക്കേഷൻ പോലും അങ്ങനെ ചെയ്തേക്കില്ല എന്ന് NGINX-നൊപ്പമുള്ള ഉദാഹരണം വ്യക്തമാക്കുന്നു, അതിനാൽ ആപ്ലിക്കേഷൻ വിന്യാസ സമയത്ത് 500 പിശകുകൾ പരിശോധിക്കുന്നത് നിർണായകമാണ്. പ്രശ്‌നത്തെ കൂടുതൽ വിശാലമായി കാണാനും ഒരൊറ്റ പോഡിലോ കണ്ടെയ്‌നറിലോ ശ്രദ്ധ കേന്ദ്രീകരിക്കാതെ, മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറും മൊത്തത്തിൽ നോക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

ഒരു ടെസ്റ്റിംഗ് ടൂൾ എന്ന നിലയിൽ, ഏത് മോണിറ്ററിംഗ് സിസ്റ്റവുമായും നിങ്ങൾക്ക് Yandex.Tank ഉപയോഗിക്കാം (ഞങ്ങളുടെ കാര്യത്തിൽ, ടെസ്റ്റിനായി ഒരു പ്രോമിത്യൂസ് ബാക്കെൻഡുള്ള ഗ്രാഫാനയിൽ നിന്ന് ഡാറ്റ എടുത്തതാണ്). ബെഞ്ച്മാർക്ക് സൃഷ്ടിക്കാൻ കഴിയുന്ന കനത്ത ലോഡുകൾക്ക് കീഴിൽ മനോഹരമായ ഷട്ട്ഡൗണിലെ പ്രശ്നങ്ങൾ വ്യക്തമായി കാണാം, കൂടാതെ പരിശോധനയ്ക്കിടയിലോ ശേഷമോ സ്ഥിതി കൂടുതൽ വിശദമായി വിശകലനം ചെയ്യാൻ നിരീക്ഷണം സഹായിക്കുന്നു.

ലേഖനത്തെക്കുറിച്ചുള്ള ഫീഡ്‌ബാക്കിനുള്ള പ്രതികരണമായി: NGINX പ്രവേശനവുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങളും പരിഹാരങ്ങളും ഇവിടെ വിവരിച്ചിരിക്കുന്നത് എടുത്തുപറയേണ്ടതാണ്. മറ്റ് സന്ദർഭങ്ങളിൽ, മറ്റ് പരിഹാരങ്ങളുണ്ട്, അവ പരമ്പരയുടെ ഇനിപ്പറയുന്ന മെറ്റീരിയലുകളിൽ ഞങ്ങൾ പരിഗണിക്കാം.

പി.എസ്

K8s നുറുങ്ങുകളും തന്ത്രങ്ങളും പരമ്പരയിൽ നിന്നുള്ള മറ്റുള്ളവ:

• «NGINX പ്രവേശനത്തിലെ ഇഷ്‌ടാനുസൃത പിശക് പേജുകൾ";
• «ഒരു വെബ് ആപ്ലിക്കേഷനിലെ നോഡ് അലോക്കേഷനെയും ലോഡുകളെയും കുറിച്ച്";
• «ഡെവലപ്പ് സൈറ്റുകളിലേക്കുള്ള ആക്സസ്";
• «വലിയ ഡാറ്റാബേസുകൾക്കായി ബൂട്ട്സ്ട്രാപ്പ് വേഗത്തിലാക്കുന്നു".

അവലംബം: www.habr.com