Kubernetes मा Liveness जांच खतरनाक हुन सक्छ

नोट। अनुवाद।: जालान्डोका प्रमुख इन्जिनियर, हेनिङ जेकब्सले कुबर्नेट्स प्रयोगकर्ताहरू बीच जीवन्तता (र तत्परता) प्रोबहरू र तिनीहरूको सही प्रयोगको उद्देश्य बुझ्नमा बारम्बार समस्याहरू देखेका छन्। तसर्थ, उनले आफ्नो विचारहरू यस विशाल नोटमा सङ्कलन गरे, जुन अन्ततः K8s कागजातको अंश बन्नेछ।

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

मेरो सहकर्मी स्यान्डरले भर्खरै ट्विटरमा आफूले सामना गर्ने सबैभन्दा सामान्य त्रुटिहरू साझा गर्नुभयो, जसमा तयारी/जीवितता जाँचहरूको प्रयोगसँग सम्बन्धित छन्:

गलत तरिकाले कन्फिगर गरियो livenessProbe उच्च-लोड अवस्थाहरू (स्नोबल बन्द + सम्भावित रूपमा लामो कन्टेनर/एप्लिकेशन स्टार्टअप समय) र अन्य नकारात्मक परिणामहरू जस्तै निर्भरता ड्रपहरू निम्त्याउन सक्छ। (यो पनि हेर्नुहोस् मेरो भर्खरको लेख K3s + ACME संयोजनमा अनुरोधहरूको संख्या सीमित गर्ने बारे)। यो अझ नराम्रो हुन्छ जब जीवन्तता जाँचलाई स्वास्थ्य जाँचसँग जोडिन्छ, जुन बाह्य डाटाबेस हो: एकल DB विफलताले तपाइँको सबै कन्टेनरहरू पुन: सुरु गर्नेछ!

सामान्य सन्देश "जीवितता जाँचहरू प्रयोग नगर्नुहोस्" यस अवस्थामा यसले धेरै मद्दत गर्दैन, त्यसैले तत्परता र जीवन्तता जाँचहरू के हुन् भनेर हेरौं।

नोट: तलका अधिकांश परीक्षणहरू मूल रूपमा Zalando को आन्तरिक विकासकर्ता कागजातमा समावेश गरिएको थियो।

तत्परता र जीवन्तता जाँच

Kubernetes भनिन्छ दुई महत्त्वपूर्ण संयन्त्र प्रदान गर्दछ जीवन्तता जाँचहरू र तयारी जाँचहरू। तिनीहरूले आवधिक रूपमा केही कार्यहरू प्रदर्शन गर्छन्-जस्तै HTTP अनुरोध पठाउने, TCP जडान खोल्ने, वा कन्टेनरमा आदेश कार्यान्वयन गर्ने-एप्लिकेसनले अपेक्षित रूपमा काम गरिरहेको छ भनी पुष्टि गर्न।

Kubernetes प्रयोग गर्दछ तयारी जाँचहरूकन्टेनर ट्राफिक स्वीकार गर्न तयार छ भनेर बुझ्न। यदि सबै कन्टेनरहरू तयार छन् भने पोड प्रयोगको लागि तयार मानिन्छ। यस मेकानिजमको एउटा प्रयोग भनेको कुन पोडहरू Kubernetes सेवाहरू (र विशेष गरी Ingress) को लागि ब्याकएन्डको रूपमा प्रयोग गरिन्छ भनेर नियन्त्रण गर्नु हो।

जीवन्तता जाँचहरू Kubernetes लाई कन्टेनर पुन: सुरु गर्ने समय हो भनेर बुझ्न मद्दत गर्नुहोस्। उदाहरण को लागी, यस्तो चेकले तपाइँलाई डेडलक रोक्न अनुमति दिन्छ जब एप्लिकेसन एक ठाउँमा अड्किन्छ। यस अवस्थामा कन्टेनर पुन: सुरु गर्नाले त्रुटिहरूको बावजुद एप्लिकेसनलाई जमिनबाट हटाउन मद्दत गर्दछ, तर यसले क्यास्केडिङ विफलताहरू पनि निम्त्याउन सक्छ (तल हेर्नुहोस्)।

यदि तपाईंले एप अपडेट डिप्लोय गर्ने प्रयास गर्नुभयो भने जीवन्तता/तत्परता जाँचहरू असफल भएमा, कुबेरनेटले स्थितिको लागि पर्खिरहेकोले यसको रोलआउट रोकिनेछ। Ready सबै पोडहरूबाट।

