Kubernetes ඉඟි සහ උපක්‍රම: NGINX සහ PHP-FPM හි අලංකාර වසා දැමීමේ විශේෂාංග

Kubernetes හි CI/CD ක්‍රියාත්මක කිරීමේදී සාමාන්‍ය කොන්දේසියක්: සම්පූර්ණයෙන්ම නතර කිරීමට පෙර නව සේවාදායක ඉල්ලීම් පිළි නොගැනීමට යෙදුමට හැකි විය යුතු අතර වඩාත්ම වැදගත් දෙය නම්, පවතින ඒවා සාර්ථකව සම්පූර්ණ කිරීමයි.

මෙම කොන්දේසියට අනුකූල වීම, යෙදවීමේදී ශුන්‍ය අක්‍රීය කාලයක් ලබා ගැනීමට ඔබට ඉඩ සලසයි. කෙසේ වෙතත්, ඉතා ජනප්‍රිය මිටි (NGINX සහ PHP-FPM වැනි) භාවිතා කරන විට පවා, ඔබට එක් එක් යෙදවීමේදී දෝෂ වැඩිවීමට හේතු වන දුෂ්කරතා වලට මුහුණ දිය හැක...

න්යාය. කොහොමද පොඩ් ජීවත් වෙන්නේ

අපි දැනටමත් කරල් වල ජීවන චක්‍රය ගැන විස්තරාත්මකව පළ කර ඇත්තෙමු මෙම ලිපිය. සලකා බලනු ලබන මාතෘකාවේ සන්දර්භය තුළ, අපි පහත සඳහන් දේ ගැන උනන්දු වෙමු: පොඩ් රාජ්යයට ඇතුල් වන මොහොතේ අවසන් කිරීම, නව ඉල්ලීම් එයට යැවීම නතර කරයි (pod ඉවත් කරන ලදි සේවාව සඳහා අවසාන ලක්ෂ්‍ය ලැයිස්තුවෙන්). මේ අනුව, යෙදවීමේදී අක්‍රිය වීම වළක්වා ගැනීම සඳහා, යෙදුම නිවැරදිව නැවැත්වීමේ ගැටලුව විසඳීමට අපට ප්‍රමාණවත් වේ.

පෙරනිමි සහන කාලය බව ද ඔබ මතක තබා ගත යුතුය තත්පර 30 යි: මෙයින් පසු, පොඩ් එක අවසන් වන අතර මෙම කාල සීමාවට පෙර සියලුම ඉල්ලීම් සැකසීමට යෙදුමට කාලය තිබිය යුතුය. අදහස් දැක්වීම්: තත්පර 5-10කට වඩා ගතවන ඕනෑම ඉල්ලීමක් දැනටමත් ගැටළු සහගත වුවද, අලංකාර වසා දැමීම තවදුරටත් එයට උදව් නොවනු ඇත...

පොඩ් එකක් අවසන් වූ විට සිදුවන්නේ කුමක්ද යන්න වඩාත් හොඳින් අවබෝධ කර ගැනීමට, පහත රූප සටහන දෙස බලන්න:

A1, B1 - උදුනේ තත්වය පිළිබඳ වෙනස්කම් ලබා ගැනීම
A2 - පිටත්වීමේ SIGTERM
B2 - අන්ත ලක්ෂ්‍යයෙන් පොඩ් එකක් ඉවත් කිරීම
B3 - වෙනස්කම් ලැබීම (අවසාන ලක්ෂ්‍ය ලැයිස්තුව වෙනස් වී ඇත)
B4 - iptables නීති යාවත්කාලීන කරන්න

කරුණාකර සටහන් කරන්න: අන්ත ලක්ෂ්‍යය මකා දැමීම සහ SIGTERM යැවීම අනුක්‍රමිකව සිදු නොවේ, නමුත් සමාන්තරව සිදු වේ. සහ Ingress වෙත යාවත්කාලීන කරන ලද අන්ත ලක්ෂ්‍ය ලැයිස්තුව වහාම නොලැබෙන නිසා, සේවාදායකයින්ගේ නව ඉල්ලීම් පොඩ් වෙත යවනු ලැබේ, එය පොඩ් අවසන් කිරීමේදී 500 දෝෂයක් ඇති කරයි. (මෙම ගැටළුව පිළිබඳ වඩාත් සවිස්තරාත්මක තොරතුරු සඳහා, අපි පරිවර්තනය කර ඇත). මෙම ගැටළුව පහත දැක්වෙන ආකාරවලින් විසඳිය යුතුය:

