Kubernetes ඉඟි සහ උපක්‍රම: 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> වේගවත් වසා දැමීම හෝ අලංකාර වසා දැමීම භාවිතයෙන් ක්‍රියාවලීන් අවසන් කරන්න. නිසැකවම, අපි දෙවන විකල්පය ගැන උනන්දු වෙමු.

එවිට සියල්ල සරලයි: ඔබ එකතු කළ යුතුයි පෙර-නැවතුම් කොක්ක අලංකාර වසා දැමීමේ සංඥාවක් යවන විධානයක්. මෙය 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 — අලංකාර වසා දැමීම (අපට අවශ්‍ය දේ).

මෙම කාර්යය සඳහා ඉතිරි සංඥා අවශ්‍ය නොවන බැවින්, අපි ඒවායේ විශ්ලේෂණය මඟ හරිමු. ක්‍රියාවලිය නිවැරදිව අවසන් වන බව සහතික කිරීම සඳහා, ඔබ පහත පූර්ව-නැවතුම් කොක්කය ලිවිය යුතුය:

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

මුලින්ම බැලූ බැල්මට, බහාලුම් දෙකෙහිම අලංකාර වසා දැමීමක් සිදු කිරීමට අවශ්‍ය වන්නේ මෙයයි. කෙසේ වෙතත්, කාර්යය පෙනෙන ආකාරයට වඩා සංකීර්ණයි. පහතින්, අලංකාර වසා දැමීම අසාර්ථක වූ සහ යෙදවීමේදී කෙටි ව්‍යාපෘතියක් ලබා ගත නොහැකි වීමට හේතු වූ අවස්ථා දෙකක් අපි පරීක්ෂා කරන්නෙමු.

පුහුණුව: Graceful Shutdown සමඟ ඇති විය හැකි ගැටළු

NGINX

පළමුවෙන්ම, මතක තබා ගැනීම ප්‍රයෝජනවත් වේ: විධානය ක්‍රියාත්මක කිරීමට අමතරව nginx -s quit තවත් එක් පියවරක් සඳහන් කිරීම වටී. NGINX තවමත් SIGQUIT වෙනුවට SIGTERM යවන ගැටලුවකට අපට මුහුණ දීමට සිදු වූ අතර, එමඟින් ඉල්ලීම් නිවැරදිව සම්පූර්ණ කිරීම වළක්වයි. ඒ හා සමාන අවස්ථා සොයාගත හැකිය, උදාහරණයක් ලෙස, මෙහිඅවාසනාවකට, මෙම හැසිරීමට නිශ්චිත හේතුව අපට තීරණය කිරීමට නොහැකි විය: අපි NGINX අනුවාදය සැක කළෙමු, නමුත් මෙය තහවුරු කර නොමැත. රෝග ලක්ෂණ අතර NGINX බහාලුම් ලොග් වල පණිවිඩ ඇතුළත් විය. "සම්බන්ධතාවය 5 හි ඉතිරිව ඇති සොකට් #10 විවෘත කරන්න", ඊට පස්සේ පොඩ් එක නැවතුනා.

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

යෙදවීමේදී තත්ව කේත දර්ශක

මෙම අවස්ථාවේදී, අපට 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... සහ තවත්

PHP-FPM සමඟ ඇති ගැටළුව සුළු වශයෙන් විස්තර කර ඇත: එය ළමා ක්‍රියාවලීන් සම්පූර්ණ වන තෙක් බලා නොසිට, ඒවා අවසන් කරමින්, යෙදවීමේදී සහ අනෙකුත් මෙහෙයුම් වලදී දෝෂ 502 ක් ඇති කරයි. 2005 සිට bugs.php.net හි දෝෂ වාර්තා කිහිපයක් තිබේ (උදාහරණයක් ලෙස, මෙහි и මෙහි), එය ගැටළුව විස්තර කරයි. කෙසේ වෙතත්, ඔබට ලොග් වල කිසිවක් නොපෙනේ: PHP-FPM කිසිදු දෝෂයක් හෝ බාහිර දැනුම්දීමකින් තොරව එහි ක්‍රියාවලිය අවසන් කිරීම නිවේදනය කරනු ඇත.