उदाहरण:

यहाँ एउटा पथ जाँच गर्ने तयारी जाँचको उदाहरण हो /health पूर्वनिर्धारित सेटिङहरूसँग HTTP मार्फत (अन्तराल: १० सेकेन्ड, समय सकियो: १ सेकेन्ड, सफलताको थ्रेसहोल्ड: 1, असफलता थ्रेसहोल्ड: ३):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

सिफारिसहरू

1. HTTP अन्त्य बिन्दु (REST, आदि) को साथ माइक्रोसर्भिसहरूका लागि। सधैं तत्परता जाँच परिभाषित गर्नुहोस्, जसले जाँच गर्दछ कि एप्लिकेसन (पोड) ट्राफिक स्वीकार गर्न तयार छ कि छैन।
2. तत्परता जाँच सुनिश्चित गर्नुहोस् वास्तविक वेब सर्भर पोर्ट को उपलब्धता कभर:
   • प्रशासनिक उद्देश्यका लागि पोर्टहरू प्रयोग गर्दै, जसलाई "व्यवस्थापक" वा "व्यवस्थापन" भनिन्छ (उदाहरणका लागि, 9090), readinessProbe, यदि प्राथमिक HTTP पोर्ट (जस्तै 8080) ट्राफिक* स्वीकार गर्न तयार छ भने अन्तिम बिन्दुले मात्र ठीक फर्काउँछ भन्ने सुनिश्चित गर्नुहोस्;

     *म Zalando मा कम्तिमा एउटा घटना बारे सचेत छु जहाँ यो भएको छैन, अर्थात्। readinessProbe मैले "व्यवस्थापन" पोर्ट जाँच गरें, तर सर्भरले क्यास लोड गर्ने समस्याहरूको कारणले काम गर्न सुरु गरेन।

   • छुट्टै पोर्टमा रेडिनेस प्रोब जोड्दा मुख्य पोर्टमा ओभरलोड स्वास्थ्य जाँचमा प्रतिबिम्बित हुने छैन भन्ने तथ्यलाई निम्त्याउन सक्छ (अर्थात, सर्भरमा थ्रेड पूल भरिएको छ, तर स्वास्थ्य जाँचले अझै पनि सबै ठीक छ भनेर देखाउँछ। )।
3. त्यो निश्चित गर रेडिनेस प्रोबले डाटाबेस प्रारम्भ/माइग्रेसन सक्षम गर्दछ;
   • यसलाई प्राप्त गर्ने सबैभन्दा सजिलो तरीका भनेको शुरुवात पूरा भएपछि मात्र HTTP सर्भरमा सम्पर्क गर्नु हो (उदाहरणका लागि, बाट डाटाबेस माइग्रेट गर्दै फ्लाईवे र यस्तै।); त्यो हो, स्वास्थ्य जाँच स्थिति परिवर्तन गर्नुको सट्टा, डाटाबेस माइग्रेसन पूरा नभएसम्म वेब सर्भर सुरु नगर्नुहोस्*।

     * तपाइँ पोड बाहिर init कन्टेनरहरूबाट डाटाबेस माइग्रेसनहरू पनि चलाउन सक्नुहुन्छ। म अझै पनि आत्म-निहित अनुप्रयोगहरूको प्रशंसक हुँ, त्यो हो, जसमा अनुप्रयोग कन्टेनरले बाह्य समन्वय बिना डाटाबेसलाई इच्छित स्थितिमा कसरी ल्याउने भनेर जान्दछ।