• Send Connection: ප්‍රතිචාර ශීර්ෂයේ වසන්න (මෙය HTTP යෙදුමක් සම්බන්ධයෙන් නම්).
• කේතයේ වෙනස්කම් සිදු කිරීමට නොහැකි නම්, පහත ලිපියෙන් ඔබට ප්‍රසන්න කාල සීමාව අවසන් වන තෙක් ඉල්ලීම් සැකසීමට ඉඩ සලසන විසඳුමක් විස්තර කෙරේ.

න්යාය. NGINX සහ PHP-FPM ඔවුන්ගේ ක්‍රියාවලීන් අවසන් කරන ආකාරය

NGINX

අපි NGINX සමඟින් පටන් ගනිමු, මන්ද එය සමඟ සෑම දෙයක්ම අඩු වැඩි වශයෙන් පැහැදිලි වේ. න්‍යායට කිමිදෙමින්, NGINX හට එක් ප්‍රධාන ක්‍රියාවලියක් සහ “කම්කරුවන්” කිහිප දෙනෙකු ඇති බව අපි ඉගෙන ගනිමු - මේවා සේවාදායක ඉල්ලීම් සකසන ළමා ක්‍රියාවලි වේ. පහසු විකල්පයක් සපයනු ලැබේ: විධානය භාවිතා කිරීම nginx -s <SIGNAL> වේගවත් වසා දැමීමේ හෝ අලංකාර වසා දැමීමේ ආකාරයෙන් ක්රියාවලීන් අවසන් කරන්න. නිසැකවම, එය අපට උනන්දුවක් දක්වන අවසාන විකල්පයයි.

එවිට සෑම දෙයක්ම සරලයි: ඔබ එකතු කළ යුතුය preStop-කොක්ක අලංකාර වසා දැමීමේ සංඥාවක් යවන විධානයක්. මෙය යෙදවීමේදී, බහාලුම් කොටසෙහි සිදු කළ හැක:

       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 අවධානය යොමු කළ යුතු තවත් එක් අදියරක් තිබේ. NGINX විසින් තවමත් SIGQUIT සංඥාව වෙනුවට 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 දෝෂය තවදුරටත් නිරීක්ෂණය නොකරන බව මෙය තහවුරු වේ.

ඔබ සමාන ගැටලුවකට මුහුණ දෙන්නේ නම්, කන්ටේනරය තුළ භාවිතා කරන නැවතුම් සංඥාව කුමක්ද සහ හරියටම preStop කොක්කය කෙබඳුදැයි සොයා බැලීම අර්ථවත් කරයි. හේතුව හරියටම මේ තුළ ඇති බව බොහෝ දුරට ඉඩ ඇත.

PHP-FPM... සහ තවත්

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කට සකසන්නේ නම්, මෙය කන්ටේනරය තුළ ක්‍රියාත්මක වන බොහෝ විමසුම් ආවරණය කරන අතර ඒවා අවසන් වූ පසු ප්‍රධාන ක්‍රියාවලිය නවත්වනු ඇත.

මෙම දැනුම සමඟ, අපි අපගේ අවසාන ගැටලුව වෙත ආපසු යමු. සඳහන් කළ පරිදි, Kubernetes යනු මොනොලිතික් වේදිකාවක් නොවේ: එහි විවිධ සංරචක අතර සන්නිවේදනය යම් කාලයක් ගත වේ. මෙය විශේෂයෙන් සත්‍ය වන්නේ අප ඇතුල්වීම් සහ අනෙකුත් අදාළ සංරචකවල ක්‍රියාකාරිත්වය සලකා බලන විට, යෙදවීමේදී එවැනි ප්‍රමාදයක් හේතුවෙන් දෝෂ 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 කන්ටේනරයක ප්‍රති result ලයක් වූ අතර, එය පසුපෙළ හේතුවෙන් සම්බන්ධතා අතහැර දැමීය (එය Ingress එයට සම්බන්ධ වීම වළක්වන ලදී).

අපි බලමු කොහොමද කියලා process_control_timeout PHP-FPM හි ළමා ක්‍රියාවලීන් අවසන් වන තෙක් බලා සිටීමට අපට උපකාරී වනු ඇත, i.e. එවැනි වැරදි නිවැරදි කරන්න. මෙම විධානය භාවිතයෙන් නැවත යෙදවීම:

500 වැනි යෙදවීමේදී තවත් දෝෂ නොමැත! යෙදවීම සාර්ථකයි, අලංකාර වසා දැමීමේ ක්‍රියා.

