कुबेरनेट्स टिप्स और ट्रिक्स: एनजीआईएनएक्स और पीएचपी-एफपीएम में शानदार शटडाउन की विशेषताएं

कुबेरनेट्स में सीआई/सीडी को लागू करते समय एक विशिष्ट स्थिति: एप्लिकेशन को पूरी तरह से रोकने से पहले नए क्लाइंट अनुरोधों को स्वीकार करने में सक्षम नहीं होना चाहिए, और सबसे महत्वपूर्ण बात यह है कि मौजूदा अनुरोधों को सफलतापूर्वक पूरा करना होगा।

इस शर्त का अनुपालन आपको तैनाती के दौरान शून्य डाउनटाइम प्राप्त करने की अनुमति देता है। हालाँकि, बहुत लोकप्रिय बंडलों (जैसे एनजीआईएनएक्स और पीएचपी-एफपीएम) का उपयोग करते समय भी, आपको कठिनाइयों का सामना करना पड़ सकता है जिससे प्रत्येक तैनाती के साथ त्रुटियों में वृद्धि होगी...

लिखित। फली कैसे रहती है

हम पहले ही फली के जीवन चक्र के बारे में विस्तार से प्रकाशित कर चुके हैं यह लेख. विचाराधीन विषय के संदर्भ में, हम निम्नलिखित में रुचि रखते हैं: उस समय जब पॉड राज्य में प्रवेश करता है समाप्त, नए अनुरोध इसे भेजे जाने बंद हो जाते हैं (पॉड)। हटाए गए सेवा के लिए अंतिम बिंदुओं की सूची से)। इस प्रकार, तैनाती के दौरान डाउनटाइम से बचने के लिए, एप्लिकेशन को सही ढंग से रोकने की समस्या को हल करना हमारे लिए पर्याप्त है।

आपको यह भी याद रखना चाहिए कि डिफ़ॉल्ट अनुग्रह अवधि है 30 सेकंड: इसके बाद, पॉड समाप्त कर दिया जाएगा और एप्लिकेशन के पास इस अवधि से पहले सभी अनुरोधों को संसाधित करने का समय होना चाहिए। नोट: हालाँकि 5-10 सेकंड से अधिक समय लेने वाला कोई भी अनुरोध पहले से ही समस्याग्रस्त है, और शालीन शटडाउन अब इसमें मदद नहीं करेगा...

यह बेहतर ढंग से समझने के लिए कि जब एक पॉड समाप्त हो जाता है तो क्या होता है, बस निम्नलिखित चित्र देखें:

ए1, बी1 - चूल्हा की स्थिति के बारे में परिवर्तन प्राप्त करना
ए2 - प्रस्थान सिगटर्म
बी2 - एंडपॉइंट से एक पॉड को हटाना
बी3 - परिवर्तन प्राप्त करना (अंतिम बिंदुओं की सूची बदल गई है)
बी4 - आईपीटेबल्स नियम अपडेट करें

कृपया ध्यान दें: एंडपॉइंट पॉड को हटाना और SIGTERM भेजना क्रमिक रूप से नहीं, बल्कि समानांतर में होता है। और इस तथ्य के कारण कि इंग्रेस को एंडपॉइंट की अद्यतन सूची तुरंत प्राप्त नहीं होती है, ग्राहकों से नए अनुरोध पॉड को भेजे जाएंगे, जिससे पॉड समाप्ति के दौरान 500 त्रुटि होगी (इस मुद्दे पर अधिक विस्तृत सामग्री के लिए, हम अनुवाद). इस समस्या को निम्नलिखित तरीकों से हल करने की आवश्यकता है:

• कनेक्शन भेजें: प्रतिक्रिया हेडर में बंद करें (यदि यह HTTP एप्लिकेशन से संबंधित है)।
• यदि कोड में परिवर्तन करना संभव नहीं है, तो निम्नलिखित आलेख एक समाधान का वर्णन करता है जो आपको अनुग्रह अवधि के अंत तक अनुरोधों को संसाधित करने की अनुमति देगा।

