कुबेरनेट्स में ऑटो-स्केलिंग और संसाधन प्रबंधन (समीक्षा और वीडियो रिपोर्ट)

27 अप्रैल को, स्ट्राइक -2019 सम्मेलन में, DevOps अनुभाग के ढांचे के भीतर, "कुबेरनेट्स में ऑटो-स्केलिंग और संसाधन प्रबंधन" शीर्षक से एक रिपोर्ट बनाई गई थी। यह अनुप्रयोगों की उच्च उपलब्धता सुनिश्चित करने और उनके अधिकतम प्रदर्शन को सुनिश्चित करने के लिए K8s का उपयोग करने के बारे में बात करता है।



परंपरा से, हम एक रिपोर्ट (44 मिनट, लेख से बहुत अधिक जानकारीपूर्ण) और पाठ के रूप में मुख्य निचोड़ के साथ एक वीडियो प्रस्तुत करने की कृपा कर रहे हैं। चलो चलते हैं!

हम शब्दों के अनुसार रिपोर्ट के विषय का विश्लेषण करेंगे और अंत से शुरू करेंगे।

Kubernetes

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

इस मामले में कुबेरनेट क्या देता है?

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

संसाधन प्रबंधन

सीपीयू

सर्वर पर nginx, php-fpm और mysql चलाएं। इन सेवाओं में वास्तव में और भी अधिक चलने वाली प्रक्रियाएँ होंगी, जिनमें से प्रत्येक में कंप्यूटिंग संसाधनों की आवश्यकता होती है:


(स्लाइड पर संख्या "तोते हैं," कंप्यूटिंग शक्ति के लिए प्रत्येक प्रक्रिया की सार आवश्यकता है)

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



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



रिपोर्ट के संदर्भ में, हम केवल cgroups में रुचि रखते हैं, क्योंकि नियंत्रण समूह कंटेनरों की कार्यक्षमता का हिस्सा हैं (Docker, आदि) जो संसाधन प्रबंधन को लागू करता है। प्रक्रियाएं, समूहों में एकजुट, जैसा कि हम चाहते थे, नियंत्रण समूह हैं।

आइए हम इन प्रक्रियाओं के लिए सीपीयू आवश्यकताओं पर लौटते हैं, और अब प्रक्रिया समूहों के लिए:


(मैं दोहराता हूं कि सभी संख्याएं संसाधन आवश्यकताओं की एक अमूर्त अभिव्यक्ति हैं)

इसी समय, सीपीयू के पास एक निश्चित अंतिम संसाधन है (उदाहरण में यह 1000 है) , जो सभी के लिए पर्याप्त नहीं हो सकता है (सभी समूहों की जरूरतों का योग 150 + 850 + 460 = 1460) है। इस मामले में क्या होगा?

कर्नेल संसाधनों को वितरित करना शुरू करता है और इसे "ईमानदारी से" करता है, जिससे प्रत्येक समूह को समान मात्रा में संसाधन मिलते हैं। लेकिन पहले मामले में उनमें से अधिक आवश्यक (333> 150) हैं, इसलिए अतिरिक्त (333-150 = 183) आरक्षित में रहता है, जो दो अन्य कंटेनरों के बीच भी समान रूप से वितरित किया जाता है:



परिणामस्वरूप: पहले कंटेनर में पर्याप्त संसाधन थे, दूसरा - पर्याप्त नहीं था, तीसरा - पर्याप्त नहीं था। यह लिनक्स में "ईमानदार" अनुसूचक का परिणाम है - सीएफएस । प्रत्येक कंटेनर में वजन असाइन करके इसका काम नियंत्रित किया जा सकता है। उदाहरण के लिए, इस तरह:



चलो दूसरे कंटेनर (php-fpm) पर संसाधनों की कमी के मामले को देखते हैं। सभी कंटेनर संसाधनों को समान रूप से प्रक्रियाओं के बीच वितरित किया जाता है। नतीजतन, मास्टर प्रक्रिया अच्छी तरह से काम करती है, और सभी श्रमिकों को धीमा हो जाता है, जो आवश्यक है उसका आधे से भी कम प्राप्त होता है:



यह सीएफएस अनुसूचक कैसे काम करता है। वेटर्स जो हम कंटेनरों को असाइन करते हैं, उन्हें भविष्य में अनुरोध कहा जाएगा। ऐसा क्यों - नीचे देखें।

