कुबर्नेट्स टिप्स आणि युक्त्या: एनजीआयएनएक्स आणि पीएचपी-एफपीएम मधील आकर्षक शटडाउनची वैशिष्ट्ये

Kubernetes मध्ये CI/CD लागू करताना एक विशिष्ट स्थिती: अनुप्रयोग पूर्णपणे थांबण्यापूर्वी नवीन क्लायंट विनंत्या स्वीकारू शकत नाही आणि सर्वात महत्त्वाचे म्हणजे, विद्यमान असलेल्या यशस्वीरित्या पूर्ण करू शकत नाही.

या अटीचे पालन केल्याने तुम्हाला तैनातीदरम्यान शून्य डाउनटाइम साध्य करता येतो. तथापि, अगदी लोकप्रिय बंडल (एनजीआयएनएक्स आणि पीएचपी-एफपीएम सारखे) वापरत असतानाही, तुम्हाला अडचणी येऊ शकतात ज्यामुळे प्रत्येक तैनातीमध्ये त्रुटींची वाढ होईल...

सिद्धांत. पॉड कसे जगतात

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

तुम्ही हे देखील लक्षात ठेवावे की डीफॉल्ट वाढीव कालावधी आहे 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 नुसार, ते असे म्हणेल की खालील POSIX सिग्नल स्वीकारले जातात:

1. SIGINT, SIGTERM - जलद शटडाउन;
2. SIGQUIT - आकर्षक शटडाउन (आम्हाला काय हवे आहे).

या कार्यामध्ये उर्वरित सिग्नल आवश्यक नाहीत, म्हणून आम्ही त्यांचे विश्लेषण वगळू. प्रक्रिया योग्यरित्या समाप्त करण्यासाठी, तुम्हाला खालील प्रीस्टॉप हुक लिहावे लागेल:

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

पहिल्या दृष्टीक्षेपात, दोन्ही कंटेनरमध्ये आकर्षक शटडाउन करण्यासाठी हे सर्व आवश्यक आहे. तथापि, कार्य दिसते त्यापेक्षा अधिक कठीण आहे. खाली दोन प्रकरणे आहेत ज्यात आकर्षक शटडाउन कार्य करत नाही आणि तैनाती दरम्यान प्रकल्पाची अल्पकालीन अनुपलब्धता निर्माण झाली.

सराव. ग्रेसफुल शटडाउनसह संभाव्य समस्या

एनजीएनएक्स

सर्व प्रथम, हे लक्षात ठेवणे उपयुक्त आहे: कमांड कार्यान्वित करण्याव्यतिरिक्त nginx -s quit आणखी एक टप्पा आहे ज्याकडे लक्ष देणे योग्य आहे. आम्हाला एक समस्या आली जिथे NGINX अजूनही SIGQUIT सिग्नलऐवजी 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 त्रुटी उद्भवतात. bugs.php.net वर 2005 पासून अनेक बग अहवाल आहेत (उदा येथे и येथे), जे या समस्येचे वर्णन करते. परंतु बहुधा तुम्हाला लॉगमध्ये काहीही दिसणार नाही: PHP-FPM कोणत्याही त्रुटी किंवा तृतीय-पक्ष सूचनांशिवाय त्याची प्रक्रिया पूर्ण झाल्याची घोषणा करेल.

हे स्पष्ट करणे योग्य आहे की समस्या स्वतःच अनुप्रयोगावर कमी किंवा जास्त प्रमाणात अवलंबून असू शकते आणि स्वतः प्रकट होऊ शकत नाही, उदाहरणार्थ, मॉनिटरिंगमध्ये. तुम्‍हाला ते आढळल्‍यास, प्रथम एक सोपा उपाय लक्षात येईल: प्रीस्‍टॉप हुक यासह जोडा sleep(30). हे तुम्हाला आधीच्या सर्व विनंत्या पूर्ण करण्यास अनुमती देईल (आणि पॉडपासून आम्ही नवीन स्वीकारत नाही आधीच सक्षम समाप्त करणे), आणि 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 आणि डिप्लॉयमेंटची वेळ मोठ्या प्रमाणात वाढवू नका: ३० सेकंद आणि एक यांमध्ये लक्षणीय फरक आहे का?.. खरं तर, ते आहे process_control_timeoutआणि lifecycle अंतराच्या बाबतीत फक्त "सुरक्षा जाळी" म्हणून वापरले जाते.