लिखित। एनजीआईएनएक्स और पीएचपी-एफपीएम अपनी प्रक्रियाओं को कैसे समाप्त करते हैं

nginx

आइए एनजीआईएनएक्स से शुरुआत करें, क्योंकि इसके साथ सब कुछ कमोबेश स्पष्ट है। सिद्धांत में गोता लगाने पर, हमें पता चलता है कि एनजीआईएनएक्स में एक मास्टर प्रक्रिया और कई "कार्यकर्ता" हैं - ये चाइल्ड प्रक्रियाएं हैं जो क्लाइंट के अनुरोधों को संसाधित करती हैं। एक सुविधाजनक विकल्प प्रदान किया गया है: कमांड का उपयोग करना nginx -s <SIGNAL> प्रक्रियाओं को तेज़ शटडाउन या ग्रेसफुल शटडाउन मोड में समाप्त करें। जाहिर है, यह बाद वाला विकल्प है जिसमें हमारी रुचि है।

फिर सब कुछ सरल है: आपको जोड़ने की जरूरत है प्रीस्टॉप-हुक एक आदेश जो एक सुंदर शटडाउन सिग्नल भेजेगा। यह परिनियोजन में, कंटेनर ब्लॉक में किया जा सकता है:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

अब, जब पॉड बंद हो जाता है, तो हम एनजीआईएनएक्स कंटेनर लॉग में निम्नलिखित देखेंगे:

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 -s quit प्रक्रिया ग़लत ढंग से समाप्त हो जाती है.

और इस स्तर पर हमने एनजीआईएनएक्स का काम पूरा कर लिया है: कम से कम लॉग से आप समझ सकते हैं कि सब कुछ उसी तरह काम कर रहा है जैसा उसे करना चाहिए।

PHP-FPM के साथ क्या डील है? यह ग्रेसफुल शटडाउन को कैसे संभालता है? आइए इसका पता लगाएं।

पीएचपी-एफ पी एम

PHP-FPM के मामले में, थोड़ी कम जानकारी है। यदि आप ध्यान केंद्रित करते हैं आधिकारिक मैनुअल PHP-FPM के अनुसार, यह कहेगा कि निम्नलिखित POSIX सिग्नल स्वीकार किए जाते हैं:

1. SIGINT, SIGTERM - तेज़ शटडाउन;
2. SIGQUIT - सुशोभित शटडाउन (हमें क्या चाहिए)।

इस कार्य में शेष संकेतों की आवश्यकता नहीं है, इसलिए हम उनका विश्लेषण छोड़ देंगे। प्रक्रिया को सही ढंग से समाप्त करने के लिए, आपको निम्नलिखित प्रीस्टॉप हुक लिखना होगा:

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

पहली नज़र में, दोनों कंटेनरों में एक शानदार शटडाउन करने के लिए बस इतना ही आवश्यक है। हालाँकि, यह कार्य जितना लगता है उससे कहीं अधिक कठिन है। नीचे दो मामले हैं जिनमें ग्रेसफुल शटडाउन ने काम नहीं किया और तैनाती के दौरान परियोजना की अल्पकालिक अनुपलब्धता हुई।

अभ्यास। ग्रेसफुल शटडाउन के साथ संभावित समस्याएं

nginx

