કુબરનેટ્સ ટીપ્સ અને યુક્તિઓ: NGINX અને PHP-FPM માં આકર્ષક શટડાઉનની સુવિધાઓ

કુબરનેટ્સમાં 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 -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, એફપીએમ

PHP-FPM ના કિસ્સામાં, થોડી ઓછી માહિતી છે. જો તમે ધ્યાન કેન્દ્રિત કરો છો સત્તાવાર માર્ગદર્શિકા PHP-FPM અનુસાર, તે કહેશે કે નીચેના POSIX સિગ્નલો સ્વીકારવામાં આવ્યા છે:

1. SIGINT, SIGTERM - ઝડપી શટડાઉન;
2. SIGQUIT - આકર્ષક શટડાઉન (અમને શું જોઈએ છે).

આ કાર્યમાં બાકીના સંકેતોની જરૂર નથી, તેથી અમે તેમના વિશ્લેષણને છોડી દઈશું. પ્રક્રિયાને યોગ્ય રીતે સમાપ્ત કરવા માટે, તમારે નીચેનું પ્રીસ્ટોપ હૂક લખવાની જરૂર પડશે:

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

પ્રથમ નજરમાં, બંને કન્ટેનરમાં આકર્ષક શટડાઉન કરવા માટે આ બધું જરૂરી છે. જો કે, કાર્ય લાગે તે કરતાં વધુ મુશ્કેલ છે. નીચે બે કિસ્સાઓ છે જેમાં આકર્ષક શટડાઉન કામ કરતું ન હતું અને જમાવટ દરમિયાન પ્રોજેક્ટની ટૂંકા ગાળાની અનુપલબ્ધતાનું કારણ બને છે.

પ્રેક્ટિસ કરો. આકર્ષક શટડાઉન સાથે સંભવિત સમસ્યાઓ

એનજીઆઈએનએક્સ

સૌ પ્રથમ, તે યાદ રાખવું ઉપયોગી છે: આદેશ ચલાવવા ઉપરાંત nginx -s quit ત્યાં એક વધુ તબક્કો છે જેના પર ધ્યાન આપવું યોગ્ય છે. અમને એક સમસ્યા આવી કે જ્યાં NGINX હજુ પણ SIGQUIT સિગ્નલને બદલે SIGTERM મોકલશે, જેના કારણે વિનંતીઓ યોગ્ય રીતે પૂર્ણ થઈ નથી. સમાન કિસ્સાઓ શોધી શકાય છે, ઉદાહરણ તરીકે, અહીં. કમનસીબે, અમે આ વર્તણૂકનું ચોક્કસ કારણ નક્કી કરવામાં અસમર્થ હતા: NGINX સંસ્કરણ વિશે શંકા હતી, પરંતુ તેની પુષ્ટિ થઈ ન હતી. લક્ષણ એ હતું કે NGINX કન્ટેનર લોગમાં સંદેશાઓ જોવા મળ્યા હતા: "ઓપન સોકેટ #10 કનેક્શન 5 માં બાકી છે", જે પછી પોડ બંધ થઈ ગયો.

અમે આવી સમસ્યાનું અવલોકન કરી શકીએ છીએ, ઉદાહરણ તરીકે, ઇન્ગ્રેસ પરના પ્રતિભાવોમાંથી અમને જરૂર છે:

જમાવટ સમયે સ્ટેટસ કોડના સૂચક

આ કિસ્સામાં, અમને ઇન્ગ્રેસ તરફથી માત્ર એક 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). તે તમને પહેલાની બધી વિનંતીઓ પૂર્ણ કરવાની મંજૂરી આપશે (અને પોડથી અમે નવી સ્વીકારતા નથી પહેલેથી સક્ષમ સમાપ્ત), અને 30 સેકન્ડ પછી પોડ પોતે સિગ્નલ સાથે સમાપ્ત થશે SIGTERM.

તે તારણ આપે છે કે lifecycle કન્ટેનર માટે આના જેવો દેખાશે:

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

જો કે, 30-સેકન્ડના કારણે sleep અમે છીએ сильно અમે જમાવટનો સમય વધારીશું, કારણ કે દરેક પોડ સમાપ્ત થશે લઘુત્તમ 30 સેકન્ડ, જે ખરાબ છે. આ વિશે શું કરી શકાય?

