Kubernetes सुझाव र युक्तिहरू: NGINX र PHP-FPM मा आकर्षक बन्दका सुविधाहरू

Kubernetes मा CI/CD लागू गर्दा एक सामान्य अवस्था: अनुप्रयोगले पूर्ण रूपमा रोकिनु अघि नयाँ ग्राहक अनुरोधहरू स्वीकार नगर्न सक्षम हुनुपर्छ, र सबैभन्दा महत्त्वपूर्ण रूपमा, अवस्थितहरूलाई सफलतापूर्वक पूरा गर्नुहोस्।

यस सर्तको अनुपालनले तपाईंलाई तैनातीको समयमा शून्य डाउनटाइम प्राप्त गर्न अनुमति दिन्छ। यद्यपि, धेरै लोकप्रिय बन्डलहरू (जस्तै NGINX र PHP-FPM) प्रयोग गर्दा पनि, तपाईंले कठिनाइहरूको सामना गर्न सक्नुहुन्छ जसले प्रत्येक डिप्लोइमेन्टमा त्रुटिहरूको वृद्धि निम्त्याउनेछ।

सिद्धान्त। पोड कसरी बाँच्छ

हामीले पहिले नै पोडको जीवन चक्रको बारेमा विस्तृत रूपमा प्रकाशित गरिसकेका छौं यो लेख। विचाराधीन विषयको सन्दर्भमा, हामी निम्नमा रुचि राख्छौं: पोड राज्यमा प्रवेश गर्ने क्षणमा टर्मिनेटिङ्, नयाँ अनुरोधहरू यसमा पठाउन रोकिन्छ (pod हटाइयो सेवाको लागि अन्तिम बिन्दुहरूको सूचीबाट)। यसैले, डिप्लोइमेन्टको समयमा डाउनटाइमबाट बच्नको लागि, यो हाम्रो लागि अनुप्रयोगलाई सही रूपमा रोक्नको समस्या समाधान गर्न पर्याप्त छ।

तपाईंले यो पनि याद गर्नुपर्छ कि पूर्वनिर्धारित अनुग्रह अवधि हो ३० सेकेन्ड: यस पछि, पोड समाप्त हुनेछ र अनुप्रयोगसँग यस अवधि अघि सबै अनुरोधहरू प्रशोधन गर्न समय हुनुपर्छ। भन्नु: यद्यपि कुनै पनि अनुरोध जसले 5-10 सेकेन्ड भन्दा बढी लिन्छ पहिले नै समस्याग्रस्त छ, र आकर्षक बन्दले अब यसलाई मद्दत गर्दैन ...

राम्रोसँग बुझ्नको लागि के हुन्छ जब पोड समाप्त हुन्छ, केवल निम्न रेखाचित्र हेर्नुहोस्:

A1, B1 - चूल्हाको अवस्था बारे परिवर्तनहरू प्राप्त गर्दै
A2 - प्रस्थान SIGTERM
B2 - अन्तिम बिन्दुहरूबाट पोड हटाउँदै
B3 - परिवर्तनहरू प्राप्त गर्दै (अन्तबिन्दुहरूको सूची परिवर्तन भएको छ)
B4 - iptables नियमहरू अपडेट गर्नुहोस्

कृपया ध्यान दिनुहोस्: अन्तिम बिन्दु पोड मेटाउनु र SIGTERM पठाउनु क्रमिक रूपमा हुँदैन, तर समानान्तरमा। र यस तथ्यको कारणले कि Ingress ले तुरुन्तै अन्तिम बिन्दुहरूको अद्यावधिक सूची प्राप्त गर्दैन, ग्राहकहरूबाट नयाँ अनुरोधहरू पोडमा पठाइनेछ, जसले पोड समाप्तिको समयमा 500 त्रुटि निम्त्याउनेछ। (यस मुद्दामा थप विस्तृत सामग्रीको लागि, हामी अनुवाद)। यो समस्या निम्न तरिकामा समाधान गर्न आवश्यक छ:

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