सबसे पहले, यह याद रखना उपयोगी है: कमांड को निष्पादित करने के अलावा nginx -s quit एक और चरण है जिस पर ध्यान देना ज़रूरी है। हमें एक समस्या का सामना करना पड़ा जहां एनजीआईएनएक्स अभी भी SIGQUIT सिग्नल के बजाय SIGTERM भेजता था, जिससे अनुरोध सही ढंग से पूरा नहीं हो पाता था। उदाहरण के लिए, ऐसे ही मामले पाए जा सकते हैं, यहां. दुर्भाग्य से, हम इस व्यवहार का विशिष्ट कारण निर्धारित करने में असमर्थ थे: एनजीआईएनएक्स संस्करण के बारे में संदेह था, लेकिन इसकी पुष्टि नहीं की गई थी। लक्षण यह था कि संदेश एनजीआईएनएक्स कंटेनर लॉग में देखे गए थे: "कनेक्शन 10 में शेष खुला सॉकेट #5", जिसके बाद पॉड बंद हो गया।

हम ऐसी समस्या का अवलोकन कर सकते हैं, उदाहरण के लिए, हमें आवश्यक इनग्रेस पर प्रतिक्रियाओं से:

तैनाती के समय स्थिति कोड के संकेतक

इस मामले में, हमें इनग्रेस से केवल 503 त्रुटि कोड प्राप्त होता है: यह एनजीआईएनएक्स कंटेनर तक नहीं पहुंच सकता है, क्योंकि यह अब पहुंच योग्य नहीं है। यदि आप एनजीआईएनएक्स के साथ कंटेनर लॉग को देखते हैं, तो उनमें निम्नलिखित शामिल हैं:

[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 सेकंड, जो ख़राब है. इसके बारे में क्या किया जा सकता है?

आइए आवेदन के सीधे निष्पादन के लिए जिम्मेदार पक्ष की ओर मुड़ें। हमारे मामले में यह है पीएचपी-एफ पी एमजो डिफ़ॉल्ट रूप से अपनी चाइल्ड प्रक्रियाओं के निष्पादन की निगरानी नहीं करता है: मास्टर प्रक्रिया तुरंत समाप्त हो जाती है। आप निर्देश का उपयोग करके इस व्यवहार को बदल सकते हैं 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 कंटेनर तक)? एप्लिकेशन में ही त्रुटियाँ (जैसा कि ऊपर वर्णित एनजीआईएनएक्स के मामले में)? मुझे आशा है कि इस लेख की परिचयात्मक जानकारी आपको यह बेहतर ढंग से समझने में मदद करेगी कि समाप्ति के दौरान कंटेनर का क्या होता है।

तो, पहला टेस्ट रन बिना हुआ lifecycle और एप्लिकेशन सर्वर के लिए अतिरिक्त निर्देशों के बिना (process_control_timeout PHP-FPM में)। इस परीक्षण का उद्देश्य त्रुटियों की अनुमानित संख्या (और क्या कोई हैं) की पहचान करना था। इसके अलावा, अतिरिक्त जानकारी से, आपको पता होना चाहिए कि प्रत्येक पॉड के लिए औसत तैनाती का समय लगभग 5-10 सेकंड था जब तक कि यह पूरी तरह से तैयार न हो जाए। परिणाम हैं:

Yandex.Tank सूचना पैनल 502 त्रुटियों की वृद्धि दिखाता है, जो तैनाती के समय हुई और औसतन 5 सेकंड तक चली। संभवतः ऐसा इसलिए था क्योंकि पुराने पॉड को समाप्त करते समय मौजूदा अनुरोध समाप्त हो रहे थे। इसके बाद, 503 त्रुटियां सामने आईं, जो एक रुके हुए एनजीआईएनएक्स कंटेनर का परिणाम था, जिसने बैकएंड के कारण कनेक्शन भी गिरा दिया (जिसने इनग्रेस को इससे कनेक्ट होने से रोक दिया)।

आइए देखें कैसे process_control_timeout PHP-FPM में हमें चाइल्ड प्रक्रियाओं के पूरा होने की प्रतीक्षा करने में मदद मिलेगी, यानी। ऐसी त्रुटियों को सुधारें. इस निर्देश का उपयोग करके पुनः तैनात करें:

500वीं तैनाती के दौरान कोई और त्रुटि नहीं है! परिनियोजन सफल है, सुंदर शटडाउन कार्य करता है।

