குபெர்னெட்டஸ் உதவிக்குறிப்புகள் மற்றும் தந்திரங்கள்: 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 க்கு ஒரு முதன்மை செயல்முறை மற்றும் பல "தொழிலாளர்கள்" உள்ளனர் - இவை கிளையன்ட் கோரிக்கைகளை செயல்படுத்தும் குழந்தை செயல்முறைகள். ஒரு வசதியான விருப்பம் வழங்கப்படுகிறது: கட்டளையைப் பயன்படுத்தி 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

முதலில், நினைவில் கொள்வது பயனுள்ளது: கட்டளையை இயக்குவதற்கு கூடுதலாக 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... மற்றும் பல

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. உங்கள் செயல்முறையை முடிக்கவும்.

இருப்பினும், எல்லா பயன்பாடுகளும் இந்த வழியில் செயல்பட முடியாது. குபெர்னெட்ஸ் யதார்த்தங்களில் உள்ள பிரச்சனைக்கு ஒரு தீர்வு:

• சில வினாடிகள் காத்திருக்கும் முன் நிறுத்தக் கொக்கியைச் சேர்த்தல்;
• பொருத்தமான அளவுருக்களுக்காக எங்கள் பின்தளத்தின் உள்ளமைவு கோப்பைப் படிக்கிறது.

NGINX உடனான உதாரணம், தொடக்கத்தில் நிறுத்தப்படும் சிக்னல்களைச் சரியாகச் செயல்படுத்தும் ஒரு பயன்பாடு கூட அவ்வாறு செய்யாமல் போகலாம் என்பதைத் தெளிவுபடுத்துகிறது, எனவே பயன்பாட்டின் வரிசைப்படுத்தலின் போது 500 பிழைகளைச் சரிபார்க்க வேண்டியது அவசியம். இது சிக்கலை இன்னும் விரிவாகப் பார்க்கவும், ஒரு பாட் அல்லது கொள்கலனில் கவனம் செலுத்தாமல், ஒட்டுமொத்த உள்கட்டமைப்பைப் பார்க்கவும் உங்களை அனுமதிக்கிறது.

ஒரு சோதனைக் கருவியாக, நீங்கள் Yandex.Tank ஐ எந்த கண்காணிப்பு அமைப்புடன் இணைந்து பயன்படுத்தலாம் (எங்கள் விஷயத்தில், சோதனைக்கான ப்ரோமிதியஸ் பின்தளத்தில் கிராஃபானாவிலிருந்து தரவு எடுக்கப்பட்டது). பெஞ்ச்மார்க் உருவாக்கக்கூடிய அதிக சுமைகளின் கீழ் அழகான பணிநிறுத்தத்தில் உள்ள சிக்கல்கள் தெளிவாகத் தெரியும், மேலும் சோதனையின் போது அல்லது அதற்குப் பிறகு நிலைமையை இன்னும் விரிவாக பகுப்பாய்வு செய்ய கண்காணிப்பு உதவுகிறது.

கட்டுரையின் பின்னூட்டங்களுக்கு பதிலளிக்கும் விதமாக: NGINX இன்க்ரெஸ் தொடர்பாக இங்குள்ள சிக்கல்கள் மற்றும் தீர்வுகள் விவரிக்கப்பட்டுள்ளன என்பது குறிப்பிடத்தக்கது. மற்ற சந்தர்ப்பங்களில், தொடரின் பின்வரும் பொருட்களில் நாம் கருத்தில் கொள்ளக்கூடிய பிற தீர்வுகள் உள்ளன.

சோசலிஸ்ட் கட்சி

K8s டிப்ஸ் & ட்ரிக்ஸ் தொடரிலிருந்து மற்றவை:

• «NGINX நுழைவில் தனிப்பயன் பிழை பக்கங்கள்";
• «வலைப் பயன்பாட்டில் முனை ஒதுக்கீடு மற்றும் ஏற்றுதல் பற்றி";
• «டெவ் தளங்களுக்கான அணுகல்";
• «பெரிய தரவுத்தளங்களுக்கான பூட்ஸ்ட்ராப்பை விரைவுபடுத்துகிறது".

ஆதாரம்: www.habr.com