सिद्धान्त। कसरी NGINX र PHP-FPM ले तिनीहरूको प्रक्रियाहरू समाप्त गर्दछ

NGINX

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

त्यसपछि सबै सरल छ: तपाईं थप्न आवश्यक छ preStop-हुक एउटा आदेश जसले सुन्दर बन्द संकेत पठाउनेछ। यो डिप्लोइमेन्टमा, कन्टेनर ब्लकमा गर्न सकिन्छ:

       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 - सुन्दर बन्द (हामीलाई के चाहिन्छ)।

यस कार्यमा बाँकी संकेतहरू आवश्यक पर्दैन, त्यसैले हामी तिनीहरूको विश्लेषण छोड्नेछौं। सही तरिकाले प्रक्रिया समाप्त गर्न, तपाईंले निम्न preStop हुक लेख्न आवश्यक हुनेछ:

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

पहिलो नजरमा, यो सबै दुबै कन्टेनरहरूमा सुन्दर बन्द गर्न आवश्यक छ। तर, काम सोचेभन्दा गाह्रो छ । तल दुईवटा केसहरू छन् जसमा आकर्षक बन्दले काम गरेन र तैनातीको समयमा परियोजनाको छोटो अवधिको अनुपलब्धताको कारण भयो।

अभ्यास गर्नुहोस्। आकर्षक बन्दको साथ सम्भावित समस्याहरू

NGINX

सबै भन्दा पहिले, यो सम्झना उपयोगी छ: आदेश कार्यान्वयन को अतिरिक्त 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 त्रुटिहरू हुन्छन्। 2005 देखि bugs.php.net मा धेरै बग रिपोर्टहरू छन् (जस्तै यहाँ и यहाँ), जसले यस समस्यालाई वर्णन गर्दछ। तर तपाईले लगमा केहि पनि देख्नुहुने छैन: PHP-FPM ले कुनै त्रुटि वा तेस्रो-पक्ष सूचनाहरू बिना यसको प्रक्रिया पूरा भएको घोषणा गर्नेछ।

यो स्पष्ट गर्न लायक छ कि समस्या आफैमा अनुप्रयोगमा कम वा धेरै हदसम्म निर्भर हुन सक्छ र आफैलाई प्रकट नहुन सक्छ, उदाहरणका लागि, निगरानीमा। यदि तपाईंले यसको सामना गर्नुभयो भने, एक साधारण समाधान पहिले दिमागमा आउँछ: एक preStop हुक थप्नुहोस् sleep(30)। यसले तपाईंलाई पहिलेका सबै अनुरोधहरू पूरा गर्न अनुमति दिनेछ (र हामी पोडबाट नयाँहरू स्वीकार गर्दैनौं पहिले नै सक्षम टर्मिनेटिङ्), र 30 सेकेन्ड पछि पोड आफै एक संकेत संग समाप्त हुनेछ SIGTERM.

यसले त्यसबाट हटाउँछ lifecycle कन्टेनरको लागि यो जस्तो देखिन्छ:

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

तर, ३० सेकेन्डको कारणले sleep हामी कडा हामी डिप्लोइमेन्ट समय बढाउनेछौं, किनकि प्रत्येक पोड समाप्त हुनेछ न्यूनतम 30 सेकेन्ड, जुन खराब छ। यस बारे के गर्न सकिन्छ?

आवेदनको प्रत्यक्ष कार्यान्वयनको लागि जिम्मेवार पक्षमा फर्कौं। हाम्रो मामला मा यो छ PHP-FPMकुन पूर्वनिर्धारित रूपमा यसको बाल प्रक्रियाहरूको कार्यान्वयनको निगरानी गर्दैन: मास्टर प्रक्रिया तुरुन्तै समाप्त हुन्छ। तपाईं निर्देशन प्रयोग गरेर यो व्यवहार परिवर्तन गर्न सक्नुहुन्छ process_control_timeout, जसले मास्टरबाट सङ्केतहरूको प्रतीक्षा गर्न बाल प्रक्रियाहरूको लागि समय सीमा निर्दिष्ट गर्दछ। यदि तपाईंले 20 सेकेन्डमा मान सेट गर्नुभयो भने, यसले कन्टेनरमा चलिरहेका अधिकांश प्रश्नहरूलाई कभर गर्नेछ र मास्टर प्रक्रिया पूरा भएपछि रोकिनेछ।