साधारणतः बोलातांनी, वर्णन केलेले वर्तन आणि संबंधित उपाय केवळ PHP-FPM ला लागू होत नाहीत. इतर भाषा/फ्रेमवर्क वापरताना एक ना एक प्रकारे अशीच परिस्थिती उद्भवू शकते. तुम्ही इतर मार्गांनी ग्रेसफुल शटडाउनचे निराकरण करू शकत नसल्यास - उदाहरणार्थ, कोड पुन्हा लिहून जेणेकरुन अनुप्रयोग समाप्ती सिग्नलवर योग्यरित्या प्रक्रिया करेल - तुम्ही वर्णन केलेली पद्धत वापरू शकता. हे सर्वात सुंदर असू शकत नाही, परंतु ते कार्य करते.

सराव. पॉडचे ऑपरेशन तपासण्यासाठी लोड चाचणी

लोड चाचणी हा कंटेनर कसा कार्य करतो हे तपासण्याचा एक मार्ग आहे, कारण वापरकर्ते साइटला भेट देतात तेव्हा ही प्रक्रिया वास्तविक लढाऊ परिस्थितीच्या जवळ आणते. वरील शिफारसी तपासण्यासाठी, आपण वापरू शकता Yandex.Tankom: हे आपल्या सर्व गरजा पूर्णपणे कव्हर करते. ग्राफाना आणि 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. तुमची प्रक्रिया संपवा.

तथापि, सर्व अनुप्रयोग अशा प्रकारे कार्य करू शकत नाहीत. कुबर्नेट्सच्या वास्तविकतेतील समस्येचे एक निराकरण आहे:

• प्री-स्टॉप हुक जोडणे जे काही सेकंद थांबेल;
• योग्य पॅरामीटर्ससाठी आमच्या बॅकएंडच्या कॉन्फिगरेशन फाइलचा अभ्यास करत आहे.

NGINX सह उदाहरण हे स्पष्ट करते की ज्या ऍप्लिकेशनने सुरुवातीला टर्मिनेशन सिग्नलवर योग्यरित्या प्रक्रिया केली पाहिजे ते देखील तसे करू शकत नाही, त्यामुळे ऍप्लिकेशन डिप्लॉयमेंट दरम्यान 500 त्रुटी तपासणे महत्वाचे आहे. हे आपल्याला समस्येकडे अधिक व्यापकपणे पाहण्याची आणि एका पॉड किंवा कंटेनरवर लक्ष केंद्रित न करता संपूर्ण पायाभूत सुविधांकडे लक्ष देण्याची अनुमती देते.

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

लेखावरील अभिप्रायाला प्रतिसाद म्हणून: हे लक्षात घेण्यासारखे आहे की येथे एनजीआयएनएक्स इंग्रेसच्या संदर्भात समस्या आणि उपाय वर्णन केले आहेत. इतर प्रकरणांसाठी, इतर उपाय आहेत, ज्यांचा आम्ही मालिकेच्या खालील सामग्रीमध्ये विचार करू शकतो.

PS

K8s टिपा आणि युक्त्या मालिकेतील इतर:

• «NGINX प्रवेश मध्ये सानुकूल त्रुटी पृष्ठे";
• «वेब ऍप्लिकेशनवर नोड वाटप आणि लोड बद्दल";
• «देव साइट्सवर प्रवेश";
• «मोठ्या डेटाबेससाठी बूटस्ट्रॅपची गती वाढवणे».

स्त्रोत: www.habr.com