आइए दूसरी तरफ से पूरी स्थिति पर एक नज़र डालें। जैसा कि आप जानते हैं, सभी सड़कें रोम तक जाती हैं, और सीपीयू के लिए कंप्यूटर के मामले में। एक सीपीयू, बहुत सारे कार्य - आपको ट्रैफिक लाइट की आवश्यकता है। संसाधनों को प्रबंधित करने का सबसे आसान तरीका "ट्रैफिक लाइट" है: वे एक प्रक्रिया को सीपीयू, फिर अगले एक, आदि के लिए एक निश्चित पहुंच समय देते हैं।



इस दृष्टिकोण को हार्ड लिमिटिंग कहा जाता है। इसे सीमा के रूप में याद रखें। हालांकि, यदि आप सभी कंटेनरों में सीमाएं वितरित करते हैं, तो एक समस्या उत्पन्न होती है: mysql सड़क पर यात्रा कर रहा था और किसी समय सीपीयू के लिए उसकी आवश्यकता समाप्त हो गई थी, लेकिन सीपीयू के निष्क्रिय होने पर अन्य सभी प्रक्रियाओं को इंतजार करने के लिए मजबूर किया गया था।



चलो लिनक्स कर्नेल और सीपीयू के साथ इसके इंटरैक्शन पर वापस जाते हैं - समग्र चित्र इस प्रकार है:



Cgroup की दो सेटिंग्स हैं - वास्तव में, ये दो सरल "ट्विस्ट" हैं जो आपको निर्धारित करने की अनुमति देते हैं:

1. कंटेनर के लिए वजन (अनुरोध) शेयर है ;
2. कंटेनर कार्यों (सीमा) पर काम करने के लिए कुल सीपीयू समय का एक प्रतिशत कोटा है ।

सीपीयू कैसे मापें?

अलग-अलग तरीके हैं:

1. तोते क्या हैं, कोई नहीं जानता - हर बार आपको सहमत होने की आवश्यकता होती है।
2. ब्याज स्पष्ट है, लेकिन सापेक्ष: 4 कोर और 20 कोर वाले सर्वर का 50% पूरी तरह से अलग चीजें हैं।
3. आप पहले से ही उल्लेखित वज़न का उपयोग कर सकते हैं जो लिनक्स जानता है, लेकिन वे भी रिश्तेदार हैं।
4. सबसे पर्याप्त विकल्प सेकंड में कंप्यूटिंग संसाधनों को मापना है। यानी वास्तविक समय के सेकंड के सापेक्ष प्रोसेसर समय के सेकंड में: उन्होंने 1 वास्तविक समय में प्रोसेसर के 1 सेकंड का समय दिया - यह एक संपूर्ण सीपीयू कोर है।

यह कहना और भी आसान बनाने के लिए, उन्होंने सीधे कोर में मापना शुरू किया, जिसका अर्थ है कि वास्तविक समय के सापेक्ष सीपीयू समय। चूंकि लिनक्स प्रोसेसर समय / कोर के बजाय भार को समझता है, इसलिए एक से दूसरे में अनुवाद तंत्र की आवश्यकता थी।

3 सीपीयू कोर के साथ एक सर्वर के साथ एक सरल उदाहरण पर विचार करें, जहां तीन पॉड वजन (500, 1000 और 1500) का चयन करेंगे जो आसानी से उन्हें आवंटित किए गए कोर के संबंधित भागों (0.5, 1 और 1.5) में परिवर्तित हो जाते हैं।



यदि आप एक दूसरा सर्वर लेते हैं, जहां दो बार कई कोर (6) होंगे, और वहां एक ही फली रखेंगे, तो कोर के वितरण को आसानी से 2 (1, 2 और 3, क्रमशः) से गुणा करके गणना की जा सकती है। लेकिन एक महत्वपूर्ण बिंदु तब होता है जब इस सर्वर पर चौथा पॉड दिखाई देता है, जिसका वजन सुविधा के लिए 3000 हो सकता है। यह सीपीयू संसाधनों (आधे कोर) में से कुछ को दूर ले जाता है, और बाकी पॉड्स उन्हें वापस कर देते हैं (आधा):

कुबेरनेट्स और सीपीयू संसाधन

कुबेरनेट्स में, सीपीयू संसाधनों को आमतौर पर मिली-कोर में मापा जाता है, अर्थात। 0.001 गुठली को आधार वजन के रूप में लिया जाता है। (लिनक्स / cgroups शब्दावली में एक ही चीज़ को CPU शेयर कहा जाता है, हालाँकि, अधिक सटीक होने के लिए, 1000 CPU = 1024 CPU शेयर।) K8s यह सुनिश्चित करता है कि सर्वर पर अधिक पॉड्स न रखें क्योंकि वज़न के योग के लिए CPU संसाधन हैं। सभी फली।