කෙසේ වෙතත්, කාලය ප්‍රමාදයක් හේතුවෙන් අපට ලැබිය හැකි දෝෂ වලින් කුඩා ප්‍රතිශතයක් වන Ingress කන්ටේනර් සමඟ ඇති ගැටළුව මතක තබා ගැනීම වටී. ඒවා වළක්වා ගැනීම සඳහා, ඉතිරිව ඇත්තේ ව්යුහයක් එකතු කිරීමයි sleep සහ යෙදවීම නැවත කරන්න. කෙසේ වෙතත්, අපගේ විශේෂිත අවස්ථාවෙහිදී, කිසිදු වෙනසක් නොපෙනුණි (නැවත, දෝෂ නොමැත).

නිගමනය

ක්‍රියාවලිය අලංකාර ලෙස අවසන් කිරීම සඳහා, අපි යෙදුමෙන් පහත හැසිරීම් බලාපොරොත්තු වෙමු:

1. තත්පර කිහිපයක් රැඳී සිට නව සම්බන්ධතා පිළිගැනීම නවත්වන්න.
2. සියලුම ඉල්ලීම් සම්පූර්ණ කිරීමට සහ ඉල්ලීම් ක්‍රියාත්මක නොකරන සියලුම Keepalive සම්බන්ධතා වසා දැමීමට රැඳී සිටින්න.
3. ඔබේ ක්‍රියාවලිය අවසන් කරන්න.

කෙසේ වෙතත්, සියලුම යෙදුම් මේ ආකාරයෙන් ක්‍රියා කළ නොහැක. Kubernetes යථාර්ථයේ ගැටලුවට එක් විසඳුමක් වන්නේ:

• තත්පර කිහිපයක් බලා සිටින පෙර-නැවතුම් කොක්කක් එකතු කිරීම;
• සුදුසු පරාමිති සඳහා අපගේ පසුබිමෙහි වින්‍යාස ගොනුව අධ්‍යයනය කිරීම.

NGINX සමඟ ඇති උදාහරණය පැහැදිලි කරන්නේ මුලින් අවසන් කිරීමේ සංඥා නිවැරදිව සැකසිය යුතු යෙදුමක් පවා එසේ නොකළ හැකි බවයි, එබැවින් යෙදුම් යෙදවීමේදී දෝෂ 500ක් පරීක්ෂා කිරීම ඉතා වැදගත් වේ. මෙමගින් ඔබට ගැටලුව වඩාත් පුළුල් ලෙස බැලීමට සහ තනි පොඩ් එකක් හෝ බහාලුමක් කෙරෙහි අවධානය යොමු නොකර සමස්ත යටිතල පහසුකම් දෙස බැලීමටද ඉඩ සලසයි.

පරීක්ෂණ මෙවලමක් ලෙස, ඔබට ඕනෑම අධීක්ෂණ පද්ධතියක් සමඟ ඒකාබද්ධව Yandex.Tank භාවිතා කළ හැකිය (අපගේ නඩුවේදී, පරීක්ෂණය සඳහා Prometheus පසුබිමක් සහිත Grafana වෙතින් දත්ත ලබාගෙන ඇත). මිණුම් ලකුණට උත්පාදනය කළ හැකි අධික බරක් යටතේ අලංකාර වසා දැමීමේ ගැටළු පැහැදිලිව දැකගත හැකි අතර, පරීක්ෂණය අතරතුර හෝ පසුව තත්වය වඩාත් විස්තරාත්මකව විශ්ලේෂණය කිරීමට අධීක්ෂණය උපකාරී වේ.

ලිපිය පිළිබඳ ප්‍රතිපෝෂණයට ප්‍රතිචාර වශයෙන්: NGINX ඇතුල්වීම සම්බන්ධ ගැටළු සහ විසඳුම් මෙහි විස්තර කර ඇති බව සඳහන් කිරීම වටී. වෙනත් අවස්ථා සඳහා, ශ්‍රේණියේ පහත සඳහන් ද්‍රව්‍ය වලින් අපට සලකා බැලිය හැකි වෙනත් විසඳුම් තිබේ.

ප්රාදේශීය සභා

K8s ඉඟි සහ උපක්‍රම මාලාවෙන් වෙනත්:

• «NGINX ඇතුල්වීමේ අභිරුචි දෝෂ පිටු»;
• «වෙබ් යෙදුමක නෝඩ් වෙන් කිරීම සහ පැටවීම ගැන»;
• «dev අඩවි වෙත ප්‍රවේශය»;
• «විශාල දත්ත සමුදායන් සඳහා bootstrap වේගවත් කිරීම".

මූලාශ්රය: www.habr.com