ચાલો અરજીના સીધા અમલ માટે જવાબદાર પક્ષ તરફ વળીએ. અમારા કિસ્સામાં તે છે PHP, એફપીએમ, જે મૂળભૂત રીતે તેની બાળ પ્રક્રિયાઓના અમલ પર દેખરેખ રાખતું નથી: માસ્ટર પ્રક્રિયા તરત જ સમાપ્ત થાય છે. તમે નિર્દેશનો ઉપયોગ કરીને આ વર્તન બદલી શકો છો 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: તે અમારી તમામ જરૂરિયાતોને સંપૂર્ણ રીતે આવરી લે છે. Grafana અને 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. તમારી પ્રક્રિયા સમાપ્ત કરો.

જો કે, બધી એપ્લિકેશનો આ રીતે કામ કરી શકતી નથી. કુબરનેટ્સ વાસ્તવિકતાઓમાં સમસ્યાનો એક ઉકેલ છે:

• પ્રી-સ્ટોપ હૂક ઉમેરવું જે થોડી સેકંડ રાહ જોશે;
• યોગ્ય પરિમાણો માટે અમારા બેકએન્ડની રૂપરેખાંકન ફાઇલનો અભ્યાસ કરી રહ્યા છીએ.

એનજીઆઈએનએક્સ સાથેનું ઉદાહરણ સ્પષ્ટ કરે છે કે જે એપ્લિકેશનને શરૂઆતમાં સમાપ્તિ સિગ્નલો પર યોગ્ય રીતે પ્રક્રિયા કરવી જોઈએ તે પણ આવું કરી શકશે નહીં, તેથી એપ્લિકેશન જમાવટ દરમિયાન 500 ભૂલો માટે તપાસ કરવી મહત્વપૂર્ણ છે. આ તમને સમસ્યાને વધુ વ્યાપક રીતે જોવાની અને એક પોડ અથવા કન્ટેનર પર ધ્યાન કેન્દ્રિત ન કરવા માટે, પરંતુ સમગ્ર ઇન્ફ્રાસ્ટ્રક્ચરને સંપૂર્ણ રીતે જોવાની મંજૂરી આપે છે.

પરીક્ષણ સાધન તરીકે, તમે કોઈપણ મોનિટરિંગ સિસ્ટમ સાથે જોડાણમાં Yandex.Tank નો ઉપયોગ કરી શકો છો (અમારા કિસ્સામાં, પરીક્ષણ માટે પ્રોમિથિયસ બેકએન્ડ સાથે ગ્રાફના પાસેથી ડેટા લેવામાં આવ્યો હતો). બેન્ચમાર્ક જનરેટ કરી શકે તેવા ભારે ભાર હેઠળ આકર્ષક શટડાઉન સાથેની સમસ્યાઓ સ્પષ્ટપણે દેખાય છે, અને નિરીક્ષણ પરીક્ષણ દરમિયાન અથવા પછી પરિસ્થિતિનું વધુ વિગતવાર વિશ્લેષણ કરવામાં મદદ કરે છે.

લેખ પરના પ્રતિસાદના જવાબમાં: એ ઉલ્લેખનીય છે કે NGINX ઇન્ગ્રેસના સંબંધમાં સમસ્યાઓ અને ઉકેલો અહીં વર્ણવેલ છે. અન્ય કિસ્સાઓમાં, ત્યાં અન્ય ઉકેલો છે, જે અમે શ્રેણીની નીચેની સામગ્રીમાં ધ્યાનમાં લઈ શકીએ છીએ.

PS

K8s ટીપ્સ અને યુક્તિઓ શ્રેણીમાંથી અન્ય:

• «NGINX પ્રવેશમાં કસ્ટમ ભૂલ પૃષ્ઠો»;
• «વેબ એપ્લિકેશન પર નોડ ફાળવણી અને લોડ વિશે»;
• «ડેવ સાઇટ્સની ઍક્સેસ»;
• «મોટા ડેટાબેસેસ માટે બુટસ્ટ્રેપને ઝડપી બનાવવું».

સોર્સ: www.habr.com