यह कैसा चल रहा है? जब किसी सर्वर को कुबेरनेट क्लस्टर में जोड़ा जाता है, तो यह रिपोर्ट करता है कि कितने CPU कोर इसके लिए उपलब्ध हैं। और एक नई पॉड बनाते समय, कुबेरनेट्स शेड्यूलर को पता है कि इस पॉड को कितने कोर चाहिए। इस प्रकार, पॉड को सर्वर पर परिभाषित किया जाएगा, जहां पर्याप्त कोर हैं।

यदि अनुरोध निर्दिष्ट नहीं किया गया है तो क्या होगा (यानी, फली को इसकी ज़रूरत के अनुसार गुठली की संख्या निर्धारित नहीं करता है)? आइए देखें कि कुबेरनेट आमतौर पर संसाधनों को कैसे गिनते हैं।

फली दोनों अनुरोधों (सीएफएस अनुसूचक) और सीमाएं निर्दिष्ट कर सकती हैं (ट्रैफिक लाइट को याद रखें?):

• यदि वे समान हैं, तो गारंटीकृत क्यूओएस वर्ग को फली को सौंपा गया है। उसके लिए हमेशा उपलब्ध गुठली की इतनी मात्रा की गारंटी होती है।
• यदि अनुरोध सीमा से कम है, तो क्यूओएस वर्ग फटने योग्य है । यानी हम उम्मीद करते हैं कि फली, उदाहरण के लिए, हमेशा 1 कोर का उपयोग करती है, लेकिन यह मान इसके लिए कोई सीमा नहीं है: कभी-कभी फली अधिक उपयोग कर सकते हैं (जब इसके लिए सर्वर पर मुफ्त संसाधन हैं)।
• सबसे अच्छा प्रयास QoS वर्ग भी है - उन पॉड्स जिनके लिए अनुरोध निर्दिष्ट नहीं है, वे इसके हैं। संसाधन उन्हें अंतिम दिए जाते हैं।

स्मृति

स्थिति स्मृति के साथ समान है, लेकिन थोड़ा अलग है - आखिरकार, इन संसाधनों की प्रकृति अलग है। सामान्य तौर पर, सादृश्य इस प्रकार है:



आइए देखें कि मेमोरी में अनुरोधों को कैसे लागू किया जाता है। सर्वर पर पॉड्स को रहने दें, भस्म मेमोरी को बदल दें, जब तक कि उनमें से एक इतना बड़ा न हो जाए कि मेमोरी बाहर निकल जाए। इस मामले में, OOM हत्यारा प्रकट होता है और सबसे बड़ी प्रक्रिया को मारता है:



यह हमेशा हमें सूट नहीं करता है, इसलिए, यह विनियमित करना संभव है कि कौन सी प्रक्रिया हमारे लिए महत्वपूर्ण है और इसे मारना नहीं चाहिए। ऐसा करने के लिए, oom_score_adj पैरामीटर का उपयोग करें।

चलो सीपीयू क्यूओएस कक्षाओं में वापस जाते हैं और ओओएम_स्कोर_एडज मूल्यों के साथ एक सादृश्य आकर्षित करते हैं, जो फली के लिए मेमोरी खपत की प्राथमिकताएं निर्धारित करते हैं:

• एक फली का सबसे कम oom_score_adj मूल्य है -998, जिसका अर्थ है कि ऐसी फली को अंतिम स्थान पर मार दिया जाना चाहिए, यह गारंटी है ।
• उच्चतम - 1000 - सबसे अच्छा प्रयास है , ऐसी फली किसी और से पहले मार दी जाती है।
• बाकी मूल्यों ( फटने योग्य ) की गणना करने के लिए, एक सूत्र है जिसका सार इस तथ्य से उबलता है कि जितना अधिक फली ने संसाधनों का अनुरोध किया है, उतना ही कम मौका मारा जाएगा।

दूसरा "ट्विस्ट" - लिमिट_इन_बाइट्स - लिमिट्स के लिए। इसके साथ सब कुछ सरल है: हम केवल जारी किए जाने के लिए अधिकतम मात्रा में मेमोरी असाइन करते हैं, और यहां (सीपीयू के विपरीत) इसमें कोई सवाल नहीं है कि यह (मेमोरी) क्या मापा जाता है।

कुल मिलाकर

