కుబెర్నెటెస్ చిట్కాలు & ఉపాయాలు: NGINX మరియు PHP-FPMలో ఆకర్షణీయమైన షట్‌డౌన్ లక్షణాలు

Kubernetesలో CI/CDని అమలు చేస్తున్నప్పుడు ఒక సాధారణ షరతు: అప్లికేషన్ పూర్తిగా ఆపివేసే ముందు కొత్త క్లయింట్ అభ్యర్థనలను ఆమోదించకుండా ఉండాలి మరియు ముఖ్యంగా, ఇప్పటికే ఉన్న వాటిని విజయవంతంగా పూర్తి చేయాలి.

ఈ షరతుతో వర్తింపు విస్తరణ సమయంలో సున్నా పనికిరాని సమయాన్ని సాధించడానికి మిమ్మల్ని అనుమతిస్తుంది. అయినప్పటికీ, చాలా జనాదరణ పొందిన బండిల్‌లను (NGINX మరియు PHP-FPM వంటివి) ఉపయోగిస్తున్నప్పుడు కూడా, మీరు ప్రతి విస్తరణతో లోపాల పెరుగుదలకు దారితీసే ఇబ్బందులను ఎదుర్కోవచ్చు...

సిద్ధాంతం. పాడ్ ఎలా జీవిస్తుంది

పాడ్ యొక్క జీవిత చక్రం గురించి మేము ఇప్పటికే వివరంగా ప్రచురించాము ఈ వ్యాసం. పరిశీలనలో ఉన్న అంశం సందర్భంలో, మేము ఈ క్రింది వాటిపై ఆసక్తి కలిగి ఉన్నాము: పాడ్ రాష్ట్రంలోకి ప్రవేశించిన సమయంలో రద్దు, కొత్త అభ్యర్థనలు దీనికి పంపబడటం ఆగిపోతుంది (పాడ్ తొలగించబడింది సేవ కోసం ముగింపు పాయింట్ల జాబితా నుండి). అందువల్ల, విస్తరణ సమయంలో పనికిరాని సమయాన్ని నివారించడానికి, అప్లికేషన్‌ను సరిగ్గా ఆపే సమస్యను పరిష్కరించడం మాకు సరిపోతుంది.

డిఫాల్ట్ గ్రేస్ పీరియడ్ అని కూడా మీరు గుర్తుంచుకోవాలి 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-FPM

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-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: ఇది మన అవసరాలన్నింటినీ సంపూర్ణంగా కవర్ చేస్తుంది. 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 ప్రవేశానికి సంబంధించి ఇక్కడ సమస్యలు మరియు పరిష్కారాలు వివరించడం విలువైనది. ఇతర సందర్భాల్లో, ఇతర పరిష్కారాలు ఉన్నాయి, వీటిని మేము సిరీస్‌లోని క్రింది పదార్థాలలో పరిగణించవచ్చు.

PS

K8s చిట్కాలు & ఉపాయాలు సిరీస్ నుండి ఇతర:

• «NGINX ప్రవేశంలో అనుకూల లోపం పేజీలు";
• «వెబ్ అప్లికేషన్‌లో నోడ్ కేటాయింపు మరియు లోడ్‌ల గురించి";
• «dev సైట్‌లకు యాక్సెస్";
• «పెద్ద డేటాబేస్‌ల కోసం బూట్‌స్ట్రాప్‌ను వేగవంతం చేస్తోంది".

మూలం: www.habr.com