Kubernetes मध्ये लाइव्हनेस प्रोब धोकादायक असू शकतात

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

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

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

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

सामान्य संदेश "लाइव्हनेस प्रोब वापरू नका" या प्रकरणात ते जास्त मदत करत नाही, म्हणून तयारी आणि चैतन्य तपासण्या कशासाठी आहेत ते पाहूया.

टीप: खाली दिलेली बहुतेक चाचणी मूलतः Zalando च्या अंतर्गत विकसक दस्तऐवजात समाविष्ट केली होती.

तत्परता आणि जिवंतपणा तपासा

Kubernetes नावाची दोन महत्वाची यंत्रणा प्रदान करते लाइव्हनेस प्रोब आणि रेडिनेस प्रोब. ते वेळोवेळी काही कृती करतात-जसे की HTTP विनंती पाठवणे, TCP कनेक्शन उघडणे किंवा कंटेनरमध्ये कमांड कार्यान्वित करणे—अ‍ॅप्लिकेशन अपेक्षेप्रमाणे काम करत असल्याची पुष्टी करण्यासाठी.

कुबर्नेट्स वापरतात तयारी तपासणीकंटेनर रहदारी स्वीकारण्यासाठी केव्हा तयार आहे हे समजून घेण्यासाठी. पॉड वापरण्यासाठी तयार मानले जाते जर त्याचे सर्व कंटेनर तयार असतील. या यंत्रणेचा एक वापर म्हणजे कुबर्नेट्स सेवांसाठी (आणि विशेषतः इंग्रेस) बॅकएंड म्हणून कोणत्या पॉड्स वापरल्या जातात हे नियंत्रित करणे.

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

तुम्ही एखादे अॅप्लिकेशन अपडेट उपयोजित करण्याचा प्रयत्न केल्यास जो जिवंतपणा/तत्परता तपासण्यात अयशस्वी झाला, तर त्याचे रोलआउट थांबवले जाईल कारण Kubernetes स्थितीची प्रतीक्षा करत आहे. Ready सर्व शेंगा पासून.

उदाहरण:

पथ तपासण्यासाठी तयारी तपासणीचे उदाहरण येथे आहे /health डीफॉल्ट सेटिंग्जसह HTTP द्वारे (मध्यांतर: 10 सेकंद, वेळ संपला: 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 सर्व्हरशी संपर्क साधणे (उदाहरणार्थ, येथून डेटाबेस स्थलांतरित करणे फ्लायवे आणि असेच.); म्हणजेच, आरोग्य तपासणी स्थिती बदलण्याऐवजी, डेटाबेस स्थलांतर पूर्ण होईपर्यंत वेब सर्व्हर सुरू करू नका*.

     * तुम्ही पॉडच्या बाहेर init कंटेनरमधून डेटाबेस स्थलांतर देखील चालवू शकता. मी अजूनही स्वयंपूर्ण ऍप्लिकेशन्सचा चाहता आहे, म्हणजेच ज्यामध्ये ऍप्लिकेशन कंटेनरला बाह्य समन्वयाशिवाय डेटाबेसला इच्छित स्थितीत कसे आणायचे हे माहित आहे.

4. वापरा httpGet सामान्य आरोग्य तपासणी एंडपॉईंट्सद्वारे तत्परता तपासणीसाठी (उदाहरणार्थ, /health).
5. डीफॉल्ट चेक पॅरामीटर्स समजून घ्या (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • डीफॉल्ट पर्याय म्हणजे पॉड होईल तयार नाही सुमारे 30 सेकंदांनंतर (3 अयशस्वी स्वच्छता तपासणी).
6. "प्रशासक" किंवा "व्यवस्थापन" साठी स्वतंत्र पोर्ट वापरा जर तंत्रज्ञान स्टॅक (उदा. Java/Spring) परवानगी देत ​​असेल, तर आरोग्य आणि मेट्रिक्स व्यवस्थापन नियमित रहदारीपासून वेगळे करण्यासाठी:
   • पण मुद्दा २ विसरू नका.
7. आवश्यक असल्यास, रेडिनेस प्रोबचा वापर कॅशे गरम करण्यासाठी/लोड करण्यासाठी आणि कंटेनर गरम होईपर्यंत 503 स्टेटस कोड परत करण्यासाठी केला जाऊ शकतो:
   • मी तुम्हाला नवीन चेक वाचण्याची देखील शिफारस करतो startupProbe, आवृत्ती 1.16 मध्ये दिसू लागले (आम्ही याबद्दल रशियनमध्ये लिहिले येथे - अंदाजे अनुवाद.).

सावधानता

1. बाह्य अवलंबनांवर अवलंबून राहू नका (जसे की डेटा वेअरहाऊस) तत्परता/लाइव्हनेस चाचण्या चालवताना - यामुळे कॅस्केडिंग अयशस्वी होऊ शकते:
   • उदाहरण म्हणून, एका पोस्टग्रेस डेटाबेसवर अवलंबून 10 पॉड्स असलेली स्टेटफुल REST सेवा घेऊ: जेव्हा चेक DB वर कार्यरत कनेक्शनवर अवलंबून असतो, तेव्हा नेटवर्क/DB बाजूला उशीर झाल्यास सर्व 10 पॉड्स अयशस्वी होऊ शकतात - सामान्यतः सर्व समाप्त ते शक्य पेक्षा वाईट;
   • कृपया लक्षात घ्या की स्प्रिंग डेटा डीफॉल्टनुसार डेटाबेस कनेक्शन तपासतो*;

     * हे स्प्रिंग डेटा रेडिसचे डीफॉल्ट वर्तन आहे (किमान ते मी तपासले होते तेव्हा शेवटचे होते), ज्यामुळे "आपत्तीजनक" अपयश आले: जेव्हा रेडिस थोड्या काळासाठी अनुपलब्ध होते, तेव्हा सर्व पॉड्स "क्रॅश" झाले.

   • या अर्थाने “बाह्य” चा अर्थ त्याच ऍप्लिकेशनच्या इतर पॉड्स देखील असू शकतो, म्हणजे, कॅस्केडिंग क्रॅश टाळण्यासाठी चेक त्याच क्लस्टरच्या इतर पॉड्सच्या स्थितीवर अवलंबून नसावा:
     • वितरित स्थिती असलेल्या अनुप्रयोगांसाठी परिणाम भिन्न असू शकतात (उदाहरणार्थ, पॉड्समधील मेमरी कॅशिंग).
2. लाइव्हनेस प्रोब वापरू नका पॉड्ससाठी (अपवाद अशी प्रकरणे आहेत जेव्हा ते खरोखर आवश्यक असतात आणि तुम्हाला त्यांच्या वापराची वैशिष्ट्ये आणि परिणामांची पूर्ण जाणीव असते):
   • लाइव्हनेस प्रोब हँग कंटेनर्स पुनर्प्राप्त करण्यात मदत करू शकते, परंतु तुमचे तुमच्या अर्जावर पूर्ण नियंत्रण असल्याने, हँग प्रक्रिया आणि डेडलॉक यासारख्या गोष्टी आदर्शपणे घडू नयेत: सर्वोत्तम पर्याय म्हणजे जाणूनबुजून ऍप्लिकेशन क्रॅश करणे आणि ते पूर्वीच्या स्थिर स्थितीत आणणे;
   • अयशस्वी लाइव्हनेस प्रोबमुळे कंटेनर रीस्टार्ट होईल, ज्यामुळे बूट-संबंधित त्रुटींचे संभाव्य परिणाम वाढतील: कंटेनर रीस्टार्ट केल्याने डाउनटाइम होईल (किमान ऍप्लिकेशन स्टार्टअपच्या कालावधीसाठी, 30+ सेकंद म्हणा), नवीन त्रुटी निर्माण होतील, इतर कंटेनरवरील भार वाढवणे आणि त्यांच्या अपयशाची शक्यता वाढवणे इ.;
   • बाह्य अवलंबित्वासह एकत्रित केलेले लाइव्हनेस चेक हे सर्वात वाईट संभाव्य संयोजन आहे, ज्यामुळे कॅस्केडिंग अयशस्वी होण्याचा धोका आहे: डेटाबेसच्या बाजूने थोडासा विलंब झाल्यास तुमचे सर्व कंटेनर रीस्टार्ट होतील!
3. जिवंतपणा आणि तयारी तपासण्याचे मापदंड भिन्न असणे आवश्यक आहे:
   • तुम्ही त्याच आरोग्य तपासणीसह लाइव्हनेस प्रोब वापरू शकता, परंतु उच्च प्रतिसाद थ्रेशोल्ड (failureThreshold), उदाहरणार्थ, स्थिती नियुक्त करा तयार नाही 3 प्रयत्नांनंतर आणि विचार करा की 10 प्रयत्नांनंतर जिवंतपणाची तपासणी अयशस्वी झाली आहे;
4. exec चेक वापरू नका, कारण ते ज्ञात समस्यांशी संबंधित आहेत ज्यामुळे झोम्बी प्रक्रिया दिसून येतात:
   • तपशील: पहा डेटाडॉग तज्ञांचे सादरीकरण.

सारांश

• ट्रॅफिक प्राप्त करण्यासाठी पॉड केव्हा तयार आहे हे निर्धारित करण्यासाठी रेडिनेस प्रोब वापरा.
• लाइव्हनेस प्रोब फक्त तेव्हाच वापरा जेव्हा त्यांची खरोखर गरज असेल.
• तत्परता/लाइव्हनेस प्रोबचा अयोग्य वापर केल्याने उपलब्धता कमी होऊ शकते आणि कॅस्केडिंग अयशस्वी होऊ शकते.

विषयावरील अतिरिक्त साहित्य

• कुबर्नेट्स डॉक्स: लाइव्हनेस आणि रेडिनेस प्रोब्स कॉन्फिगर करा;
• कुबर्नेट्स लाइव्हनेस अँड रेडिनेस प्रोब्सची पुनरावृत्ती झाली: दुसर्‍या पायात स्वतःला गोळी मारणे कसे टाळावे;
• NRE लॅब आउटेज पोस्ट-मॉर्टम (तो livenessProbe बद्दल देखील बोलतो).

1-2019-09 पासून अपडेट क्रमांक 29

डेटाबेस स्थलांतरासाठी init कंटेनरबद्दल: तळटीप जोडली.

ईजेने मला आठवण करून दिली PDB बद्दल: जिवंतपणा तपासणीमधील समस्यांपैकी एक म्हणजे शेंगा दरम्यान समन्वयाचा अभाव. कुबर्नेट्स यांच्याकडे आहे पॉड व्यत्यय बजेट (PDB) समवर्ती अपयशांची संख्या मर्यादित करण्यासाठी अनुप्रयोग अनुभवू शकतो, तथापि धनादेश PDB ला विचारात घेत नाहीत. आदर्शपणे, आम्ही K8s ला सांगू शकतो की "चाचणी अयशस्वी झाल्यास एक पॉड रीस्टार्ट करा, परंतु गोष्टी खराब होऊ नयेत म्हणून ते सर्व रीस्टार्ट करू नका."

ब्रायनने ते उत्तम प्रकारे मांडले: “जेव्हा तुम्हाला नक्की काय माहित असेल तेव्हा लाइव्हनेस प्रोबिंग वापरा अनुप्रयोग मारणे ही सर्वात चांगली गोष्ट आहे"(पुन्हा, वाहून जाऊ नका).

2-2019-09 पासून अपडेट क्रमांक 29

वापरण्यापूर्वी कागदपत्रे वाचण्याबाबत: मी संबंधित विनंती तयार केली (वैशिष्ट्य विनंती) लिव्हनेस प्रोबबद्दल दस्तऐवज जोडण्यासाठी.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्स: पॉड लाइफ";
• «Google नुसार कंटेनर वापरण्यासाठी 7 सर्वोत्तम पद्धती";
• «कंटेनर-आधारित अनुप्रयोग डिझाइन करण्यासाठी 7 तत्त्वे».

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