कुबेरनेट्स में प्रत्येक पॉड के लिए अनुरोध और limits निर्धारित की जाती हैं - सीपीयू और मेमोरी के लिए दोनों पैरामीटर:

1. अनुरोधों के आधार पर, कुबेरनेट्स अनुसूचक काम करता है, जो सर्वरों में फली वितरित करता है;
2. सभी मापदंडों के आधार पर, फली का QodS वर्ग निर्धारित किया जाता है;
3. रिश्तेदार वजन सीपीयू अनुरोधों के आधार पर गणना की जाती है;
4. सीपीयू अनुरोधों के आधार पर, एक सीएफएस अनुसूचक कॉन्फ़िगर किया गया है;
5. स्मृति अनुरोधों के आधार पर, OOM हत्यारा कॉन्फ़िगर किया गया है;
6. CPU सीमाओं के आधार पर, "ट्रैफ़िक लाइट" कॉन्फ़िगर किया गया है;
7. मेमोरी सीमा के आधार पर, cgroup पर एक सीमा निर्धारित की जाती है।

सामान्य तौर पर, यह तस्वीर सभी सवालों के जवाब देती है कि कुबेरनेट्स में संसाधन प्रबंधन का मुख्य हिस्सा कैसे होता है।

autoscaling

K8s क्लस्टर-ऑटोस्कोलर

कल्पना करें कि पूरे क्लस्टर पर पहले से ही कब्जा है और एक नया पॉड बनाया जाना चाहिए। जबकि फली दिखाई नहीं दे सकती है, यह लंबित स्थिति में लटका हुआ है। ताकि यह दिखाई दे, हम क्लस्टर के लिए एक नया सर्वर कनेक्ट कर सकते हैं या ... क्लस्टर-ऑटोस्कोलर डाल सकते हैं, जो इसे हमारे लिए करेगा: क्लाउड प्रदाता से एक आभासी मशीन का ऑर्डर करें (एपीआई अनुरोध द्वारा) और इसे क्लस्टर से कनेक्ट करें, जिसके बाद फली को जोड़ा जाएगा; ।



यह कुबेरनेत्स क्लस्टर का ऑटो-स्केलिंग है, जो महान (हमारे अनुभव में) काम करता है। हालाँकि, अन्यत्र भी, यहाँ कुछ बारीकियाँ हैं ...

जब हम क्लस्टर आकार बढ़ा रहे थे, तो सब कुछ ठीक था, लेकिन जब क्लस्टर मुक्त होना शुरू हुआ तो क्या हुआ? समस्या यह है कि संसाधनों की दृष्टि से फली (मेजबान मुक्त करने के लिए) बहुत तकनीकी रूप से कठिन और महंगी है। कुबेरनेट्स का दृष्टिकोण बिल्कुल अलग है।

3 सर्वर के क्लस्टर पर विचार करें जिसमें परिनियोजन है। उसके पास 6 पॉड हैं: अब यह प्रत्येक सर्वर के लिए 2 है। किसी कारण से, हम सर्वरों में से एक को बंद करना चाहते थे। ऐसा करने के लिए, kubectl drain कमांड का उपयोग करें, जो:

• इस सर्वर पर नई पॉड्स भेजने पर रोक;
• सर्वर पर मौजूदा पॉड्स को हटा दें।

चूंकि कुबेरनेट्स फली की संख्या (6) के रखरखाव की निगरानी करते हैं, यह बस उन्हें अन्य नोड्स पर फिर से बनाएगा, लेकिन डिस्कनेक्ट किए गए पर नहीं, क्योंकि यह पहले से ही नई फली रखने के लिए दुर्गम के रूप में चिह्नित है। यह कुबेरनेट्स के लिए मूलभूत यांत्रिकी है।



हालांकि, यहां एक अति सूक्ष्म अंतर है। स्टेटफुलसेट (तैनाती के बजाय) के लिए एक समान स्थिति में कार्रवाई अलग होगी। अब हमारे पास पहले से ही एक स्टेटफुल एप्लिकेशन है - उदाहरण के लिए, MongoDB के साथ तीन पॉड, जिनमें से एक को किसी प्रकार की समस्या थी (डेटा दूषित हो गया या कुछ अन्य त्रुटि पॉड को सही तरीके से शुरू करने से रोकती है)। और फिर से हम एक सर्वर को डिस्कनेक्ट करने का निर्णय लेते हैं। क्या होगा?