हालाँकि, इनग्रेस कंटेनरों के मुद्दे को याद रखना उचित है, त्रुटियों का एक छोटा प्रतिशत जो हमें समय अंतराल के कारण प्राप्त हो सकता है। उनसे बचने के लिए, जो कुछ बचा है वह है एक संरचना जोड़ना sleep और परिनियोजन दोहराएँ. हालाँकि, हमारे विशेष मामले में, कोई परिवर्तन दिखाई नहीं दे रहा था (फिर से, कोई त्रुटि नहीं)।

निष्कर्ष

प्रक्रिया को शालीनतापूर्वक समाप्त करने के लिए, हम एप्लिकेशन से निम्नलिखित व्यवहार की अपेक्षा करते हैं:

1. कुछ सेकंड प्रतीक्षा करें और फिर नए कनेक्शन स्वीकार करना बंद कर दें।
2. सभी अनुरोधों के पूरा होने तक प्रतीक्षा करें और उन सभी कीपेलिव कनेक्शनों को बंद कर दें जो अनुरोधों को निष्पादित नहीं कर रहे हैं।
3. अपनी प्रक्रिया समाप्त करें.

हालाँकि, सभी एप्लिकेशन इस तरह से काम नहीं कर सकते। कुबेरनेट्स वास्तविकताओं में समस्या का एक समाधान है:

• एक प्री-स्टॉप हुक जोड़ना जो कुछ सेकंड प्रतीक्षा करेगा;
• उपयुक्त मापदंडों के लिए हमारे बैकएंड की कॉन्फ़िगरेशन फ़ाइल का अध्ययन करना।

एनजीआईएनएक्स के साथ उदाहरण यह स्पष्ट करता है कि यहां तक ​​कि एक एप्लिकेशन जिसे शुरू में समाप्ति संकेतों को सही ढंग से संसाधित करना चाहिए, वह ऐसा नहीं कर सकता है, इसलिए एप्लिकेशन परिनियोजन के दौरान 500 त्रुटियों की जांच करना महत्वपूर्ण है। यह आपको समस्या को अधिक व्यापक रूप से देखने की अनुमति देता है और किसी एक पॉड या कंटेनर पर ध्यान केंद्रित नहीं करता है, बल्कि संपूर्ण बुनियादी ढांचे को समग्र रूप से देखता है।

एक परीक्षण उपकरण के रूप में, आप किसी भी निगरानी प्रणाली के साथ Yandex.Tank का उपयोग कर सकते हैं (हमारे मामले में, परीक्षण के लिए प्रोमेथियस बैकएंड के साथ ग्राफाना से डेटा लिया गया था)। ग्रेसफुल शटडाउन की समस्याएँ भारी भार के तहत स्पष्ट रूप से दिखाई देती हैं जो बेंचमार्क उत्पन्न कर सकता है, और निगरानी परीक्षण के दौरान या उसके बाद स्थिति का अधिक विस्तार से विश्लेषण करने में मदद करती है।

लेख पर प्रतिक्रिया के जवाब में: यह उल्लेखनीय है कि एनजीआईएनएक्स इनग्रेस के संबंध में समस्याओं और समाधानों का वर्णन यहां किया गया है। अन्य मामलों के लिए, अन्य समाधान भी हैं, जिन पर हम श्रृंखला की निम्नलिखित सामग्रियों में विचार कर सकते हैं।

पुनश्च

K8s टिप्स और ट्रिक्स श्रृंखला से अन्य:

• «एनजीआईएनएक्स इनग्रेस में कस्टम त्रुटि पृष्ठ";
• «नोड्स के आवंटन और वेब एप्लिकेशन पर लोड के बारे में";
• «देव साइटों तक पहुंच";
• «बड़े डेटाबेस के लिए बूटस्ट्रैप को तेज़ करना'.

स्रोत: www.habr.com