कुबेरनेट्स में जीवंतता जांच खतरनाक हो सकती है

टिप्पणी। अनुवाद।: ज़ालैंडो के प्रमुख इंजीनियर, हेनिंग जैकब्स ने बार-बार कुबेरनेट्स उपयोगकर्ताओं के बीच जीवंतता (और तत्परता) जांच के उद्देश्य और उनके सही उपयोग को समझने में समस्याओं को देखा है। इसलिए, उन्होंने अपने विचारों को इस विशाल नोट में एकत्र किया, जो अंततः K8s दस्तावेज़ीकरण का हिस्सा बन जाएगा।

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

मेरे सहकर्मी सैंडोर ने हाल ही में ट्विटर पर सबसे आम त्रुटियों को साझा किया, जिनमें तत्परता/लाइवनेस जांच के उपयोग से संबंधित त्रुटियां भी शामिल हैं:

ग़लत ढंग से कॉन्फ़िगर किया गया livenessProbe उच्च-लोड स्थितियों (स्नोबॉल शटडाउन + संभावित लंबे कंटेनर/एप्लिकेशन स्टार्टअप समय) को बढ़ा सकता है और निर्भरता में गिरावट जैसे अन्य नकारात्मक परिणामों को जन्म दे सकता है (यह सभी देखें मेरा हालिया लेख K3s+ACME संयोजन में अनुरोधों की संख्या सीमित करने के बारे में). यह और भी बुरा है जब जीवंतता जांच को स्वास्थ्य जांच के साथ जोड़ दिया जाता है, जो एक बाहरी डेटाबेस है: एक भी DB विफलता आपके सभी कंटेनरों को पुनः प्रारंभ कर देगी!

सामान्य संदेश "लाइवनेस प्रोब का उपयोग न करें" इस मामले में यह ज्यादा मदद नहीं करता है, तो आइए देखें कि तत्परता और जीवंतता जांच किस लिए हैं।

नोट: नीचे दिए गए अधिकांश परीक्षण मूल रूप से ज़ालैंडो के आंतरिक डेवलपर दस्तावेज़ में शामिल किए गए थे।

तत्परता और सजीवता की जाँच

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

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

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

यदि आप किसी एप्लिकेशन अपडेट को तैनात करने का प्रयास करते हैं जो जीवंतता/तत्परता जांच में विफल रहता है, तो इसका रोलआउट रुक जाएगा क्योंकि कुबेरनेट्स स्थिति की प्रतीक्षा करता है Ready सभी पॉड्स से.

उदाहरण

यहां पथ की जांच करने वाली तत्परता जांच का एक उदाहरण दिया गया है /health डिफ़ॉल्ट सेटिंग्स के साथ HTTP के माध्यम से (अंतराल: दस पल, मध्यांतर: 1 सेकंड, सफलता की दहलीज: 1, विफलता सीमा: 3):

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

अनुशंसाएँ

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

     *मुझे ज़ालैंडो के कम से कम एक मामले की जानकारी है जहां ऐसा नहीं हुआ, यानी। readinessProbe मैंने "प्रबंधन" पोर्ट की जाँच की, लेकिन कैश लोड करने में समस्याओं के कारण सर्वर ने काम करना शुरू नहीं किया।

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

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

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

चेतावनी

1. बाहरी निर्भरता पर निर्भर न रहें (जैसे डेटा वेयरहाउस) तत्परता/लाइवनेस परीक्षण चलाते समय - इससे व्यापक विफलताएं हो सकती हैं:
   • उदाहरण के तौर पर, आइए एक पोस्टग्रेज डेटाबेस के आधार पर 10 पॉड्स के साथ एक स्टेटफुल आरईएसटी सेवा लें: जब चेक डीबी के कामकाजी कनेक्शन पर निर्भर करता है, तो नेटवर्क/डीबी पक्ष पर देरी होने पर सभी 10 पॉड्स विफल हो सकते हैं - आमतौर पर यह सभी का अंत जितना हो सकता था उससे भी बदतर होता है;
   • कृपया ध्यान दें कि स्प्रिंग डेटा डिफ़ॉल्ट रूप से डेटाबेस कनेक्शन की जाँच करता है*;

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

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

सारांश

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

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

• कुबेरनेट्स दस्तावेज़: जीवंतता और तत्परता जांच कॉन्फ़िगर करें;
• कुबेरनेट्स जीवंतता और तत्परता जांच पर दोबारा गौर किया गया: दूसरे पैर पर खुद को गोली मारने से कैसे बचें;
• एनआरई लैब्स ने पोस्टमॉर्टम बंद कर दिया (वह जीवंतता जांच के बारे में भी बात करते हैं)।

1-2019-09 से अपडेट नंबर 29

डेटाबेस माइग्रेशन के लिए init कंटेनर के बारे में: फ़ुटनोट जोड़ा गया.

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

ब्रायन ने इसे पूरी तरह से प्रस्तुत किया: “जब आपको ठीक-ठीक पता हो कि जीवंतता जांच का उपयोग करें सबसे अच्छी बात यह है कि एप्लिकेशन को बंद कर दिया जाए"(फिर से, दूर मत जाओ)।

2-2019-09 से अपडेट नंबर 29

उपयोग से पहले दस्तावेज़ पढ़ने के संबंध में: मैंने संबंधित अनुरोध बनाया (महत्वपूर्ण लेख मांगना) जीवंतता जांच के बारे में दस्तावेज़ जोड़ने के लिए।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट्स: पॉड लाइफ";
• «Google के अनुसार कंटेनरों का उपयोग करने की 7 सर्वोत्तम प्रथाएँ";
• «कंटेनर-आधारित अनुप्रयोगों को डिज़ाइन करने के लिए 7 सिद्धांत'.

स्रोत: www.habr.com