MongoDB मर सकता है क्योंकि इसे एक कोरम की जरूरत है: तीन प्रतिष्ठानों के एक क्लस्टर के लिए, कम से कम दो को कार्य करना चाहिए। हालांकि, ऐसा नहीं होता है - पॉडडिस्पिरेशन बायडगेट के लिए धन्यवाद। यह पैरामीटर कार्यशील फली की न्यूनतम आवश्यक संख्या निर्धारित करता है। यह जानते हुए कि MongoDB के साथ पॉड्स में से एक अब काम नहीं कर रहा है, और यह देखते हुए कि PodAisruptionBudget में MongoDB के लिए minAvailable सेट है minAvailable: 2 , Kubernetes आपको पॉड को निकालने नहीं देगा।

निचला रेखा: जब क्लस्टर जारी किया जाता है, तो सही ढंग से (और वास्तव में फिर से बनाना) फली को स्थानांतरित करने के लिए, आपको पॉडिसिपेरियनबीड को कॉन्फ़िगर करना होगा।

क्षैतिज स्केलिंग

एक अलग स्थिति पर विचार करें। Kubernetes में परिनियोजन के रूप में एक एप्लिकेशन चल रहा है। उपयोगकर्ता ट्रैफ़िक इसकी पॉड्स में आता है (उदाहरण के लिए, उनमें से तीन हैं), और हम उनमें एक निश्चित संकेतक मापते हैं (जैसे, सीपीयू लोड)। जब लोड बढ़ता है, तो हम इसे शेड्यूल पर ठीक करते हैं और अनुरोधों को वितरित करने के लिए फली की संख्या बढ़ाते हैं।

कुबेरनेट्स में आज आपको मैन्युअल रूप से ऐसा करने की आवश्यकता नहीं है: आप मापा लोड संकेतकों के मूल्यों के आधार पर फली की संख्या को स्वचालित रूप से बढ़ा / घटा सकते हैं।



यहां मुख्य प्रश्न हैं कि वास्तव में क्या मापें और प्राप्त मूल्यों की व्याख्या कैसे करें (फली की संख्या बदलने पर निर्णय लेने के लिए)। आप बहुत कुछ माप सकते हैं:



इसे तकनीकी रूप से कैसे किया जाए - मेट्रिक्स इकट्ठा करें, आदि। - मैंने मॉनिटरिंग और कुबेरनेट पर रिपोर्ट में विस्तार से बात की। और इष्टतम मापदंडों को चुनने के लिए मुख्य सलाह प्रयोग करना है !

एक USE (यूटिलाइजेशन सैचुरेशन एंड एरर्स ) विधि है , जिसका अर्थ इस प्रकार है। किस आधार पर, यह पैमाने पर समझ में आता है, उदाहरण के लिए, php-fpm? इस तथ्य के आधार पर कि श्रमिक समाप्त हो जाते हैं, यह उपयोग है । और अगर श्रमिक खत्म हो गए हैं और नए कनेक्शन स्वीकार नहीं किए गए हैं - यह संतृप्ति है । इन दोनों मापदंडों को मापने की आवश्यकता है, और मूल्यों के आधार पर, स्केलिंग को बाहर किया जाना चाहिए।

एक निष्कर्ष के बजाय

रिपोर्ट में एक निरंतरता है: ऊर्ध्वाधर स्केलिंग के बारे में और सही संसाधनों का चयन कैसे करें। मैं अपने YouTube पर भविष्य के वीडियो में इस बारे में बात करूंगा - सदस्यता लें, ताकि याद न हो!

वीडियो और स्लाइड

प्रदर्शन से वीडियो (44 मिनट):



रिपोर्ट की प्रस्तुति:

पुनश्च

हमारे ब्लॉग पर अन्य कुबेरनेट रिपोर्ट:

• " विस्तार और पूरक कुबेरनेट्स " (एंड्री पोलोव; 8 अप्रैल, 2019 को सेंट हाईलाड ++) ;
• " डेटाबेस और कुबेरनेट्स " (दिमित्री स्टोलारोव ; 8 नवंबर, 2018 को हाईलाड ++) ;
• " निगरानी और कुबेरनेट्स " (दिमित्री स्टोलारोव ; 28 मई, 2018 रूटकॉन्फ़ पर) ;
• " कुबेरनेट्स और गिटलैब के साथ सर्वश्रेष्ठ सीआई / सीडी अभ्यास " (दिमित्री स्टोलिरोव ; 7 नवंबर, 2017 को हाईलाड ++) ;
• " छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (दिमित्री स्टोलिरोव; 6 जून, 2017 को रूटकॉन्फ़) ।