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

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



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

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



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

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

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

रेडीनेस और लाईनेस चेक

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

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

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

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

उदाहरण

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

 #    deployment'/ podTemplate: spec: containers: - name: my-container # ... readinessProbe: httpGet: path: /health port: 8080 

सिफारिशें

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

चेतावनी

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

सारांश

• ट्रैफ़िक प्राप्त करने के लिए पॉड तैयार होने पर निर्धारित करने के लिए तत्परता जांच का उपयोग करें।
• जब उन्हें सही मायने में जरूरत हो, तभी लेवन जांच का उपयोग करें।
• तत्परता / लीनिंग जांच का गलत उपयोग कम उपलब्धता और कैस्केडिंग विफलताओं को जन्म दे सकता है।

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

• कुबेरनेट्स डॉक्स: कॉन्फिगरिंग लाईनेस एंड रेडीनेस प्रोब्स ;
• कुबेरनेट्स लाईनेस एंड रेडीनेस प्रोबिस रीविस्ड: कैसे दूसरे पैर में शूटिंग से बचने के लिए ;
• एनआरई लैब्स आउटेज पोस्टमार्टम (लीनरप्रोबी के बारे में बातचीत)।

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

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

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

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

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

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

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

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

• कुबेरनेट्स: द लाइफ ऑफ द हार्ट ;
• " Google के अनुसार कंटेनरों के संचालन के लिए 7 सर्वोत्तम अभ्यास ";
• " कंटेनर-आधारित अनुप्रयोगों के डिजाइन के लिए 7 सिद्धांत ।"