4. प्रयोग गर्नुहोस् httpGet सामान्य स्वास्थ्य जाँच अन्तिम बिन्दुहरू मार्फत तत्परता जाँचको लागि (उदाहरणका लागि, /health).
5. पूर्वनिर्धारित जाँच प्यारामिटरहरू बुझ्नुहोस् (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • पूर्वनिर्धारित विकल्पहरूको अर्थ पोड बन्नेछ तयार छैन लगभग 30 सेकेन्ड पछि (3 असफल स्वास्थ्य जाँच)।
6. यदि टेक्नोलोजी स्ट्याक (जस्तै जाभा/स्प्रिंग) ले अनुमति दिन्छ भने "प्रशासक" वा "व्यवस्थापन" को लागि छुट्टै पोर्ट प्रयोग गर्नुहोस्, स्वास्थ्य र मेट्रिक्स व्यवस्थापनलाई नियमित ट्राफिकबाट अलग गर्न:
   • तर बिन्दु 2 को बारेमा नबिर्सनुहोस्।
7. आवश्यक भएमा, क्यासलाई न्यानो अप/लोड गर्न र कन्टेनर न्यानो नभएसम्म ५०३ स्टेटस कोड फर्काउन रेडिनेस प्रोब प्रयोग गर्न सकिन्छ:
   • म तपाईंलाई नयाँ चेक पढ्न पनि सिफारिस गर्दछु startupProbe, संस्करण 1.16 मा देखा पर्यो (हामीले यसको बारेमा रूसीमा लेख्यौं यहाँ - लगभग। अनुवाद।).

Caveats

1. बाह्य निर्भरताहरूमा भर नपर्नुहोस् (जस्तै डाटा गोदामहरू) तयारी/जीवितता परीक्षणहरू चलाउँदा - यसले क्यास्केडिङ विफलताहरू निम्त्याउन सक्छ:
   • उदाहरणको रूपमा, एउटा Postgres डाटाबेसको आधारमा 10 पोडहरू सहितको स्टेटफुल REST सेवा लिऔं: जब चेक DB मा काम गर्ने जडानमा निर्भर हुन्छ, नेटवर्क/DB साइडमा ढिलाइ भएमा सबै 10 पोडहरू असफल हुन सक्छन् - सामान्यतया यो सबै समाप्त हुन सक्छ भन्दा खराब हुन्छ;
   • कृपया ध्यान दिनुहोस् कि वसन्त डाटाले पूर्वनिर्धारित रूपमा डेटाबेस जडान जाँच गर्दछ*;

     * यो वसन्त डाटा रेडिसको पूर्वनिर्धारित व्यवहार हो (कम्तीमा यो मैले जाँच गरेको अन्तिम पटक थियो), जसले "विपत्तिजनक" विफलता निम्त्यायो: जब रेडिस छोटो समयको लागि उपलब्ध थिएन, सबै पोडहरू "क्र्यास" भयो।

   • यस अर्थमा "बाह्य" को अर्थ एउटै एप्लिकेसनका अन्य पोडहरू पनि हुन सक्छ, त्यो हो, क्यास्केडिङ क्र्यासहरू रोक्नको लागि जाँच समान क्लस्टरको अन्य पोडहरूको स्थितिमा निर्भर हुनु हुँदैन:
     • नतिजाहरू वितरित अवस्था भएका अनुप्रयोगहरूको लागि भिन्न हुन सक्छन् (उदाहरणका लागि, पोडहरूमा इन-मेमोरी क्यासिङ)।
2. जीवन्तता जाँच प्रयोग नगर्नुहोस् पोडहरूका लागि (अपवादहरू घटनाहरू हुन् जब तिनीहरू वास्तवमै आवश्यक हुन्छन् र तपाईं तिनीहरूको प्रयोगको विशिष्टता र परिणामहरू बारे पूर्ण रूपमा सचेत हुनुहुन्छ):
   • एक जीवन्तता जाँचले झुण्डिएको कन्टेनरहरू पुन: प्राप्ति गर्न मद्दत गर्न सक्छ, तर तपाईंको अनुप्रयोगमा पूर्ण नियन्त्रण भएकोले, झुण्डिएका प्रक्रियाहरू र गतिरोधहरू जस्ता चीजहरू आदर्श रूपमा हुनु हुँदैन: सबैभन्दा राम्रो विकल्प भनेको जानाजानी अनुप्रयोगलाई क्र्यास गर्नु र यसलाई अघिल्लो स्थिर अवस्थामा ल्याउनु हो।
   • एक असफल जीवन्तता जाँचले कन्टेनरलाई पुन: सुरु गर्न निम्त्याउनेछ, जसले गर्दा सम्भावित रूपमा लोडिङ-सम्बन्धित त्रुटिहरूको नतिजा बढाउँछ: कन्टेनर पुन: सुरु गर्दा डाउनटाइम (कम्तिमा एप्लिकेसन स्टार्टअपको अवधिको लागि, 30-विजोड सेकेन्ड भन्नुहोस्), नयाँ त्रुटिहरू निम्त्याउँछ। , अन्य कन्टेनरहरूमा लोड बढ्दै र तिनीहरूको विफलताको सम्भावना बढाउँदै, आदि;
   • बाह्य निर्भरताको साथ संयुक्त जीवन्तता जाँचहरू सबैभन्दा खराब सम्भावित संयोजन हुन्, क्यास्केडिङ विफलताहरूलाई धम्की दिन्छ: डाटाबेस पक्षमा थोरै ढिलाइले तपाइँका सबै कन्टेनरहरू पुन: सुरु गर्न नेतृत्व गर्नेछ!
3. जीवन्तता र तत्परता जाँचको प्यारामिटरहरू फरक हुनुपर्छ:
   • तपाईं समान स्वास्थ्य जाँचको साथ एक जीवन्तता जाँच प्रयोग गर्न सक्नुहुन्छ, तर उच्च प्रतिक्रिया थ्रेसहोल्ड (failureThreshold), उदाहरणका लागि, स्थिति असाइन गर्नुहोस् तयार छैन 3 प्रयास पछि र 10 प्रयास पछि liveness जाँच असफल भएको विचार गर्नुहोस्;
4. Exec चेकहरू प्रयोग नगर्नुहोस्, किनकि तिनीहरू ज्ञात समस्याहरूसँग सम्बन्धित छन् जुन जोम्बी प्रक्रियाहरूको उपस्थितिमा नेतृत्व गर्दछ:
   • विवरण: हेर्नुहोस् Datadog विशेषज्ञहरु द्वारा प्रस्तुतीकरण.

सारांश

• ट्राफिक प्राप्त गर्नको लागि पोड तयार छ भनेर निर्धारण गर्न तयारी जाँचहरू प्रयोग गर्नुहोस्।
• तिनीहरू साँच्चै आवश्यक हुँदा मात्र जीवन्तता जाँचहरू प्रयोग गर्नुहोस्।
• तत्परता/जीवितता जाँचहरूको अनुचित प्रयोगले कम उपलब्धता र क्यास्केडिङ विफलता निम्त्याउन सक्छ।

विषय मा अतिरिक्त सामग्री

• Kubernetes कागजातहरू: Liveness र Readiness Probes कन्फिगर गर्नुहोस्;
• Kubernetes Liveness and Readiness Probes Revisited: कसरी आफूलाई अर्को खुट्टामा गोली हान्नबाट बच्ने;
• NRE ल्याब आउटेज पोस्ट-मार्टम (उनी livenessProbe को बारेमा पनि कुरा गर्छन्)।

1-2019-09 देखि अपडेट नम्बर 29

डाटाबेस माइग्रेसनका लागि init कन्टेनरहरूको बारेमा: फुटनोट थपियो।

EJ ले मलाई सम्झाए PDB को बारेमा: जीवन्तता जाँचको समस्याहरू मध्ये एक पोडहरू बीच समन्वयको अभाव हो। Kubernetes छ पोड अवरोध बजेट (PDB) एक अनुप्रयोगले अनुभव गर्न सक्ने समवर्ती विफलताहरूको संख्या सीमित गर्न, यद्यपि जाँचहरूले PDB लाई ध्यानमा राख्दैन। आदर्श रूपमा, हामीले K8s लाई "यदि यसको परीक्षण असफल भएमा एउटा पोडलाई पुन: सुरु गर्न, तर चीजहरूलाई खराब बनाउनबाट जोगिन ती सबैलाई पुन: सुरु नगर्नुहोस्" भन्न सक्छौं।

ब्रायनले राम्रोसँग राखे: "लाइभनेस प्रोबिङ प्रयोग गर्नुहोस् जब तपाईलाई ठ्याक्कै के थाहा छ गर्न को लागी सबै भन्दा राम्रो कुरा आवेदन मार्न छ"(फेरि, टाढा नजानुहोस्)।

2-2019-09 देखि अपडेट नम्बर 29

प्रयोग गर्नु अघि कागजात पढ्ने सन्दर्भमा: मैले सम्बन्धित अनुरोध सिर्जना गरें (सुविधा अनुरोध) लाईनेस प्रोबहरूको बारेमा कागजातहरू थप्न।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes: पोड जीवन»;
• «गुगल अनुसार कन्टेनरहरू प्रयोग गर्नका लागि 7 उत्तम अभ्यासहरू»;
• «कन्टेनर-आधारित अनुप्रयोगहरू डिजाइन गर्नका लागि 7 सिद्धान्तहरू"।

स्रोत: www.habr.com