ගැටළුව බොහෝ දුරට යෙදුම්-විශේෂිත විය හැකි අතර එයම ප්‍රකාශ නොවිය හැකි බව පැහැදිලි කිරීම වටී, උදාහරණයක් ලෙස, නිරීක්ෂණයේදී. ඔබ එයට මුහුණ දෙන්නේ නම්, සරල විසඳුමක් මතකයට එයි: පෙර-නැවතුම් කොක්කක් එක් කරන්න sleep(30). එය ඔබට පෙර කරන ලද සියලුම ඉල්ලීම් සම්පූර්ණ කිරීමට ඉඩ සලසයි (තවද අපි නව ඒවා පිළිගන්නේ නැත, මන්ද pod දැනටමත් හැකියාව ඇත අවසන් කිරීම), සහ තත්පර 30 කට පසු පොඩ් එක සංඥාවක් සමඟ අවසන් වේ. 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.ටැංකිය: එය අපගේ සියලු අවශ්‍යතා පරිපූර්ණ ලෙස ආවරණය කරයි. ග්‍රැෆනා සහ යාන්ඩෙක්ස්.ටැංකි ප්‍රස්ථාරවලට ස්තූතිවන්ත වන පරිදි, අපගේ අත්දැකීම් වලින් දෘශ්‍ය උදාහරණයක් සමඟින්, පරීක්ෂා කිරීම සඳහා උපදෙස් සහ නිර්දේශ කිහිපයක් පහත දැක්වේ.

මෙහි වැදගත්ම දෙය නම් අදියරවල වෙනස්කම් පරීක්ෂා කරන්නනව නිවැරදි කිරීමක් එකතු කිරීමෙන් පසු, පරීක්ෂණයක් පවත්වා පෙර ධාවනයට සාපේක්ෂව ප්‍රතිඵල වෙනස් වී ඇත්දැයි බලන්න. එසේ නොමැතිනම්, අකාර්යක්ෂම විසඳුම් හඳුනා ගැනීම දුෂ්කර වනු ඇති අතර, දිගු කාලීනව, ඇත්ත වශයෙන්ම හානියක් සිදුවිය හැකිය (උදාහරණයක් ලෙස, යෙදවීමේ කාලය වැඩි කිරීමෙන්).

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

ඉතින්, පළමු පරීක්ෂණ ධාවනය නොමැතිව සිදු විය lifecycle සහ යෙදුම් සේවාදායකය සඳහා අමතර නියෝග නොමැතිව (process_control_timeout (PHP-FPM හි). මෙම පරීක්ෂණයේ අරමුණ වූයේ ආසන්න දෝෂ ගණන (සහ ඒවා තිබේද යන්න) හඳුනා ගැනීමයි. තවද, අතිරේක තොරතුරු වලින්, එක් එක් පොඩ් සඳහා සාමාන්‍ය යෙදවීමේ කාලය සම්පූර්ණ සූදානම දක්වා ආසන්න වශයෙන් තත්පර 5-10 ක් වූ බව සටහන් කළ යුතුය. ප්‍රතිඵල පහත පරිදි වේ:

Yandex.Tank උපකරණ පුවරුවේ, යෙදවීමේදී සිදු වූ සහ සාමාන්‍යයෙන් තත්පර 5 ක කාලයක් පැවති දෝෂ 502 ක වැඩිවීමක් පෙන්නුම් කරයි. මෙය පැරණි පොඩ් එක අවසන් කිරීම සඳහා පවතින ඉල්ලීම් නිසා ඇති වූවක් විය හැකිය. මෙයින් පසු, දෝෂ 503 ක් දර්ශනය වූ අතර, එය නතර කරන ලද NGINX බහාලුමක ප්‍රතිඵලයක් වූ අතර, එය පසුබිම හේතුවෙන් සම්බන්ධතා ද බිඳ වැටුණි (Ingress එයට සම්බන්ධ වීම වැළැක්වීම).

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

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

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

නිගමනය

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

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

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

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

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

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

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

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

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

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

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