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

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

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

आइए रिपोर्ट के विषय का शब्दशः विश्लेषण करें और अंत से शुरू करें।

Kubernetes

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

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

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

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

सी पी यू

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

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

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

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

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

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

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

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

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

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

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

सीएफएस शेड्यूलर इस प्रकार काम करता है। हम आगे उन भारों को बुलाएंगे जो हम कंटेनरों को निर्दिष्ट करते हैं अनुरोध. ऐसा क्यों है - आगे देखें.

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

इस दृष्टिकोण को कठिन कोटा कहा जाता है (हार्ड लिमिटिंग). आइए इसे ऐसे ही याद रखें सीमा. हालाँकि, यदि आप सभी कंटेनरों को सीमाएँ वितरित करते हैं, तो एक समस्या उत्पन्न होती है: MySQL सड़क पर गाड़ी चला रहा था और किसी बिंदु पर CPU की आवश्यकता समाप्त हो गई, लेकिन अन्य सभी प्रक्रियाओं को CPU तक प्रतीक्षा करने के लिए मजबूर किया जाता है निठल्ला.

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

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

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

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

भिन्न भिन्न तरीका होता है:

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

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

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

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

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

कुबेरनेट्स में, सीपीयू संसाधनों को आमतौर पर मापा जाता है milliadrax, अर्थात। 0,001 कोर को आधार भार के रूप में लिया जाता है। (लिनक्स/सीग्रुप्स शब्दावली में इसी चीज को सीपीयू शेयर कहा जाता है, हालांकि, अधिक सटीक रूप से, 1000 मिलीकोर्स = 1024 सीपीयू शेयर।) K8s यह सुनिश्चित करता है कि यह सर्वर पर सभी पॉड्स के वजन के योग के लिए सीपीयू संसाधनों की तुलना में अधिक पॉड्स न रखे।

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

क्या होगा अगर नहीं अनुरोध निर्दिष्ट है (अर्थात् पॉड में आवश्यक कोर की निर्धारित संख्या नहीं है)? आइए जानें कि कुबेरनेट्स आम तौर पर संसाधनों की गणना कैसे करता है।

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

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

स्मृति

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

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

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

आइए सीपीयू की क्यूओएस कक्षाओं पर लौटें और oom_score_adj मानों के साथ एक सादृश्य बनाएं जो पॉड्स के लिए मेमोरी खपत प्राथमिकताओं को निर्धारित करते हैं:

• किसी पॉड के लिए सबसे कम oom_score_adj मान - -998 - का मतलब है कि ऐसे पॉड को सबसे अंत में ख़त्म किया जाना चाहिए, यह गारंटी.
• उच्चतम - 1000 - है सबसे अच्छा प्रयास, ऐसे पॉड्स को पहले मार दिया जाता है।
• शेष मानों की गणना करने के लिए (फटने योग्य) एक सूत्र है, जिसका सार इस तथ्य पर आधारित है कि एक पॉड ने जितने अधिक संसाधनों का अनुरोध किया है, उसके मारे जाने की संभावना उतनी ही कम है।

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

कुल मिलाकर

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

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

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

ऑटो स्केलिंग

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

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

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

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

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

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

चूँकि कुबेरनेट्स पॉड्स की संख्या (6) बनाए रखने के लिए ज़िम्मेदार है, यह सरल है पुनः बनायेगा उन्हें अन्य नोड्स पर, लेकिन अक्षम किए जा रहे नोड्स पर नहीं, क्योंकि यह पहले से ही नए पॉड्स की मेजबानी के लिए अनुपलब्ध के रूप में चिह्नित है। यह कुबेरनेट्स के लिए एक मौलिक मैकेनिक है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पुनश्च

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

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

स्रोत: www.habr.com