यस ज्ञानको साथ, हाम्रो अन्तिम समस्यामा फर्कौं। उल्लेख गरिएझैं, Kubernetes एक मोनोलिथिक प्लेटफर्म होइन: यसको विभिन्न घटकहरू बीचको सञ्चारले केही समय लिन्छ। यो विशेष गरी सत्य हो जब हामी Ingresses र अन्य सम्बन्धित कम्पोनेन्टहरूको अपरेशनलाई विचार गर्छौं, किनकि तैनातीको समयमा यस्तो ढिलाइको कारणले 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 त्रुटिहरू देखा पर्यो, जुन रोकिएको NGINX कन्टेनरको परिणाम थियो, जसले ब्याकइन्डको कारणले जडानहरू पनि छोड्यो (जसले यसमा जडान हुनबाट इन्ग्रेसलाई रोकेको थियो)।

कसरी हेरौं process_control_timeout PHP-FPM मा हामीलाई बाल प्रक्रियाहरू पूरा हुनको लागि पर्खन मद्दत गर्नेछ, अर्थात्। यस्ता त्रुटिहरू सच्याउनुहोस्। यो निर्देशन प्रयोग गरेर पुन: तैनाती गर्नुहोस्:

500th तैनाती को समयमा कुनै त्रुटिहरू छैनन्! परिनियोजन सफल छ, आकर्षक बन्द काम गर्दछ।

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

निष्कर्षमा

प्रक्रियालाई राम्रोसँग समाप्त गर्न, हामी अनुप्रयोगबाट निम्न व्यवहारको अपेक्षा गर्छौं:

1. केही सेकेन्ड पर्खनुहोस् र त्यसपछि नयाँ जडानहरू स्वीकार गर्न रोक्नुहोस्।
2. सबै अनुरोधहरू पूरा हुनका लागि पर्खनुहोस् र अनुरोधहरू कार्यान्वयन नगर्ने सबै Keepalive जडानहरू बन्द गर्नुहोस्।
3. तपाइँको प्रक्रिया समाप्त गर्नुहोस्।

यद्यपि, सबै अनुप्रयोगहरूले यसरी काम गर्न सक्दैनन्। Kubernetes वास्तविकता मा समस्या को एक समाधान हो:

• प्रि-स्टप हुक थप्दै जुन केहि सेकेन्ड पर्खनेछ;
• उपयुक्त प्यारामिटरहरूको लागि हाम्रो ब्याकइन्डको कन्फिगरेसन फाइल अध्ययन गर्दै।

NT यसले तपाईंलाई समस्यालाई अझ व्यापक रूपमा हेर्न र एकल पोड वा कन्टेनरमा फोकस नगरी सम्पूर्ण पूर्वाधारलाई समग्र रूपमा हेर्न अनुमति दिन्छ।

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

लेखमा प्रतिक्रियाको जवाफमा: यो उल्लेखनीय छ कि समस्या र समाधानहरू यहाँ NGINX Ingress को सम्बन्धमा वर्णन गरिएको छ। अन्य केसहरूको लागि, त्यहाँ अन्य समाधानहरू छन्, जुन हामी श्रृंखलाको निम्न सामग्रीहरूमा विचार गर्न सक्छौं।

PS

K8s सुझाव र चाल श्रृंखलाबाट अन्य:

• «NGINX प्रवेशमा अनुकूलन त्रुटि पृष्ठहरू»;
• «वेब अनुप्रयोगमा नोड आवंटन र लोडहरू बारे»;
• «dev साइटहरूमा पहुँच»;
• «ठूला डाटाबेसहरूको लागि बुटस्ट्र्यापको गति बढाउँदै"।

स्रोत: www.habr.com